“To be or not to be. That is the question.”
Ah, the angst of youth — feeling that you are on the cusp of something incredible, but not having the maturity to understand what it is. William Shakespeare brought life to those words over 400 years ago and yet they still ring true today. I will venture to say that they apply equally as well to this middle-aged SIP guy who still struggles to find his place in an ever complex world of people, places, and gadgets.
Knowing who you are extends well past the trials of Hamlet, the Prince of Denmark. Here in the world of technology, we apply names to the entities we wish to control, be controlled by, or communicate with. In the IP space, we have the Machine Access Control (MAC) and Internet Protocol (IP) addresses.
The MAC address uniquely identifies a network interface on a physical network segment. Every Network Interface Card (NIC) has a MAC address. This address is universally unique and no two NIC cards will ever share the same MAC address.
An IP address is a label assigned to a device (e.g. computer, printer, call processing server, etc.) that uses the Internet Protocol for communication. An IP address must be unique within the LAN or WAN it resides in, but is not necessarily universally unique. One enterprise can use many of the same IP address that another enterprise uses. Communication between those two enterprises is possible using Network Address Translation (NAT) techniques, but that is a subject beyond the scope of this article.
SIP has its own share of names and you will find them in a variety of different places. It’s important to know that there are different types of addresses and a single SIP element may be addressed in more than one way.
At the core of SIP communication is the Address of Record (AOR). The AOR is a high level name that is assigned to a SIP entity without regard to the device or devices that names might use. The format for an AOR is as follows.
When a SIP entity wishes to communicate with another SIP entity, it populates the SIP Request-URI and the To header with the recipient’s AOR. It will place its own AOR in the From header.
The AOR is great for high level routing, but it falls short when it comes to identifying the actual recipient of a SIP message. That’s because the form of name@domain doesn’t specify the device or devices that that AOR might be currently using. For instance, I can use my AOR of SIP:firstname.lastname@example.org to register the 9641 SIP telephone on my desk, the One-X Communicator on my PC, the One-X Mobile on my iPhone, and the Flare Experience on my iPad.
That’s four devices and four IP addresses. How do I go from an AOR to a device?
This is where the SIP Contact header comes into play. The Contact header allows a user to associate one or more devices to a single AOR. Each of those devices will send its own REGISTER message and each REGISTER will contain a unique Contact header.
For example, the Contact header used by the REGISTER from my PC might look as follows:
Contact: Andrew Prokop <SIP:email@example.com>
The Contact header used by the REGISTER from my iPhone might look as follows:
Contact: Andrew Prokop <SIP:firstname.lastname@example.org>
Notice how each Contact header uses a different IP address for the same “aprokop.” This allows a SIP registrar (which in my case is an Avaya Session Manager) to support multiple devices for a single user. If someone calls SIP:email@example.com, both my One-X Communicator and my One-X Mobile will ring. There is no reason for the caller to ever know the actual IP addresses of my devices. DNS routing will find arrows3.com and my company’s Session Manager will simultaneously alert all my registered devices.
Contact headers can be used in messages other than REGISTER, but in all cases the goal is to associate a device address with a user.
So, even though a rose by any other name would smell as sweet, a single AOR may take on different odors depending on the Contact headers associated with that AOR. Okay, that’s a weak metaphor, but I’m an engineer and not a poet.