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:aprokop@arrowsi.com) 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 (168.175.59.168), and iPad client (50.171.225.14). 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:
Mischief Managed
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.
Tao, Zen, and Tomorrow 
Great article as always Andrew, and this is why the industry absolutely needs to break the current ties of E911 and telephone numbers equalling a location. Just as they do not relate to a specific device.
Yet legislative agendas from some companies want to handcuff commercial enterprises by requiring DID telephone numbers that become tied to stations. This does nothing but lock in their antiquated technology and for the consumer to buy something they do not need. Left unchecked, these practices become law, and public safety officials blindly endorse them without promulgating the value behind them.
It’s all in my latest Podcast:
https://soundcloud.com/fletch911/e911-talk-240-911-laws-dont-always-make-sense
Fletch
Great podcast on a very important subject, Fletch! I hope “the right people” hear it and take action. Thanks for spreading the word.
Hi Andrew, I have been reading your posts and have been enjoying learning about SIP. Thank you.
I have a question about forking that I hope you can help me with. Let’s consider that a real-time passive monitoring tool is looking at the SIP messages and is trying to correlate the request/response messages to one another.
“How the response/s to the forked requests can be correlated to the each of the forked requests in real-time (or near)? As you have mentioned above, the forked requests (INVITE in your example) almost look alike.”
I would appreciate your input on this.
Thanks
Varga
Does this help? https://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/
thanks for the quick reply. Unless I’m missing something, I am not sure if the “To tag” is the answer for the very first response. It is certainly useful for the subsequent messages but not for the first response (say the 180 Ringing in the example you have). I read something (I am sure in one of your posts) about the Branch-ID. That may be the answer that I need to explore.. by the way, is there any way to get the PCAP file for your example above? I would appreciate it. Thanks
Thanks Andrew. Your articles are always helpful. Is it possible if you can please explain the network Architecture of Avaya Communication Manager, Avaya Session Manager and SBC.