To truly understand the power and versatility of SIP, it is necessary to look beyond its basic protocol constructs. Yes, 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. It’s like building a house. You need boards, nails, and shingles for the finished product, but without the concepts of kitchen, living room, and bedrooms who knows what you might end up with?
Let’s begin with the User Agent. The User Agent comes in two flavors — the User Agent Client and the User Agent Server. A User Agent Client (or UAC) is an entity that sends SIP requests and responses. For example, a SIP telephone is a UAC because it sends an INVITE request to create a voice call. A User Agent Server (or UAS) is an entity that receives SIP requests and sends SIP responses. A UAS will send SIP REGISTER requests, but these are not considered to be session creation messages. A SIP telephone is also a UAS because it accepts INVITE requests in order to ring the telephone and alert the user. Because of its dual roles, you refer to a SIP telephone as a User Agent Client Server (or UACS). However, some SIP entities are only UAC’s or UAS’s. A device that monitors a patient’s heart rate might only send SIP status messages making it a UAC. Additionally, the server that accepts those status updates might only receive SIP messages making it a UAS.
The next SIP entity is the SIP Registrar. The Registrar accepts SIP REGISTER requests from SIP User Agents. REGISTER requests create a binding between a user’s Address of Record (AOR) and the IP address of the user’s SIP device. For example, SIP:email@example.com is my AOR and the IP of my One-X SIP Communicator is 10.11.228.58. SIP supports multiple REGISTER requests for the same AOR. This allows me to have a SIP device at one IP address (e.g. my One-X Communicator) and another at a different IP address (e.g. my Flare device). When someone calls my AOR, both devices will simultaneously ring.
Of extreme importance is the SIP Proxy. The job of the SIP proxy is to accept SIP requests from a UAC and forward, or proxy, them on to the appropriate UAS. In many cases, the SIP Proxy is also the SIP Registrar, but it’s also possible for the Proxy to query a separate Registrar for address information. No matter how it’s built, the Proxy will need the registration information of the UAS’s it serves in order to send messages to them.
There are two types of proxies – stateless and stateful. A Stateful proxy will stay in the path of a SIP session for the duration of the call and a stateless proxy will drop out of the path as soon as the session has been established. Clearly, if call detail records (CDR) are needed from your SIP proxy, it must be stateful.
The SIP Redirect Server is similar to a SIP Proxy in that it accepts SIP requests, but instead of forwarding the requests onto their final destination, it tells the senders where to send the requests. This is accomplished by returning a “3xx moved” response to the sender. This response will contain the next hop information that the sender will use when it resends the message. Redirect Servers are used as SIP traffic cops to move calls through a network as quickly as possible. Redirect Servers are always stateless.
The next SIP entity is a combination of a UACS and a SIP Proxy. That entity is the Back to Back User Agent or B2BUA. The B2BUA is positioned in the middle of a SIP session much like a proxy, but it regenerates each message before sending it to the final destination. In other words, a B2BUA will receive an incoming SIP request and possibly modify the request before sending it on. This allows a B2BUA to become a services platform for SIP. For example, a B2BUA might implement the forward feature by changing the destination of a SIP message to the forwarded telephone. It also might implement music on hold by redirecting a session’s audio to a music source when one SIP telephone puts another on hold. A B2BUA can also create two or more outgoing calls from a single incoming call to provide simultaneous ringing at multiple devices.
All Session Border Controllers are B2BUA’s. The Avaya Aura Session Manager is a B2BUA. It’s also possible to create Aura Sequenced Applications that function as B2BUA’s. The B2BUA is the services platform of an enterprise communications cloud.
The last major SIP entity is the Presence Server. The Presence Server is responsible for processing SIP subscriptions and sending SIP NOTIFY messages on behalf of the subscribed-to entities. For example, if User-A subscribes to User-B’s presence, the Presence Server would accept store the SUBSCRIBE request from User-A, monitor the presence of User-B, and send a NOTIFY message each time User-B’s status changed (e.g. on-line, off-line, on a call, do not disturb, etc.). Similar to the SIP Registrar, Presence Server functionality is sometimes performed by a Proxy Server. For a deeper dive into SIP subscriptions, please read refer to my previous blog about “SIP Subscribe, Notify, and Publish.”
Understanding SIP is far from daunting if you look at it from the standpoint of the services built using the SIP protocol primitives. Yes, there may be times when a thorough comprehension of SIP requests, responses, and headers may be necessary, but unless you are in level 4 support, those times are minimal. It’s far more important to understand the building blocks that make up your SIP cloud. Being familiar with the concepts described above is the first step in making the right decisions for your enterprise and the future of your communications.