Session Initiation Protocol: Presentation by

SIP
SIP
Session Initiation Protocol
Presentation by : Training Team
Sasken Communication Technologies Ltd.
© 2006 Sasken Communication Technologies 1

OBJECTIVES
o Understand Pros and Cons of circuit & Packet

switching.
o Introduction to IP Telephony.
o Understand the basic SIP elements and their functions.
o Analyze call flow in SIP.
o Understand the functions of SDP.
o Understand the functions of RTP.
o Understand the functions of RTCP.
o Assessment

Introduction to Circuit & Packet Switching.
CIRCUIT SWITCHING
PSTN Telephony switch
321
switch 54
67890
321
54
67890
switch
PACKET SWITCHING
IP Telephony
router
router
router
router

Pros of Circuit Switching
These systems are very fast. Since switches do not examine

the contents of the transmission, the decision on where to send the
information received at a certain interface is made just once, at the
beginning of connection, and remains the same for the duration.
Thus, the delay introduced by a switch is almost negligible.
After a circuit has been established, the transmission delay is small
and is kept constant through the duration of the connection.

Cons of Circuit Switching
Before an information exchange between terminals can take

place, a path through the network must be established. Setting up a
path takes time, and the actual transmission is delayed until the path
establishment phase is finished.
Once a dedicated path is established between two terminals, the
resources associated with it cannot be used for another connection
until the path is torn down.

Pros of Packet Switching
Efficiency and suitability are the reasons why packet switching

compares favorably to circuit switching.
Routers are designed to buffer incoming packets until they can be
sent on the outgoing interface, so the incoming data rate is not
necessarily the same as the outgoing data rate.
Price is another strength. In general, packet-switching equipment
costs less than circuit-switching gear because it’s simpler.
Falling computer prices in the last few years directly benefit packet-
switching nodes.

Cons of Circuit Switching
Delay and higher overhead as the two primary reasons why

packet switching may not perform as well as circuit switching
under certain circumstances. Circuit switching nodes do not
examine contents of the information transferred at all, whereas
packet switching routers examine the headers of every packet
before forwarding them.
For instance, if a 20-octet header is used to transfer 5
octets of user data, the network will transmit a packet of 25
octets, in which just 5 octets are user data.

IP Telephony Vs. PSTN Telephony
IP Telephony PSTN Telephony
ROUTING Dynamic Static switching
INTELLIGENCE Decentralized, or Centralized

distributed
SWITCHING Packet switched Circuit switched

network network
BANDWIDTH Variable Fixed

Protocols and Standards
IP Telephony PSTN Telephony
H.323 SIP MGCP TUP ISUP
ITU-T IETF ITU-T and IETF ITU and ANSI ITU and ANSI
Standard Standard Standard Standard Standard

Origins of the Request For Comments (RFCs)
ARPANET was developed within the research and

academic community, with its strong tradition of sharing
results and ideas. The research community is an open
environment that creates quick development.
The idea was to gather all the feedback on a specific

RFC in one place and to publicly identify open issues. After all
the necessary discussions, when consensus was reached, a
technical specification could be developed without
encountering continual obstacles.

References
References Description
RFC 2068 Hypertext Transfer Protocol

RFC 793 Transmission Control Protocol
RFC 768 User Datagram Protocol
RFC 1889 Real-time Transport Protocol

Protocol stack
OSI Model IP Telephony PSTN Telephony
SDP
APPLICATION H.323 SIP RTP RTCP ISUP

PRESENTATION
SESSION
TRANSPORT TCP UDP SCCP

NETWORK IP MTP 3
DATA LINK LAYER 1 & 2
PHYSICAL

IP TELEPHONY
Sasken Confidential © 2006 Sasken Communication Technologies

VoIP Standards
ITU
- H323 –Multimedia transmission (Voice, Data, Video) over packet switched network
- H248- Inter-operability between Packet switched and Circuit switched networks
- H.245 – Media and Bearer Channel creation
- H.225 – Address Resolution & Access Authorization (Call Signaling)
IETF
IPv4/IPv6 - Internet Protocol version 4 & 6
SI P- Session Initiation Protocol (alternate to H323 of ITU)
MGCP – Media Gateway Control Protocol
RSVP – Resource Reservation Protocol (Integrated Services)
RTP – Real Time Protocol

