Session Initiation Protocol: the Right Choice for VoIP
Session Initiation Protocol (SIP) is a standard designed by the Internet Engineering Task Force (IETF) to serve VoIP services. It’s an application layer protocol that can operate over UDP (User Datagram Protocol) or TCP (Transmission Control Protocol). SIP, currently at version 2, is defined in RFC 3261.
Simplicity and flexibility are the primary characteristics of SIP. However, despite its structural simplicity it can be used to establish any kind of session between end-systems (known as User Agents in SIP). SIP is responsible for session setup and tear down; supported sessions include:
- Two party sessions
- Multiparty sessions
- Multicast sessions
Besides audio, sll supported sessions can contain video and data as well. SIP also provides the means for User Agents to negotiate session capabilities and decide about session behavior. Moreover, sophisticated services, such as UA portability and video conferencing can be well served by SIP.
Why Choose SIP?
The new version of SIP has much to offer:
- Adaptable to network changes: Can easily adjust to different network infrastructures and provide non-stop reliable service.
- Scalable: The magnitude of serving capability can be easily increased and also designed in such a way as to provide full redundancy architecture.
- Text based, hence ease of programming: Due to its simple presentation, SIP services can be programmed more easily. Since it’s similar to HTTP, SIP shares many cause codes and message header syntax.
- Carries most of the intelligence at the end devices: Session control begins from the end devices, hence, edge devices participate in the session establishment and tear down setup.
- Can easily and quickly support the requirements of new services: Easier and quicker adaptation to the session control requirements of new services. Via SDP, SIP can transport almost any service requirements, even transport other protocol messages.
- Can effectively support mobile and ported users and services: SIP’s interaction with server farms supports mobile users by providing location-based services, presence and follow-me services. The service is following the user anywhere the user is located.
SIP Terminology … Get to Know the “SIP Language”
Before getting into more details about SIP, lets take a look at the most important SIP terms:
- Transaction: A complete sequence of messages consisting of a request, several possible provisional responses and one final response.
- User Agent: It’s a SIP end point. It can be either a client or server. User Agent Client (UAC) is the originate side of the transaction that generates the request and User Agent Server (UAS) is the terminating side that generates the responses.
- SIP URI: SIP addressing scheme can use an IP address or a Fully Qualified Domain Name (FQDN) to refer to UAs. If the later is used, then DNS is needed for translating Domain Name to real IP address.
- SIP Proxy: Network node that routes SIP transactions by using the information of the SIP URI.
- Dialogue: A SIP dialogue consists of several transactions. Therefore a SIP dialogue represents a long-term peer-to-peer session between UAs.
What SIP Messages Look Like
SIP messages are text-based messages similar to HTTP. They consist of a Request line, various Header fields, and the body field (optional). The image below shows SIP’s general format.
SIP: general format
Starting line: SIP’s first line is called Request-Line in requests and Status-Line in responses. It consists of the method used along with the destination SIP URI. The following is an example of a SIP starting line:
Request-Line: INVITE sip:[email protected]:5060;user=phone SIP/2.0 Method: INVITE
Message Header fields: These fields contain useful information for efficiently routing SIP messages. They also include information about UA’s supported capabilities and sequencing of messages. A sample Header field block is provided below:
Via: SIP/2.0/UDP 10.176.22.24:5060;branch=z9hG4bK06224778770000019777. From: sip:[email protected];user=phone>;tag=46dfdde0-a545-0ab0141c To: <sip:[email protected]:5060;user=phone> Call-ID: [email protected] CSeq: 1 INVITE Accept: application/sdp,application/isup,multipart/mixed,application/ Contact: <sip:10.176.22.24:5060> MIME-Version: 1.0 Supported: timer Supported: 100rel Max-Forwards: 70 Session-Expires: 1800 Allow: ACK,INFO,BYE,CANCEL,INVITE,OPTIONS,NOTIFY,PRACK,UPDATE Content-Type: application/sdp Content-Length: 360
Message Body: The body of the message may carry session descriptions (SDP). This part of the SIP message is used by UAs during negotiation and settlement of media related information like IP addresses, port numbers and codecs. A sample message body can be seen below:
Session Description Protocol Version (v): 0 Connection information (c): IN IP4 10.176.3.10 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 5588 RTP/AVP 8 18 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:18 G729/8000 . . Media Attribute (a): sendrecv
Introducing Basic SIP Message Headers
Via: Consists of SIP version, transport protocol, SIP URI and branch code. Its purpose is to indicate the address that responses to a request should be forwarded. The branch parameter is used to identify the transaction. Example:
Via: SIP/2.0/UDP 10.176.22.24:5060;branch=z9hG4bK06224778770005001
From: Consists of the SIP URI of the originator of the request. It also contains a random generated tag for identification purposes. Example:
From: <sip:[email protected];user=phone>; tag=46dfdde0-a545-0ab0141c
To: Contains the destination’s SIP URI. Example:
To: <sip:[email protected]:5060;user=phone>
Call-ID: Is a unique reference, identifying a complete dialogue between SIP peers. Example:
Call-ID: [email protected]
CSeq: Contains an integer that counts the requests within a dialog and a method name. Example:
CSeq: 1 INVITE
Contact: Instructs SIP UAs where to send future requests. Example:
Supported:Optional header field used to specify SIP options that the sender supports. Example:
Allow: Another optional header field listing all methods supported by the SIP UA that generated the message. Example:
Content-Type: Indicates the type of content within the body of the SIP message. Example:
Introducing Basic SDP Fields
Version (v=): Defines the SDP’s version (currently only v=0 exists)
Connection information (c=): Specifies the IP address where media is expected to arrive. Example:
Connection information (c): IN IP4 10.176.3.10
Media (m=): Indicates the type of media (e.g. audio, video), the RTP port for the media packets, transport protocol for the media and a list of supported payload formats (e.g. payload type number 8= G.711 a-law codec, number 18=G.729 codec). Example:
Media Description, name and address (m): audio 5588 RTP/AVP 8 18
Media attributes (a=): Can be either media (e.g. “rtpmap” is a media attribute describing payload types) or session attributes (e.g. “sendrecv” is a session attribute specifying media flow direction. Example:
Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:18 G729/8000 Media Attribute (a): sendrecv
Block Diagram of SIP Transactions
The image below presents a basic SIP Dialogue consisting of an INVITE and a BYE method.
Basic INVITE and BYE methods
The INVITE method is more like a 3-way handshake consisting of the INVITE request, the final response to the INVITE which is a 200 OK message, and an ACK transaction with no response. The BYE transaction consists of the BYE request and its response coming as a 200 OK message.
Not convinced SIP is right for you? There are other options, however SIP is the preffered choice for telecom companies for Broadband VoIP service session control, and its usage is growing more and more each day. My prediction is that SIP will eventually dominate call control protocols, so start benefiting from all that SIP has to offer.