What is the main difference between SIP Proxy and B2BUA?

APRIL 23, 2017 ~ THANHLOI

Knowing that an INVITE request is used to create a SIP session is important, but that only paints half the picture. To make sense of SIP, it’s necessary to understand how to use its protocol elements to create a services infrastructure.

Andrew Prokop

SIP Proxy

So, let’s begin with the 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 approriate destination, or to another proxy closer to the destination.

A proxy most of the times just acts as a middle man 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.

Stop yawning, I’m going to give you an example.
As usual,

192.168.X.X: Caller
192.168.X.P: Proxy
192.168.X.Y: Callee

H2.1 Proxy 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, that 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). 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. We’ll talk about this in another post, soon.

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 said that? Because back-to-back user agent operates between both end points of a communication session, and divides the communication channel into two call legs.

B2BUA acts as an UAS in the originating call leg, when receives a call from the caller (UAC), and acts as an UAC in the other leg, by calling the callee (UAS).

H2.2 B2BUA Call Flow

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 … hmm, just another call.

That’s the point I want to talk about today, technically, B2BUA consider 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 endpoint (no footprint on Via, Contact header), because they just communicate to the B2BUA.

That is how topology hiding works.

Okay, that’s enough for today. I hope you’re as thrilled as I am.

References:

https://en.wikipedia.org/wiki/Session_Initiation_Protocol#Proxy_server

https://en.wikipedia.org/wiki/Back-to-back_user_agent

https://tools.ietf.org/html/rfc3261

Advertisements

REPORT THIS AD