You cannot use scenario 4 and scenario 2 in the same INVITE. Scenario 2 can only be used as the initial offer/answer (for a new session) or for an established session (i.e. a re-INVITE). There can be only one offer/answer in a single INVITE transaction. There can be a second offer/answer exchange on an early dialog (i.e. before the 200 on the INVITE), but that second offer/answer must be in a PRACK (scenario 5) or UPDATE (scenario 6) and only when the initial answer delivered in a reliable provisional response (scenario 3).
As to the original question, the UAS is not behaving correctly since the SDP in the 200 OK does not exactly match the SDP in the 183 (assuming they have are for the same dialog and thus have the same to-tag). However, in this particular case, since only the session version has changed, the UAC can be forgiving and accept it. If it is your UAS implementation, you should fix it to send identical SDP. Having dealt with a variety of misbehaving UAS implementations for nearly 10 years, I have found that it is always best for the UAC to honor the SDP in the 200OK even if it does not match the 18x because that is usually what the UAS is expecting. Especially when the 18x is not reliable. I realize that this is against the RFCs, but the call almost always works and the alternative is to fail every call with that particular UA. Be conservative/strict in what you send and liberal in what you accept. cheers, (-:bob -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Attila Sipos Sent: Wednesday, March 09, 2011 9:10 AM To: ashok kumar; Nitin Kapoor Cc: [email protected] Subject: Re: [Sip-implementors] Different SDP Session Version in 183 & 200 OK There is a draft which tries to clarify what is legal. http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-13 Offer Answer RFC Ini Est Early ------------------------------------------------------------------- 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N 5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y Table 1: Summary of SIP Usage of the Offer/Answer Model According to Table 1 it seems that you could be allowed scenario 4 followed by scenario 2. Nitin, if you are sending SDP with your INVITE then obviously you can't have 4 followed by 2. Ashok said: >>In this case, the answer must be in the reliable non-failure message from the >>terminating endpoint which is 200 OK from the terminating endpoint in your case. >>so SDP answer in 183 Session Progress should be ignored. No, the SDP answer in the 183 should not be ignored. The extract from 3261 says that the answer MUST be in the 200 OK. It also says (as you quoted): That same exact answer MAY also be placed in any provisional responses sent prior to the answer. And... 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. So if it receives the 18x with SDP as an answer then it MUST ignore any SDP in the 200 OK. Regards Attila -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ashok kumar Sent: 09 March 2011 13:19 To: Nitin Kapoor Cc: [email protected] Subject: Re: [Sip-implementors] Different SDP Session Version in 183 & 200 OK Hi Nitin, I did not get to know the complete call flow which you are trying to do. However, there could be two possibilities: 1> 183 Session Progress is reliable provisional response (PRACK 1> procedure) If this is the case then the 200 OK from the termination contains the new offer in your case because the session version is incremented. But If I see the contents of the 183 Session Progress and 200 OK then all the session description remains same which means terminating endpoint is not trying to modify any aspects of the session and hence no need to increment the session version. See below the excerpts from rfc 3264: " Nearly all aspects of the session can be modified. New streams can be added, existing streams can be deleted, and parameters of existing streams can change. When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section 6. " 2> 183 Session Progress is non-reliable provisional response In this case, the answer must be in the reliable non-failure message from the terminating endpoint which is 200 OK from the terminating endpoint in your case. so SDP answer in 183 Session Progress should be ignored. But having said that there is a bit confusion in what rfc 3261 says: " 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." Hope it helps you. Thanks, Ashok On Wed, Mar 9, 2011 at 3:18 AM, Nitin Kapoor <[email protected]> wrote: > Dear All, > > I have one call scenario where my termination is sending the SDP in > 183 as well as in 200 OK also. As far as i know if we are getting SDP > in 183 session progress then my UAC can ignore the SDP in 200 OK. Also > most of the time SDP is same. > > But here i noticed the slight difference of "Session Version". Here > when my termination is sending 188 Session Progress with SDP is > sending the SDP as below. > > I can see that my Termination is incrementing "*Session Version*" > for SDP in 183 & 200 OK in same dialog.. > > *183 with SDP* > > S_OWNER : o=TLPMSXP2 22660 *22660* IN IP4 69.90.230.210 S_NAME : s=sip > call S_CONNECT : c=IN IP4 69.90.230.217 TIME : t=0 0 M_NAME : m=audio > 59072 RTP/AVP 18 4 8 98 > > 200 OK with SDP: > > S_OWNER : o=TLPMSXP2 22660 *22661* IN IP4 69.90.230.210 S_NAME : s=sip > call S_CONNECT : c=IN IP4 69.90.230.217 TIME : t=0 0 > > Could anyone please let me know if that is okay to increment the > session version and if any supported document is there? > > Thanks, > Nitin > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