SIP Vs H.323
SIP H.323
Range Carrier-class solution Addressing the Based on the LAN focusing on
wide area application enterprise client tele
Characteristics Messages are formatted as text- Fit Binary format- Unsuitable for the
for Internet Internet
Allows for standards-based Extensions are added by using
extensions to perform specific vendor-specific software
functions
Hierarchical, URL style addressing Addressing scheme doesn’t scale
scheme that scales well well
Minimal delay Possibilities of delay up to 7-8 sec
Light weight in complexity Very Complex

SIP Vs H.323 (Contd..)
SIP H.323
Services Ability to ‘fork’ calls ‘Forking’ not possible in the
existing standard
Unique ability to mix media Cannot mix media within a session
URLs can be embedded in H.323 has no URL format

web browsers and email tools
Status •Industry endorsed •Popularity due to the fact that it
•Fast catching up because of was the first set of standards for
IETF VOIP
•Loosing to SIP
Cost Cheap Expensive

Session Initiation Protocol
Sasken Confidential © 2006 Sasken Communication Technologies

About SIP
Session Initiation Protocol (SIP) is an

ASCII-based, application-layer control protocol
that can be used to establish, maintain, and
terminate calls between two or more
endpoints.
SIP is an alternative protocol developed by the

Internet Engineering Task Force (IETF) for
multimedia conferencing over IP.

SIP Basics
• SIP is a peer-to-peer protocol

 end-devices (User Agents—UAs) initiate sessions
• SIP is an application layer signaling protocol
 create, modify and terminate sessions
 two or more participants
• SIP sessions include:
 Internet multimedia conferences
 Internet telephone calls
 Instant Messaging
 multimedia distribution
• Endpoints can communicate via multicast, via a unicast mesh, or any
combination

SIP Basics (Contd…)
• SIP uses existing IETF protocols to provide:

 message formatting (HTTP 1.1)
 media negotiation (Session Description Protocol—SDP), media (RTP)
 name resolution and mobility (DHCP and DNS)
 application encoding (MIME)
• Flexible transport:
 can use UDP, TCP, TLS, or SCTP
• SIP is ASCII text-based
 eases implementation and debugging

SIP Basics (Contd…)
• Uses URL style addresses and syntax

• Uses SDP for describing media sessions
 Audio, Video, real-time Text, IM, speech services, etc.
• Applications include (but not limited to):
 Voice, video, gaming, instant messaging, presence, call control,
etc.
• Simple extensible protocol
 Methods—Define transaction
 Headers—Describe transaction
 Body—SDP and other MIME content

SIP Capabilities
• 5 facets of establishing and terminating multimedia communications:

1. User location: determination of end system to be used for
communication.
2. User capabilities: determination of media and media parameters
to be used.
3. User availability: determination of willingness of called party to
engage in communications.
4. Call setup: ringing, establishment of call parameters at both
called and calling party.
5. Call handling: including transfer and termination of calls.

SIP Entities
• There are several different SIP servers, each with their own
purpose
• There are:
 User agent servers
 Proxy servers
 Redirect servers
 Registrars
• There is also something called a location server running a
location service which may be co-located with a SIP server

SIP Entities : User Agents
SIP SIP
SIP SIP
LAN A LAN B
• Client—Server model
• User Agent Client (UAC)—Initiates sessions
• User Agent Server (UAS)—Responds to session requests
• User Agent = UAC + UAS

SIP Entities : User Agent (Contd..)
User Agent Servers (UAS)
• Application which contacts user when a SIP request is

received
• UAS then returns a response on behalf of user
• Response either accepts, rejects, or redirects the request
SIP Call Request User “Call for you?”

Agent
Call Accepted Server “I accept.”

SIP Entities : Proxy Server
• Intermediary program that acts as both a server and a client
to make requests on behalf of other clients
• A proxy interprets a request, and if necessary, rewrites
request message before forwarding it
User
Agent 1
Originates SIP
Requests
Proxy User
Server Agent X
Responds for 1 and X
Answers on behalf
of users.

SIP Entities : Proxy Server (Contd..)
Stateful vs. Stateless Proxy
• Transaction stateless
 Proxy server forwards all methods and responses without
interaction
• Transaction Stateful
 Proxy server opens a Transaction Control Block (TCB) when a
method is received,
 maintains state for the transaction until the final response is
received
 a stateful server is required to originate a CANCEL method, or
an acknowledgement

SIP Entities : Redirect Server
• Redirects calls to new User Agent

