SIP Introduction

Version 3.00

ZTE CORPORATION
ZTE Plaza, Keji Road South,
Hi-Tech Industrial Park,
Nanshan District, Shenzhen,
P. R. China
518057
Tel: (86) 755 26771900 800-9830-9830
Fax: (86) 755 26772236
URL: http://support.zte.com.cn
E-mail: doc@zte.com.cn
Contents

Chapter 1.................................................................1

Overview..................................................................1

Chapter 2.................................................................3

SIP Functions...........................................................3

Chapter 3.................................................................5

Components of SIP....................................................5
User agent client...................................................................5
User agent server .................................................................5

Chapter 4.................................................................7

Commands of SIP......................................................7

Chapter 5.................................................................9

Request Message Format of SIP.................................9

Chapter 6................................................................15

Response Message Format of SIP.............................15

Chapter 7................................................................17

Response Types of SIP.............................................17

Chapter 8................................................................19

SIP Call scenario analysis.........................................19

Sip session between a UA and proxy server.............................19
Typical Example of a SIP Session (end-to-end)........................23

Chapter 9................................................................27

Relation among Call, Dialog, Transaction & Message. .27

Chapter 10..............................................................29

Registration in SIP..................................................29

Chapter 11..............................................................31

Development of SIP-T and SIP-I...............................31

Chapter 12..............................................................33

SIP for Telephones (SIP-T)......................................33

Sip-T Sample Analysis..........................................................33
SIP-ISUP mapping and Call Flow............................................34

Chapter 13..............................................................37

SIP with encapsulated ISUP (SIP-I).........................37

Chapter 14..............................................................39

Difference between SIP-T and SIP-I.........................39

Chapter 15..............................................................41

SDP Introduction.....................................................41
Session Description Parameters.............................................42
Example Session (SDP)........................................................43

Chapter 16..............................................................45

SIP/H.323 comparison............................................45
Comparing the Basic Call Setup.............................................47
Comparison Conclusion........................................................49
Chapter 1

Overview

There are many applications of the Internet that require the

creation and management of a session, where a session is
considered an exchange of data between an association of
participants. The implementation of these applications is
complicated by the practices of participants: users may move
between endpoints, they may be addressable by multiple names,
and they may communicate in several different media -
sometimes simultaneously. Numerous protocols have been
authored that carry various forms of real-time multimedia
session data such as voice, video, or text messages.
Initially only the traditional switch-based telephone system was
the main medium for transmitting messages. However with the
advent of the Internet, the need was felt to fabricate a system,
which connects people over the IP based network. Different
communities put forward different solutions but the solution
presented by IETF (Internet Engineering Task Force ) was finally
accepted as the most general one.
Types of protocols needed for IP telephony:
Signaling Protocol:
To establish presence, locate users, set up, modify and tear
down sessions
Media Transport Protocols
For transmission of packetized audio/video
Supporting Protocols
Gateway Location, QoS, inter-domain AAA
(Authentication, Authorization, Accounting), address
translation, IP, etc.

Confidential and Proprietary Information of ZTE CORPORATION 1

 F I G U R E 1 S I P, H . 3 2 3 A N D H . 2 4 8

Signaling: SIP/SDP (IETF), H.323 (ITU-T)

Media: RTP (IETFs, adopted by ITU-T)
Transport: UDP, TCP, Stream Control Transmission Protocol
(SCTP RFC 2960)
Supporting protocols:
Media Gateway Control Protocol (Megaco, officially H.248)
The solution put forth by IETF was SIP (session initiation
protocol) defined in (RFC 3261). SIP has been the choice for
services related to Voice over IP (VoIP) in the recent past. SIP is
still growing and being modified to take into account all relevant
features as the technology expands and evolves. But it should
be noted that the job of SIP is limited to only the setup and
control of sessions. The details of the data exchange within a
session e.g. the encoding or codec related to an audio/video
media is not controlled by SIP and is taken care of by other
protocols.
SIP (Session Initiation Protocol) is a signaling protocol used to
create, manage and terminate sessions in an IP based network.
A session could be a simple two-way telephone call or it could be
a collaborative multi-media conference session. This makes
possible to implement services like voice-enriched e-commerce,
web page click-to-dial or Instant Messaging with buddy lists in
an IP based environment.

Confidential and Proprietary Information of ZTE CORPORATION 2

Chapter 2

SIP Functions

SIP is limited to only the setup, modification, and termination of

sessions. It serves four major purposes which are:
Establishment of user location (i.e. translating from a user's
name to their current network address).
Feature negotiation so that all of the participants in a session
can agree on the features to be supported among them.
Call management - for example adding, dropping, or
transferring participants.
Changing features of a session while it is in progress.
All of the other key functions are done with other protocols.
SIP is not a session description protocol (SDP) and it does not
provide conference control. Additionally, SIP is not a resource
reservation protocol and it has nothing to do with quality of
service (QoS). SIP can work in a framework with other protocols
to make sure these roles are played out - but SIP does not do
them. SIP can function with SOAP, HTTP, XML, VXML , WSDL,
UDDI, SDP and others.
SIP does not provide services. Rather, SIP provides primitives
that can be used to implement different services. For example,
SIP can locate a user and deliver an opaque object to his current
location. If this primitive is used to deliver a session description
written in SDP, for instance, the endpoints can agree on the
parameters of a session. If the same primitive is used to deliver
a photo of the caller as well as the session description, a "caller
ID" service can be easily implemented. As this example shows, a
single primitive is typically used to provide several different
services.
SIP does not offer conference control services such as floor
control or voting and does not prescribe how a conference is to
be managed. SIP can be used to initiate a session that uses
some other conference control protocol. Since SIP messages and
the session they establish can pass through entirely different
networks, SIP cannot, and does not, provide any kind of network
resource reservation capabilities.

