I agree with this comment.
The trouble with defining "transparent B2BUA" is defining "how
transparent". If it were entirely transparent it would be a proxy. If it
is doing anything that a proxy can't do then it is necessarily at least
somewhat opaque. This means that it must assess whether the things it
does have some impact on each option. In many cases it may indeed be
proper to forward a "Supported" option. But each one must be judged
separately. If the B2BUA doesn't understand an option then it can't make
a judgment whether it is safe to forward it or not. If it does forward
it, then it may have made a promise it cannot keep. This is one of the
major weaknesses of B2BUAs.
Paul
Ivar wrote:
> Hi,
>
> draft-marjou-sipping-b2bua-00
> If a SIP INVITE message sent by Alice indicates some supported
> extensions (e.g. 100rel), it is important that the B2BUA forward
> these extensions in the SIP INVITE message sent to Bob. Otherwise,
> the two users will never be able to use these SIP extensions.
>
> I can get from there that Supported must be forwarded, isn't it illegal.
> For example UA1 has some xxx feature what B2BUA won't support, now B2BUA
> forwards it to UA2, UA2 requires to handle it but B2BUA don't know how.
>
> I think B2BUA must always generate it's own Supported: with value what
> it supports or i miss something ?
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