location
• Provides router functionality Redirect
Server
• A server that accepts a SIP
request, maps address into 0
or more new addresses and
returns those addresses to
User Agent
client Proxy
Agent
• Unlike a proxy server, a
redirect server does not
initiate its own SIP request
PSTN

SIP Entities : Registrar
• Allows users to register

their presence Proxy Server
• A server that accepts

REGISTER requests
• Typically co-located Register
with a proxy or Server
redirect server Redirect Server
• May offer location services

SIP Addressing
• Objects addressed by SIP are users at hosts

• Users are identified by a SIP Uniform Resource
Locator (URL) [user@host] or [user@domain.com]
 User part is a user name or a telephone number
 Host part is a domain name or IP address
• SIP addresses may be obtained out-of-band, learned
via media gateways, recorded during earlier
conversations, or guessed (since they’re often
similar to E-mail addresses)

Locating a SIP Server
• A client sends a request either to a Universal Resource

Identifier (Request-URI), or a locally configured SIP proxy
server
• If sending to a Request-URI, client must determine IP
address, protocol, and port number of destination server
 DNS is used to obtain an IP address
 Client should try to contact server at a specified port or
well known port 5060
 If no protocol is specified, UDP is assumed
‐ If UDP fails, TCP is attempted

SIP Operation
• Callers & recipients are identified by SIP addresses

• A caller first locates the appropriate server, then
sends a SIP request (probably an INVITE)
• In the perfect world, the request arrives at its
destination when the client accepts the call by
returning a SIP response code 200
• Originating caller then sends an ACK to recipient

How Does SIP Connect Session Members?
• SIP can communicate via:

 Multicast
 A mesh of unicast relationships
 A combination of multicast and unicast

SIP Messages: Requests.
Method Description
INVITE Initiates a call, changes call parameters (re-INVITE).
ACK Confirms a final response for INVITE.
BYE Terminates a call.
CANCEL Cancels searches and “ringing”.
OPTIONS Queries the capabilities of the other side.
REGISTER Registers with the Location Service.
INFO Sends mid-session information that does not modify
the session state.
REFER Used in Call-Transfer

SUBSCRIBE / NOTIFY Ascertain the presence of a SIP user in the network.

SIP Messages : Response
Response Code Reason Definition
1XX Informational Request Received and continuing to process the

request.
2XX Success Action was successfully received,understood
and accepted.
3XX Redirection Further action needed to complete the
request.
4XX Client Error Request contains bad syntax and cannot be
fulfilled at this server.
5XX Server Error Server failed to fulfill an apparently valid
request.
6XX Global Failure Request cannot be fulfilled at any server.

SIP Messages : Examples of Response (1/4)
1XX Informational Response
Code Reason
100 Trying
180 Ringing
183 Session Progress
2XX Success
Code Reason
200 OK
202 Accepted

3XX Redirection
Code Reason
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
4XX Client Error
Code Reason
400 Bad request
401 Unauthorized
403 Forbidden

Code Reason
404 Not Found
407 Proxy Authentication required
408 Request Timeout
480 Temporarily Unavailable
482 Loop Detected
486 Busy Here
487 Request Terminated
488 Not Acceptable Here

5XX Server Error
Code Reason
500 Server Internal Error
503 Service Unavailable
505 Version Not Supported
6XX Global failure
Code Reason
600 Busy Everywhere
606 Not Acceptable

SIP Message Parts
SIP messages are composed of the following three parts:

(1) Start line (2) Headers (3) Message body
Start Line:
Every SIP message begins with a Start Line. The Start Line conveys the
message type (method type in requests, and response code in responses)
and the protocol version.
The Start Line may be either a Request-line (requests) or a Status-line
(responses),as follows:
• The Request-line includes a Request-URI, which indicates the user or
service to which this request is being addressed.
• The Status-line holds the numeric Status-code and its associated textual
phrase.

SIP Message Parts
Headers
• SIP header fields convey message attributes that provide additional
information about the message.
• They are similar in syntax and semantics to HTTP header fields
• Headers can span multiple lines.
Message Body
• A message body is used to describe the session to be initiated (for example, in
a multimedia session this may include audio and video codec types and
sampling rates), or alternatively it may be used to contain opaque textual or
binary data of any type which relates in some way to the session.
• Message bodies can appear both in request and in response messages.
• SIP makes a clear distinction between signaling information, conveyed in the
SIP Start Line and headers, and the session description information.

