An Introduction to SIP, Part 1: Meet SIP

by Emmanuel Proulx
02/07/2006

Abstract

The Session Initiation Protocol (SIP) is a signaling protocol with great significance to the
telecommunications industry. This article provides a general and technical introduction to
SIP, and shows how SIP is an important enabler of telecommunication solutions.

Introduction

I once had a great idea for a piece of software that would "float" on top of an application,
providing assistance. No, this would not be a dumb "help" system. It would be a live
technical support agent, conferenced in over the Internet. At the time I was told "there are
no tools, libraries, protocols, or bandwidth for doing that!"

Times have changed.

Many people have broadband at home, over DSL, cable, and other technologies. Good
quality tools and libraries abound, both commercial and open source. Standards enable
applications. Now is the time for the cool ideas to be executed.

Meet SIP

Let me introduce you to SIP, the Session Initiation Protocol. SIP is a lightweight,
extensible, request/response protocol for starting communication sessions between two
end-points. Does this sound familiar? SIP was inspired by HTTP and SMTP
conceptually, although its intent is different. You can compare SIP messages to the CB
lingo 10-codes, and Q-signals.

Figure 1. Lingo used to manage a CB call

In this example, the real message is surrounded with special call negotiation messages.

SIP was supplied by the IETF in 1999, and then revised in 2002. It is described in RFC
3261. Much of the information about SIP in this article was distilled from that RFC.
Many extensions to SIP exist, and many of these extensions can be found in this list of
SIP-related RFCs and drafts.

What are the benefits of SIP? Generally it is used by two end-points to negotiate a "call."
By negotiate I mean the medium (text, voice, other), the transport (usually RTP, Real
Time Protocol), and the encoding (codec). Once the negotiation is successful, the two
end-points use the selected method for talking to each other—independently of SIP. Once
the "call" is over, SIP is used to indicate a disconnection. Therefore, SIP is best used as a
signaling mechanism. SIP and its extensions also provide related functions such as instant
messaging, registration, and presence.

An end-point in the SIP jargon is called a user agent. This could be a "soft phone," an
instant messenger, an IP phone, or even a cellular phone. Centralized services are
provided by server user agents such as registrars, proxies, or application servers.

SIP sounds very simple, and it is. But while this simplicity is important for the protocol to
be stable, it doesn't limit the usefulness of the protocol, which has found a rich set of
applications areas.

Think of HTTP for example. The protocol definition by itself is tiny. But the ways to use
it are unlimited. SIP is also extensible. Dozens of extensions already exist for SIP that
cover a wide range of applications. Let's now take a more in-depth look at SIP and why
it's important.

Is SIP Significant?

It's been said that what HTTP did for the Web, SIP will do for telecommunications.

SIP has colossal repercussions in the telecommunications industry. Cellular-technology

companies have decided to standardize on SIP for all future applications. VoIP (Voice
over IP) vendors, Internet telephony, and instant messaging applications (for example,
Microsoft MSN Messenger) are all standardizing on SIP.

Some signaling protocols as well as peer-to-peer technology already exist. This begs the
question, what advantage does SIP have over them? SIP offers some definite advantages:

• Stability: The protocol has been used for years now and is rock-solid.
• Speed: This UDP-based tiny protocol is extremely efficient.
• Flexibility: This text-based protocol is easily extensible.
• Security: Features like encryption (SSL, S/MIME) and authentication are
available. Extensions to SIP offer other security features.
 • Standardization: With the entire telecommunications industry moving to it, SIP is
rapidly becoming the standard. Other technologies may have some advantages
over SIP, but they lack global adoption.

This means that if you want your applications to interoperate with other tools, equipment,
and servers, SIP is the best way to go. Vendors are serious about interoperability and
meet on a regular basis to test their products together. These meetings are called SIPit for
SIP Interoperability Tests (previously Bakeoff, which was renamed because Pillsbury
sued).

Anatomy of a SIP Call

Let's now look more closely at the technology. SIP is usually transported over UDP
although TCP must also be supported by SIP tools. A SIP message contains two parts:

• An envelope that describes a request or the result of a request (response) in the

form of header fields.
• An optional payload or content that contains data about the request.

The envelope is text, but the content may be text or binary.

As an example, let's dissect a typical SIP call. In this scenario, User A wants to call User
B. Figure 2 illustrates this call:
Figure 2. A typical SIP call

All these messages are explained here:

1. User Agent A sends a SIP request INVITE

"INVITE" to User Agent B to indicate sip:UAB@example.com
User A's wish to talk to User B. This
request contains the details of the voice SIP/2.0
streaming protocol. The Session
Description Protocol (SDP) is used in the Via: SIP/2.0/UDP 10.20.30.40:5060
payload for this purpose. The SDP message From: UserA
contains a list of all media codecs <sip:UAA@example.com>;tag=589304
supported by User A. (These codecs are
using RTP for transport.) To: UserB <sip:UAB@example.com>

Call-ID: 8204589102@example.com
 CSeq: 1 INVITE

Contact: <sip:UserA@10.20.30.40>

Content-Type: application/sdp

Content-Length: 141

v=0

o=UserA 2890844526 2890844526 IN IP4

10.20.30.40

s=Session SDP

c=IN IP4 10.20.30.40

t=3034423619 0

m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000
2. User Agent B reads the request and tells SIP/2.0
User Agent A it has been received.
100 Trying

From: UserA
<sip:UAA@example.com>;tag=589304

To: UserB <sip:UAB@example.com>

Call-ID: 8204589102@example.com

CSeq: 1 INVITE

