Hi, >"Fake forking" is allowed because normal forking is allowed. >It is completely valid SIP but you might have to be a bit >clever to handle the forked leg. > >Handling the change in streams between 180 and 200 does seem >to work for a lot of UA's (including ours) but it is still >not technically valid SIP. > >RFC3261 says: >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.
I believe that is meant to be per dialog. >Now, I don't know why the 2xx response's SDP should be ignored. >Maybe someone can think of a scenario where not ignoring the >2xx SDP would cause an error. ?? If you have already received SDP on the same dialog as the 200 SDP, and you are listening to the media associated to that dialog, it should not cause an error - assuming the sender of the SDP behaves correctly. Regards, Christer > > > -----Original Message----- > From: [EMAIL PROTECTED] on > behalf of Sweeney, Andrew (Andrew) > Sent: Mon 19/02/2007 14:11 > To: Christer Holmberg (JO/LMF); Ira Kadin; Sanjay Sinha > (sanjsinh); Miljanovic, Nebojsa (Neb); > [email protected] > Cc: > Subject: Re: [Sip-implementors] SDP in 2xx response > after reliable 18x > > > > Why is "Fake Forking" OK to do? What is the issue that > the SDP can only > be changed during "Fake Forking" and if this is > acceptable then it seems > that changing streams between 18x and 200 should be OK as well. > > The overhead in handling a "Fake Forking" case seems to > be unnecessary > and can affect call performance. > > Seems like a lot of older devices still allow the > change of the SDP. I > think Broadsoft pre rel 14 does it this way. > > Thanks > Andy > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Christer > Holmberg (JO/LMF) > Sent: Thursday, February 15, 2007 7:06 AM > To: Ira Kadin; Sanjay Sinha (sanjsinh); Miljanovic, > Nebojsa (Neb); > [email protected] > Subject: Re: [Sip-implementors] SDP in 2xx response > after reliable 18x > > > Hi, > > >It can be the situation when the call originally is connected > >to some media announcement server (connected - meaning > >getting RTP, for example to play ringback), than - to the > >final user. In that case the UAC has to switch from the media > >in 18x SDP to the media in 200 SDP > > It is not allowed, for the same dialog. > > But, in your use-case you can use "fake forking" (see > separte thread), > and use different To tags in the 18x and 200. Then the > 18x (tag=x) can > be used for the announcement, and 200 (tag=y) be used > for the UAS. > > Regards, > > Christer > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Sanjay Sinha (sanjsinh) > > Sent: Wednesday, February 14, 2007 8:37 PM > > To: Nebojsa Miljanovic; [email protected] > > Subject: Re: [Sip-implementors] SDP in 2xx response > after reliable 18x > > > > > > Option 2 does not seem correct. Option 1 is correct and you > > may also want to ignore the sdp in 200 OK, just treat it as > > if there was no sdp in 200 OK. > > > > Sanjay > > > > >-----Original Message----- > > >From: [EMAIL PROTECTED] > > >[mailto:[EMAIL PROTECTED] On Behalf > > Of Nebojsa > > >Miljanovic > > >Sent: Wednesday, February 14, 2007 12:30 PM > > >To: [email protected] > > >Subject: [Sip-implementors] SDP in 2xx response > after reliable 18x > > > > > >Trying to get a feel on how various developers > interpret RFCs 3261, > > >3262 and 3264. > > > > > >If you are acting as an UAC and you have received SDP in > > reliable 18x > > >response (i.e. PRACK was used), and then again that same SDP > > comes in > > >2xx, what will you do? > > > > > >1. Verify that 18x and 2xx SDPs are the same and accept it. > > > > > >2. Tear down the call since you consider SDP in 2xx > as an invalid > > >Offer. > > > > > > > > >Also, do you know of any UAs that require 2xx to contain SDP > > even after > > >Offer/Answer was done with 183/PRACK. > > > > > >Thanks. > > > > > > > > > > > > > > >_______________________________________________ > > >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 > > _______________________________________________ > 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