SIP Message Parts –Example (1/2)
Request-Line: INVITE sip:1111@164.164.57.187 SIP/2.0
Message Header
Via: SIP/2.0/UDP 164.164.58.14:41752;branch=z9hG4bK-d87543-
Max-Forwards: 70
Contact: <sip:4348@164.164.58.14:41752>
To: "Test"<sip:1111@164.164.57.187>
From: "Santhosh"<sip:4348@164.164.57.187>;tag=fc270514
Call-ID: NGExZWJlNDE5OWQ5MjgxODFhY2YxZjhhNDg2MzE1NDI.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
User-Agent: X-Lite release 1006e stamp 34025
Content-Type: application/sdp
Content-Length: 291

SIP Message Parts –Example (2/2)
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 4 2 IN IP4 164.164.58.14
Session Name (s): CounterPath X-Lite 3.0
Connection Information (c): IN IP4 164.164.58.14
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 55792 RTP/AVP 107 98 3 101
Media Attribute (a): alt:1 1 : VNOnzyTb FFFh7Pnp 164.164.58.14 55792
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): rtpmap:107 BV32/16000
Media Attribute (a): rtpmap:98 iLBC/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): sendrecv

SIP Transactions
• Consists of a SIP request with the appropriate response

• To identify which SIP request a response is for, the following
fields should be identical:
 Call-ID - uniquely identifies a particular invitation
 Cseq (command sequence number) - a unique number that is
incremented for each command with the same call-ID
 To
 From
 Tag (only present when more than one Via header field is present)

SIP Dialogs
 A dialog represents a peer-to-peer SIP relationship between two

user agents that persists for some time.
 The dialog facilitates sequencing of messages between the user
agents and proper routing of requests between both of them. The
dialog represents a context in which to interpret SIP messages.
 A dialog is identified at each UA with a dialog ID, which consists of
a Call-ID value, a local tag and a remote tag. The dialog ID at each
UA involved in the dialog is not the same. Specifically, the local
tag at one UA is identical to the remote tag at the peer UA.

Simple Session Establishment
User Agent A User Agent B
INVITing A for a call
B is RINGING
B has accepted the Call
A ACKnowledges B
CONVERSATION
A is ending the call
OK

SIP Registration (Without Authentication)
User Agent Registrar
Contact: UserAgent@domain.com;
REGISTER
Expires: 3600
Contact: UserAgent@domain.com;
Expires: 3600
200 OK

SIP De-Registration
Contact: UserAgent@domain.com; REGISTER
Expires: 0
401 Unauthorized
Expires: 0
200 OK

SIP –SIP Call
User Agent A Proxy Server Location/Redirect Server Proxy Server User Agent B
INVITE INVITE
100 Trying 302
(Moved Temporarily)
ACK
Call
Setup INVITE
INVITE
100 Trying
180 (Ringing)
180 (Ringing)
180 (Ringing)
200 (OK) 200 (OK) 200 (OK)

ACK ACK ACK
Media
Path RTP MEDIA PATH
Call BYE BYE BYE

Teardown 200 (OK) 200 (OK) 200 (OK)

Call Failure - No Answer
User Agent A Proxy Server 1 Proxy Server 2 User Agent A
INVITE INVITE INVITE
Ringing Ringing
Ringing
CANCEL
CANCEL
CANCEL
200 OK
200 OK 200 OK
487 Req Term
ACK
487 Req Term 487 Req Term
ACK ACK

Call Failure – Ringing Timeout
Ringing Ringing
Ringing
408 Req Timeout
ACK
408 Req Timeout
ACK

Call Failure – User Busy
486 Busy Here
ACK
486 Busy Here
ACK
486 Busy Here
ACK

SIP Presence
User Agent A Proxy Server 1 User Agent A
SUBSCRIBE
100 Trying SUBSCRIBE
202 Accepted
202 Accepted
NOTIFY
NOTIFY
200 OK
200 OK

Security Concerns
• Replay Attacks
• Registration Hijacking
• Request Spoofing
• Impersonating a Server
• Chosen Plaintext Attack
Solution : SIP Security Mechanisms

SIP Security Mechanisms
Authentication
Authentication
Digest S / MIME
D S
Basic
B A I A /
A U G U Application
M
S T E T
Layer
I Mechanisms
I H S H M
C T E
TLS Transport Layer Mechanisms
IP Sec Network Layer Mechanisms