Content-Length: 0
3. While the phone rings, User Agent B SIP/2.0
sends provisional messages (ringing) to
180 Ringing
User Agent A just so it doesn't time out
and give up. From: UserA
<sip:UAA@example.com>;tag=589304

To: UserB
<sip:UAB@example.com>;tag=314159

Call-ID: 8204589102@example.com

CSeq: 1 INVITE

Content Length: 0
4. Eventually User B decides to accept the SIP/2.0
call. At this point User Agent B sends an
200 OK
OK response to User Agent A. In the
payload of the response, there's another From: UserA
SDP message. It contains a set of media <sip:UAA@example.com>;tag=589304
codecs that are supported by both user
agents. At this point both parties are To: UserB
<sip:UAB@example.com>;tag=314159
officially in the call. All types of SIP
requests are accepted using 200-type Call-ID: 8204589102@example.com
responses.
CSeq: 1 INVITE

Contact: <sip:UserB@10.20.30.41>

Content-Type: application/sdp

Content-Length: 140

v=0

o=UserB 2890844527 2890844527 IN IP4

10.20.30.41

s=Session SDP

c=IN IP4 10.20.30.41

t=3034423619 0

m=audio 3456 RTP/AVP 0

a=rtpmap:0 PCMU/8000
5. User Agent A finally confirms with an ACK
ACK message. There are no retries and no sip:UAB@example.com SIP/2.0
response messages for this request type,
even if the message is lost. ACK is only Via: SIP/2.0/UDP 10.20.30.41:5060
used in the case of an INVITE message.
Route: <sip:UserB@10.20.30.41>

From: UserA
<sip:UAA@example.com>;tag=589304

To: UserB
<sip:UAB@example.com>;tag=314159

Call-ID: 8204589102@example.com

CSeq: 1 ACK

Content-Length: 0
6. Both user agents are now connected RTP packets of audio data going in both
using the method selected in the last SDP
message.
7. At the end of the communication
session, one of the users hangs up. At this
point this user's user agent sends a new
request BYE. This message can be sent by Via: SIP/2.0/UDP 10.20.30.41:5060
any of the parties.
directions over ports 49170 & 3456 using
PCMU/8000 encoding.
BYE
sip:UAB@example.com SIP/2.0
To: UserB
<sip:UAB@example.com>;tag=314159

From: UserA
<sip:UAA@example.com>;tag=589304

Call-ID: 8204589102@example.com

CSeq: 1 BYE

Content-Length: 0
8. The other user's user agent accepts the SIP/2.0
request and replies with an OK message. 200 OK
The call is disconnected.
To: UserB
<sip:UAB@example.com>;tag=314159

From: UserA
<sip:UAA@example.com>;tag=589304

Call-ID: 8204589102@example.com

CSeq: 1 BYE

Content-Length: 0

The first line of a SIP message contains the type of message and the version of SIP used
(2.0). In requests, this line also contains an address called the SIP URI. This represents
the destination of the message.

This example illustrates the use of request messages INVITE, ACK, and BYE, as well as
the 200 OK response message. Many other messages exist in SIP. Here are a few
requests:

Message Usage
INVITE Call a user agent, transfer a call.
ACK Confirm the call.
BYE End a call.
CANCEL End a call that hasn't been OK'd yet.
 Provide a registrar service with a contact address and the alias that can be
used instead. For example, the address sip:UAA@example.com is an alias for
REGISTER
sip:UserA@10.20.30.40 in the previous example. The registrar server
example.com can then forward calls for UAA to the address 10.20.30.40.
Ask a user agent for its "capabilities" (for example, messages and codecs it
OPTIONS
understands).

Now here are some often-used response messages:

Message Usage
The message has been received but not processed by the end
100 Trying
user agent yet. Please wait.
The message has been received by the end user agent, which is
180 Ringing
prompting the user. Please wait.
200 OK The message was accepted by the end user.
301 Moved Permanently & The address of the user agent has changed; here's the new
302 Moved Temporarily permanent or temporary address, in the Contact field.
A generic error message. The client doesn't understand the
400 Bad Request
message.
401 Unauthorized & 407
Proxy Authentication Please try again with credentials.
Required
404 Not Found The user you're trying to reach doesn't exist or isn't registered.
The other party isn't responding. This means a SIP message
was never OK'd. All retries were dropped as well. It doesn't
408 Request Timeout
mean that the phone rang for too long (phones can ring
forever).

Messages use similar types of header fields. Here are a few of them:

Header
Usage
field
From Sender of the SIP request.
Receiver of the SIP request. This is often the same as the SIP URI (can be an
To
"alias" or a real address).
Contact Real address of the user agent.
Call-ID No, this isn't the phone number of the caller. It uniquely represents the whole
call, or dialog, between the two user agents. All related SIP messages use the
same Call-ID. For example, when a user agent receives a BYE message, it
 knows which call to hang up based on the Call-ID.
Sequence number of a message. This is unique inside a single dialog or Call-
ID. This is used to differentiate between new messages and "retries." Retries
CSeq
happen when an initial message isn't OK'd in time, and are sent at regular
intervals.
Content-
The MIME type for the payload inside the message.
Type
Content- Size in bytes of the payload. The envelope and the payload are separated by an
Length empty line.

Additional headers exist for message-routing-related functions, like Via, Route, and
Record-Route. Many headers provide capabilities such as Accept, User-Agent, and
Supported. Other headers provide security such as Authorization, Privacy, and WWW-
Authenticate. Many more headers exist. Also, many of these fields have a short syntax
(for example, From = f, To = t, and so on)