Jan. 14, 2011, 1:13 p.m.
posted by who
SIP Message Building Blocks
This section describes the structure of SIP messages, addressing schemes, and key header fields. Much of the SIP messages and header field syntax is identical to HTTP/1.1. Refer to RFC 3261 for an in-depth description.
You can find all RFCs online at http://www.ietf.org/rfc/rfcxxx.txt, where xxxx is the number of the RFC. If you do not know the number of the RFC, you can try searching by topic at http://www.rfc-editor.org/cgi-bin/rfcsearch.pl.
SIP addresses identify a user or a resource within a network domain. SIP addresses are typically referred to as SIP URI. A SIP URI is typically an e-mail-type address with a format such as one of the following:
The user field identifies a user by name, such as john.doe, or by telephone number, such as 4081234567, within the context of a domain or a host. The port is an optional field. If no port is specified, the default port for a SIP URI is 5060. If a port is explicitly specified, you must use it. Examples of SIP URIs are as follows:
The public SIP address of a user or a resource is referred to as an Address-of-Record (AOR). An AOR is a SIP URI that is globally routable and points to a domain whose location service can map the AOR to another SIP URI, where the user might be located.
RFC 3261 specifies a secure SIP URI format also known as a SIPS URI. The format of a SIPS URI is as follows:
The default port for a SIPS URI is 5061.
SIP messages can be broadly divided into SIP requests and responses, as further defined in the sections that follow.
SIP requests are messages that are sent from client to server to invoke a SIP operation. RFC 3261 defines six SIP requests or methods that enable UA and proxy to locate users and initiate, modify, and tear down sessions:
A server sends a SIP response to a client to indicate the status of a SIP request that the client previously sent to the server. The UAS or proxy generates SIP responses in response to a SIP request that the UAC initiates. SIP responses are numbered from 100 to 699. SIP responses are grouped as 1xx, 2xx, and so on through 6xx. SIP responses are classified as provisional and final.
A provisional response indicates progress by the server but does not indicate the final outcome as a result of processing the SIP request. The 1xx class of SIP response indicates provisional status. A final response indicates the termination and the final status of a SIP request. All 2xx, 3xx, 4xx, 5xx, and 6xx class responses are final, specifically:
Figure lists the various SIP responses per RFC 3261.
SIP Message Structure
A SIP message consists of the following:
You must terminate the start-line, each message-header line, and the empty line by a Carriage Return Line Feed (CRLF) sequence.
The start-line for a SIP request is a Request-Line. The start-line for a SIP response is a Status-line.
The Request-Line specifies the SIP method, the Request-URI, and the SIP version. The Status-line describes the SIP version, the SIP response code, and an optional reason phrase. The reason phrase is a textual description of the 3-digit SIP response code.
Figure shows the various components of a SIP request message.
*The information in Figure is taken from RFC 3261.
Figure shows the structure of a SIP response message.
*The information presented in Figure is taken from RFC 3261.
A SIP message is composed of header fields (defined in RFC 3261) that convey the signaling and routing information for the SIP network entities. SIP follows the same format as defined for an HTTP header (RFC 2616). Each header field consists of a field name followed by a colon (:) and the field value.
Figure describes the functions of the key SIP headers
SIP Transactions and Dialog
A SIP signaling session between two user agents might be comprised of one or more SIP transactions. A SIP transaction occurs between a UAC and a UAS, which might involve one or more intermediate SIP servers such as proxy or redirect. A SIP transaction comprises all messages that begin with the SIP request initiated from the UAC, until a final response (that is, a non-1xx response) is received from the UAS. A SIP transaction is identified by the Call-ID, via-branch, local tag, remote tag, and CSeq value. Figure shows a SIP REGISTER transaction between a UAC and a registrar server. The SIP transaction comprises a SIP request message followed by one or more SIP response messages. In this case, the REGISTER message is a SIP request sent from the UAC to the registrar server. 100 Trying and 200 OK are SIP responses. The user agent server sends SIP responses to the UAC indicating the status of the SIP request.
SIP REGISTER Transaction
A SIP transaction can result in the establishment, modification, or termination of a media session. The establishment of a session also results in a SIP signaling relationship between the peers, known as a dialog. A dialog is defined as a peer-to-peer SIP relationship between two or more UAs that persists for the duration of the session. A dialog is the state identified by the Call-ID, the local tag, and the remote tag. Not all SIP transactions affect the state of a dialog. Multiple SIP transactions might take place within the context of a SIP dialog. Each SIP transaction within a dialog has a sequentially increasing integer value in the CSeq header.
A successful INVITE-200 OK transaction results in the establishment of a SIP dialog and an audio or video session between the participants. After the media session is established, you can exchange INVITE messages within the existing dialog context using the same Call-ID and tags to modify the media session parameters. Later, you can tear down the dialog using a BYE transaction or transfer it to another device using a REFER transaction, again within the dialog context.
A successful SUBSCRIBE-200 OK transaction results in the establishment of a dialog. The SUBSCRIBE request is discussed in the "SIP Extensions" section.
Dialog and transaction states are maintained at the SIP UAs or endpoints. SIP servers such as proxy and redirect typically maintain state for the duration of the transactionthat is, they maintain only the transaction state. The transaction state is held for at least 32 seconds per RFC 3261. SIP servers such as proxies and redirect servers maintain the transaction state, but not the dialog state, which enables them to serve many SIP endpoints. Because the network servers maintain only transaction state, a proxy that is going out of service within a cluster affects the transactions that are in progress but has no effect on established dialogs.
Transport Layer Protocols for SIP Signaling
SIP transactions use either connection-oriented transport layer protocols such as TCP or Stream Control Transmission Protocol (SCTP) or connectionless protocols such as UDP. For connectionless protocols, SIP specifies that the SIP application start retransmission timers to retry the SIP requests to guarantee end-to-end reliability.
SIP defines a SIPS URI, which indicates the need for securing the end-to-end SIP signaling information in a network. SIP RFC 3261 specifies the use of TLS or IPsec to encrypt the signaling information.