Understanding SIP Registration

Let’s start at the very beginning

a very good place to start

when you read you begin with A B C

when you sing you begin with Do Re Mi

I have always loved musicals and Rogers and Hammerstein’s “The Sound of Music” is high on my list of favorites. Sure, it’s corny and far from historically accurate, but that doesn’t bother me in the least. I am always willing to set aside any sense of reality for good singing, romance, and adventure and “The Sound of Music” has them all.

So, what does this have to do with unified communications? REGISTER, of course. Like Do Re Me, you begin SIP with REGISTER.

Can you get SIP devices to communicate without REGISTER? Absolutely. In fact, when I teach my SIP class, the students put their SIP clients into point-to-point mode which does not require REGISTER. This means that clients send SIP requests and responses directly to the other clients and not through a proxy. The clients can do everything all by themselves.

However, point-to-point without REGISTER has a serious downfall. The clients are required to know the IP addresses of all the other clients they wish to communicate with. While this is fine in a limited classroom environment, it becomes unwieldy after you grow beyond a handful of endpoints.

As an analogy, imagine having to know the IP address of everyone you wanted to send an email to.   That’s the same problem you have if you don’t use REGISTER. It’s simply not practical.

The Tie that Binds

REGISTER associates a user’s identification, or Address of Record (AOR), with one or more locations. Note that I said locations. You are not limited to registering an AOR to a single device. Personally, I routinely register my AOR to a physical desk phone and multiple SIP soft-clients. Present day Avaya Aura supports up to ten such registrations per user. That’s enough to make even the most device crazy nerd happy.

You bind an AOR to an IP address with a Contact header.  For example, one of my soft clients might tell a SIP registrar that aprokop can be reached at with this Contact header.

Contact: Andrew Prokop <SIP:aprokop@>

Registrations are time-based and will eventually expire. This requires the client to periodically refresh a REGISTER with a new REGISTER. Actually, new isn’t the correct word to use for this. Subsequent REGISTER messages must contain the same Contact, To, From, call-ID, and From tag  as the original registration. This allows the SIP registrar to know that it’s simply a refresh and not a new registration for the same AOR.

Please note that CSeq will increment with each REGISTER sent.

To learn more about registration timers, please see my article, Understanding SIP Timers Part II.

Keeping Things Secure

I may tell my communications system that I am Andrew Prokop, but it would be foolish to trust me at face value. That’s why SIP allows a REGISTER to be challenged as to the authenticity of the user.

Before I go through a REGISTER challenge, allow me to define something known as a nonce.

Nonce stands for Number Once and is an arbitrary number used only once in a cryptographic communication. The recipient of a nonce will use it to encrypt his or her credentials. Number once refers to the fact that encryption with this nonce can only be done one time. If someone were to sniff the LAN and obtain someone’s encrypted password, it won’t do them any good because it can only be used in a single transaction. It becomes stale and useless immediately after its first use.

A REGISTER flow is fairly simple and follows these steps:

  1. A user sends a REGISTER to the SIP registrar. The To and From headers contain the user’s AOR. The user specifies the number of seconds the registration should be valid in the Expires header. This value can be later raised or lowered by the registrar.
  2. The registrar returns a 401 Unauthorized response with a WWW-Authenticate header.  This header contains data that must be used to encrypt the user’s communications password. Specifically, it contains a nonce along with the name of the encryption algorithm that the client must use.
  3. The user sends a second REGISTER to the SIP registrar. This REGISTER contains an Authorization header.   Within Authorization is the user’s encrypted password.
  4. If the correct password is received by the registrar, a 200 Ok response is sent to signify a successful registration. An Expires header may be present with a different value than what the user requested.  This is the time the registration will be valid as determined by the registrar’s policies.

A registration is removed by sending a REGISTER with an Expires header value of 0 (zero).

In a picture, we have this.


Using the traceSM tool on an Avaya Aura Session Manager, I captured the following trace which shows a REGISTER, the challenge, and a REGISTER with encrypted credentials.  Take a look at the headers and you will see that they are doing exactly what I said they would do.




In the case of my daily life, my various SIP devices will each send a REGISTER, be challenged, and resend the REGISTER with the encrypted credentials. They periodically refresh their registrations to ensure that I am able to make and receive calls on all my devices until I am finished for the day.

Speaking of finished for the day, that’s about all I have to say about REGISTER.  It’s not that complicated once you understand the basics.  Just keep in mind that while registration isn’t absolutely mandatory, it enables a secure, scalable, and easy to manage SIP solution.

And these are a few of my favorite things.


  1. Very nicely explained Andrew!

  2. Very clear article.
    Clean and crisp!!!

  3. Is it mandatory to get 401 response to REGISTER REQUEST always.

    1. No, but it’s smart. You want to make sure that registrations are authenticated.

  4. when device send refresh register

    1. Before the current one expires. Generally, halfway through the Expires time.

  5. Hi,

    Why the From and To header of a register message is same.In the other SIP messages like invite this From and To address header is different.Could you please clarify it.

    1. It’s because you are registering yourself. You aren’t registering anyone else.

      1. Hi ,

        Sorry I am a bit confused. My understanding was when a client is sending the register message the From address will contain the Client address and Register server we are requesting will be in the To address.
        If both the address contains the same address of the client , then how can it identify the register server address.

  6. Indrani · · Reply

    Hi I am sending register and getting 200 OK response but i want it to get 401 first and then 200 OK.

    1. The SIP Registrar must send the 401. Perhaps there is a security setting you can enable. The client has no control over that.

  7. So when the REGISTER packet is created, let’s say using your example of:

    Contact: Andrew Prokop

    This means that the User device is aprokop and the IP of is the user’s device as well? Or is that IP the address of the proxy session manager (CSCF) that received the REGISTER? If that’s the case, then the VIA header should match the Contact IP address right?

    1. The REGISTER should contain the IP address of the device sending it. It should not be that of a proxy.

  8. You said that you register to your AOR using multiple devices. Each of your device use different Call-Id and is authorized separately to add Contact biding. When one of your device sends request for current contact list (no Contact header in REGISTER), should OK response contains all bindings to AOR or just those added with corresponding Call-Id?

    1. The RFC states the following: The registrar returns a 200 (OK) response. The response MUST
      contain Contact header field values enumerating all current
      bindings. Each Contact value MUST feature an “expires”
      parameter indicating its expiration interval chosen by the

      To me, this implies all registrations for that AOR.

      1. It’s not so obvious for me. Same RFC states that ‘the registrar checks whether the Call-ID agrees with the value stored for each binding’. So bindings are somehow related with Call-IDs. I’m saying somehow because I don’t understand rest of RFC – ‘If not, it MUST remove the binding’. Why removing binding from other device? Section 10.3 of RFC… no sorry, whole RFC is clear as mud.

      2. The response MUST contain Contact header field values enumerating all current bindings (I would add) for current Call-ID. Otherwise request with Contact header * and Expiration header zero would result in removing bindings from devices which don’t know about it. Whole Expires header algorithm which gives relative time after which the message expires would break.

        Is that makes sense for you?

  9. Abhilash · · Reply

    What are the possible 4xx responses that can be sent for register request?

    1. 401 is, of course, the most common. The others would depend on the implementation. For instance, I’ve never seen a 416 sent, but I don’t see why it couldn’t be. I can also envision a server that sends a 422.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: