Menu
I have a trivial doubt with respect to SIP. I tried googling and referring many books, but still I am not able to find a solid reason for adding from-tag in SIP request.
Example SIP request (Snapshot from rfc-3261)
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application//sdp
Content-Length: 142
As per rfc-3261:
Dialog can be identified using from-tag, to-tag and call-id.
I know the precise reason for adding to-tag and call-id. What I don't know is,
603
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.
From header is the logical identity of the user that will be used for auth/callerid (i.e. sip:[email protected]). The Contact header is the TCP/IP network address where you should send all packets to (i.e. sip:[email protected]:43085;transport=tcp) - IP/port/transport info.
Branch - ID and Tag Tags are used by the UAC to distinguish multiple final responses from different UAS. A UAS cannot resolve whether the request has been forked or not. Therefore, it need to add a tag.
The CSeq header specifies the number of requests of each type that have been sent. For example, CSeq: 15 INVITE means that is the 15th invite request. The number increases by one for each additional request of the same type. Format. 1CSeq: (number) (request type)
@Ani, here is one realistic example when you can say why "From-tag" is really required. In case of re-INVITE, when it was done from the called party/terminating number from the initial INVITE, the To and From header gets exchanged, and so the From tag and To-Tag.
Example link: Example re-invite flow
Assume A sends initial INVITE to B, From header has A's tag (local tag), To Header has B's tag (remote tag). later after call accepted, B sends a re-INVITE to A, in this re-INVITE, From Header has B's sip uri with B's tag, and TO header has A's sip uri with A's tag. Now for this case B's tag become local tag and A's tag become remote tag.
Now if you think if From-tag wasn't there in initial INVITE itself, there will be no To-Tag in re-INVITE, and difficult to identify the recipient.
54
[EDIT] About the meaning of the attribute "tag" inside the header field From, here is your answer : http://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/
Removing the tag would simply invite servers to consider messages as duplicated.
To resume what Andrew Prokop wrote :
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.
37
From Tag is UAC's identifier for the Dialog other than the Call-Id. Combined they provide unique nature to the dialog.
Other use cases
Hair-pinning / Tromboning - although different services, they both rely on the FROM tag to distinguish the call direction based on Dialog tags.
Sending Multiple INVITE for interworking with PSTN where the IAM and subsequent Digits in SAM are carried in the INVITE and the same FROM Header. Helps downstream Gateways to match it specific dialogs. RFC 3578 has more details. So in this case the FROM Tag for the same call helps the GW determine how to handle the INVITE containing further digits.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
