The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent. A Via header field value is added only after the transport that will be used to reach the next hop has been selected. When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server.
Branch Parameter:
The branch parameter value MUST be unique across space and time for all requests sent by the User Agent. The exceptions to this rule are CANCEL and ACK for non-2xx responses. A CANCEL request will have the same value of the branch parameter as the request it cancels. An ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges.
The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of RFC 2543. 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). Beyond this requirement, the precise format of the branch token is implementation-defined. JSIP defines a convenience function to generate unique branch identifiers at {@link javax.sip.Transaction#getBranchId()}
A common way to create the branch value is to compute a cryptographic hash of the To tag, From tag, Call-ID header field, the Request-URI of the request received (before translation), the topmost Via header, and the sequence number from the CSeq header field, in addition to any Proxy-Require and Proxy-Authorization header fields that may be present. The algorithm used to compute the hash is implementation-dependent.
Via Processing Rules
- Generating Requests (UAC): The client originating the Request must insert into the Request a ViaHeader containing its host name or network address and, if not the default port number, the port number at which it wishes to receive Responses. (Note that this port number can differ from the UDP source port number of the Request.) A fully-qualified domain name is recommended.
- Request Forwarding by Proxies: The proxy MUST insert a Via header field value into the copy before the existing Via header field values. This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch, and contain the requisite magic cookie. Note that this implies that the branch parameter will be different for different instances of a spiraled or looped request through a proxy. If a proxy server receives a Request which contains its own address in a ViaHeader, it must respond with a 482 (Loop Detected) Response. A proxy server must not forward a Request to a multicast group which already appears in any of the ViaHeaders. This prevents a malfunctioning proxy server from causing loops. Also, it cannot be guaranteed that a proxy server can always detect that the address returned by a location service refers to a host listed in the ViaHeader list, as a single host may have aliases or several network interfaces.
- Response processing by UAC and proxies:
- The first ViaHeader should indicate the proxy or client processing this Response. If it does not, discard the Response. Otherwise, remove this ViaHeader.
- If there is no second ViaHeader, this Response is destined for this client. Otherwise, the processing depends on whether the ViaHeader contains a maddr parameter or is a receiver-tagged field.
- If the second ViaHeader 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 ViaHeader does not contain a maddr parameter and is a receiver-tagged ViaHeader, send the Response to the address in the received parameter, using the port indicated in the port value, or using port 5060 if none is present.
- If neither of the previous cases apply, send the Response to the address indicated by the host value in the second ViaHeader.
- Sending Responses (UAS):
- If the first ViaHeader in the Request contains a maddr parameter, send the Response to the multicast address listed there, using the port indicated, 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 address in the first ViaHeader differs from the source address of the packet, send the Response to the actual packet source address, similar to the treatment for receiver-tagged ViaHeaders.
- If neither of these conditions is true, send the Response to the address contained in the host value. If the Request was sent using TCP, use the existing TCP connection if available.
Via Parameters: A Via header field value contains the transport protocol used to send the message, the client's host name or network address, and possibly the port number at which it wishes to receive responses. Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the protocol still indicates "SIP", and the transport protocol is TLS. A Via header field value can also contain parameters such as "maddr", "ttl", "received", and "branch". A proxy sending a Request to a multicast address must add the maddr parameter to its ViaHeader, and should add the ttl parameter. If a server receives a Request which contained an maddr parameter in the topmost ViaHeader, it should send the Response to the multicast address listed in the maddr parameter. The received parameter is added only for receiver-added ViaHeaders.
Two Via header fields are equal if their sent-protocol and sent-by fields (including port) are equal, both have the same set of parameters, and the values of all parameters are equal.
@author BEA Systems, NIST
@version 1.2