Confidential and Proprietary Information of ZTE CORPORATION 3

The nature of the services provided make security particularly
important. To that end, SIP provides a suite of security services,
which include denial-of-service prevention, authentication (both
user to user and proxy to user), integrity protection, and
encryption and privacy services.
SIP works with both IPv4 and IPv6.

Confidential and Proprietary Information of ZTE CORPORATION 4

Chapter 3

Components of SIP

Entities interacting in a SIP scenario are called User Agents (UA)

User Agents may operate in two fashions -
User Agent Client (UAC) : It generates requests and send
those to servers.
User Agent Server (UAS): It gets requests, processes those
requests and generate responses.
Note: A single UA may function as both.

User agent client

In general we associate the notion of clients to the end users i.e.
the applications running on the systems used by people. It may
be a softphone application running a PC or a messaging device
in an IP phone. It generates a request when one tries
to call another person over the network and sends the request to
a server (generally a proxy server). We will go through the
format of requests and proxy servers in more detail later.

User agent server

Servers are in general part of the network. They possess a
predefined set of rules to handle the requests sent by clients.
Servers can be of several types:
Proxy Server: These are the most common type of server in
a SIP environment. When a request is generated, the exact
address of the recipient is not known in advance. So the
client sends the request to a proxy server. The server on
behalf of the client (as if giving a proxy for it) forwards the
request to another proxy server or the recipient itself. It
ensures that a request is sent to another entity "closer" to
the targeted user

Confidential and Proprietary Information of ZTE CORPORATION 5

 Redirect Server: A redirect server redirects the request back
to the client indicating that the client needs to try a different
route to get to the recipient. It generally happens when a
recipient has moved from its original position either
temporarily or permanently. It also helps improve signaling
path robustness and also reduces load on the proxy servers.
Registrar: One of the prime jobs of the servers is to detect
the location of a user in a network. The users have to
register their locations to a Registrar server. Users from time
to time refresh their locations by registering (sending a
special type of message) to a Registrar server.
Location Server: The addresses registered to a Registrar are
stored in a Location Server.

FIGURE 2 SIP COMPONENTS DISTRIBUTED ARCHITECTURE

Confidential and Proprietary Information of ZTE CORPORATION 6

Chapter 4

Commands of SIP

MESSAGE FUNCTION

Initializes conversation and invites

INVITE
a user to a call.

Acknowledge the invite message.

Acknowledgement is used to
ACK
facilitate reliable message

exchange for INVITEs

Terminates a connection between

BYE
users.

Terminates a request, or search,

for a user. It is used if a client

CANCEL
sends an INVITE and then changes

its decision to call the recipient.

Query the server capacity. Solicits

OPTIONS information about a server's

capabilities.

REGISTER Registers a user's current location

Used for mid-session signaling.

INFO Pass the interaction contents of a

certain call

Confidential and Proprietary Information of ZTE CORPORATION 7

 Chapter 5 Request Message Format of SIP

Chapter 5

Request Message Format

of SIP

In the previous SIP session example we have seen that requests

are sent by clients to servers. We will now discuss what that
request actually contains. The following is the format of INVITE
request as sent by user1.

The first line of the text-encoded message is called Request-

Line. It identifies that the message is a request.
Request-Line
Method SP Request-URI SP SIP-Version CRLF
[SP = single-space & CRLF=Carriage Return + Line Feed (i.e.
the character inserted when "Enter" key is pressed on the
computer keyboard)]
Method:
This specification defines six methods: REGISTER for
registering contact information, INVITE, ACK, and CANCEL
for setting up sessions, BYE for terminating sessions, and
OPTIONS for querying servers about their capabilities. SIP
extensions, documented in standards track RFCs, may define
additional methods.
Request-URI:

Confidential and Proprietary Information of ZTE CORPORATION 9

 The Request-URI is a SIP or SIPS URI or a general URI (RFC
2396 [5]). It indicates the user or service to which this
request is being addressed.
SIP-Version:
Both request and response messages include the version of
SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and
HTTP/1.1 replaced by SIP/2.0) regarding version ordering,
compliance requirements, and upgrading of version numbers.
To be compliant with this specification, applications sending
SIP messages MUST include a SIP-Version of "SIP/2.0". The
SIP-Version string is case-insensitive, but implementations
MUST send upper-case.
Here method is INVITE, request-uri is "user2@server2.com" and
SIP version is 2.

The following lines are a set of header fields.

Via:
It contains the local address of user1 i.e. pc33.server1.com
where it is expecting the responses to come.
The Via header field indicates the transport used for the
transaction and identifies the location where the response is to
be sent. A Via header field value is added only after the
transport that will be used to reach the next hop has been
selected (which may involve the usage of the procedures in [4]).
When the UAC creates a request, it MUST insert a Via into that
request. The protocol name and protocol version in the header
field MUST be SIP and 2.0, respectively. The Via header field
value MUST contain a branch parameter. This parameter is used
to identify the transaction created by that request. This
parameter is used by both the client and the server.
The branch parameter value MUST be unique across space and
time for all requests sent by the UA. The exceptions to this rule
are CANCEL and ACK for non-2xx responses. As discussed
below, a CANCEL request will have the same value of the branch
parameter as the request it cancels. As discussed in Section
17.1.1.3, an ACK for a non-2xx response will also have the same
branch ID as the INVITE whose response it acknowledges.
The uniqueness property of the branch ID parameter, to facilitate
its use as a transaction ID, was not part of RFC 2543.
The branch ID inserted by an element compliant with this
specification MUST always begin with the characters "z9hG4bK".
These 7 characters are used as a magic cookie (7 is deemed
sufficient to ensure that an older RFC 2543 implementation
would not pick such a value), so that servers receiving the
request can determine that the branch ID was constructed in the
fashion described by this specification (that is, globally unique).
Beyond this requirement, the precise format of the branch token
is implementation-defined. The Via header maddr, ttl, and sent-

