Hi,

>I agree , may be it's not allowed, but we were forced to do 
>the possibility to change media from 180SDP to 200SDP in 
>order to work with other equipment.

Been there, done that...

Regards,

Christer



> -----Original Message-----
> From: Sweeney, Andrew (Andrew) [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 19, 2007 4:12 PM
> To: Christer Holmberg (JO/LMF); Ira Kadin; Sanjay Sinha 
> (sanjsinh); Miljanovic, Nebojsa (Neb); 
> [email protected]
> 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

Reply via email to