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 192.168.0.14 with this Contact header.
Contact: Andrew Prokop <SIP:aprokop@192.168.0.14>
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.
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:
- 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.
- 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.
- The user sends a second REGISTER to the SIP registrar. This REGISTER contains an Authorization header. Within Authorization is the user’s encrypted password.
- 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.