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.

      1. What about call forwarding to VM. In that scenario if the To-tag and call ID are tracked only, no traces of the MO would apprear, since the To-tag would be added by VM system and the new From-tag would be changed probably by any B2BUA. Just thinking out loud.

  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.

  27. Chaudhary · · Reply

    what is TO tag & From Tag in SIP

    1. It’s all in the article.

  28. Hi Andrew,
    so if i’m doing forking (for 2 end points) i need to use the same call-id for both 2 invites and different to header tags?
    if so when i will receive 200 OK from one of end points i should send cancel to other with same call id? it will not cause the all call to fail?

    1. Same callID and two different from tags. The UASs will add the to tags.

      I am not sure what you mean by “I.” Is “I” the endpoint or the proxy? Forking is done by a proxy.

  29. Thanks for your explanation, really it helped me a lot

  30. Edwin · · Reply

    very clear and useful, I wish you were one of RFC 3261’s writers… 🙂

  31. I thank you so much for all the work you did. I use your blog as quick reference lecture notes 🙂
    Keep your posts coming to Andrew

  32. Hi Andrew,
    Pretty well explained for Call-Id and To-Tag. However, I still wonder what the “From-tag” is required for? Since, we have one initiator of request, so when the response lands to the initiator of request it can easily be matched with the request at the initiator using To-tag (for UAS identification) and the Call-Id for UAC (since call-id is globally unique in time and space). So, why do we need From-Tag at all?


    1. About all I can think of is when the the sender and recipient are the same entity.

      1. Is it a valid scenario? In this case both To-Tag and From-Tag will be same. Also, won’t it create a loop?

      2. There is nothing wrong with writing a service that can be called from the same entity.

  33. The user agent that generates the initial INVITE to establish the session generates the unique Call-ID and From tag,and when it returns back with response it will add “To tag ” In “To” header field..let me correct if i am wrong…

    1. The client adds the From tag. The server adds the To tag. They are added by two different user agents.

      1. Yes sir you are right..now i am clear on that..thank you..

  34. Is the from tag something I can used to search on as a call traverses multiple proxies?

    1. Perhaps. All bets are off if you go through a proxy that acts as a B2BUA. In that case, the proxy may generate a different from-tag.

  35. santhi vardhan · · Reply

    thank you for explaining. Now i know about tags accurately 🙂

  36. What about From-tag? Why do we need it?

    1. I discuss that earlier in the comment stream.

  37. as always great explanation by andrew

  38. just don’t understand how a tag and a call_id can work together, if a fork change the call_id how can make an entire dialog unique

    1. A fork does not change the Call ID.

  39. It was helpful + Really good to see you responding to the comments after 4 years.
    where can i find all your sip related blogs ?

    1. I have hundreds of SIP related articles on this blog.

  40. Simple yet amazing explanation. on SIP forking in given example, it will create 2 different dialog or call leg? one for smart phone and another for PC sip client?

    1. Yes. Two separate dialogs.

  41. Hi,
    The From and To tags are unique for each call. So in a dialog why is that even Call-id is considered.
    Can dialog be just From + To Tags , can’t the call-id be ignored
    What is the importance of this Call-id

    1. Debarati Biswas · · Reply

      When there are tandem server involved the their tags may be referenced in existing call leg of single sip call but call id is the one and same for an entire sip call for that particular call leg.

  42. Hi Andrew,
    Thanks for your articles. Your article are great resource for me to understand SIP related stuff in a easier way.

    I have a question regarding To header when doing the shortCode translation.
    e.g. shortCode 111 will be translated to 3501111
    In the scenario:
    A–INVITE ->UAS with To header 111
    B<–INVITE–UAS UAS does number translation now To header is 350111

    In the following messages like 200/ACK/BYE/200-bye. I expect all the messages to A are still with header 111 since A should only know 111.
    But if A receives message with header uri 350111, what will A do for this case? From Header and Call-ID are still the same. But To header is changed. Will A treat it as a different dialog?


  43. very nice , helpful for me

  44. Marco Bungalski · · Reply

    Great explained. Thank you!

  45. Hemant Jha · · Reply

    Simplest way explanation of Tag and call I’d… Thank you so much.

  46. Shivesh Kumar · · Reply

    Thank you so much,

    It was the real content for which I was looking since long time. Explained so easily and effortlessly.

    You are Awesome !!

  47. Charlie · · Reply

    Simple and clear & understandable. Newbie in SIP July 2021

  48. Thank you Mr.Andrew! Your explanations help us understand better many things in the SIP world

  49. Fotios Papadakis · · Reply

    I enjoy reading you very much, and you have been a great help! My hat is off to you!

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: