>>Also, different SDP in 200 OK will be considered as new offer only when >>offer-answer is done previously through reliable 18X response.
No, the SDP in the 200 OK should be ignored in this case. Once an INVITE's offer/answer has been completed there cannot be another offer/answer for that INVITE transaction. Have a look at Figure 1: Example of Offer/Answer with 100rel Extension (1) in http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-13 You can see that once the INV/18x/PRACK/200(of PRACK) is completed, the offer/answer has been completed. Any subsequcent 18x or 200 in the INVITE transaction should not contain any SDP. regards Attila -----Original Message----- From: ashok kumar [mailto:ash....@gmail.com] Sent: Fri 11/03/2011 09:57 To: Jaiswal, Sanjiv (NSN - IN/Bangalore) Cc: Attila Sipos; sip-implementors@lists.cs.columbia.edu; Nitin Kapoor Subject: Re: [Sip-implementors] Different SDP Session Version in 183 & 200 OK Hi Sanjiv, You are talking about the positive scenario. And moreover what you are saying is correct only when 183 is a reliable response (RFC wise). Also, different SDP in 200 OK will be considered as new offer only when offer-answer is done previously through reliable 18X response. There could be different scenarios (error scenarios) and what Attila says is correct because it's largely implementation dependent. I agree with the Attila's response. Thanks, Ashok On Fri, Mar 11, 2011 at 2:50 PM, Jaiswal, Sanjiv (NSN - IN/Bangalore) < sanjiv.jais...@nsn.com> wrote: > Hi Ashok, > > The SDP from 183 is considered as Answer of initial offer. > Different SDP in 200 OK is considered as new offer and then it is must > to send the ACK with SDP answer for second negotiation to successful. > > Regards > Sanjiv > > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext > ashok kumar > Sent: Friday, March 11, 2011 1:58 PM > To: Attila Sipos > Cc: sip-implementors@lists.cs.columbia.edu; Nitin Kapoor > Subject: Re: [Sip-implementors] Different SDP Session Version in 183 & > 200 OK > > Hi Attila, > > Agree with you but what happens when 183 and 200 OK have different SDPs > from > the terminating endpoint. Then which SDP should be considered as an > answer. > RFC 3261 does not talk about this. And in case of Nitin's scenario, SDPs > are > different since session version is incremented (though all other > contents > remain same). > > Only when the same answer is placed in 18X and 200 then only the SDP in > 18X > will be considered as an answer. > > Please correct me if I'm wrong. > > Thanks, > Ashok > > > On Wed, Mar 9, 2011 at 7:40 PM, Attila Sipos > <attila.si...@vegastream.com>wrote: > > > 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: sip-implementors-boun...@lists.cs.columbia.edu > > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > > ashok kumar > > Sent: 09 March 2011 13:19 > > To: Nitin Kapoor > > Cc: sip-implementors@lists.cs.columbia.edu > > 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 <nitinkapo...@gmail.com> > > 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 > > > Sip-implementors@lists.cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
