Section 18 Transport

The transport layer is responsible for the actual transmission of
   requests and responses over network transports.  This includes
   determination of the connection to use for a request or response in
   the case of connection-oriented transports.
   The transport layer is responsible for managing persistent
   connections for transport protocols like TCP and SCTP, or TLS over
   those, including ones opened to the transport layer.  This includes
   connections opened by the client or server transports, so that
   connections are shared between client and server transport functions.
   These connections are indexed by the tuple formed from the address,
   port, and transport protocol at the far end of the connection.  When
   a connection is opened by the transport layer, this index is set to
   the destination IP, port and transport.  When the connection is
   accepted by the transport layer, this index is set to the source IP
   address, port number, and transport.  Note that, because the source
   port is often ephemeral, but it cannot be known whether it is
   ephemeral or selected through procedures in [4], connections accepted
   by the transport layer will frequently not be reused.  The result is
   that two proxies in a "peering" relationship using a connection-
   oriented transport frequently will have two connections in use, one
   for transactions initiated in each direction.
   It is RECOMMENDED that connections be kept open for some
   implementation-defined duration after the last message was sent or
   received over that connection.  This duration SHOULD at least equal
   the longest amount of time the element would need in order to bring a
   transaction from instantiation to the terminated state.  This is to
   make it likely that transactions are completed over the same
   connection on which they are initiated (for example, request,
   response, and in the case of INVITE, ACK for non-2xx responses).
   This usually means at least 64*T1 (see Section 17.1.1.1 for a
   definition of T1).  However, it could be larger in an element that
   has a TU using a large value for timer C (bullet 11 of Section 16.6),
   for example.
   All SIP elements MUST implement UDP and TCP.  SIP elements MAY
   implement other protocols.
      Making TCP mandatory for the UA is a substantial change from RFC
      2543.  It has arisen out of the need to handle larger messages,
      which MUST use TCP, as discussed below.  Thus, even if an element
      never sends large messages, it may receive one and needs to be
      able to handle them.
