"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.
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. ??
Regards,
Attila
http://www.vegastream.com
-----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
