Hi Attila, Take for example the early media is established with invite/18x/PRACK/200k(of PRACK). Now announcement is played and after that if endpoint want to change the media( for established dialog) then as per you mention , end point has to send update with change media stream. And Sending 200 OK (new offer ) and ACK (SDP ) doesn't make any difference. Is this correct? Regards Sanjiv
________________________________ From: ext Attila Sipos [mailto:attila.si...@vegastream.com] Sent: Friday, March 11, 2011 3:18 PM To: Jaiswal, Sanjiv (NSN - IN/Bangalore); ext ashok kumar Cc: sip-implementors@lists.cs.columbia.edu; Nitin Kapoor Subject: RE: [Sip-implementors] Different SDP Session Version in 183 & 200 OK Hi Sanjiv, The behaviour you describe is not permitted. As Bob Penfield correctly said: 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). Best Regards Attila -----Original Message----- From: Jaiswal, Sanjiv (NSN - IN/Bangalore) [mailto:sanjiv.jais...@nsn.com] Sent: Fri 11/03/2011 09:20 To: ext ashok kumar; Attila Sipos Cc: sip-implementors@lists.cs.columbia.edu; Nitin Kapoor Subject: RE: [Sip-implementors] Different SDP Session Version in 183 & 200 OK 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
