Introduction to SIP |
43 |
Poison answers with a reply, which is also sent outside of any dialog, with a new Call-ID and From tag (an instant message response is never sent in a 200 OK reply to a MESSAGE request).
MESSAGE sip:chebychev@academy.ru SIP/2.0 Via SIP/2.0/TCP dist.probablilty.org:5060 ;branch=z9hG4bK4526245
Max-Forwards: 70
To: P. L. Chebychev <sip:chebychev@academy.ru>
From: M. Poisson <sip:s.possion@dist.probability.org> ;tag=14083
Call-ID: lk34452k592520 CSeq: 2321 MESSAGE
Allow: ACK, INVITE, CANCEL, BYE, NOTIFY, SUBSCRIBE, MESSAGE Content-Type: text/plain
Content-Length: 2
Well, hello there to you, too!
This receives a 200 OK reply:
SIP/2.0 200 OK
Via SIP/2.0/TCP dist.probablilty.org:5060 ;branch=z9hG4bK4526245;received=24.32.1.3
To: P. L. Chebychev <sip:chebychev@academy.ru> ;tag=mc3bg5q77wms
From: M. Poisson <sip:s.possion@dist.probability.org>; tag=14083
Call-ID: lk34452k592520 CSeq: 2321 MESSAGE Content-Length: 0
Other presence packages define other sets of information that can be requested by watchers from presence servers. Further examples of SIP presence and instant messaging can be found in Chapter 8.
2.5 Message Transport
As discussed in Chapter 1, SIP is an application layer protocol in the Internet Multimedia Protocol stack shown in Figure 1.1. RFC 3261 defines the use of TCP, UDP, or TLS transport. An extension document describes how SCTP can be used. How a SIP message is transported using these four protocols will be described in the following sections. The compression of SIP for transport over low bandwidth connections, such as wireless, is discussed in Chapter 7.
2.5.1UDP Transport
When using UDP, each SIP request or response message is carried in a single UDP datagram or packet. For a particularly large message body, there is a com-
44 |
SIP: Understanding the Session Initiation Protocol |
pact form of SIP that saves space in representing some header fields with a single character. This is discussed in Chapter 6. Figure 2.5 shows a SIP BYE request exchange during an established SIP session using UDP.
The source port is chosen from a pool of available port numbers (above 49172), or the default SIP port of 5060 can be used. The lack of handshaking or acknowledgment in UDP transport means that a datagram could be lost along with a SIP message. The checksum, however, enables UDP to discard errored datagrams, allowing SIP to assume that a received message is complete and errorfree. The reliability mechanisms built into SIP to handle message retransmissions are described in Section 3.7. The reply is also sent to port 5060, or the port number listed in the top Via header field.
UDP provides the simplest transport for user agents and servers, and allows them to operate without the transport layer state. However, UDP offers no congestion control. A series of lost packets on a heavily loaded IP link can cause retransmissions, which in turn produce more lost packets and can push the link into congestion collapse. Also, UDP may only be used for SIP when the message (and its response) is known to be less than the Message Transport Unit (MTU) size of the IP network. For simple SIP messages, this is not a problem. However, for large messages containing multiple message bodies and large header fields, this can be a problem. In this case, TCP must be used, since SIP does not support fragmentation at the SIP layer.
Figure 2.5 Transmission of a SIP message using UDP.
Introduction to SIP |
45 |
2.5.2TCP Transport
TCP provides a reliable transport layer, but at a cost of complexity and transmission delay over the network. The use of TCP for transport in a SIP message exchange is shown in Figure 2.6. This example shows an INVITE sent by a user agent at 100.101.103.103 to a type of SIP server called a redirect server at 200.201.202.203. A SIP redirect server does not forward INVITE requests like a proxy, but looks up the destination address and instead returns that address in a redirection class (3xx) response. The 302 Moved Temporarily response is acknowledged by the user agent with an ACK message. Not shown in this figure is the next step, where the INVITE would be resent to the address returned by the redirect server. As in the UDP example, the well-known SIP port number of 5060 is chosen for the destination port, and the source port is chosen from an available pool of port numbers. Before the message can be sent, however, the TCP connection must be opened between the two end points. This transport layer datagram exchange is shown in Figure 2.6 as a single arrow, but it is actually a three-way handshake between the end points as shown in Figure 1.2. Once the connection is established, the messages are sent in the stream.
The Content-Length header field is critical when TCP is used to transport SIP, since it is used to find the end of one message and the start of the next. When TCP or another stream-based transport is used, Content-Length is a required header field in all requests and responses.
To send the 302 Moved Temporarily response, the server typically opens a new TCP connection in the reverse direction, using 5060 (or the port listed in
Figure 2.6 Transmission of a SIP message using TCP.
46 |
SIP: Understanding the Session Initiation Protocol |
the top Via header field) as the destination port. The acknowledgment ACK is sent in the TCP stream used for the INVITE. Because this concludes the SIP session, the connection is then closed. If a TCP connection closes during a dialog, a new one can be opened to send a request within the dialog, such as a BYE request to terminate the media session.
As previously mentioned, TCP provides reliable transport and congestion control. It can also transport SIP messages of arbitrary sizes. The disadvantages of TCP include the setup delay in establishing the connection and the need for servers to maintain this connection state at the transport layer.
2.5.3TLS Transport
SIP can use TLS [7] over TCP the same way as for encrypted transport, with the additional capabilities of authentication. In Section 4.2.1 the secure SIP URI scheme (sips) will be discussed, which uses TLS transport. The default SIP port number for TLS transport is port 5061.
If TLS is used between two proxies, each proxy may have a certificate allowing mutual authentication. However, if a client does not have a certificate, TLS can be used in conjunction with another authentication mechanism, such as SIP digest, to allow mutual authentication.
The SIP use of TLS takes advantage of both the encryption and authentication services. However, the encryption and authentication is only useful on a single hop. If a SIP request takes multiple hops (i.e., includes one or more proxy servers), TLS is not useful for end-to-end authentication. SIP proxies must support TLS and will likely use TLS for long-lived connections. TLS will be covered more in Chapter 14.
2.5.4SCTP Transport
An extension to SIP defines the use of SCTP [8] with SIP to provide reliable stream-based transport with some advantages over TCP transport for a messagebased protocol such as SIP. First, it has built-in message segmentation, so that individual SIP messages are separated at the transport layer. With TCP, the SIP protocol must use the Content-Length calculation to delineate messages. If a TCP connection is being shared by a number of SIP transactions and dialogs, the “head of line blocking” problem discussed in Section 1.2.4.5 can cause the buffer to contain valid SIP messages that could be processed by the server while the retransmission takes place. Due to its message level delineation, SCTP is able to continue to forward messages to the application layer while simultaneously requesting a retransmission of a dropped message. Note that this is only a problem when multiple applications are multiplexed over a single TCP connection. An example of this is a TCP link between two signaling proxy servers. For a user