Confidential and Proprietary Information of ZTE CORPORATION 10

 Chapter 5 Request Message Format of SIP

by components will be set when the request is processed by the

transport layer.
Max-Forward:
It is used to limit the number of hops that this request may take
before reaching the recipient. It is decreased by one at each
hop. It is necessary to prevent the request from traveling
forever in case it is trapped in a loop. If the Max-Forwards value
reaches 0 before the request reaches its destination, it will be
rejected with a 483(Too Many Hops) error response.
A UAC MUST insert a Max-Forwards header field into each
request it originates with a value that SHOULD be 70. This
number was chosen to be sufficiently large to guarantee that a
request would not be dropped in any SIP network when there
were no loops, but not so large as to consume proxy resources
when a loop does occur. Lower values should be used with
caution and only in networks where topologies are known by the
UA.

To:
It contains a display name "user2" and a SIP or SIPS URI
<user2@server2.com>
The To header field first and foremost specifies the desired
"logical" recipient of the request, or the address-of-record of the
user or resource that is the target of this request. This may or
may not be the ultimate recipient of the request. The To header
field MAY contain a SIP or SIPS URI, but it may also make use of
other URI schemes (the tel URL (RFC 2806 [9]), for example)
when appropriate. All SIP implementations MUST support the
SIP URI scheme. Any implementation that supports TLS MUST
support the SIPS URI scheme. The To header field allows for a
display name.
A UAC may learn how to populate the To header field for a
particular request in a number of ways. Usually the user will
suggest the To header field through a human interface, perhaps
inputting the URI manually or selecting it from some sort of
address book. Frequently, the user will not enter a complete
URI, but rather a string of digits or letters (for example, "bob").
It is at the discretion of the UA to choose how to interpret this
input. Using the string to form the user part of a SIP URI implies
that the UA wishes the name to be resolved in the domain to the
right-hand side (RHS) of the at-sign in the SIP URI (for instance,
sip:bob@example.com). Using the string to form the user part of
a SIPS URI implies that the UA wishes to communicate securely,
and that the name is to be resolved in the domain to the RHS of
the at-sign. The RHS will frequently be the home domain of the
requestor, which allows for the home domain to process the
outgoing request. This is useful for features like "speed dial" that
require interpretation of the user part in the home domain. The
tel URL may be used when the UA does not wish to specify the
domain that should interpret a telephone number that has been

Confidential and Proprietary Information of ZTE CORPORATION 11

SIP Introduction

input by the user. Rather, each domain through which the

request passes would be given that opportunity. As an example,
a user in an airport might log in and send requests through an
outbound proxy in the airport. If they enter "411 " (this is the
phone number for local directory assistance in the United
States), that needs to be interpreted and processed by the
outbound proxy in the airport, not the user's home domain. In
this case, tel:411 would be the right choice.
A request outside of a dialog MUST NOT contain a To tag; the
tag in the To field of a request identifies the peer of the dialog.
Since no dialog is established, no tag is present.

From:
It also contains a display name "user1" and a SIP or SIPS URI
<user1@server1.com>. It also contains a tag which is a pseudo-
random sequence inserted by the SIP application. It works as an
identifier of the caller in the dialog. The From header field
indicates the logical identity of the initiator of the request,
possibly the user's address-of-record. Like the To header field, it
contains a URI and optionally a display name. It is used by SIP
elements to determine which processing rules to apply to a
request (for example, automatic call rejection).
As such, it is very important that the From URI not contain IP
addresses or the FQDN of the host on which the UA is running,
since these are not logical names.
The From header field allows for a display name. A UAC SHOULD
use the display name "Anonymous", along with a syntactically
correct, but otherwise meaningless URI (like
sip:thisis@anonymous.invalid), if the identity of the client is to
remain hidden.
Usually, the value that populates the From header field in
requests generated by a particular UA is preprovisioned by the
user or by the administrators of the user's local domain. If a
particular UA is used by multiple users, it might have switchable
profiles that include a URI corresponding to the identity of the
profiled user. Recipients of requests can authenticate the
originator of a request in order to ascertain that they are who
their From header field claims they are.
Call-ID:
It is a globally unique identifier of the call generated as the
combination of a pseudo-random string and the softphone's IP
address.
The Call-ID is unique for a call. A call may contain several
dialogs. Each dialog is uniquely identified by a combination of
From, To and Call-ID.
The Call-ID header field acts as a unique identifier to group
together a series of messages. It MUST be the same for all
requests and responses sent by either UA in a dialog. It SHOULD
be the same in each registration from a UA.

12 Confidential and Proprietary Information of ZTE CORPORATION

 Chapter 5 Request Message Format of SIP

In a new request created by a UAC outside of any dialog, the

