I will concur with Jeroen here.
But first, your original question cited rules relative to reliable
provisional responses, but your call flow shows the use of unreliable
provisionals.
The issues here aren't that different in the two cases. Even with
unreliable provisionals there will be problems with the two different
answers that are unrelated.
There aren't a lot of rules for B2BUAs other than that they behave like
a UA. In this case it might be useful to think of this as a forking
proxy that forks to a separate B2BUA for each alternative. Each B2BUA
assigns a unique to-tag for its responses to the caller. Then you simply
optimize out the extra Via headers because the proxy and the B2BUAs are
collocated.
Paul
Jeroen van Bemmel wrote:
> Hi Vivek,
>
> Yes, that *can be* a function of a B2BUA. Whether or not it is a requirement
> here is unclear, Umesh did not share those details. Since his call flow was
> showing forwarded 180s from multiple callee's, I assumed that forking
> transparency was not required.
>
> It is also still unclear what requirement makes it a B2BUA instead of a
> proxy
>
> Regards,
> Jeroen
>
> Vivek Gupta wrote:
>> Hi Jeroen
>>
>> Looking at your comment, I have a doubt.
>>
>> Being a B2BUA, the ingress leg and egress leg are completed
>> independent where the incoming call is terminated on B2BUA and a new
>> call is initiated on the egress leg.
>> So the forking on the egress leg shouldn't be transparent on the
>> ingress leg.
>>
>> With regards
>> Vivek Gupta
>>
>> Jeroen van Bemmel wrote:
>>> Umesh,
>>>
>>> 180(SDP2) and 180(SDP3) should have different to-tags, so for the
>>> CALLER they are two distinct dialogs. Forwarding 180(SDP3) would not
>>> be a refresh, but an initial answer for a second dialog. Your B2BUA
>>> can safely forward 180(SDP3)
>>>
>>> A different question is whether the CALLER UA properly supports
>>> responses from multiple callees. If not, your B2BUA will have to do
>>> the honors: hold the SDP until a 2xx response is received (forward
>>> ringing responses from a single callee, stripping the SDP body),
>>> then continue with the dialog that succeeds. There are limits to
>>> this solution however, it gets complicated when 100rel is used for
>>> example. Better to take a proper caller UA Regards,
>>> Jeroen
>>>
>>> Umesh wrote:
>>>
>>>> Hello All,
>>>> We have a B2BUA server which needs to support a particular
>>>> call flow.
>>>> The initial set up call flow is as shown
>>>>
>>>>
>>>> CALLER B2BUA CALLEE1
>>>> CALLEE2
>>>>
>>>>> --------INVITE(SDP1)-->| | |
>>>>>
>>>>> |-------INVITE(SDP1)--->| |
>>>>> |<--------180(SDP2)-----| |
>>>>> <-------180(SDP2) -----| | |
>>>>> |<---------4xx ---------| |
>>>>> |----------ACK----------| |
>>>>> |-------INVITE(SDP1)------------------->|
>>>>> |<------180(SDP3)-----------------------|
>>>>> | |
>>>>>
>>>> The flow here is of sequential routing wherein if one user is not
>>>> responding then the next number configured has to be tried until one
>>>> person answers. But as you can see the issue with the flow is that
>>>> the 180 with SDP3 cannot be forwarded to the caller directly.
>>>> As per rules of RFC 3261,3262 as I understand when a reliable
>>>> provisional response contains a session description, and is the
>>>> first to do so, then that session description is the answer to the
>>>> offer in the INVITE request. SDP should not be included in the
>>>> subsequent 1xx-rel once offer/answer has been completed.
>>>>
>>>> Due to this we cannot refresh the SDP to the caller. Even use of
>>>> UPDATE would result in a race condition.
>>>>
>>>> Please let me know if there is a solution to update the SDP( SDP3)
>>>> on the caller side. Is there any other way of handling this
>>>> situation? Thanks and Regards,
>>>> Umesh
>>>>
>>>>
>>>> ****************************************************************************
>>>> ***********
>>>> This e-mail and attachments contain confidential information from
>>>> HUAWEI, which is intended only for the person or entity whose
>>>> address is listed above. Any use of the information contained
>>>> herein in any way (including, but not limited to, total or partial
>>>> disclosure, reproduction, or dissemination) by persons other than
>>>> the intended recipient's) is prohibited. If you receive this e-mail
>>>> in error, please notify the sender by phone or email immediately
>>>> and delete it! _______________________________________________
>>>> 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