Digest Authentication
SIP provides a challenge- User Agent A Proxy Server 1 / Registrar

based mechanism for
authentication that is
REQUEST
based on authentication in
HTTP.
CHALLENGE
A scheme is known as
Digest Authentication
based on MD5 hashing REQUEST WITH
function on the CREDENTIALS
username/password
combination is used.

Digest Authentication Headers
SIP uses headers for authentication. The WWW-

Authenticate header is used in 401 response message sent by
the server. In response to the 410 challenge, the UA should
include a Authorization header containing the credentials in
the next request. Similarly the Proxy-Authenticate header is
used in 407 response message sent by the proxy; and the UA
should include a Proxy-Authorization header in the next
request.

WWW-Authenticate Header in 401 and 407 Challenge
WWW-Authenticate: digest
realm="164.164.57.187",
qop="auth",
nonce="9e0962d5e57c4c5dbaa63dbcbe965d19",
opaque="5ccc069c403ebaf9f0171e9517f40e41“
algorithm=MD5

WWW-Authenticate Header Parameters
Parameter Description
Digest Indicator of authentication scheme.
Realm Associated protection domain
Qop Specifying “ Quality of Protection” that the server supports. It’s
value can be either”auth” for authentication, or “auth-int” for
authentication and integrity.
Nonce Unique string specified by the server.
Opaque String specified by the server for the client to return in the
subsequent requests.
Algorithm The algorithm to be used for checksum calculation. Default is
MD5
stale A flag indicating if the nonce value in the previous request is
stale.

Authorization Header in response to 401 and 407 challenge.
Authorization: Digest
username=“student",
realm="164.164.57.187",
nonce="9e0962d5e57c4c5dbaa63dbcbe965d19",
uri="sip:164.164.57.187:5061",
response="47255c75f12faa78d699965c4325dab0",

Authorization Header in response to 401 and 407 challenge.
(Contd..)
cnonce="ed1ed6a122e4647b",
nc=00000001,
qop = auth,
Algorithm = MD5,
opaque="5ccc069c403ebaf9f0171e9517f40e41"

Authorization Header Parameters
Parameter Description
Username The user’s name in the specifies realm
Nc Count of the number of requests that the client has sent
with the nonce value
Cnonce If a qop value is specified, the client must specify cnonce
value
Response The string of 32 Hex digits calculated checksum.

SIP Registration (With Authentication)
Expires: 3600
401 Unauthorized
Expires: 3600
200 OK

Simple SIP Call with Proxy Authentication
INVITE
100 Trying
407 Proxy Auth
ACK
INVITE
100 Trying INVITE
180 Ringing
180 Ringing
200 OK
200 OK

Simple SIP Call with Proxy Authentication (Contd..)
200 OK
200 OK
RTP MEDIA PATH
BYE
BYE
200 OK
200 OK

Session Description Protocol (SDP)

Introduction
Session Description Protocol (SDP) [RFC 2327] specifies,

how the information necessary to describe a session
should be encoded.
SDP does not include any transport mechanism or any
kind of parameter negotiation.
SDP is contained in the message body of a SIP message.
It includes, for instance, IP addresses, port numbers,
and times and dates when the session is active.

SDP Operation Example
IP Address, Port No, User Agent A User Agent B

Media Description
Supported : Codec Type INVITE / SDP
and attributes used by
the Caller. 180 RINGING
200 OK / SDP
IP Address, Port No, ACK

Media Description
Supported : Codec Type
RTP MEDIA PATH
and attributes used by
the Callee.
BYE
200 OK

SDP Parameters
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)

SDP Parameters (Contd…)
c=* (connection information)

b=* (bandwidth information)
z=* (time zone adjustments)
k=* (encryption key)
a=* (session attribute lines)

SDP Syntax
Message body
Session Description Protocol
Session Description Protocol Version (v): 0

Owner/Creator, Session Id (o): - 4 2 IN IP4 164.164.58.14
Session Name (s): CounterPath X-Lite 3.0
Connection Information (c): IN IP4 164.164.58.14
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 55792 RTP/AVP
107 98 3 101

SDP Syntax ( Contd…)
Media Attribute (a): alt:1 1 : VNOnzyTb FFFh7Pnp 164.164.58.14

55792
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): rtpmap:107 BV32/16000
Media Attribute (a): rtpmap:98 iLBC/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): sendrecv

Real-time Transport Protocol