Call-ID header field MUST be selected by the UAC as a globally
unique identifier over space and time unless overridden by
method-specific behavior.
All SIP UAs must have a means to guarantee that the Call- ID
header fields they produce will not be inadvertently generated
by any other UA. Note that when request are retried after
certain failure responses that solicit an amendment to a request
(for example, a challenge for authentication), these retried
requests are not considered new requests, and therefore do not
need new Call-ID header fields; see Section 8.1.3.5.
Use of cryptographically random identifiers (RFC 1750 [12]) in
the generation of Call-IDs is RECOMMENDED.
Implementations may use the form "localid@host". Call-IDs are
case-sensitive and are simply compared byte-by-byte.
Using cryptographically random identifiers provides some
protection against session hijacking and reduces the likelihood of
unintentional Call-ID collisions.
No provisioning or human interface is required for the selection
of the Call-ID header field value for a request.
CSeq:
It contains an integer and a method name. When a transaction
starts, the first message is given a random CSeq. After that it is
incremented by one with each new message. It is used to detect
non-delivery of a message or out-of-order delivery of messages.
The CSeq header field serves as a way to identify and order
transactions. It consists of a sequence number and a method.
The method MUST match that of the request. For non-REGISTER
requests outside of a dialog, the sequence number value is
arbitrary. The sequence number value MUST be expressible as a
32-bit unsigned integer and MUST be less than 2**31. As long
as it follows the above guidelines, a client may use any
mechanism it would like to select CSeq header field values.

Contact:
It contains a SIP or SIPS URI that is a direct route to user1. It
contains a username and a fully qualified domain name(FQDN).
It may also have an IP address.
Via field is used to send the response to the request. Contact
field is used to send future requests. That is why the 200 OK
response from user2 goes to user1 through proxies. But when
user2 generates a BYE request (a new request and not a
response to INVITE), it goes directly to user1 bypassing the
proxies.
Content-Type:
It contains a description of the message body (not shown).
Content-Length:

Confidential and Proprietary Information of ZTE CORPORATION 13

SIP Introduction

It is an octet (byte) count of the message body.

The header may contain other header fields also. However those
fields are optional. Please note that the body of the message is
not shown here. The body is used to convey information about
the media session written in Session Description Protocol (SDP).
To learn about SDP, please refer relevant document.

14 Confidential and Proprietary Information of ZTE CORPORATION

Chapter 6

Response Message
Format of SIP

The SIP response of user2 will look like this.

Status Line
The first line in a response is called Status line.
SIP- Status Line
Version SP Status-Code SP Reason-Phrase CRLF
[SP = single-space & CRLF=Carriage Return + Line Feed (i.e.
the character inserted when "Enter" key is pressed on the
computer keyboard)]
Here SIP version is 2, Status-Code is 200 and Reason Phrase is
OK.
The header fields that follow the status line are similar to those
in a request. I will just mention the differences

Via:
There are more than one via field. This is because each element
through which the INVITE request has passed has added its
identity in the Via field. Three Via fields are added by softphone
of user1, server1 the first proxy and server2 the second proxy.
The response retraces the path of INVITE using the Via fields.

Confidential and Proprietary Information of ZTE CORPORATION 15

On its way back, each element removes the corresponding Via
field before forwarding it back to the caller.
To:
Note that the To field now contains a tag. This tag is used to
represent the callee in a dialog.
Contact:
It contains the exact address of user2. So user1 doesn't need to
use the proxy servers to find user2 in the future.
It is a 2xx response. However responses can be different
depending on particular situations. Learn about the different
types of SIP responses.

Confidential and Proprietary Information of ZTE CORPORATION 16

Chapter 7

Response Types of SIP

The first digit of a Status-Code defines the category of response.

So any response between 100 and 199 is termed as a "1xx"
response and so is done for any other type. SIP/2.0 allows six
types of response. They are similar to those of HTTP.
1xx: Provisional -- request received, continuing to process
the request;
2xx: Success -- the action was successfully received,
understood, and accepted;
3xx: Redirection -- further action needs to be taken in
order to complete the request;
4xx: Client Error -- the request contains bad syntax or
cannot be fulfilled at this server;
5xx: Server Error -- the server failed to fulfill an apparently
valid request;
6xx: Global Failure -- the request cannot be fulfilled at any
server.
If a response is received having a Status-Code of the form yxx
which is not understood by the receiving party, it treats the
response as a y00 response i.e. if a client receives an unknown
response 345, it treats that as a 300 response. An unknown 1xx
is treated as 183 (Session in Progress). So each UA must know
how to react to 100,183,200,300,400,500 and 600.

Confidential and Proprietary Information of ZTE CORPORATION 17

Chapter 8

SIP Call scenario analysis

Following is a call scenario between a softphone and a POT over

an IP network. H.248 is implemented as the media gateway
control protocol to control the media gateway on the IP network
and the PSTN to support of multimedia streams across computer
networks. It is typically used to provide Voice over Internet
Protocol (VoIP) services (voice and fax) between IP networks
and the PSTN, or entirely within IP networks.

F I G U R E 3 C AL L S C E N AR I O AN A LYS I S

Sip session between a UA and proxy

server

Confidential and Proprietary Information of ZTE CORPORATION 19

 F I G U R E 4 S E S S I O N I N I T I A L I Z AT I O N

Note: The message format also includes SDP message format.

To understand SDP message formats, please refer to the topic
SDP Introduction.

Confidential and Proprietary Information of ZTE CORPORATION 20

 Chapter 8 SIP Call scenario analysis

FIGURE 5 SESSION PROGRESS

At this stage, the connection is made to the far end and ring-
back-tone can be heard.

Confidential and Proprietary Information of ZTE CORPORATION 21

SIP Introduction

FIGURE 6 OK RESPONSE

This response indicates that the called party is ready to initiate

relevant media communication. As this is a VoIP call, this
response would indicate that the called party is off hook and is
ready for voice call.

FIGURE 7 ACK RESPONSE TO OK MESSAGE

The calling party sends an ACK message to the proxy indicating

that it is ready to commence the voice call. At this point in time,

22 Confidential and Proprietary Information of ZTE CORPORATION

 Chapter 8 SIP Call scenario analysis

SIP terminates and goes out of the picture and the IP packets
are exchanged directly between the two ends during the session
until one of the parties sends BYE message.

