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.

Note

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

or

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

Explanation

Informational

100

Trying

180

Ringing

181

Call is being forwarded

182

Queued

183

Session progress

Success

200

OK

Redirection

300

Multiple choices

301

Moved permanently

302

Moved temporarily

305

Use proxy

380

Alternative service

Client-Error

400

Bad request

401

Unauthorized

402

Payment required

403

Forbidden

404

Not found

405

Method not allowed

406

Not acceptable

407

Proxy authentication required

408

Request timeout

410

Gone

413

Request entity too large

414

Requested URL too large

415

Unsupported media type

416

Unsupported URI scheme

420

Bad extension

421

Extension required

423

Interval too brief

480

Temporarily not available

481

Call leg or transaction does not exist

482

Loop detected

483

Too many hops

484

Address incomplete

485

Ambiguous

486

Busy here

487

Request terminated

488

Not acceptable here

491

Request pending

493

Undecipherable

Server-Error

500

Internal server error

501

Not implemented

502

Bad gateway

503

Service unavailable

504

Server timeout

505

SIP version not supported

513

Message too large

Global Failure

600

Busy everywhere

603

Decline

604

Does not exist anywhere

606

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 ph1.company.com:5060;branch=z9hG4bK83749.1

SIP Message headers

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

 

To: Bob <sip:[email protected]>

 

Call-ID: [email protected]

 

CSeq: 1 INVITE

 

Contact: <sip:[email protected]>

 

Content-Type: application/sdp

 

Content-Length: ...

 
 

Blank line between SIP header fields and body

v=0

SDP body in SIP message

o=alice 2890844526 28908445456 IN IP4 172.18.193.102

 

s=Session SDP

 

c=IN IP4 172.18.193.102

 

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 ph1.company.com:5060;branch=z9hG4bK83749.1

SIP message headers

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

 

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

 

Call-ID: [email protected]

 

CSeq: 1 INVITE

 

Content-Length: ...

 
 

Blank line between SIP header fields and body

v=0

SDP body in 200 OK response

o=bob 3800844316 3760844696 IN IP4 172.18.193.109

 

s=Session SDP

 

c=IN IP4 172.18.193.109

 

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

Explanation

From

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.

To

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.

Call-ID

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.

Cseq

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.

Via

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

Contact

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

Allow

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

Supported

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.

Require

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.

Content-Type

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.

Content-Length

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