Hi Paul,
I think your suggestion of including the value in Allow header only if
it's received from other side, is the best solution considering the
following constraints:
1) Since the call is in early dialog, translating the UPDATE to Re-INVITE on
the other leg would result in failure of the UPDATE request.
2) My B2BUA does not support transcoding.
Thanks,
Jagan
On 8/20/08, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
>
>
> Jagan Mohan wrote:
>
>> Hi All,
>>
>> I would like to know whether a B2BUA can insert the SIP Methods it
>> support in the Allow header, when a SIP call is made between two UAs
>> through
>> the B2BUA.
>>
>
> There are *no* rules for B2BUAs, other than that each *side* must behave
> correctly as a UA. There are no rules for how the two sides are correlated.
>
> So the B2BUA can put anything it likes into the Allow header, as long as it
> truly does allow it.
>
> BUT, if the B2BUA can only allow it when the other side allows it (which
> depends on the relationship that the B2BUA establishes between the two
> sides), then it ought only include the value in Allow if it receives it from
> the other side.
>
> If yes, then I have query on the following call flow:
>>
>> UAC ---- B2BUA ---- UAS.
>>
>> Say, UAC and B2BUA support UPDATE method. And UAS does not support
>> UPDATE method.
>>
>> If an UPDATE request for codec change is received from UAC within an
>> early dialog, then what should be the Error response from B2BUA? Here,
>> B2BUA
>> is aware that UAS does not support UPDATE method from the reliable
>> provisional response. So, it should not forward the UPDATE request to the
>> UAS.
>>
>
> The B2BUA need not match messages 1:1 on the two sides. If it is
> sufficiently clever, it may be able to create some valid signaling on the
> other side to make things work. E.g. it might send a reINVITE toward the
> UAS.
>
> Or, if the B2BUA is also processes/relays the media, it may just handle the
> UPDATE locally, and start transcoding to the format(s) negotiated with the
> UAS.
>
> It sounds like you want your B2BUA to act like a proxy. If so, then why not
> just let it *be* a proxy?
>
> Thanks,
> Paul
>
> Thanks,
>> Jagan
>> _______________________________________________
>> 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