FIGURE 8 BYE MESSAGE

Here, the BYE message is sent from the SIP proxy server
indicating that the far end wants to terminate the session.

FIGURE 9 OK RESPONSE TO BYE MESSAGE

Confidential and Proprietary Information of ZTE CORPORATION 23

SIP Introduction

Typical Example of a SIP Session

(end-to-end)
IP signaling follows the server-client paradigm as used widely in
the Internet by protocols like HTTP or SMTP. The following
picture presents a typical exchange of requests and responses.
Please note that it is only a typical case and doesn't include all
possible cases.
Before understanding the methods, first understand the pictorial
diagram in Figure 11. User 1 uses his softphone to reach the SIP
phone of user2. Server1 and server2 help to setup the session
on behalf of the users. This common arrangement of the proxies
and the end-users is called "SIP Trapezoid" as depicted by the
red line. The messages appear vertically in the order they
appear i.e. the message on top (INVITE M1) comes first followed
by others. The direction of arrows shows the sender and
recipient of each message. Each message contains a 3-digit-
number followed by a name and each one is labeled by 'M' and a
serial number. The 3-digit-number is the numerical code of the
associated message comprehended easily by machines. Human
users use the name to identify the message.

FIGURE 10 SIP IN ZXSS10 TRAPEZOID ARCHITECTURE

24 Confidential and Proprietary Information of ZTE CORPORATION

 Chapter 8 SIP Call scenario analysis

FIGURE 11 SIP SESSION EXAMPLE WITH SIP TRAPEZOID

The transaction starts with user1 making an INVITE request for

user2. But user1 doesn't know the exact location of user2 in the
IP network. So it passes the request to server1. Server1 on
behalf of user1 forwards an INVITE request for user2 to server2.
It sends a TRYING response to user1 informing that it is trying
to reach user2. The response could have been different but we
will discuss the other types of responses later.
Note: To understand how server1 knows that it has to forward
the request to server2, please go through the topic
Registration in SIP.
Receiving INVITE M2 from server1, server2 works in a similar
fashion as server1. It forwards an INVITE request to user2
(note: Here server2 knows the location of user2. If it didn't
know the location, it would have forwarded it to another proxy
server. So an INVITE request may travel through several proxies
before reaching the recipient). After forwarding INVITE M3
server2 issues a TRYING response to server1.
The SIP phone, on receiving the INVITE request, starts ringing
informing user2 that a call request has come. It sends a
RINGING response back to server2 which reaches user1 through
server1. So user1 gets a feedback that user2 has received the
INVITE request.
User2 at this point has a choice to accept or decline the call. Let
us assume that he decides to accept it. As soon as he accepts
the call, a 200 OK response is sent by the phone to server2.
Retracing the route of INVITE, it reaches user1. The softphone of
user1 sends an ACK message to confirm the setup of the call.

Confidential and Proprietary Information of ZTE CORPORATION 25

SIP Introduction

This 3-way-handshaking (INVITE+OK+ACK) is used for reliable

call setup. Note that the ACK message is not using the proxies to
reach user2 as by now user1 knows the exact location of user2.
Once the connection has been setup, media flows between the
two endpoints. Media flow is controlled using protocols different
from SIP e.g. RTP.
When one party in the session decides to disconnect, it (user2 in
this case) sends a BYE message to the other party. The other
party sends a 200 OK message to confirm the termination of the
session.

26 Confidential and Proprietary Information of ZTE CORPORATION

Chapter 9

Relation among Call,

Dialog, Transaction &
Message

Messages are the individual textual bodies exchanged between a

server and a client. There can be two types of messages,
requests and Responses.
Transaction occurs between a client and a server and comprises
all messages from the first request sent from the client to the
server up to a final (non-1xx) response sent from the server to
the client. If the request is INVITE and the final response is a
non-2xx, the transaction also includes an ACK to the response.
The ACK for a 2xx response to an INVITE request is a separate
transaction.
Dialog is a peer-to-peer SIP relationship between two UAs that
persists for some time. A dialog is identified by a Call-ID, a local
tag and a remote tag. A dialog used to be referred as a 'call leg'.
Call of a callee comprises of all the dialogs it is involved in. I
think a Call is same as a Session.
The following figure will make the relation clearer.

Confidential and Proprietary Information of ZTE CORPORATION 27

FIGURE 12 SIP INDIVIDUAL MESSAGES

A caller may have connections to a number of callees at a time

forming a number of dialogs. All these dialogs make a single call.

Confidential and Proprietary Information of ZTE CORPORATION 28

Chapter 10

Registration in SIP

While going through a typical SIP session it is already seen that

the caller doesn't know the address of the callee initially. The
proxy servers do the job of finding out the exact location of the
recipient. What actually happens is that every user registers its
current location to a REGISTRAR server. The application sends a
message called REGISTER informing the server of its present
location. The Registrar stores this binding (between the user and
its present address) in a location server which is used by other
proxies to locate the user.

F I G U R E 1 3 R E G I S T R AT I O N I N S I P

User yy uses the IP 195.31.65.152 as its current location and

registers it with the server. This actually helps in user mobility.
Say there is a messaging application. one can log in from
different computers. As soon as one is logged in using their
username, the application REGISTER the username with the IP
of that computer. The 'Expire' field reflects the duration for which
this registration will be valid. So the user has to refresh its
registration from time to time.
Please note that the difference between a proxy server and a
registration or a location server is often only logical. Physically
they may be situated on the same machine.

Confidential and Proprietary Information of ZTE CORPORATION 29

Chapter 11

Development of SIP-T and

SIP-I

