SIP Back-to- Back User Agent Role  [ Signaling B2BUA Role ]

Recently, while I was working on SIP Call flow issue we had to work a custom built application. Unfortunately, there were no documentation  or diagrams available for us in order to understand that application. Later while discussing about the application, we got to know that it was a custom application designed for a specific purpose like masking the Caller's Identity (before leaving the network), identifying and tearing down idle sessions etc for security reasons.


From the SIP logs that we collected from that application, we realized that the SIP Call flow looked different than the predominant SIP server roles (like SIP Registrar, SIP Proxy or SIP Redirect server  Roles) which we were well aware.  Moreover, it was not an SBC connecting to the PSTN network either.Instead it was a SIP B2BUA. Since I have worked mostly on more on Microsoft UC products the only B2BUA that I was aware was Mediation server Role in Microsoft Lync or SfB infrastructure.
What is a Mediation server ? For readers who are new to Microsoft UC platform, the Mediation Server is considered the last point of contact for the Lync/SfB environment before communicating to the telephony world for audio communication, whether its is a inbound  or outbound VoIP calls from/to the Public Switched Telephone Network (PSTN) network.  But later while learning about the B2BUA understood that there are several categories with in B2BUA.

So, started searching and reading about B2BUA in the Internet and i would like to share some of the information which i gathered while trying to understand the functionalities of a SIP B2BUA.


Back to Back User Agent:

What is a SIP B2BUA Role ?

Back to Back User Agent (B2BUA) is the logical combination of a UAS and UAC.

UAS :    User  Agent Server.

UAC :    User Agent Client.

In SIP deployments, there are several Back to Back User Agents (B2BUA). So, it is very important to understand the different types and what a B2BUA Role can do or Cannot do in a SIP infrastructure.  

Note, the Back to Back User Agents are further classified in several types. Again, it is a SIP server Role not a single system. That is, a system or a server can perform all of the B2BUA roles mentioned below in one server and not necessarily each Back to Back UA Role should run on a separate server.

 The B2BUA is broadly classified into two categories:

• Signaling Plane B2BUA
• Signaling + Media Plane B2BUA

The SIP B2BUA Role is in itself a vast topic. So in this post, we will discuss about the Signaling Plane B2BUA and discuss about the Signaling + Media Plane B2BUA  in a different post.

what is a Signaling Plane B2BUA ?

A  Signaling Plane B2BUA as it name implies it ONLY operates on the SIP Messages and SIP Headers.  and  NOT on the Media.

Again there are several classification within the Signaling plane B2BUA like

    1)  Proxy-B2BUA 

    2)  Signaling Only B2BUA 

3  3)  SDP Modifying Only Signaling 

     1)  Proxy B2BUA: (REPLACES only the VIA: and Record-Route: SIP Headers)

The Proxy B2BUA maintains the Sufficient SIP Dialog state in order to (or if required to) generate the In-Dialog SIP messages on its own. If the Proxy B2BUA can generate In-Dialog SIP messages then it can also MODIFY the CSEQ: header after it has generated its own.

Example of this B2BUA is, sending the BYE requests in order to tear down a dead SIP session.

so what are all the SIP headers that a SIP Proxy B2BUA can modify ?

The Proxy B2BUA role can only modify the Via: and Record-Route: SIP header fields.

What SIP headers a SIP Proxy B2BUA cannot modify ?

The Proxy B2BUA role does not modify the TO: ,  FROM:  , Contact:  SIP headers. 

2)  Signaling – only B2BUA: (Replaces all the SIP Headers)

A Signaling Only B2BUA is the one, that operates at the SIP layer but in ways beyond those of the SIP Proxies.

That is, the Signaling -Only B2BUA can  replace the Contact URI  along with modifying or removing the Via and Record-Route headers.

Also, in this Signaling Only B2BUA role - No SIP headers are guaranteed to be copied from the Received SIP request messages from the UAS and generated on the UAC side.

So if you want to completely create a new call leg between two different System or Networks, then you need to have Signaling-only B2BUA. (The Mediation servers in the Lync/SfB infrastrucure)

Example:

Like a Application Server or a PBX which actually Processes the REFER methods locally and then generates a new INVITE on Behalf of the REFER’s target.

Another example is a  Privacy Service Proxy performing the ‘Header’ Privacy function.

This kind of  B2BUA,  a Singaling only B2BUA is useful if you want to hide the caller's identity before it leaves your SIP infrastructure. Or may be for billing purposes if you want to convert all the Call transfer (like REFER) to a new INVITE session. Then, you can have a Signaling only B2BUA Server sit in the Perimeter of a network and makes sure that any call transfers that made within the network to any outside network should be treated as a new Call. Thus, the Billing server would only consider the INVITE sessions generated with unique Call-ID and charge the calls transferred outside of a system as a new Call. So, may be then you might need this kind of feature.

3) SDP modifying Signaling-Only (can modify the SDP in SIP message).

An SDP –Modifying Signaling Only B2BUA is one that operates in the Signaling Plan only AND NOT in the Media Path. However, it can MODIFY the SDP. Thus, this type of B2BUA is aware of the SDP semantics.

Purpose:

This SDP modifying B2BUA does NOT  make changes to the Media Path.  That is, it does not stay or INSERT themselves in the PATH of the Media (like a Third Party Call control servers).

However, it will make SDP changes that affects 

• what is sent on the Media Plane ?  (like the SDP offer changes like removing the unsupported Codecs ) OR 
• It can MERGE two separate Media end points into one SDP offer etc.  

Certain Application servers or SIP PBX or SIP PSTN Gateways act in this role (SDP modifying B2BUA). So that they can remove the unsupported Codecs from the SDP.