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.
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,
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.
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).
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.