One of the key limitations of SIP is that it does not provide any
method of directly interworking with the PSTN. The reason for
this is that the IETF did not create SIP with the intention of full
backward compatibility with legacy PSTN signaling mechanisms.
The lack of full SIP/PSTN interworking has many technical
causes, primary among those being that the call signaling
protocol used in the legacy PSTN (i.e. ISUP) is based on a
fundamentally different call model than SIP. Under many
circumstances, the ISUP call model requires a particular
sequence of messaging for which no corresponding SIP message
or messages have been defined. There are also cases in which
the rich feature set available on the PSTN and facilitated by ISUP
cannot be easily developed using SIP due to lack of
corresponding SIP functionality. There are other cases in which
regulatory requirements are most easily and immediately
fulfilled by retaining an ability to delivels1r ISUP services as
opposed to trying to meet complex regulatory mandates with a
new SIP implementation.
The necessity of protocol interworking between networks based
on SIP and ISUP was recognized by both the ITU and IETF who
independently developed alternative methods for SIP with ISUP
encapsulation referred to as SIP-I and SIP-T, respectively.

Confidential and Proprietary Information of ZTE CORPORATION 31

Chapter 12

SIP for Telephones (SIP-T)

SIP for Telephones provides a framework for the integration of

legacy telephony signalling into SIP messages. It provides two
key characteristics, namely encapsulation and translation.
The SS7 ISUP messages arriving at a SIP-ISUP gateway are
encapsulated within SIP; this makes sure that the information
necessary for services is not discarded in the SIP request.
However, routing decisions for SIP requests are made at proxy
servers which cannot be expected to understand ISUP
messages. To overcome this, some of the critical information is
translated from an ISUP message into the corresponding SIP
headers, allowing the SIP request to be routed.
Softswitch network is an integrated servce network, apart from
providing service for IAD, SIP subscribers, it also has to consider
inheritance of existing PSTN subscribers without losing service
properties.

Sip-T Sample Analysis

FIGURE 14 EXAMPLE FIGURE

After the SS1 receives the ISUP message coming from LS1, it
will encapsulate and translate the package into SIP form. Firstly,
it will finish the header according to the caller/callee information
in ISUP, such as the From/TO domain and Request-URI domain.

Confidential and Proprietary Information of ZTE CORPORATION 33

For SS2, as the callee has been analyzed to be a PSTN subscriber,
the ss2 will extract the ISUP message from SIP and route the call
according to the local information.
As for the intermediate message, such as SUS or INR, they have
been encapsulated into Info. Message in SIP

SIP-ISUP mapping and Call Flow

FIGURE 15 BASIC MAPPING

Based on the translation of the SIP and ISUP messages, a call

can be established as shown in the figure below.

FIGURE 16 SIP-T CALL FLOW

When LS1 wishes to begin a session it generates an IAM

message for the softswitch SS1 which encapsulates the original
IAM message to INVITE message and then sends it to SS2
preserving the ISUP signaling transparency.
SS2 on the other hand does exactly opposite of what SS1 did.
That is to map and decapsulate the SIP (INVITE) message to
ISUP (IAM) and deliver the message to LS2. LS2 in turn
generates ACM which is translated across as 180 (ACM) and
then again to ACM in its original transmitted form.

Confidential and Proprietary Information of ZTE CORPORATION 34

 Chapter 12 SIP for Telephones (SIP-T)

IF the called party LS2 goes off hook, ANM is generated which is
translated across as 200 OK and then again as ANM.
ACK message is returned by SS1 and an ANM message is sent to
LS1 indicating that LS2 is off hook for the media session.
As for termination of the session, REL message is sent which is
mapped to as BYE. Here, in this case, LS1 initiates the
termination sequence by sending REL message to SS1which is
translated across to SS2 as BYE and again BYE message is
mapped to as REL to inform LS2 that LS1 wants to terminate the
session. LS2 responds with RLC indicating that it had
acknowledged it. This is translated across as 200 OK and then
again as RLC.

Confidential and Proprietary Information of ZTE CORPORATION 35

Chapter 13

SIP with encapsulated

ISUP (SIP-I)

Session Initiation Protocol (SIP) with encapsulated ISUP (SIP-I)

provides an extension to the standard SIP protocol, as defined
by RFC 3261, to transport ISUP messages across a SIP network
as attachments to the SIP messages. Both ITU-T and ANSI have
standardized SIP-I and from this point on the term SIP-I will
refer to both of these ISUP encapsulation scenarios. SIP-I was
standardized by ITU-T in 2004 in ITU-T Q.1912.5. The
specification covers
SIP interworking with ISUP (Q.761-Q.764) and BICC (Q.1902.1-
Q.1902.4) and uses RFC 3402 for the encapsulation
specification. It specifies actions for three profiles, A, B, and C.
These profiles cover key interworking scenarios.
Profile A specifically addresses 3GPP SIP requirements as
documented in 3GPP TS 24.229 where encapsulated ISUP is
not used. It also makes simplifying assumptions that are
guaranteed to apply when interworking to a 3GPP network.
The Media Gateway Control Function (MGCF) function in the
3GPP reference architecture uses this profile, with a few
minor differences noted in an appendix of 3GPP TS 29.163.
Profile A can only support ISUP services to the degree that
can be provided through the information mapped into SIP
headers.
Profile B is a pure SIP solution which generalizes the 3GPP
specific details of profile A to cover interworking with a range
of ISUP networks. For example, it allows the option of
overlap signaling propagation through the SIP network where
Profile A does not (because mobile networks never generate
overlap signaling). Profile B is also used in the gateway
configuration when interworking between ISUP and SIP.
Profile B is very similar to Profile A in that no ISUP
encapsulation is provided, but the ISUP interworking default
mappings are slightly different to accommodate interworking
with PSTN networks. Profile B differs from SIP-Ts use in a
gateway configuration in that Profile B does not provide

