Andreas Byström wrote:
> Thanks Bala and Paul,
>
> I have looked for this issue in the latest months in the archive but didn’t
> find anything about it (I will dig deeper to see earlier queries in this
> matter).
>
> I can understand that A will get two sessions (one to A and one to B). Now
> to spice up the case a bit I will change the proxy to a B2BUA (which I'm
> responsible over). Im very sorry that it was not clear in the first mail,
> basicly I was just looking for a scenario and it was not until I saw your
> answer that I understood that B2BUA or proxy makes a big differnece in this
> case
>
> So...
> * A sends invite to B2BUA
> * B2B forks the call to B and C
> * B answers with 183 with SDP
The B2BUA sends the SDP from B in a 183 to A?
The B2BUA must choose its own tag to use in this 183.
> * C sends 180 with no SDP
Do you want the B2BUA to send a corresponding 183 to A?
If so, it must again choose a tag. If it wants to play like a proxy then
it will send the 183 with a different tag than it used in the prior 183.
Or it could keep this 183 to itself since it doesn't contain any useful
information for A.
> * C sends 200 OK with SDP
> (* B2BUA cancel call to C)
YOu mean sends a cancel to B, right?
Now the B2BUA must send a 200 to A. Because a B2BUA is a UA, it must
follow all the rules for UAs.
Again it must choose which tag to use in this response. If it has wanted
to use only one session with A, then it will use the same tag it used
for the 183 relayed from B. In that case, because it is the same dialog,
it must follow the O/A rules. But if the earlier 183 was unreliable,
then the O/A rules say that the SDP in the 200 must be the same. So the
SDP from C can't be sent this way.
(If the earlier 183 was reliable, then the B2BUA could send a new SDP to
A in an UPDATE. This will require the B2BUA to keep track of the sdp for
all time and keep managing the o-line. There are other consistency
requirements for the sdp (concerning mapping of payload numbers to
codecs) that in general make this impossible to do without terminating
and reoriginating the media.)
Alternately, the B2BUA can act more like a proxy. It can send the sdp
from C using a different tag from that used for the sdp from B. In that
case A will see these as two sessions and the O/A rules for the two are
independent.
> Now A has only one session, and that session is with B2BUA.
Not necessarily. See above.
> What A does with
> the SDP(bsdp) sent from B2BUA to A in a 200 OK I have to read about in 3264
> but if I remember correctly it will just ignore it (will do some reading and
> get back if I find some other actions). Maybe it does also matter if the SDP
> is in a reliable provisinal response or not? Anyway, my guess is that B2BUA
> needs, when it gets 200 OK from B:
> - send first the 200 OK (with bsdp) to A
> - Send a empty reInvite to A
> - get 200 OK with a'sdp
> - send reInvite to B with a'sdp
> - get 200 OK from B with b'sdp
> - send ACK to B
> - send ACK to A with b' sdp
I've gotten lost in your scenario. Try again after reading the above.
The bottom line is that a B2BUA really can't mix SDP from two sources
into one session unless it terminates and reoriginates the media. If it
doesn't want to do that it must switch session to A in order to switch
the SDP.
In the case of an initial invite it can establish the multiple sessions
in parallel using different tags. Or it can switch the sessions serially
by sending an INVITE/Replaces to A.
Paul
> That will do the trick, will it? Maybe it is also possible to use UPDATE in
> some way
>
> // Andreas
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of Paul Kyzivat
>> Sent: Thursday, September 13, 2007 8:26 PM
>> To: [EMAIL PROTECTED]
>> Cc: 'Andreas Byström'; [email protected]
>> Subject: Re: [Sip-implementors] Early media and forking calls
>>
>>
>> When you get the 200 from C you can assume that the proxy
>> sent a CANCEL
>> to B. But you cannot assume the CANCEL will work. It is still
>> possible
>> to receive a 200 from B. You need to be prepared to handle that case
>> too. (The usual thing to do is send a BYE on the dialog of any
>> subsequent 200 responses.)
>>
>> Paul
>>
>> Bala Neelakantan wrote:
>>>> -----Original Message-----
>>>> From: [EMAIL PROTECTED] [mailto:sip-
>>>> [EMAIL PROTECTED] On Behalf Of Andreas
>>>> Byström
>>>> Sent: Thursday, September 13, 2007 9:48 AM
>>>> To: [email protected]
>>>> Subject: [Sip-implementors] Early media and forking calls
>>>>
>>>> Hi everyone,
>>>>
>>>> I'm working with a case that involves a call from A that a proxy
>>>> forks to B and C. I see a potential problem when the following
>>>> happens:
>>>> * A sends SDP offer
>>>> <proxy forks the call to B and C>
>>>> * B answers with a 183 including a sdp answer
>>> Please refer to RFC 3264 as it describes the offer/answer
>> scenarios.
>>> Also this issue has been discussed in the Sip-implementors list a
>>> number of times, and you will learn a lot by reading through them.
>>>
>>> So, 183 from B will create a dialog.
>>>
>>>> * C sends 180 with no spd
>>> This 180 response is another dialog and A should be
>> prepared to handle
>>> this dialog. At this point, the final response (200 OK) could be
>>> coming from B or C.
>>>
>>>> * C answers the call first, which means C sends a sdp
>> response in the
>>>> 200 OK.
>>>>
>>> In this scenario, the call is established between A and C.
>> Typically
>>> the proxy will CANCEL the forked call to B.
>>>
>>>> I have tried to find info on this but have failed to do
>> so. So I was
>>>> thinking that someone on this forum have already been facing a
>>>> scenario like this, or maybe know where I can find info on how to
>>>> solve it in a way that dont violate specs (and also works
>> of course)
>>> Please refer to the mailing list archives.
>>>
>>>> How should A handle this (it already got a sdp answer on
>> the offer)?
>>>> Does A or proxy have to start a renegotiation with C?
>>> I think your question is how should A handle the answer it received
>>> already from B? The proxy CANCELs the call to B.
>>>
>>> When the C comes back with 200 OK with SDP, that is going
>> to be used.
>>>> Should A see in the tag that this is a respone from
>> another UA then
>>>> from where it did get the first spd answer (the on in 183
>> sent from
>>>> B) and therefore accept it?
>>> That could be bad implementation choice.
>>>
>>>> Proxy needs to send a cancel to B when it sees that C is replying
>>>> wiht 200 OK. Does the proxy also need to say something to A to
>>>> terminate the media session already set up between A and B?
>>> Proxy doesn’t tell anything about media/SDP. It is between
>> endpoints.
>>>
>>>> Thanks in advance
>>>> // Andreas
>>> Thanks,
>>> Neel.
>>>
>>>> _______________________________
>>>>
>>>> Andreas Byström
>>>> Software Engineer
>>>>
>>>> Teligent AB
>>>> Konsul Jonssons väg 17
>>>> P.O. Box 213
>>>> SE 14923 Nynäshamn
>>>>
>>>> mail: [EMAIL PROTECTED]
>>>> web: www.teligent.se <http://www.teligent.se/>
>>>> phone: +46 (0)8 4101 7221
>>>> mobile: +46 (0)733 1172 21
>>>> fax: +46 (0)8 520 193 36
>>>> _______________________________
>>>>
>>>> _______________________________________________
>>>> 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