Multimedia Traffic
Streaming Live A/V : Like broadcast TV/radio but via Internet,

Can’t pause, rewind. The time between request and display 1 to 10
seconds. Continuous play out.
Real-Time Interactive A/V : IP phone, video conferencing. Can’t
pause, rewind. Delay between initial request and display is small:
video <150ms, audio <400 acceptable. Continuous play out.
Streaming Stored A/V : Like DVD but via Internet Prerecorded
multimedia content, user may pause, rewind, forward,…The time
between request and display 1 to 10 seconds After display start the
play out must be continuous.

Real-time Multimedia Traffic
RTP RTP RTP RTP RTP RTP
Audio/Video frames are transmitted as

they are produced and displayed

Real-time Multimedia Traffic : Time Relationship
00
01
10
11
20
21
30
31
Send Time (Sec) Arrival & Play Time (Sec)
Note: Each packet holds 10 seconds of audio/video information. Assumption: transfer delay is
constant and equal 1 second (exaggerated).The receiver sees the audio/ video with the same
speed as it is created, the constant transfer delay is immaterial.

Real-time Multimedia Traffic : Jitter
The gaps between the received packets are

called JITTER
00
01
10
20
15
30
27
37
Send Time (Sec)
Arrival & Play Time (Sec)

Real-time Multimedia Traffic : Timestamp
Play back delayed by 7 Sec

after the reception of the first
packet. All gaps are eliminated
00
01
10 7 Sec
5 Sec 08
20
15
30 18
2 Sec
27
28
Play back time is separated 37

from the arrival time 38
Send Time (Sec) Arrival Time (Sec) Play Time (Sec)

Real-time Multimedia Traffic : Playback Buffer
For most of the voice applications

the play out delay should be less
than 300ms (for some applications
even less than 150 ms is required)
Playback point or playout delay

(constant offset between data generation and
playback)

Requirements for Real-Time Multimedia Traffic
In order to ensure playback timing and jitter

removal timestamps are required.
In order to ensure the presence and order of data a
sequence number is required.
Most of the real-time multimedia applications are video
conferencing where several clients receive data.
Therefore the multicast mode is preferred.
In order to deal with congestion a mechanism for
sender notification and change of encoding
parameters must be provided.

Requirements for Real-Time Multimedia Traffic (Contd..)
 In order to display streams generated by different

standards the choice of encoding must be provided.
 In order to display audio and video streams (and
user data like titles) within a single A/V session
mixers are required.
 In order to use high bit rate streams over a low-
bandwidth network the translators are required
(multimedia payload encoders and decoders).

Why real-time data doesn’t prefer TCP ?
 TCP forces the receiver application to wait for

retransmission(s) in case of packet loss, which causes
large delays.
 TCP cannot support multicast.
 TCP congestion control mechanisms decreases the
congestion window when packet losses are detected
("slow start"). Audio and video, on the other hand,
have "natural" rates that cannot be suddenly
decreased.

Why real-time doesn’t prefer TCP ? (Contd..)
TCP headers are larger than a UDP header (40 bytes

for TCP compared to 8 bytes for UDP).
TCP doesn’t contain the necessary timestamp and
encoding information needed by the receiving
application.
TCP doesn’t allow packet loss. In A/V however loss of 1-
20% is tolerable.

Features of RTP.
RTP doesn’t ensure real-time delivery,but provide means for :

 Jitter elimination/reduction (with application’s play out buffers).
 Synchronization of several audio and/or video streams that belong
to the same multimedia session.
 Multiplexing of audio/video streams that can belong to different
multimedia sessions.
 Translation of video a/v streams from one encoding type to
another.
 With the help of RTCP, RTP also provides “hooks” for adding
reliability and flow/congestion control which is implemented
within the multimedia application.

RTP Stack
Audio /Video Codecs
Application
G.711 G.729 H.261 H.263
Layer
RTP
Transport
Layer
UDP
Network
Layer IP
PHY &
Datalink Layer 1 & 2
Layer

RTP Packet Structure
Ethernet IP UDP RTP

RTP Payload
Header Header Header Header
38 Bytes 20 Bytes 20 Bytes 12 Bytes Variable

RTP Header Structure
Payload
V P X CC M Sequence Number
Type
Time Stamp
SSRC
CSRC list
.
.
.
.
CSRC list

RTP Header Structure (Contd…)
Version (V): 2 bits
This field identifies the version of RTP. The version defined by this specification is
two (2).
Padding (P): 1 bit