Confidential and Proprietary Information of ZTE CORPORATION 37

 encapsulated ISUP. Profile B can only support ISUP services
to the degree that can be provided through the information
mapped into SIP headers.
Profile C, also known as SIP-I, is the same as Profile B with
the addition of ISUP encapsulation. This is applicable where
ISUP islands are interconnected via a SIP backbone. The
encapsulated ISUP is used to meet regulatory requirements
that are not yet supported by SIP. It can also be used to
support key legacy services where SIP does not provide any
equivalent functionality.
ITU-T Q.1912.5 is similar to the combination of the IETF RFCs
3398 and 3372, except that there are differences in both the
interworking and encapsulation rules. Q.1912.5 went on to
specify the interworking rules for the ISUP services where this
was left unspecified by IETF. Similar to SIP-T, the SIP headers
take precedence over any encapsulated information that may be
present, with limited exceptions. The interworking rules are
applied even when the ISUP message is not encapsulated.

ITU-T Q.1912.5 will also use the RTP/AVP transport and framing
as specified by RFC 3550, 3551 and various codec specific RFCs.
SIP-I explicitly references the SDP offer/answer rules as
specified by IETF RFC 3264 (there is no explicit reference to
these procedures by SIP-T).

ANSI T1.679 also covers SIP interworking with ISUP (T1.113-

2000) and BICC (T1.673-2002). T1.679 is based upon Q.1912.5
and is intended to be compatible with that recommendation.
However, it uses network options (ISUP encapsulation, SIP
preconditions, etc.) instead of SIP profiles (e.g. Profile A, B or
C). There are also som other minor differences between what
these two (2) specifications consider to be part of their
respective scopes. However, as outlined in this document, this
specification is largely in alignment with its ITU predecessor.
Once standardized by ITU-T, SIP-I was incorporated by other
standardization bodies, specifically ETSI and ANSI, and generally
embraced by the industry as a more complete specification as
compared to SIP-T. Most recently, 3GPP has untaken an effort to
incorporate the use of SIP-I into the 3GPP specifications as an
alternative to BICC for the Nc interface and as an outward facing
protocol from the MS MGCF. It is expected that the full technical
specification of the SIP-I based Nc protocol will be provided
during the 3GPP Release 8 timeframe.
Note: The call flow for SIP-T and SIP-I are same. For the
differences of these two technologies, please refer to the topic
Difference between SIP-T and SIP-I.

Confidential and Proprietary Information of ZTE CORPORATION 38

Chapter 14

Difference between SIP-T

and SIP-I

SIP-I reuses many IETF standards and drafts and is richer than
SIP-T in contents. SIP-I contains not only the interworking of the
basic call, but also the interworking of supplementary services
such as CLIP and CLIR. Besides interworking of the call
signaling, SIP-I takes other issues into account such as resource
reservation, media information conversion, and interworking
between fixed-line SIP/3GPPSIP and BICC/ISUP. The most
important is that SIP-I inherits advantages (such as clarity,
preciseness and elaboration) of the traditional ITU-T
recommendations and is much better than SIP-T in operability.
SIP-I and SIP-T have very similar approaches for interworking
ISUP networks with SIP networks. In particular, they provide the
means for conveying ISUP-specific parameters through a SIP
network so that calls that originate and terminate on the ISUP
network can transit a SIP network with no loss of information.
SIP-I and SIP-T both define the mapping of messages,
parameters, and error codes between SIP and ISUP. Both of
them are fully interoperable with compliant SIP network
components on the SIP network.
The key differences between SIP-I and SIP-T are:
SIP-I defines a mapping from SIP to BICC (in additional to
ISUP), while SIP-T addresses only the ISUP case.
SIP-T is inherently designed for interoperation with native
SIP terminals, while SIP-I is restricted for use between PSTN
gateways only.
SIP-I and SIP-T also define somewhat different mappings of
information between the protocols, mostly in terms of converting
from SIP error codes to ISUP cause codes.
At present, SIP is a dominant protocol that controls the
communication between softswitch and application server, and
will be the absolutely dominant protocol for communication
between softswitch and terminal in the future. In the context of

Confidential and Proprietary Information of ZTE CORPORATION 39

inter-softswitch communication, SIP - T has a wider application.
For example, in CDMA2000 protocol, SIP-T is used between
MSCes. SIP - I has been regarded as the core interworking
protocol between softswitch and traditional telecommunication
networks by 3GPP, main telecommunication carriers and big
telecommunication equipment supplier around the world.

Confidential and Proprietary Information of ZTE CORPORATION 40

Chapter 15

SDP Introduction

SDP is the short form of Session Description Protocol. It is used

to describe multimedia sessions in a format understood by the
participants over a network. Depending on this description a
party decides whether to join a conference or when or how to
join a conference.
The owner of a conference advertises it over the network by
sending multicast messages which contain description of the
session e.g. the name of the owner, the name of the session, the
coding, the timing etc. Depending on these information the
recipients of the advertisement take a decision about
participation in the session.
SDP is intended for describing multimedia communication
sessions for the purposes of session announcement, session
invitation, and parameter negotiation. SDP does not deliver
media itself but is used for negotiation between end points of
media type, format, and all associated properties. The set of
properties and parameters are often called a session profile. SDP
is designed to be extensible to support new media types and
formats.
SDP started off as a component of the Session Announcement
Protocol (SAP), but found other uses in conjunction with Real-
time Transport Protocol (RTP), Real-time Streaming Protocol
(RTSP), Session Initiation Protocol (SIP) and even as a
standalone format for describing multicast sessions.
SDP is generally contained in the body part of SIP.
SDP includes
Session name and purpose
Time(s) the session is active
The media comprising the session
Information to receive those media (addresses, ports,
formats and so on)

