Trying to properly manage interworking with PSTN with early media, and pre-connect free call announcements, I would ask if someone can clarify my doubts.
According to RFC3261: o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. Considering this RFC only, and assuming the SDP offer is within the INVITE request, it is not clear if the SDP answer MUST be present in the 2xx response also in the case the SDP answer has already been provided to the UAC in a provisional response (such as a 183 Session Progress). In case it is mandatory, it appears the UAC must ignore the "duplicated" answers, behaving as they are missing. When using PRACK, it is not clear if provisional responses may be considered as a "reliable non-failure message" in the sense reported above. If so, it appears the UAS would no longer be needed to put the "duplicated" answer in the 2xx response. Is my assumption correct? Finally, things get more complex when media changes before 200 OK by using the UPDATE method. Consider the following sequence: INVITE (SDP Offer A) -> <- 183 Session progress (SDP Answer A) PRACK -> <- 200 PRACK <- UPDATE (SDP Offer B) 200 UPDATE (SDP Answer B) -> <- 200 INVITE (SDP ???) -> ACK (SDP ???) This is a quite common scenario to manage free call announcements before 3PCC-based redirection to the final destination. In this case, I'd like to understand if the SDP in the 200 response to the INVITE is mandatory or not, and if it is, how the SDP has to be filled and how the UAC has to consider this new SDP (a new offer, or ignore it as RFC3261 says for the basic scenario? Regards Andrea _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
