SIP Servers and Services

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?

User Elements

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 (UAC) is an entity that sends SIP requests and receives SIP responses.  For example, a SIP telephone is a UAC because it sends an INVITE request to create a voice call.  A User Agent Server (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.

Network Elements

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, is my AOR and the IP of my One-X SIP Communicator is  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 blog about “SIP Subscribe, Notify, and Publish.”

Putting it all Together

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.



  1. […] To learn about the different SIP components, please refer to SIP Servers and Services. […]

  2. sleifer_dh · · Reply

    Hello. At second paragraph, second 2, I think you wanted to say “A User Agent Client (UAC) is an entity that sends SIP requests and receives responses.” Also I like your posts. They help a lot. Thank you.

    1. Thanks for catching my mistake. It’s correct now. Thanks also for the compliment. It’s nice to know that people are reading my babble. 🙂

  3. I think the best that I read 🙂 Simple and easy to understand

  4. vyassen · · Reply

    you are super 🙂 thanks.

    1. Thanks! That made my day.

  5. Hi, My application is playing role as statful proxy- When proxy received ACK from caller party session state comes into confirmed state. My requirment is to send sip INFO message to caller party on received of ACK request. Can I create INFO message on SIP proxy session ? I execute req.getSession.createRequest(“INFO”), it throws exception “your session is proxy”. Can somebody help how can I create INFO request and send it to caller ?

  6. Mohamed Elwan · · Reply

    thanks for the valuable article, is the response group service in LYNC equal to B2BUA ?

  7. Paul Maillet · · Reply

    A clear and concise statement of the SIP protagonists. Thanks for your time!

    1. Thanks! I try.

  8. Your blog is perfect for SIP learning. I wish it had a road map to learn SIP step by step. You’re great. Don’t you have any video tutorial about SIP?

  9. Great blog Andrew. Much better than parsing the RFC myself. Live long and prosper.

  10. Sumit saini · · Reply

    Hello I want to know does redirect server gets the location from location server and if yes then why we need redirect server since we have location server ?

    and the second question is how any UAs gets to know before processing requests that it has to query first to redirect server or it is mandatory to have Redirect server ?

    1. The UA doesn’t know it is sending to a Redirect server. It simply sends its messages and follows the redirect path. A location server is not a SIP element. It doesn’t send and receive SIP messages. It could be anything from a database to a service at the end of a REST call.

      1. Sumit saini · ·

        Thank you so much I understood

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: