Dale's "in practice" discussion is a good one. It seems that most times
when people ask about B2BUAs that is what they are thinking of.
There are however lots of other things that are also in some sense
B2BUAs - in fact more kosher flavors. For instance:
- a conference focus
- some implementations of 3pcc call controllers
(i.e. "click to dial") (But there are ways to
do this without a B2BUA)
- a Resource List Server (RLS) that explodes subscriptions
and messages to buddy lists
IMO there is a key distinction between cases where the B2BUA is the
intended destination of a request, and cases where the intended
destination is elsewhere and the B2BUA insinuates itself in the middle.
Paul
[EMAIL PROTECTED] wrote:
> From: "Bill Lo" <[EMAIL PROTECTED]>
>
> Can someone direct me to a document that clearly outlines the
> differences between a SIP Proxy and a B2BUA. While RFC 3261
> outlines a proxy, the B2BUA is still a bit vague. How and why
> would I use a B2BUA?
>
> The rules for proxies are set out in RFC 3261. Or as I would say, you
> can be a proxy if you can make it look like you're following the rules
> in RFC 3261, which somewhat enlarges what the agent can do.
>
> My personal opinion is that since "back-to-back user agent" is a
> phrase made up of words with set meanings, the meaning of the phrase
> is fixed: a device which consists of two SIP user agents which
> communicate with each other strictly at the application level. That
> is, none of the protocol details on one side are visible on the other,
> only actions that would be visible in a real user interface of a SIP
> UA. In particular, the SIP features that could be used when talking
> SIP to one side of the device do not depend on those features being
> implemented by the SIP UA talking to the other side of the device.
>
> In practice, people use the term B2BUA to describe any SIP transducing
> agent which violates the rules for proxies. Often it intercepts media
> traffic and sometimes transcodes it. SIP requests on one side are
> rarely actually terminated at the B2BUA, but are heavily edited and
> passed through to the other side to be implemented. Usually such
> devices aren't very extensible, and can only support SIP oerations
> that were taken into account when the device was designed.
>
> Dale
> _______________________________________________
> 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