If the padding bit is set, the packet contains one or more additional padding
octets at the end which are not part of the payload. The last octet of the padding
contains a count of how many padding octets should be ignored. Padding may be
needed by some encryption algorithms with fixed block sizes or for carrying
several RTP packets in a lower-layer protocol data unit.
Extension (X): 1 bit

If the extension bit is set, the fixed header is followed by exactly one header
extension.
CSRC count (CC): 4 bits

The CSRC count contains the number of CSRC identifiers that follow the fixed
header.

Marker (M): 1 bit

The interpretation of the marker is defined by a profile. It is intended to allow
significant events such as frame boundaries to be marked in the packet stream. A
profile may define additional marker bits or specify that there is no marker bit by
changing the number of bits in the payload type field.
Payload type (PT): 7 bits

This field identifies the format of the RTP payload and determines its
interpretation by the application.
Sequence number: 16 bits

The sequence number increments by one for each RTP data packet sent, and may
be used by the receiver to detect packet loss and to restore packet sequence. The
initial value of the sequence number is random (unpredictable) to make known
plaintext attacks on encryption more difficult, even if the source itself does not
encrypt, because the packets may flow through a translator that does.

Timestamp: 32 bits
The timestamp reflects the sampling instant of the first octet in the RTP data
packet. The sampling instant must be derived from a clock that increments
monotonically and linearly in time to allow synchronization and jitter
calculations.
SSRC: 32 bits
The SSRC field identifies the synchronization source. This identifier is chosen
randomly, with the intent that no two synchronization sources within the same
RTP session will have the same SSRC identifier.
CSRC list: 0 to 15 items, 32 bits each

The CSRC list identifies the contributing sources for the payload contained in this
packet. The number of identifiers is given by the CC field. If there are more than
15 contributing sources, only 15 may be identified. CSRC identifiers are inserted
by mixers, using the SSRC identifiers of contributing sources.

RTP Syntax (Example)
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: iLBC (98)
Sequence number: 1053
Timestamp: 263020
Synchronization Source identifier: 3088456435
Payload: 77B7F3537F80F01104A163350854F2FAADE50EBE66BAA1AE...

RTP Payload Type
PT Name Type RTP timestamp References

clock rate (Hz)
0 PCMU AUDIO 8000 RFC 3551
1 1016 AUDIO 8000 RFC 3551
2 G721 AUDIO 8000 RFC 3551
3 GSM AUDIO 8000 RFC 3551
4 G723 AUDIO 8000
5 DV14 AUDIO 8000 RFC 3551
6 DV14 AUDIO 16000 RFC 3551
7 LPC AUDIO 8000 RFC 3551
8 PCMA AUDIO 8000 RFC 3551
9 G722 AUDIO 8000 RFC 3551

RTP Payload Type (Contd..)
PT Name Type RTP timestamp References

clock rate (Hz)
10 L16(CH2) AUDIO 44100 RFC 3551
11 L16(CH1) AUDIO 44100 RFC 3551
12 QCELP AUDIO 8000
13 CN AUDIO 8000 RFC 3389
14 MPA AUDIO 90000 RFC 3551
15 G728 AUDIO 8000 RFC 3551
16 DV14 AUDIO 11025
17 DV14 AUDIO 22050
18 G729 AUDIO 8000
25 CellB VIDEO 90000 RFC 2029

Timestamp and Sequence Number
Audio:
Timestamp clock rate for audio 8000 Hz (= 125 μs) & for video is 90,000Hz.
One RTP packet caries 20 ms of audio samples, each RTP packet is sent by a
separate UDP datagram to avoid packetization delay.
Timestamp increments by 20 ms/125 μs = 160 .
Packet rate = 1 sec/20 ms = 50 Hz
Number of bits per RTP payload for uncompressed audio = 160*8 = 1280
Sequence number increments by one for each RTP packet.
RTP Packet K RTP Packet K+1
TS = X TS = X+160
Audio Stream Audio Stream
SN = Y SN = Y+1

