For those of you who have been waiting for me to write one of my deep-in-the-weeds blogs about some esoteric aspect of SIP, the wait is over. As for the rest of you, now might be a good time to peruse through my previous blogs where I tackle less geeky subjects. However, you won’t know what you’re missing unless you give it a try. So, without any further delay, let’s play tag.
With any protocol that creates and manipulates objects it’s important to be able to distinguish one object from the next. In the SIP world, the object that we are most interested in is the dialog. From RFC 3261, a dialog is defined as follows:
“A peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg.”
It’s important to know that a dialog isn’t necessarily associated with a media session. A dialog can be created with a presence subscription. Media requires SDP and SDP is never carried in a Subscribe message.
Notice the reference to tag values in the RFC definition. Those tags, local and remote, are what I want to spend some time on today.
If you’ve got a basic knowledge of SIP then you are aware of the header Call-ID. Call-ID appears in every SIP request and every SIP response. It is required to be globally unique and is generally a GUID (Globally Unique Identifier) associated with the IP addresses of the sender. For instance, a typical Call-ID might look as follows:
77_1c6d7a3d17ea48dd6d916db4_I@10.100.1.9
If you are like me when I was first figuring out SIP you might be thinking to yourself, “Since a Call-ID is unique then that’s all that I need to uniquely identify a SIP dialog.” Unfortunately, even though a unique call-ID guarantees uniqueness when the message leaves the UAC (User Agent Client), network elements along the way may cause that uniqueness to disappear.
The most obvious problem with using Call-ID to uniquely identify a message arises with call forking. In call forking, a single SIP Invite message is turned into multiple Invite messages to different destinations. For example, you might call me, Andrew Prokop, but call forking might cause Invite messages to be sent to all my registered endpoints — my smart phone, my desk phone, and my PC phone. That single Call-ID was fine when it was one Invite, but it’s not so fine when it becomes three. This is where tags come in.
Tags are really quite simple, but require a bit of explanation. The goal of a tag is to work with the Call-ID to make an entire dialog unique no matter how many times a session might be forked. Actually, I should have said tags since there are two. There is the local tag (From tag) which is assigned by the sender of a message or the UAC. There is also the remote tag (To tag) which is assigned by the final recipient of the message or the UAS (User Agent Server). The UAC puts its tag in the From header and the UAS puts its tag in the To header. So, when a message leaves a UAC it has one tag in the From header and there is no tag in the To header. When a UAS receives that message and responds back with a SIP response (e.g. 180 Ringing), it then adds a tag to the To header. If multiple clients received the original message then they would all add their own specific tag values. In other words, all those SIP messages will have the same From tag, but depending on who is responding, there will be different To tags. Does this make sense? If not, here is a dumbed down call flow that might explain it better:
Andrew sends:
INVITE Mary@bigcompany.com
To: Mary@bigcompany.com
From: Andrew@smallcompany.com; tag = 1930394343437322@10.10.1.100
Mary’s smart phone SIP client responds with:
180 Ringing
To: Mary@bigcompany.com; tag = 9777484849@10.10.1.110
From: Andrew@smallcompany.com; tag = 1930394343437322@10.10.1.100
Mary’s PC SIP client responds with:
180 Ringing
To: Mary@bigcompany.com; tag = 1190593343@10.10.1.130
From: Andrew@smallcompany.com; tag = 1930394343437322@10.10.1.100
Note that every message has the same From tag, but the To tags differ from client to client. Eventually, someone will answer the call with a 200 OK and the remaining dialog(s) will be cancelled. Along with Call-ID, those tags allow you to identify which call to keep and which call(s) to release.
For another discussion on SIP forking, please see my blog How to be in Three Places at the Same Time.
That’s pretty much it for tags. Pretty simple and easily overlooked, but very important to making SIP work. Are you happy that you stuck around? I am.
Tao, Zen, and Tomorrow 
Very good explanation in simple world, easy to understand. Thank you so much Andrew..
Reading your post 9 years after you wrote it! Thank you.