A back-to-back user agent (B2BUA) is a logical network element in SIP applications.
It is a type of SIP User Agent (UA) that receives a SIP request, then reformulates the request, and sends it out as a new request. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. A B2BUA breaks the end-to-end nature of SIP.
A B2BUA agent operates between two endpoints of a phone call and divides the communication channel into two call legs. B2BUA is a concatenation of UAC and UAS. It participates in all SIP signaling between both ends of the call, it has established. As B2BUA available in a dialog service provider may implement some value-added features.
In the originating call leg, the B2BUA acts as a user agent server (UAS) and processes the request as a user agent client (UAC) to the destination end, handling the signaling between endpoints back-to-back. A B2BUA maintains the complete state for the calls it handles. Each side of a B2BUA operates as a standard SIP network element as specified in RFC 3261.
Main Difference between SIP Proxy and B2BUA
SIP Proxy:
- Proxy functionality (stateful and stateless) is defined in RFC3261.
- A proxy server relays requests and responses, that means, it accepts request from the UAC, and then forward, or proxy it to the appropriate destination, or to another proxy closer to the destination.
- A proxy most of the time just acts as a middleman between the client and the terminating server.
- A proxy also interprets, and, if necessary, rewrites specific parts of a request, response message before forwarding it.
Ex:
192.168.X.X: Caller
192.168.X.P: Proxy
192.168.X.Y: Callee
SIP Proxy basic Call Flow
Just focus on INVITE requests (F1, F2) and the most important responses to them (F3, F4).
/* F1 */
INVITE sip:callee@192.168.X.P SIP/2.0.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.72ccKTzfG.
Call-ID: ~OsELfLaIG.
Contact: <sip:caller@192.168.X.X>.
/* F2 */
INVITE sip:callee@192.168.X.P SIP/2.0.
Record-Route: <sip:192.168.X.P;lr>.
Via: SIP/2.0/UDP 192.168.X.P;branch=z9hG4bKb234.aea6.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.72ccKTzfG.
Call-ID: ~OsELfLaIG.
Contact: <sip:caller@192.168.X.X>.
/* F3 */
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.X.P;branch=z9hG4bKb234.aea6.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.72ccKTzfG.
Record-Route: <sip:192.168.X.P;lr>.
Call-ID: ~OsELfLaIG.
Contact: <sip:callee@192.168.X.Y>.
/* F4 */
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.72ccKTzfG.
Record-Route: <sip:192.168.X.P;lr>.
Call-ID: ~OsELfLaIG.
Contact: <sip:callee@192.168.X.Y>.
As you can see, all the messages have the same Call-ID header, which means, they’re on the SAME call.
When Caller initiates her INVITE (F1), she puts her location URI into Contact header. Proxy modifies that INVITE (by putting additional Record-Route and Via header) and then forwards it to Callee (F2). Callee accepts that call, and then put his location URI into Contact header in 200 OK response (F3). The proxy forwards 200 OK back to Callee (F4).
Another note, SIP Proxy presents the actual caller in the bottom-most Via header to the callee. That behavior is defined in RFC3261, section 16.6.
In this case, later requests within the same dialog, e.g: ACK, BYE are still relayed on Proxy, but it’s not mandatory, since caller/callee knows each other’s location, they could send SIP messages directly.
SIP B2BUA:
B2BUA stands for Back-to-Back User Agent. It’s not a standard definition in any RFC but considered playing roles of both UAS and UAC.
Why would I have said that? Because back-to-back user agent operates between both endpoints of a communication session and divides the communication channel into two call legs.
B2BUA acts as a UAS in the originating call leg, when receives a call from the caller (UAC), and acts as a UAC in the other leg, by calling the callee (UAS).
SIPB2BUA basic Call Flow
EX:
192.168.X.X: Caller
192.168.X.B: B2BUA
192.168.X.Y: Callee
/* F1 */
INVITE sip:callee@192.168.X.B SIP/2.0
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bKyyH5584Hm48De
Call-ID: 75f09e68-a1e0-1235-bb85-00155d011c0d
Contact: <sip:192.168.X.X>
/* F2 */
INVITE sip:callee@192.168.X.Y SIP/2.0
Via: SIP/2.0/UDP 192.168.X.B;branch=z9hG4bK1969739b
Contact: <sip:192.168.X.B>
Call-ID: 3dc4f44941bc1b5674b4794d345e2a3c
/* F7 */
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.X.B;branch=z9hG4bK1969739b
Call-ID: 3dc4f44941bc1b5674b4794d345e2a3c
Contact: <sip:192.168.X.Y>
/* F8 */
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bKyyH5584Hm48De
Call-ID: 75f09e68-a1e0-1235-bb85-00155d011c0d
Contact: <sip:192.168.X.B>
So, as you notice, F1 and F8 have the same Call-ID, but they’re different from F2’s and F7’s. That say, F1 and F8 are in the same call, while F2 and F7 are in , just another call.
B2BUA considers these two calls are different but bridged together.
Not like SIP Proxy, no request/response is forwarded from the caller to the callee or vice versa. When B2BUA receives a message, it creates (or not) a corresponding message, and send it to the bridged call leg. So the endpoints have no idea who’s the actual other endpoints (no footprint on Via, Contact header) because they just communicate to the B2BUA.
That is how topology hiding works.