SIP Message Building Blocks

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, 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

SIP Addressing

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:

sip:[email protected]:port

sip:[email protected]:port

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:

sip:[email protected]

sip:[email protected]

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:

sips:[email protected]:port


sips:[email protected]:port

The default port for a SIPS URI is 5061.

SIP Messages

SIP messages can be broadly divided into SIP requests and responses, as further defined in the sections that follow.

SIP Requests

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:

  • INVITEAn INVITE method indicates that the recipient user or service is invited to participate in a session. You can also use this method to modify the characteristics of a previously established session. The INVITE message body might include the description of the media session being set up or modified, encoded per SDP. A successful response (200 OK response) to an INVITE indicates the willingness of the called party to participate in the resulting media session.

  • ACKAn ACK request confirms that the UAC has received the final response to an INVITE request. ACK is used only with INVITE requests. ACK is sent end to end for a 200 OK response. The previous hop proxy or UAC sends ACK for other final responses. The ACK request can include a message body with the final session description if the INVITE request did not contain a session description.

  • OPTIONSA UA uses the OPTIONS request to query a UAS about its capabilities. If the UAS is capable of delivering a session to the user, it responds with the capability set of the UAS.

  • BYEA UA uses BYE to request the termination of a previously established session.

  • CANCELThe CANCEL request enables UACs and network servers to cancel an in-progress request, such as INVITE. This does not affect completed requests in which the UAS had already sent final responses.

  • REGISTERA client uses a REGISTER request to register its current location information corresponding to the AOR of the user with SIP servers.

SIP Responses

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:

  • A 2xx class response indicates successful processing of the SIP request.

  • A 3xx class response indicates that the SIP request needs to be redirected to another UAS for processing.

  • A 4xx, 5xx, or 6xx class of response indicates failure in processing of the SIP request.

Figure lists the various SIP responses per RFC 3261.

SIP Response Table

Class of Response

Status Code








Call is being forwarded




Session progress






Multiple choices


Moved permanently


Moved temporarily


Use proxy


Alternative service



Bad request




Payment required




Not found


Method not allowed


Not acceptable


Proxy authentication required


Request timeout




Request entity too large


Requested URL too large


Unsupported media type


Unsupported URI scheme


Bad extension


Extension required


Interval too brief


Temporarily not available


Call leg or transaction does not exist


Loop detected


Too many hops


Address incomplete




Busy here


Request terminated


Not acceptable here


Request pending





Internal server error


Not implemented


Bad gateway


Service unavailable


Server timeout


SIP version not supported


Message too large

Global Failure


Busy everywhere




Does not exist anywhere


Not acceptable

SIP Message Structure

A SIP message consists of the following:

  • A start-line

  • One or more header fields

  • An empty line indicating the end of header fields

  • An optional message body

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.

SIP Request Components

INVITE sip:[email protected] SIP/2.0

Request Line

Via: SIP/2.0/UDP;branch=z9hG4bK83749.1

SIP Message headers

From: Alice <sip:[email protected]>;tag=1234567


To: Bob <sip:[email protected]>


Call-ID: [email protected]




Contact: <sip:[email protected]>


Content-Type: application/sdp


Content-Length: ...


Blank line between SIP header fields and body


SDP body in SIP message

o=alice 2890844526 28908445456 IN IP4


s=Session SDP


c=IN IP4


t=0 0


m=audio 49170 RTP/AVP 0


a=rtpmap:0 PCMU/8000


*The information in Figure is taken from RFC 3261.

Figure shows the structure of a SIP response message.

SIP Response Components

SIP/2.0 200 OK

Status (Response) Line

Via: SIP/2.0/UDP;branch=z9hG4bK83749.1

SIP message headers

From: Alice <sip:[email protected]>;tag=1234567


To: Bob <sip:[email protected]>;tag=9345678


Call-ID: [email protected]




Content-Length: ...


Blank line between SIP header fields and body


SDP body in 200 OK response

o=bob 3800844316 3760844696 IN IP4


s=Session SDP


c=IN IP4


t=0 0


m=audio 48140 RTP/AVP 0


a=rtpmap:0 PCMU/8000


*The information presented in Figure is taken from RFC 3261.

SIP Headers

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

Key SIP Headers

SIP Header



This header indicates the identity of the initiator of a SIP request. The From header is usually the AOR of the sender. It consists of a SIP or SIPS URI and an optional display name.


This header indicates the desired recipient of a SIP request. The To header is usually the AOR of the recipient. The SIP request might not always be delivered to the "desired" recipient because of redirection or forwarding. The To header consists of a SIP or SIPS URI and an optional display name.


This header field identifies a series of SIP messages. Call-ID must be identical for all SIP requests and responses sent by either UA within a dialog.


This header is composed of an integer value and method-name. This header identifies, orders, and sequences SIP requests within a dialog. The Cseq header also differentiates between message retransmissions and new messages.


The Via header indicates the path taken by the request and identifies where the response needs to be sent.


This header identifies a SIP or SIPS URI where the UA wants to receive a new SIP request.


The Allow header lists the set of SIP methods supported by the UA that is generating the message.


This header lists all SIP extensions supported by the UA. SIP extensions are SIP RFCs other than RFC 3261. SIP extensions are represented as option tags such as 100rel defined in RFC 3262.


This header has similar semantics to the Supported header, but the support of the SIP extension at the remote UA is a must for the transaction to be processed.


This header indicates the type of the message body that is attached to a SIP request or response. This header must be present if the SIP message has a body.


This header indicates the size of the message body (in decimal) in a SIP message. This header is a must when SIP messages are carried over stream-based protocols such as TCP.

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.

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows