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

© 2006 Sasken Communication Technologies 2

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

© 2006 Sasken Communication Technologies 3

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.

© 2006 Sasken Communication Technologies 4

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.

© 2006 Sasken Communication Technologies 5

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.

© 2006 Sasken Communication Technologies 6

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.

© 2006 Sasken Communication Technologies 7

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

© 2006 Sasken Communication Technologies 8

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

© 2006 Sasken Communication Technologies 9

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.

© 2006 Sasken Communication Technologies 10

References

References Description

RFC 2068 Hypertext Transfer Protocol

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

© 2006 Sasken Communication Technologies 11

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

© 2006 Sasken Communication Technologies 12

 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

© 2006 Sasken Communication Technologies 14

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

© 2006 Sasken Communication Technologies 15

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

© 2006 Sasken Communication Technologies 16

 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.

© 2006 Sasken Communication Technologies 18

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

© 2006 Sasken Communication Technologies 19

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

© 2006 Sasken Communication Technologies 20

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

© 2006 Sasken Communication Technologies 21

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.

© 2006 Sasken Communication Technologies 22

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

© 2006 Sasken Communication Technologies 23

 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

© 2006 Sasken Communication Technologies 24

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

© 2006 Sasken Communication Technologies 25

 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.

© 2006 Sasken Communication Technologies 26

 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

© 2006 Sasken Communication Technologies 27

 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

© 2006 Sasken Communication Technologies 28

 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

© 2006 Sasken Communication Technologies 29

 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)

© 2006 Sasken Communication Technologies 30

 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

© 2006 Sasken Communication Technologies 31

 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

© 2006 Sasken Communication Technologies 32

 How Does SIP Connect Session Members?

• SIP can communicate via:

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

© 2006 Sasken Communication Technologies 33

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.

© 2006 Sasken Communication Technologies 34

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.

© 2006 Sasken Communication Technologies 35

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

© 2006 Sasken Communication Technologies 36

SIP Messages : Examples of Response (2/4)

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

© 2006 Sasken Communication Technologies 37

SIP Messages : Examples of Response (3/4)

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

© 2006 Sasken Communication Technologies 38

SIP Messages : Examples of Response (4/4)

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

© 2006 Sasken Communication Technologies 39

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.

© 2006 Sasken Communication Technologies 40

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.

© 2006 Sasken Communication Technologies 41

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

© 2006 Sasken Communication Technologies 42

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

© 2006 Sasken Communication Technologies 43

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)

© 2006 Sasken Communication Technologies 44

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.

© 2006 Sasken Communication Technologies 45

 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

© 2006 Sasken Communication Technologies 46

 SIP Registration (Without Authentication)

User Agent Registrar

Contact: UserAgent@domain.com;
REGISTER
Expires: 3600
Contact: UserAgent@domain.com;
Expires: 3600

200 OK

© 2006 Sasken Communication Technologies 47

 SIP De-Registration

User Agent Registrar

Contact: UserAgent@domain.com; REGISTER

Expires: 0
401 Unauthorized

Contact: UserAgent@domain.com; REGISTER

Expires: 0
200 OK

© 2006 Sasken Communication Technologies 48

 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)

© 2006 Sasken Communication Technologies 49

 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

© 2006 Sasken Communication Technologies 50

 Call Failure – Ringing Timeout

User Agent A Proxy Server 1 Proxy Server 2 User Agent A

INVITE INVITE INVITE

Ringing Ringing
Ringing

408 Req Timeout

ACK
408 Req Timeout

ACK

© 2006 Sasken Communication Technologies 51

 Call Failure – User Busy

User Agent A Proxy Server 1 Proxy Server 2 User Agent A

INVITE INVITE INVITE

486 Busy Here

ACK
486 Busy Here

ACK
486 Busy Here

ACK

© 2006 Sasken Communication Technologies 52

 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

© 2006 Sasken Communication Technologies 53

 Security Concerns

• Replay Attacks
• Registration Hijacking
• Request Spoofing
• Impersonating a Server
• Chosen Plaintext Attack

Solution : SIP Security Mechanisms

© 2006 Sasken Communication Technologies 54

 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

© 2006 Sasken Communication Technologies 55

 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.

© 2006 Sasken Communication Technologies 56

 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.

© 2006 Sasken Communication Technologies 57

WWW-Authenticate Header in 401 and 407 Challenge

WWW-Authenticate: digest

realm="164.164.57.187",

qop="auth",

nonce="9e0962d5e57c4c5dbaa63dbcbe965d19",

opaque="5ccc069c403ebaf9f0171e9517f40e41“

algorithm=MD5

© 2006 Sasken Communication Technologies 58

 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.

© 2006 Sasken Communication Technologies 59

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

© 2006 Sasken Communication Technologies 60

Authorization Header in response to 401 and 407 challenge.
(Contd..)

cnonce="ed1ed6a122e4647b",

nc=00000001,

qop = auth,

Algorithm = MD5,

opaque="5ccc069c403ebaf9f0171e9517f40e41"

© 2006 Sasken Communication Technologies 61

 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.

© 2006 Sasken Communication Technologies 62

 SIP Registration (With Authentication)

User Agent Registrar

Contact: UserAgent@domain.com; REGISTER

Expires: 3600
401 Unauthorized

Contact: UserAgent@domain.com; REGISTER

Expires: 3600
200 OK

© 2006 Sasken Communication Technologies 63

 Simple SIP Call with Proxy Authentication

User Agent A Proxy Server 1 User Agent A

INVITE

100 Trying

407 Proxy Auth

ACK

INVITE

100 Trying INVITE

180 Ringing
180 Ringing
200 OK
200 OK

© 2006 Sasken Communication Technologies 64

Simple SIP Call with Proxy Authentication (Contd..)

User Agent A Proxy Server 1 User Agent A

200 OK
200 OK

RTP MEDIA PATH

BYE
BYE

200 OK
200 OK

© 2006 Sasken Communication Technologies 65

Session Description Protocol (SDP)

© 2006 Sasken Communication Technologies 66

 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.

© 2006 Sasken Communication Technologies 67

 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

© 2006 Sasken Communication Technologies 68

 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)

© 2006 Sasken Communication Technologies 69

 SDP Parameters (Contd…)

c=* (connection information)

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

© 2006 Sasken Communication Technologies 70

 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

© 2006 Sasken Communication Technologies 71

 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

© 2006 Sasken Communication Technologies 72

 Real-time Transport Protocol

© 2006 Sasken Communication Technologies 73

 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.

© 2006 Sasken Communication Technologies 74

 Real-time Multimedia Traffic

RTP RTP RTP RTP RTP RTP

Audio/Video frames are transmitted as

they are produced and displayed

© 2006 Sasken Communication Technologies 75

 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.

© 2006 Sasken Communication Technologies 76

 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)

© 2006 Sasken Communication Technologies 77

 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)

© 2006 Sasken Communication Technologies 78

 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)

© 2006 Sasken Communication Technologies 79

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.

© 2006 Sasken Communication Technologies 80

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

© 2006 Sasken Communication Technologies 81

 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.

© 2006 Sasken Communication Technologies 82

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.

© 2006 Sasken Communication Technologies 83

 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.

© 2006 Sasken Communication Technologies 84

 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

© 2006 Sasken Communication Technologies 85

 RTP Packet Structure

Ethernet IP UDP RTP

RTP Payload
Header Header Header Header

38 Bytes 20 Bytes 20 Bytes 12 Bytes Variable

© 2006 Sasken Communication Technologies 86

 RTP Header Structure

Payload
V P X CC M Sequence Number
Type

Time Stamp

SSRC

CSRC list
.
.
.
.
CSRC list

© 2006 Sasken Communication Technologies 87

 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.

© 2006 Sasken Communication Technologies 88

 RTP Header Structure (Contd…)

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.

© 2006 Sasken Communication Technologies 89

 RTP Header Structure (Contd…)

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.

© 2006 Sasken Communication Technologies 90

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

© 2006 Sasken Communication Technologies 91

 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

© 2006 Sasken Communication Technologies 92

 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

© 2006 Sasken Communication Technologies 93

 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

© 2006 Sasken Communication Technologies 94

 Real –Time Control Protocol (RTCP

© 2006 Sasken Communication Technologies 95

 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.

© 2006 Sasken Communication Technologies 96

 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)

© 2006 Sasken Communication Technologies 97

 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.

© 2006 Sasken Communication Technologies 98

 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.

© 2006 Sasken Communication Technologies 99

 Sender and Receiver reports (Contd..)

RECEIVER 2
SENDER

RECEIVER 1

© 2006 Sasken Communication Technologies 100

END

© 2006 Sasken Communication Technologies 105