Real –Time Control Protocol (RTCP

What’s Real-Time Control Protocol ?
RTP is a protocol that provides basic transport layer for real

time applications but does not provide any mechanism for error and
flow control, congestion control, quality feedback and synchronization.
For that purpose the RTCP is added as a companion to RTP to provide
end-to-end monitoring and data delivery, and QoS .
RTCP is responsible for three main functions:
Feedback on performance of the application and the network.
Correlation and synchronization of different media streams

generated by the same sender.(e.g. combined audio and video)
The way to convey the identity of sender for display on a user

interface.

RTCP Packet Structure
Ethernet IP UDP RTCP

RTCP Data
Header Header Header Header
38 Bytes 20 Bytes 20 Bytes 12 Bytes Variable
RTCP UDP port number = RTP UDP port number + 1

(Usually one port number pair per multimedia session)

RTCP Packet Type
Packet Acronym Description

Type
200 SR Sender Report for transmission and
reception statistics from active senders.
(periodically transmitted)
201 RR Receiver Report for reception statistics
from participants that are not active
senders. (periodically transmitted)
202 SDES Source Description items. (including CNAME
– canonical name)
203 BYE Goodbye – Indicates end of participation.
204 APP Application specific functions.

Sender and Receiver reports
RTP receivers provide reception quality feedback

using RTCP report packets which may take one of two
forms depending upon whether or not the receiver is also
a sender. The only difference between the sender report
(SR) and receiver report (RR) forms, besides the packet
type code, is that the sender report includes a 20-byte
sender information section for use by active senders. The
SR is issued if a site has sent any data packets during the
interval since issuing the last report or the previous one,
otherwise the RR is issued.

Sender and Receiver reports (Contd..)
RECEIVER 2
SENDER
RECEIVER 1

END

Session Initiation Protocol: Presentation by

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Session Initiation Protocol: Presentation by

Încărcat de

Drepturi de autor:

Formate disponibile

SIP

Presentation by : Training Team

Sasken Communication Technologies Ltd.

© 2006 Sasken Communication Technologies 1

o Understand Pros and Cons of circuit & Packet

© 2006 Sasken Communication Technologies 2

© 2006 Sasken Communication Technologies 3

These systems are very fast. Since switches do not examine

© 2006 Sasken Communication Technologies 4

Before an information exchange between terminals can take

© 2006 Sasken Communication Technologies 5

Efficiency and suitability are the reasons why packet switching

© 2006 Sasken Communication Technologies 6

Delay and higher overhead as the two primary reasons why

© 2006 Sasken Communication Technologies 7

IP Telephony PSTN Telephony

ROUTING Dynamic Static switching

INTELLIGENCE Decentralized, or Centralized

SWITCHING Packet switched Circuit switched

BANDWIDTH Variable Fixed

© 2006 Sasken Communication Technologies 8

IP Telephony PSTN Telephony

H.323 SIP MGCP TUP ISUP

© 2006 Sasken Communication Technologies 9

ARPANET was developed within the research and

The idea was to gather all the feedback on a specific

© 2006 Sasken Communication Technologies 10

RFC 2068 Hypertext Transfer Protocol

© 2006 Sasken Communication Technologies 11

OSI Model IP Telephony PSTN Telephony

APPLICATION H.323 SIP RTP RTCP ISUP

TRANSPORT TCP UDP SCCP

© 2006 Sasken Communication Technologies 12

Sasken Confidential © 2006 Sasken Communication Technologies

© 2006 Sasken Communication Technologies 14

Light weight in complexity Very Complex

© 2006 Sasken Communication Technologies 15

URLs can be embedded in H.323 has no URL format

Cost Cheap Expensive

© 2006 Sasken Communication Technologies 16

Sasken Confidential © 2006 Sasken Communication Technologies

Session Initiation Protocol (SIP) is an

SIP is an alternative protocol developed by the

© 2006 Sasken Communication Technologies 18

• SIP is a peer-to-peer protocol

© 2006 Sasken Communication Technologies 19

• SIP uses existing IETF protocols to provide:

© 2006 Sasken Communication Technologies 20

• Uses URL style addresses and syntax

© 2006 Sasken Communication Technologies 21

• 5 facets of establishing and terminating multimedia communications:

© 2006 Sasken Communication Technologies 22

© 2006 Sasken Communication Technologies 23

© 2006 Sasken Communication Technologies 24

User Agent Servers (UAS)

• Application which contacts user when a SIP request is

SIP Call Request User “Call for you?”

© 2006 Sasken Communication Technologies 25

© 2006 Sasken Communication Technologies 26

Stateful vs. Stateless Proxy

© 2006 Sasken Communication Technologies 27

• Redirects calls to new User Agent

© 2006 Sasken Communication Technologies 28