Alex Balashov wrote:
> Paul Kyzivat wrote:
>
>> Alex,
>>
>> If I understand you, you are arguing that either:
>> - proxies shouldn't fork at all, or
>> - proxies should violate 3261 by not forwarding
>> some provisional responses when forking.
>>
>> In the description, the proxy is acting exactly as it should. And it has
>> no way of knowing its UAC is actually a B2BUA, nor should it.
>>
>> It is the B2BUA that carries the burden of behaving correctly. The rules
>> for B2BUAs are very simple in 3261 - such a thing must behave correctly
>> as a UAC and as a UAS. What it does in between is its business, but it
>> must satisfy that simple rule. B2BUAs have much potential to mess things
>> up - it is there responsibility to not create a mess.
>
> You're right. My argument was more philosophical, when it should have
> been more about what would constitute a valid interpretation of the
> existing specifications, which is what this list is about. This is
> SIP-Implementors, not Alex's Editorial SIP Prescriptions :-)
>
> The problem is that 183+SDP is not an "ordinary" provisional response
> because it has the potential to enact media flow, not just provide an
> indication of a far-end action and/or establish a formal early dialog.
>
> But no, no real argument there. It's up to the B2BUA to behave more or
> less "transparently" by making decisions about this condition in the
> plumbing between the UAS and UAC side. It's just that I wonder how this
> would be viewed differently if no B2BUA were involved and the
> originating UAC simply called through a forking proxy that sent it back
> two 183s with different SDP information. I would think that the rule
> would be to capture the SDP offer in the first 183 as the winner and
> ignore the other one, so presumably it is reasonable for the B2BUA to do
> the same on the sending UAC's behalf.
>
> To return to Iñaki's original question, though; I think that one
> explanation for why the B2BUA "generates a 183 response in leg_A for
> each 183 in leg_B, but it uses an *unique and same* To_tag in both 183
> responses in leg_A (but they have different SDP)" is that the
> implementors interpreted RFC 3261 13.3.1.1:
>
> "A UAS MAY send as many provisional responses as it likes. Each of
> these MUST indicate the same dialog ID."
>
> ... to mean that under no circumstances should the UAS side of the B2BUA
> deviate from the original tags present in the dialog between the sending
> UAC and the UAS side of the B2BUA.
I don't interpret it that way. Just because you have one *box* doesn't
mean you only have one UAS. In this case I would consider that you
logically have multiple UASs, each processing one leg of the call.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