Confidential and Proprietary Information of ZTE CORPORATION 41

Session Description Parameters
A session is described by a series of attribute/value pairs, one
per line. The attribute names are single characters, followed by
'=', and a value. Optional values are specified with '=*'. Values
are either an ASCII string, or a sequence of specific types
separated by spaces. Attribute names are only unique within the
associated syntactic construct, i.e. within the Session, Time, or
Media only. The syntax of SDP is extensible and new attributes
are added to the standard occasionally.[1]
The following is an abbreviated overview:

Session description (* denotes optional )

v= (protocol version)
o= (owner/creator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -not required if included in all
media)
b=* (bandwidth information)
One or more time descriptions
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description (* denotes optional )
t= (time the session is active)
r=* (zero or more repeat times)
Media description (* denotes optional )
m= (media name and transport address)
i=* (media title)
c=* (connection information -optional if included at session-
level)
b=* (bandwidth information)
k=* (encryption key)
a=* (zero or more media attribute lines)

Confidential and Proprietary Information of ZTE CORPORATION 42

 Chapter 15 SDP Introduction

Example Session (SDP)

Below is an example session description, taken from RFC 2327:
v=0
o=mhandley2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu(Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416udp wb
a=orient:portrait

Confidential and Proprietary Information of ZTE CORPORATION 43

Chapter 16

SIP/H.323 comparison

SIP H.323

Based on simple Internet Protocol Based on the Telco model of

models; designed to meet communications; evolved from

converged (data, video, voice) the telephone connectivity

connectivity challenges world

Standards established by the IETF Standards established by the

ITU

Able to address the needs of a Evolved from a LAN-centric

distributed WAN infrastructure view of the Internet;

disproportionate

suitable for carrier-class focus on telephone connectivity

deployment to the exclusion of a rich data

or video feature set

Edge devices are identified in a IP is the carrier protocol for

standard Internet manner (URLs, RTP (Real Time Protocol) but

DNS lookup, MIME encoding) and the underlying behaviors of the

protocol interaction is consistent protocols are specified uniquely

with the general TCP/UDP/IP by H.323

world

Circuit reliability, or the lack Reliability is inherent in H.323

thereof, is the responsibility of the often introducing unnecessary

underlying network infrastructure levels of service

SIP messages are transmitted as Evolved from a LAN-centric

Confidential and Proprietary Information of ZTE CORPORATION 45

 SIP H.323

ASCII text strings, consistent with view of the Internet;

email and web messages (SMTP, disproportionate

POP, HTTP, etc.)

SIP allows architectural as well as H.323 uses binary messaging

command/response extensions

using well documented methods

Efficient code implementation Complex, cumbersome code

supporting easy of embedding in that is difficult to implement in

minimum memory model devices embedded systems

Architecture minimizes setup As much as 7 or 8 seconds

delay may be required to negotiate

circuit setup

Ability to ring more than 1 No ability to fork calls

telephone end-point for an

incoming call (call 'forking') ie:

office, home, and cell phones all

ring when a call is received.

Individual user profile

management

'Unified messaging'

Presence management

Media can be mixed in a single No ability to mix media in a

connection (voice, data, single call

streaming video)

Connection initiation through No ability to identify end-points

URL's that can be embedded in with URL's

web pages or other browser-

based devices

SIP allows seamless integration H.323 capabilities are fixed and

with other IP-based protocols must be used in the voice

context of the PSTN

Confidential and Proprietary Information of ZTE CORPORATION 46

 Chapter 16 SIP/H.323 comparison

SIP H.323

IP-based services allow easy SS7 PSTN service model

interoperation with various types requires H.323 devices, often

of gateway and Internet devices with vendor-proprietary

implementations

Comparing the Basic Call Setup

H.323 control procedures of connection have three parts, H.225
RAS, H.225 Call Signaling and H.245. H.245 provides control to
the multimedia session that has been established and messages
are carried via a special channel called the H.245 control
channel.

FIGURE 17 .245 CONTROL CHANNEL.

The trace of H.323 connection requires the debugging tools

enabling decoding of ASN.1 format, whereas SIP messages use
text formats.
Openning the H.245 Control Channel is optional, this mode is
called as Fast Connect. With the use of Fast Connect, there is no
need to open an H.245 channel, the endpoints may transmit
fastStart element in the SETUP message and return a fastStart
element in any message to the caller.

Confidential and Proprietary Information of ZTE CORPORATION 47

FIGURE 18 BASIC CALL SETUP USING H.323 FAST CONNECT

Figure 18 illustrates the message exchange that is required to

set up a similar call using H.323 Fast Connect and SIP in Figure
19.

F I G U R E 1 9 B A S I C C A L L S E T U P U S I N G S I P.

Confidential and Proprietary Information of ZTE CORPORATION 48

 Chapter 16 SIP/H.323 comparison

Comparison Conclusion
H.323 describes and enables an object-oriented approach based
on QSIG in accordance with ITU-T recommendation H.323 Annex
M1 11/00 and provides better interworking with already existing
telephony systems (e.g. ISDN).
The programming languages derived from HTTP are more easily
applicable for SIP, SIP is based on HTTP. SIP is the better for
new services implementation. SIP requires less code to
implement than H.323. H.323 was an early leader in the VoIP
market, and continues to be used in a lot of networks, but IETF
standards are more flexible and accessible then ITU protocols
and it could be important for the VoIP device design and its
development. The reality is that most H.323 products on the
market today also support SIP, including SIP/H.323
interworking.

Confidential and Proprietary Information of ZTE CORPORATION 49