The document provides an in-depth examination of the Session Initiation Protocol (SIP) via header, detailing its functions, parameters, and differences from other headers. It emphasizes the significance of the via header in routing responses and handling NAT concerns, introducing concepts such as the 'magic cookie' for unique transaction identification. Additionally, it covers various parameters like maddr, ttl, received, and rport that enhance the functionality of the via header in different networking scenarios.

1. Session Initiation
Protocol(SIP)
Via Header
- Detailed Coverage
Sridhar Kumar N

2. Takeaways
 Why Via?
 List of Via-Parameters & role
 Magic Cookie
 Role played in Response
 Via vs Other Headers
 Addressing NAT Concerns
 Summary

3. Why Via ?
 SIP is based on an HTTP-like request/response transaction
model. So Request originator has to receive the response back.
Between request travels one or more proxies and reaches
destination finally, further returned back to originator. During
each proxy travel Via header records the route taken based on
stack methodologies and uses the same route one by one(Last
in First Out) usually called TOP-VIA to reach back to Originator.
i.e Consider Starting journey from home to unknown preferred
destination for Picnic. So During travel, we usually memorize few
Landmarks to reach home Back successfully without wastage of
time.
 The Via header field indicates the transport used for the
transaction and identifies the location where the response is
to be sent. So It contains the transport protocol, the client's
host name or network address, and possible the port number
at which it wishes to receive responses. Default -5060
Example:-
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

4. Mandatory Header vs Methods

5. Via –Parameters
 A Via header field value can contain parameters such as
 sent-protocol (UDP,TCP,SCTP)
 sent-by
 Branch
 maddr
 ttl
 Rport (RFC3581)
 received
 via-hidden (RFC2543- deprecated/was used for encryption purpose)

6. Via : Sent-protocol & Sent-by
Sent-Protocol:-
 The protocol name and protocol version in the header field MUST be SIP and
2.0(Latest version), respectively with transport protocol details.
i.e SIP 1.0 (RFC2543) and SIP 2.0 (RFC3261)
Sent-by:-
 IP address or host name, and port. The usage of an FQDN is RECOMMENDED.
 When a response arrives at a stateless proxy, the proxy MUST inspect the sent-by
value in the first (topmost) Via header field value. If that address matches the
proxy, (it equals a value this proxy has inserted into previous requests) the proxy
MUST remove that header field value from the response and forward the result to
the location indicated in the next Via header field value.
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

7. Via:Branch
What is Magic Cookie
 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).
 This avoids the complex and bug-laden transaction identification rules from RFC 2543.
 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

8. Via:maddr & ttl
Maddr:-
 The intent is that maddr is really for multicast. This need not be an IP address, since DNS names can refer to multicast addresses
(sip.mcast.net) and not to use SRV processing.
 A client that sends a request to a multicast address MUST add the "maddr" parameter to its Via header field value containing the
destination multicast address, and for IPv4, SHOULD add the "ttl“ parameter with a value of 1. Usage of IPv6 multicast is not defined in
this specification, and will be a subject of future.
 Originally, the maddr in the URI was the same - meant just for multicast. However, in the absence of a suitable loose routing mechanism,
it got continually abused until the common case was for that, and not for multicast at all. Doing that properly required SRV processing.
Now, we have thankfully deprecated the usage of maddr for that purpose, but older rfc2543 elements might construct such URIs, and so
RFC3263 continues to perform the SRV processing for the maddr in the request URI, when present.
Note:-
Service Records(SRV): SIP using NAPTR and SRV DNS Records to locate Server IP details.
ttl:-
 The ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address
and the transport protocol is UDP. For example, to specify a call to alice@atlanta.com using multicast to 239.255.255.1 with a ttl of 15,
the following URI would be used. If not specified default value is 1.
sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15

9. Via:Received & Rport
Received:-
 During reply response, Received parameter is added. It’s actual source address from which the packet was
received.
Usually if Sent-By is FQDN, then IP address will be mentioned. if Sent-by is IP address, Received is not
added in response.
Request via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Response Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7;received=192.0.2.4
 Special usage for RPORT.
Rport:
 A new parameter for the Via header field, called "rport", that allows a client to request that the server send
the response back to the source IP address and port from which the request originated.
 RFC3581 specification is primarily aimed at allowing SIP responses to be received when a request is sent
through a NAT.
 To resolve traversal of NAT, we have many methods, among that one is RFC 3581. In that Rport Introduced :
To Solve NAT issue as shown below and etc.

10. Response Handling by UAC
 The branch parameter in the top Via header field is used for this purpose.
 A response matches a client transaction under two conditions:

11. Role Played in Response
 The proxy removes the topmost Via header field value from the response. If no Via header
field values remain in the response, the response was meant for this element and MUST NOT
be forwarded.
 When a response is received, the client transport examines the top Via header field value. If
the value of the "sent-by" parameter in that header field value does not correspond to a value
that the client transport is configured to insert into requests, the response MUST be silently
discarded.
 If there is no second Via header field, this response is destined for this client. Otherwise,
the processing depends on whether the Via field contains a "maddr" parameter or is a
receiver-tagged field.
 If the second Via header field contains a "maddr“ parameter, send the response to the
multicast address listed there, using the port indicated in "sent-by", or port 5060 if none is
present. The response SHOULD be sent using the TTL indicated in the "ttl" parameter, or with a
TTL of 1 if that parameter is not present. For
robustness, responses MUST be sent to the address indicated in the "maddr" parameter even if
it is not a multicast address.
 If the second Via header field does not contain a "maddr“ parameter and is a receiver-tagged
field send the message to the address in the "received" parameter, using the port indicated in
the "sent-by" value, or using port 5060 if none is present.
 If neither of the previous cases apply, send the message to the address indicated by the "sent-
by" value in the second Via header field.

12. Via vs Other Headers
 VIA vs CONTACT Headers
While the Via header field tells other elements where to send the response, the
Contact header field tells other elements where to send future requests with in
same dialog. i.e the sender is expecting to receive requests re-Invite, BYE, Ack.
 Via-BRANCH vs Cseq:-
Both are transaction Identifier. However Serves purpose in different manner.
The CSeq header field serves as a way to identify and order transactions. It
consists of a sequence number and a method. The method MUST match that
of the request(invite, bye, etc) and to differentiate between new requests and
request retransmissions.
The branch ID parameter in the Via header field values serves as a global unique
transaction identifier, and provides Magic Cookie also used by proxies to detect
loops.

13. Summary
 Identifies which transport Protocol is used.
 The branch ID parameter in the Via header field values serves as a global
unique transaction identifier
 Loop detection i.e This prevents request looping and ensures replies take the
same path as the requests,
ErrorCode -482 Loop Detected
The server received a request with a Via path containing itself.
 Serve the purpose to rectify the NAT issue using rport features.

14. Courtesy:- RFC & Books
 RFC3261 - SIP: Session Initiation Protocol
 RFC3581 - An Extension to the Session Initiation Protocol (SIP) for Symmetric
Response Routing
 https://mailarchive.ietf.org/arch/msg/sip/RRLaJoxbVgbetbAWvLtheITT7O0
 https://www.z9hg4bk.org/
 https://www.dialogic.com/webhelp/BorderNet2020/1.1.0/WebHelp/sip_invite_m
ethod.htm
 Internet Multimedia Communications Using SIP: A Modern Approach Including
 SIP: Understanding the Session Initiation Protocol

15. 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