Hi,
>>Fake forking is away to get around that, by using separate dialogs (To
>>tag values).
>>
>Why are we calling it "fake" forking? The UAC obviously can not tell
whether it is fake or not. The B2BUA black-box which
>is doing this so called "fake" forking will anyway have to act as if
the INVITE was forked by a proxy to two UASs
>(18X/tag=x and 2XX/tag=y) for all intents and purposes.
You can call it whatever you wnat, but I think it's good to call it
something so that we know what we're talking about. Someone started to
use "fake", so...
>So, apart from the person who knows how the B2BUA is implemented,
nobody else knows that this is "fake" forking. Is there
>any difference between fake and real forking from protocol perspective?
No.
Regards,
Christer
> -----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
<https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors>
> > >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [email protected]
<mailto:[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
<https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
