Let’s Play (SIP) Tag

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:


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@

Mary’s smart phone SIP client responds with:

180 Ringing

To: Mary@bigcompany.com; tag = 9777484849@

From: Andrew@smallcompany.com; tag = 1930394343437322@

Mary’s PC SIP client responds with:

180 Ringing

To: Mary@bigcompany.com; tag = 1190593343@

From: Andrew@smallcompany.com; tag = 1930394343437322@


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.


  1. sigarcher · · Reply

    Amazing! Simple explanation. Many times better than reading RFC or googling..

  2. Thank you. I always try and add a little something to the RFC. While it has the final say, it’s not always that easy to read and understand.

  3. Nice and Simple Explanation. Thanks

    1. Thank you for reading and taking the time to comment!

  4. Well explained !!..thanks for the posts..

  5. Great explanation. This post did explain the reason for To-tag.

    What about From-tag? Why do we need it?
    From this explanation, I understand that to-tag and call-id can uniquely identify a dialog.
    If so, then why do we have from tag?

    1. That’s a good question and I don’t have a good answer. The original SIP RFC did not have from-tags and I can’t find anything that explains why they were added. If I had to guess I would say that it might help B2BUAs match dialogs, but even then I can’t find a good use case.

  6. Fotis Papadakis · · Reply

    Very easygoing and pleasant post. You should consider authoring a book🙂

    1. Thank you. I appreciate you saying that.

  7. I agree with Fotis’ comment above, it will be a great book for learning SIP in a comprehensive way!
    and thanks for this sip tag post😉

  8. very nicely written Sir!!

  9. Superb Explanation…

  10. Wow!!! I haven’t seen such easy explanation about SIP. On reading the second post itself I have subscribed to your newsletter. Thanks for your great effort and time. Keep posting :O

    1. Thanks! I am happy you like my blog!

  11. Great explanation however I remember i stuck in a situation where the dialog was maintained based on From and To URIs (to maintain backward compatibility with older RFC).

    We have a hard time with customer to explain them since customer was sending modified To-URI causing our application server to consider this call as a new call.

  12. Sanjay · · Reply

    Hi Andrew
    Excellent article on SIP tag. For the beginner like me, it was really helpful in getting the basics clear.

  13. Hi Andrew

    Thanks for the article.Could you pls tell what is the use of From tag apart from hairpinning(Calling onself)

    1. This has been discussed here before and no one can come up with a really good reason for a From tag. There may have been intentions in the minds of the specification writers that never came to fruition.

  14. Beautiful and simple explanations
    Thanks AJ

    1. Thanks for reading and commenting!

  15. Ahmed Hegazy · · Reply

    I don’t understand why the Call-ID can’t identify the request!
    Is it the same if I have 2 sip clients registered withe the same account?

    1. Call-ID is insufficient when call forking is used. You need something to distinguish the different dialogs — thus To and From tags.

  16. Hello Andrew,

    Just wanted to thank you for your amazing posts. I have been following your blog for a while now and must say that almost all i know about SIP i learned it from You.

    Your explanations are clear and examples are straight to the point.
    Have you ever thought about putting all your knowledge into a book maybe. Good SIP reference books are almost non-existent.


    1. Thanks! A book? As if I am not too busy as it is. This blog is a hobby. A book would be a career. 😉

  17. i have ought,can we create the dialog with out using remote tag value’s .?

    1. Why would you want to? You would be violating the protocol.

  18. Hi,

    Great Explanation.
    I have one doubt. Will this tag is automatically generated for each device or is it defined some where? The next time a session established for the same device will it change?

    1. It’s always new. Never reused.

  19. Great explanation! Thank you! Andrew, you have a really outstanding skill to explain complicated technical processes in easy words.

  20. Great stuff, Thank you

  21. Great and simple way of explanation. I am updating my skills set it’s a great help. ppl like you make the world much more simple.

  22. Mukesh · · Reply

    it great explanation and easy way of explaining the article with good examples. I have one query here , Is there any situation when we could use tag with call id?

    1. Not that I am aware of. It’s To and From headers only.

  23. nicolae · · Reply

    Thank you for the nice and concise explanation of SIP tags

  24. Surender Singh · · Reply

    realy great exaplanation about tag,

    Please also help in exaplanation on SIP headers.. Via,Route and record-route

  25. Jeetendra · · Reply

    Really to helpful for beginners.. i m very thankful to Mr Andrew that you have explain it ….

  26. as in the normal condition we use proxy server. so i want to know in what case sip uses redirect server and why a redirect server can not forward the message to next server why it sends back IP to user? thanks

    1. If a redirect server as to forward the message on, it would be a proxy server.

      Redirect servers are most often used as dial plan servers. They are fast and stateless.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: