As Paul said, there are different types of usages for a B2BUA:
- a basic intermediary (that "only" relays SIP messages between UA A and UA B)
- a conference focus server,
- a message exploder server
I'll discuss only the first type: a basic SIP intermediary
> differences between a SIP Proxy and a B2BUA
According to RFC3261:
A SIP Proxy keeps a single SIP dialog (ie: same Call-Id, from-tag,
to-tag) between a UA A and a UA B, and routes the SIP message nearly
unchanged (in particular unknown headers).
A SIP B2BUA creates a 2nd SIP dialog (ie: new Call-ID, from-tag and
to-tag), and can modify any information within the SIP message when
routing it towards a remote UA.
> How and why would I use a B2BUA?
If possible, you should avoid B2BUA. However, there are some SIP
intermediaries that need to locally implement features like: hiding
the user-identity, hiding topology modifying a body, terminating
established dialog(s) or establishing 3rd-party call control with 2
INVITE (rfc3725). This is not feasible with a behavior of SIP 3261
Proxy. To circumvent this, 2 non-specified alternatives exist:
- A) to implement a behavior of "extended" proxy behavior that breaks
some few rules of RFC3261 like "a proxy must not modify a SIP body".
- B) to implement a behavior of B2BUA. This does not seem to break any
rule in term of SIP element behavior (RFC3261 only says that a B2BUA
is a UAS||UAC). However, note that a B2BUA can potentially break any
existing SIP extension between a UA A and a UA B if not carefully
implemented. A careful implementation should lead to a more or less
"transparent" B2BUA.
I personally prefer option A ("extended" proxy), which is more elegant
(eg: when tracing a SIP "call" between A and B with Ethereal).
However, several products implement option B ("transparent" b2bua). As
there is clearly a need for a best-practices document on this
category, I've started writing a draft on "transparent" B2BUA; I plan
to send it to the IETF sipping mailing list at the beginning of
February.
Of course, the difference between A) and B) is very week. As there is
no specification dealing on this, one could even argue that a
"transparent" B2BUA should keep the same dialog instead of creating a
2nd one.
Xavier
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
