In legacy telephony, everything revolves around hardware. There is the telephone receiver you hold in your hand and the buttons you press to make calls. The telephone is connected back to a central brain by one or more dedicated wires. Those wires eventually connect the telephone to a line card that feeds signals into a call processor. The call processor manages a voice bus that ultimately connects the calling and called parties.
In other words, circuit-switched telephony requires a lot of moving parts and most of those moving parts consist of metal and plastic.
Along with hardware, there is the telephone number. While you might want to think about the telephone number as an abstract idea that allows people to make and receive calls, it has a very intimate relationship with all that hardware. A telephone number has a tighter association with wires and devices than it does with users. You can’t go home and easily change the telephone number of your landline, and even though there aren’t any physical wires, you can’t do that to your cell phone, either.
With SIP, the telephone number can be an abstract concept. I use several SIP endpoints and it’s a trivial job to reconfigure them with a new number. With a few keystrokes, I can log out the current user, log in a new user, and voila, my telephone now marches to a new drummer.
With SIP, this logging in and out is accomplished with the REGISTER method. It’s what associates a user (e.g. sip:firstname.lastname@example.org) with an IP address and ultimately, a device.
For a deep dive into REGISTER, please see Understanding SIP Registration.
Today I want to talk about one of my favorite aspects of SIP – multiple registration. With multiple registration, I can be in more than one place at the same time. Personally, I use it to be in three places at the same time. Using the same user ID and password, I register my Avaya 9641 desk phone, One-X Communicator for IOS iPhone client, and iPad Communicator. Every time someone calls me, all three devices ring.
To demonstrate how this works, I started my mobile clients on separate networks (my iPhone on AT&T LTE and my iPad on a Comcast cable network) and then using my home telephone, I called my work number. I captured all the messages that went in and out of my company’s Avaya SBC with traceSBC.
The details of traceSBC can be found in my article A Necessary Guide to the Avaya traceSBC Utility.
The call flow can be described as follows:
- Using my home telephone, I call my work number.
- The call traverses the PSTN and eventually arrives at my company’s Avaya Aura system via an ISDN trunk.
- The Avaya Aura system sends the call to Session Manager (10.11.238.49).
- The Session Manager sends the call to three destinations: 9641 deskphone, iPhone client (188.8.131.52), and iPad client (184.108.40.206). Since the iPhone and iPad clients ingress and egress through an Avaya SBC, the session manager sends two separate INVITE messages to the SBC.
- The SBC sends the INVITE messages to each mobile client.
- Both clients return 180 Ringing responses.
- I press answer on my iPhone. One-X Communicator sends a 200 Ok response.
- Session Manager cancels the ringing call on the iPhone with a SIP CANCEL.
- Lots of presence and Avaya proprietary subscription event messages are sent.
The following traceSBC screen capture shows steps 1 through 5.
Expanding the first INVITE shows you the following:
Expanding the second INVITE shows you the following:
Notice how these INVITE messages essentially look the same. Specifically, they have the same Call-ID, To header, From header and From tag. There is no To tag in either header. That will come later.
Next, the clients return 180 Ringing responses.
Notice that there are tags in the To headers and they are not the same value. This allows the proxy (or proxies) to distinguish SIP dialogs.
For a deep dive into To and From tags, please see my article Let’s Play (SIP) Tag.
When I answered the call on my iPhone, a 200 Ok was sent.
Notice how the User-Agent header tells me that this response is from an iPhone.
Now that Session Manager realizes that at least one of the ringing calls has been answered, it needs to cancel all remaining ringing calls. It does this, of course, by sending a SIP CANCEL. In my example, the CANCEL will go to the iPad Communicator client.
The iPad Communicator client sends a 200 Ok response for the CANCEL.
Note that CSeq header indicates that this response is for the CANCEL.
All that is left to do now is release the INVITE session to the iPad Communicator. This is accomplished by the iPad Communicator sending a 487 Request Terminated.
For a deep dive into CANCEL, please see Understanding SIP CANCEL.
Putting it all together, we see the entire call flow as follows:
I hope this made sense to you. The notion of separating the user from the device is one of the most powerful aspects of SIP. Not only does it give us device independence and mobility, it is at the core of SIP’s ability to be in more than one place at the same time.