As we confuse the known parameters functionality, here is snippet with explanation in Session Initiation Protocol.

1. SIP- CallID, Cseq, Via-Branch,
FROM/To-TAG Role Play
- Usage Clarifications
Sridhar Kumar N

2. Transaction vs Dialog

3. Call-ID
 Call-ID is so called Call Identifier.
 Globally Unique Identifier. Cryptographically random identifiers(RFC 1750) is
adopted to avoid traditional pseudo-random number pitfalls. Using
cryptographically random identifiers provides some protection against session
hijacking and reduces the likelihood of unintentional Call-ID collisions.
 It MUST be the same for all requests and responses sent by either UA in a
dialog
 Call-IDs are case-sensitive and are simply compared byte-by-byte.
 A single multimedia conference can give rise to several calls with different
Call-IDs, for example, if a user invites a single individual several times to the
same (long-running) conference.
Examples:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4

4. Reuse of Call-ID

5. Cseq - Command Sequence
 The CSeq header field serves as a way to identify and order transactions. It
consists of a sequence number and a method.
 CSeq or Command Sequence contains an integer and a method name. The CSeq
number is incremented for each new request within a dialog and is a traditional
sequence number.
 32-bit unsigned integer and MUST be less than 2**31. i.e within a single call, one
request a second for about 136 years before needing to wrap around. Also client
can choose from 1 or 31 most significant bits of a 32-bit second clock as an initial
sequence number
 Exception - ACK and CANCEL
 Example:
CSeq: 4711 INVITE

6. Via-Branch
 The Via header field value MUST contain a branch parameter. The branch parameter
value MUST be unique. The exceptions to this rule are CANCEL and ACK for non-2xx
responses.
 The branch ID inserted by an element compliant with this specification MUST always
begin with the characters "z9hG4bK". These 7 characters are used as a magic
cookie (7 is deemed sufficient to ensure that an older RFC 2543 implementation
would not pick such a value), so that servers receiving the request can determine
that the branch ID was constructed in the fashion described by this specification
(that is, globally unique).
 It now plays the role of a unique transaction identifier. This requirement was added
to identify that the branch was created in accordance with RFC 3261 and not the
older RFC 2543 which did not require global uniqueness.
 It’s Case Insensitive
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

7. Via-Branch & Cseq –Response Matching
 A response matches a client transaction under two conditions:

8. From-TAG
 In the old SIP RFC, RFC 2543, the from-tag was optional and in RFC 3261, from-tag is
mandatory.
 Call-ID is not necessarily unique for all new requests from the same UAC. It can be reused when,
for example, retrying an INVITE with credentials after receiving a 401 Unauthorized response.
From RFC 3261 §8.1.1.4:
Note that when requests are retried after certain failure responses ,these retried requests are
not considered new requests, and therefore do not need new Call-ID header fields;
 Also For SIP Dialogue, It makes things symmetrical. It's easier to think about the dialog ID when
your dialog always has a local-tag and remote-tag, whether you were the initiator of the dialog or
not. And It's also easier to distinguish between initial and subsequent requests in a dialog, i.e. if
no to-tag then it must be an initial request
 Also It’s Serves purpose for “The Join header is used to logically join an existing SIP dialog with a
new SIP dialog SIP dialog (using call-id, to-tag, and from-tag)
i.e Actually we don’t have clarity that why FROM-TAG is mandatory. But RFC made mandatory. Hence
all are following. May be in future, we can see the fruits. But currently It’s purpose is joining with
Call- ID and TO-tag forms Dialogue Identity.

9. TO-Tag
 It’s a must add TAG parameter in response message by UAS.
 The "tag" parameter serves as a general mechanism to distinguish multiple instances
of a user identified by a single SIP URL. As proxies can fork requests, the same
request can reach multiple instances of a user (mobile and home phones, for
example). As each can respond, there needs to be a means to distinguish the
responses from each at the caller.
 The situation also arises with multicast requests. If a request is sent via multicast, it
is possible that it will generate multiple responses from different servers. but vary in
the To tag
 The "tag" MUST be added by UAS, registrars and redirect servers, but MUST NOT be
inserted into responses forwarded upstream by proxies. The "tag" is added for all
definitive responses for all methods, and MAY be added for informational responses
from a UAS or redirect server.
 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.

10. SIP FORKING
 Definition of fork : is an operation whereby a process creates a copy of
itself.
 In SIP terminology , Single SIP call is send to multiple SIP endpoints in i.e
Laptop or Mobile or Landline etc or If a request is sent via multicast
 The forking of SIP requests means that multiple dialogs can be established
from a single request. This also explains the need for the two-sided dialog
identifier; without a contribution from the recipients, the originator could not
disambiguate the multiple dialogs established from a single request.
 A proxy MUST NOT insert a tag into the To header field of a 1xx or 2xx
response if the request did not contain one. A proxy MUST NOT modify the
tag in the To header field of a 1xx or 2xx response.

11. Together Played to Serve:
 Dialogs are identified using Call-ID, From tag, and To tag. Messages that have
these three identifiers same belong to the same dialog.
 CSeq header field is used to order messages, in fact it is used to order messages
within a dialog. The number must be monotonically increased for each message
sent within a dialog otherwise the peer will handle it as out of order request or
retransmission.
 When a user agent receives a request, it checks the Call-ID against those of in-
progress calls. If the Call-ID was found, it compares the tag value of To with the
user's tag and rejects the request if the two do not match.
 If the From header, including any tag value, matches the value for an existing call
leg, the server compares the CSeq header field value. If less than or equal to the
current sequence number, the request is a retransmission. Otherwise, it is a new
request. If the From header does not match an existing call leg,a new call leg is
created.

12. Summary
 The combination of the To tag, From tag, and Call-ID completely defines a peer-to-
peer SIP relationship between Caller and Callee and is referred to as a dialog.
 The BranchID and Cseq serves purpose to identify the transaction and order delivery.
 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.
 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.

13. Courtesy:- RFC & Books
 RFC3261 - SIP: Session Initiation Protocol
 RFC3581 - An Extension to the Session Initiation Protocol (SIP) for Symmetric
Response Routing
 http://www.kamailio.org/docs/tutorials/sip-introduction/
 https://telconotes.wordpress.com/2013/03/13/sip-transactions-vs-dialogs/
 https://stackoverflow.com/questions/26264207/what-is-the-use-of-from-tag-in-
sip-request
 Internet Multimedia Communications Using SIP: A Modern Approach Including
 SIP: Understanding the Session Initiation Protocol

14. Thanks for Listening
Be Happy and Make Happy
@how? given by my aasaan:-
#Go below what you have # Dream above what you have # First love what you have
#Spread info what you have # Get info what others have # Help as per what you have