18.1 Clients
18.1.1 Sending Requests
   The client side of the transport layer is responsible for sending the
   request and receiving responses.  The user of the transport layer
   passes the client transport the request, an IP address, port,
   transport, and possibly TTL for multicast destinations.
   If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP. If this causes a change in the transport protocol from the
   one indicated in the top Via, the value in the top Via MUST be
   changed.  This prevents fragmentation of messages over UDP and
   provides congestion control for larger messages.  However,
   implementations MUST be able to handle messages up to the maximum
   datagram packet size.  For UDP, this size is 65,535 bytes, including
   IP and UDP headers.
      The 200 byte "buffer" between the message size and the MTU
      accommodates the fact that the response in SIP can be larger than
      the request.  This happens due to the addition of Record-Route
      header field values to the responses to INVITE, for example.  With
      the extra buffer, the response can be about 170 bytes larger than
      the request, and still not be fragmented on IPv4 (about 30 bytes
      is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when
      path MTU is not known, based on the assumption of a 1500 byte
      Ethernet MTU.
   If an element sends a request over TCP because of these message size
   constraints, and that request would have otherwise been sent over
   UDP, if the attempt to establish the connection generates either an
   ICMP Protocol Not Supported, or results in a TCP reset, the element
   SHOULD retry the request, using UDP.  This is only to provide
   backwards compatibility with RFC 2543 compliant implementations that
   do not support TCP.  It is anticipated that this behavior will be
   deprecated in a future revision of this specification.
   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
   standardization when the need arises.
   These rules result in a purposeful limitation of multicast in SIP.
   Its primary function is to provide a "single-hop-discovery-like"
   service, delivering a request to a group of homogeneous servers,
   where it is only required to process the response from any one of
   them.  This functionality is most useful for registrations.  In fact,
   based on the transaction processing rules in Section 17.1.3, the
   client transaction will accept the first response, and view any
   others as retransmissions because they all contain the same Via
   branch identifier.
   Before a request is sent, the client transport MUST insert a value of
   the "sent-by" field into the Via header field.  This field contains
   an IP address or host name, and port.  The usage of an FQDN is
   RECOMMENDED.  This field is used for sending responses under certain
   conditions, described below.  If the port is absent, the default
   value depends on the transport.  It is 5060 for UDP, TCP and SCTP,
   5061 for TLS.
   For reliable transports, the response is normally sent on the
   connection on which the request was received.  Therefore, the client
   transport MUST be prepared to receive the response on the same
   connection used to send the request.  Under error conditions, the
   server may attempt to open a new connection to send the response.  To
   handle this case, the transport layer MUST also be prepared to
   receive an incoming connection on the source IP address from which
   the request was sent and port number in the "sent-by" field.  It also
   MUST be prepared to receive incoming connections on any address and
   port that would be selected by a server based on the procedures
   described in Section 5 of [4].
   For unreliable unicast transports, the client transport MUST be
   prepared to receive responses on the source IP address from which the
   request is sent (as responses are sent back to the source address)
   and the port number in the "sent-by" field.  Furthermore, as with
   reliable transports, in certain cases the response will be sent
   elsewhere.  The client MUST be prepared to receive responses on any
   address and port that would be selected by a server based on the
   procedures described in Section 5 of [4].
   For multicast, the client transport MUST be prepared to receive
   responses on the same multicast group and port to which the request
   is sent (that is, it needs to be a member of the multicast group it
   sent the request to.)
   If a request is destined to an IP address, port, and transport to
   which an existing connection is open, it is RECOMMENDED that this
   connection be used to send the request, but another connection MAY be
   opened and used.
   If a request is sent using multicast, it is sent to the group
   address, port, and TTL provided by the transport user.  If a request
   is sent using unicast unreliable transports, it is sent to the IP
   address and port provided by the transport user.
18.1.2 Receiving Responses
   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 are any client transactions in existence, the client
   transport uses the matching procedures of Section 17.1.3 to attempt
   to match the response to an existing transaction.  If there is a
   match, the response MUST be passed to that transaction.  Otherwise,
   the response MUST be passed to the core (whether it be stateless
   proxy, stateful proxy, or UA) for further processing.  Handling of
   these "stray" responses is dependent on the core (a proxy will
   forward them, while a UA will discard, for example).
18.2 Servers
18.2.1 Receiving Requests
   A server SHOULD be prepared to receive requests on any IP address,
   port and transport combination that can be the result of a DNS lookup
   on a SIP or SIPS URI [4] that is handed out for the purposes of
   communicating with that server.  In this context, "handing out"
   includes placing a URI in a Contact header field in a REGISTER
   request or a redirect response, or in a Record-Route header field in
   a request or response.  A URI can also be "handed out" by placing it
   on a web page or business card.  It is also RECOMMENDED that a server
   listen for requests on the default SIP ports (5060 for TCP and UDP,
   5061 for TLS over TCP) on all public interfaces.  The typical
   exception would be private networks, or when multiple server
   instances are running on the same host.  For any port and interface
   that a server listens on for UDP, it MUST listen on that same port
   and interface for TCP.  This is because a message may need to be sent
   using TCP, rather than UDP, if it is too large.  As a result, the
   converse is not true.  A server need not listen for UDP on a
   particular address and port just because it is listening on that same
   address and port for TCP.  There may, of course, be other reasons why
   a server needs to listen for UDP on a particular address and port.
   When the server transport receives a request over any transport, it
   MUST examine the value of the "sent-by" parameter in the top Via
   header field value.  If the host portion of the "sent-by" parameter
   contains a domain name, or if it contains an IP address that differs
   from the packet source address, the server MUST add a "received"
   parameter to that Via header field value.  This parameter MUST
   contain the source address from which the packet was received.  This
   is to assist the server transport layer in sending the response,
   since it must be sent to the source IP address from which the request
   came.
   Consider a request received by the server transport which looks like,
   in part:
      INVITE sip:bob@Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060
   The request is received with a source IP address of 192.0.2.4.
   Before passing the request up, the transport adds a "received"
   parameter, so that the request would look like, in part:
      INVITE sip:bob@Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4
   Next, the server transport attempts to match the request to a server
   transaction.  It does so using the matching rules described in
   Section 17.2.3.  If a matching server transaction is found, the
   request is passed to that transaction for processing.  If no match is
   found, the request is passed to the core, which may decide to
   construct a new server transaction for that request.  Note that when
   a UAS core sends a 2xx response to INVITE, the server transaction is
   destroyed.  This means that when the ACK arrives, there will be no
   matching server transaction, and based on this rule, the ACK is
   passed to the UAS core, where it is processed.
18.2.2 Sending Responses
   The server transport uses the value of the top Via header field in
   order to determine where to send a response.  It MUST follow the
   following process:
      o  If the "sent-protocol" is a reliable transport protocol such as
         TCP or SCTP, or TLS over those, the response MUST be sent using
         the existing connection to the source of the original request
         that created the transaction, if that connection is still open.
         This requires the server transport to maintain an association
         between server transactions and transport connections.  If that
         connection is no longer open, the server SHOULD open a
         connection to the IP address in the "received" parameter, if
         present, using the port in the "sent-by" value, or the default
         port for that transport, if no port is specified.  If that
         connection attempt fails, the server SHOULD use the procedures
         in [4] for servers in order to determine the IP address and
         port to open the connection and send the response to.
      o  Otherwise, if the Via header field value contains a "maddr"
         parameter, the response MUST be forwarded to the address listed
         there, using the port indicated in "sent-by", or port 5060 if
         none is present.  If the address is a multicast address, 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.
      o  Otherwise (for unreliable unicast transports), if the top Via
         has a "received" parameter, the response MUST be sent to the
         address in the "received" parameter, using the port indicated
         in the "sent-by" value, or using port 5060 if none is specified
         explicitly.  If this fails, for example, elicits an ICMP "port
         unreachable" response, the procedures of Section 5 of [4]
         SHOULD be used to determine where to send the response.
      o  Otherwise, if it is not receiver-tagged, the response MUST be
         sent to the address indicated by the "sent-by" value, using the
         procedures in Section 5 of [4].
18.3 Framing
   In the case of message-oriented transports (such as UDP), if the
   message has a Content-Length header field, the message body is
   assumed to contain that many bytes.  If there are additional bytes in
   the transport packet beyond the end of the body, they MUST be
   discarded.  If the transport packet ends before the end of the
   message body, this is considered an error.  If the message is a
   response, it MUST be discarded.  If the message is a request, the
   element SHOULD generate a 400 (Bad Request) response.  If the message
   has no Content-Length header field, the message body is assumed to
   end at the end of the transport packet.
   In the case of stream-oriented transports such as TCP, the Content-
   Length header field indicates the size of the body.  The Content-
   Length header field MUST be used with stream oriented transports.
18.4 Error Handling
   Error handling is independent of whether the message was a request or
   response.
   If the transport user asks for a message to be sent over an
   unreliable transport, and the result is an ICMP error, the behavior
   depends on the type of ICMP error.  Host, network, port or protocol
   unreachable errors, or parameter problem errors SHOULD cause the
   transport layer to inform the transport user of a failure in sending.
   Source quench and TTL exceeded ICMP errors SHOULD be ignored.
   If the transport user asks for a request to be sent over a reliable
   transport, and the result is a connection failure, the transport
   layer SHOULD inform the transport user of a failure in sending.