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
