Tom Qi

CSCF RT team
ericsson XYD/VV2
E-mail: tom.qi@ericsson.com
Overview
• Introduction to SIP
• SIP Components and Basic Operation
• SIP Methods and Message
• SDP
• Other SIP Knowledge
SIP URL and URI
SIP Routing and Domain Name System
SIP Reliability
Authentication
Extensibility Model

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Background

• Developed by IETF MMUSIC

(Multi-Party Multimedia Session
Control) Work Group
– The protocol standard is
released as RFC 2543 in 1999
– RFC 3261 (current base spec)
– Signaling protocol for exchange
of media information
– Can run on top of TCP and UDP

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Function

The basic functions of SIP:

1. location of an end point.
2.Signal of a desire to communicate.
3.Negotiation of session parameters to establish the
session.
4.Teardown of the session once established.

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Basic Design

Request
• SIP is a Client Server Protocol
– Clients send requests, receive
responses SIP Response SIP
– Servers receive requests, send Client Server
response
– A physical entity can have both
client and server functions
• Modeled after HTTP
• Each request invokes a method on
server

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Basic Concepts

• Session

• Dialog

• Transaction

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Session INVITE

180 Ringing

200 OK
Sessions include Internet
telephone calls, ACK
multimedia distribution,
and multimedia Media Session
conferences. Session
can include multimedia,
audio, video, data, pic,
etc.

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Dialog
A dialog represents a peer-to-
INVITE INVITE
peer
SIP relationship between two user
100 trying
agents. A dialog persists for some 100 trying

time and it is very important 200 OK 200 OK

concept for user agents. Dialogs
ACK
facilitate proper sequencing and ACK

routing of messages between SIP

Bye
endpoints. Dialogs are identified
using Call-ID, From tag, and To 200 OK
tag.

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Transactions INVITE

180 Ringing

• All signaling messages are composed of 200 OK CSeq: 1

independent transactions
• Fundamental unit of messaging ACK
exchange
– Request
Media Session
– Zero or more provisional responses
– One final response
– Maybe ACK BYE
• Identified by CSeq (Command CSeq: 2
Sequence) 200 OK
– Sequence number
– Method tag

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

 SIP Components and Basic Operation

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP – Protocol Components
TWO basic components exist in the SIP System Architecture

User Agent Network Servers

User Agent Client User Agent Server

Redirect Server Proxy Server
(Protocol Client) (Protocol Server)

User Agent Client Redirect Server

 End systems  “Network” server; redirects users to try other
 Send SIP requests server (user agent may act as redirect
 Usually contain SIP user agent server)
server Proxy Server
User Agent Server  “Network Server” Proxies request to another
 Listens for call requests server (user agent also may do this)
 Prompts user or executes program to  Can “fork” request to multiple servers,
determine response creating a search tree

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Architecture – Basic Operation

Request
SIP Redirect
Response Server
Location Service
2
3

5
4
6
1
7
11
12 10
SIP Proxy SIP Proxy
8

9
SIP Client
SIP Client
(User Agent
Server)

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Network Servers
Proxy servers must determine next hop server
Redirect servers must determine server to redirect to
Use Locator Service to determine next hop
 Locator Service outside scope of SIP
 Locator Service can be anything
 LDAP, whois, whois++
 POST corporate directory database
 local file
 result of program execution (IN)
If multiple next-hops are found it might do forking both in a parallel and sequential fashion
Servers can be totally stateless (i.e. after current transaction there is no memory of transaction)
Servers can be state-full if need be (i.e. a server can remain in the signaling path by using the
Route and Record-Route headers)

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Proxy Servers

• Forwards requests and responses only • Stateless proxy server process each request
– Does not issue a request; only responds to based solely on the message content
requests from user agent (except CANCEL) – Never retransmits
– Has no media capabilities – No memory
• Proxy server can be stateless or stateful • Stateful proxy server keeps track of requests
received and use that info for future response
– Uses a timer and retransmits after the timer
expires
– Can require user agent authentication
– Usually sends a 100 Trying response
– Proxy handling TCP must be stateful

User Agent Proxy Server User Agent

Client Server
Server Server
Server Client

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Forking Proxy Servers
INVITE
Branch = 1
SIP
• Stateful proxy Phone
• Forking proxy server can receive an INVITE request,
then forward to a number of locations at the same
time if the database lookup returns multiple possible INVITE
locations for the called party that need to be tried Branch = 2
• Two variations INVITE
– Sequential search: Try first address, only if that fails try SIP Mobile
second INVITE Phone
– Parallel search: Try all at once Forking Branch = 3
• First response (200 OK) received is forwarded Proxy Server
upstream Calling
• All other unanswered requests cancelled User
Agent
SIP
Enabled
PC

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

 Via: C
Via: B
Via: A
Loop Detection Via: U

Proxy Server Proxy Server

D C
• With all this forking and forwarding, request may Via: D
fall into a loop and come back to the same proxy! Via: C
• SIP provides two mechanisms to prevent Via: B
Via: B Via: A
messages from looping forever


Via: A Via: U
– Max-Forwards
Via: U
• Max-Hops counter decremented by 1 on each
hop
• Discard request when Max-Hops is zero
– Via based loop detection and prevention
• Every proxy inserts its address in the Via Via: A
header Proxy Server Via: U Proxy Server
• Check for its own address and branch in the A B
list of Via header Via: U
• Drop the request if loops are detected

Calling
User
Agent

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Redirect Servers
Redirect Server
User Agent A User Agent B

• INVITE
Uses a database or location service to
look up a user 302 Moved Temoprarily
• Responds to, but does not forward
requests ACK
• The location information is sent back to
the caller in a direction class response INVITE
200 OK
ACK

Media Session

BYE
200 OK

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Registration Servers

• Registration is for clients to tell proxy where

users are sitting using REGISTER messages
• Registration server accepts SIP REGISTER User Agent Registrar Server
requests
• Upon receiving the REGISTER message, the
server REGISTER
– Check if domain is its own Contact: sip:fei@ericsson.com
– Authenticate and authorize user
– Add address binding
– Return, in response, list of current registrations
200 OK
– Return, in response, expiration time for all
registrations

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

B2BUA
User Agent A B2BUA User Agent B

• a UAS linked to a UAC INVITE

– Acts as a UAS and as a 200 OK
UAC linked by some INVITE
application logic ACK

• Responds to, but does not 200 OK

forward requests, Generate ACK
new request to terminator

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

 SIP Methods and Message

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Methods and Message Structure
Request Line
Headers

Payload or Body
Note that this is opaque to SIP

REGISTER
 Informs a SIP server about the location of a user
INVITE
OPTIONS
 Invites a participant to a call
ACK
 Queries a participant about their
 For call acceptance capabilities
UPDATE
 Change media attributes of a call BYE
 Ends a client’s participation in a call
CANCEL
 Terminates a request
PRACK
 Confirm reliable delivery of an
intermediate response

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Message Syntax
Many header fields from http
New ones (Also, Replaces, Via) are SIP specific
Payload contains a media description
SDP – Session Description Protocol is used for media description in payload

• INVITE Request
INVITE sip:johndoe@xyz.com SIP/2.0
Via: SIP/2.0/UDP ihgp192.ih.ericsson.com:5060
To: John Doe <sip:johndoe@xyz.com>
From: Sam fei <sip:fei@ericsson.com>
Call-ID: 1354@ ihgp192.ih.ericsson.com
CSeq: 1 INVITE
Subject: About SIP
Contact: sip:fei@ericsson.com
Content-Type: application/SDP
Content-Length: 156

v=0 ;version
o=fei 6309794261 6309794261 IN IP4 ihgp192.ih.ericsson.com ;origin containing name
s=Phone Call ;subject
c=IN IP4 135.185.192.53 ;connection
t=0 0 ;time limit
m=audio 49170 RTP/AVP 0 ;media
a=rtpmap:0 PCMU/8000 ;attributes

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

An example of a SIP request
Request Method
Line INVITE sip:Gonzalo.Camarillo@ericsson.com SIP/2.0 Version
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7
Max-Forwards: 70 Request-URI
Route: <sip:pcscf1.visited1.net;lr>, <sip:scscf1.home1.net;lr>
Header

From: <sip:user1_public1@home1.net>;tag=171828
To: <sip:Gonzalo.Camarillo@ericsson.com> Header Field
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Contact: <sip:[5555::aaa:bbb:ccc:ddd]>
Content-Type: application/sdp
Header Field Name
Content-Length: 248 Header Field Value
 
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
Body

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=907165275 0
m=audio 3458 RTP/AVP 97 96 0 15
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 G726-32/8000

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Message Syntax (2)

• 200 OK Response
SIP/2.0 200 OK
Via: SIP/2.0/UDP ihgp192.ih.ericsson.com:5060
To: John Doe <sip:johndoe@xyz.com>;
tag=314511
From: Sam fei <sip:fei@ericsson.com>
Call-ID: 1354@ ihgp192.ih.ericsson.com
CSeq: 1 INVITE
Contact: sip:johndoe@xyz.com
Content-Type: application/SDP
Content-Length: 148

v=0 ;version
o=John 3125551234 3125551234 IN IP4 star9.xyz.com ;origin containing name
s=Phone Call ;subject
c=IN IP4 128.135.26.52 ;connection
t=0 0 ;time limit
m=audio 38767 RTP/AVP 0 ;media
a=rtpmap:0 PCMU/8000 ;attributes

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

An example of a SIP response
Status SIP Version
SIP/2.0 200 OK Reason phrase
Line Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];branch=z9hG4bKnashds7
Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>
From: <sip:user1_public1@home1.net>;tag=171828 Status codes in SIP
To: <sip:Gonzalo.Camarillo@ericsson.com>;tag=314159 1xx - Provisional responses
Header

Call-ID: cb03a0s09a2sdfglkj490333 Status code 2xx - Success

CSeq: 127 INVITE
Contact: <sip:[5555::eee:fff:aaa:bbb]> 3xx - Redirection
Content-Type: application/sdp 4xx - Client Error
Content-Length: 220
5xx - Server Error

v= 6xx - Global Failures

o=- 2987933615 2987933615 IN IP6 5555::eee:fff:aaa:bbb
s=-
Body

c=IN IP6 5555::eee:fff:aaa:bbb

t=907165275 0
m=audio 3458 RTP/AVP 97 0
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Request Methods

• Six basic SIP methods

– INVITE, REGISTER, BYE, ACK, CANCEL, OPTION
• New methods
– INFO, PRACK,MESSAGE,SUBSCRIBE,NOTIFY,REFER,PUBLISH
• A proxy treats an unknown method as if it were an OPTION and
forwards the request to the destination
– Allow new feature to be introduced by user agents without having proxies in
the middle involved
• Method names are case sensitive

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Summary of SIP methods (cont.)
SIP methods

RFC-3261
ExtensionProtocol
Extension Protocolmethods
methods
Core Protocol methods Extension Protocol methods

INVITE PRACK (RFC 3262)

ACK REFER (RFC 3515)
SUBSCRIBE (RFC 3265)
CANCEL
NOTIFY (RFC 3265)
BYE INFO (RFC 2976)
OPTION UPDATE (RFC 3311)
REGISTER PUBLISH (RFC 3903)
MESSAGE (RFC 3428)

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Request Methods
Request Method Description

INVITE Used to establish session between user agents

REGISTER Used by a user agent to notify a SIP network of its current IP

address and URL for calls

BYE Used to terminate an established media session

ACK Used to acknowledge final response to INVITE requests

CANCEL Used to terminate pending searches or call attempts

OPTION Used to query a user agent or server about its capability and
its current availability

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Request Methods (2)
Request Method Description
INFO Used by user agent to send call signaling information to other
user agent with which it has an established session
PRACK (Provisional Used to acknowledge receipt of reliably transported
Response Ack) provisional responses (1xx)
SUBSCRIBE: installs a subscription for a resource
NOTIFY: informs about changes in the state of the resource
MESSAGE: delivers an Instant Message
REFER: used for call transfer, call diversion, etc.
PRACK: acknowledges a provisional response for an INVITE request
UPDATE: changes the media description (e.g. SDP) in an existing
session
INFO: used to transport mid-session information
PUBLISH: publication of presence information

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP: INVITE
UAC UAS

INVITE
• Final responses to INVITE are always
acknowledged with the ACK method
• Usually has a message body containing the 100 Trying
media information of the caller
– May also contain QoS or security information 180 Ringing
– If an INVITE does not contain media
information, the ACK contains the media
information of the UAS
200 OK
• A media session is established after
INVITE, 200 OK, and ACK messages are sdp UAS
exchanged between UAC and UAS
ACK
sdp UAC

Media Session

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP: REGISTER

• Registration is not required for user agent to make

calls through proxies, but is required to receive calls
User Registrar Server
• Agent
If no expires parameter , a SIP URL expires in 1
hour.
REGISTER
• If an expires parameter is present, it sets the Contact: sip:fei@ericsson.com
expiration time for that Contact only.

• The CSeq is incremented for a REGISTER request 200 OK

• The To header contains the SIP URL of the user
agent being registered, the From contains the SIP
URL of the sender of the request

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP: BYE

• Terminates an established media session, similar to a

release message
• BYE is an End-to-end method User Agent User Agent
A B
• Only sent by user agents participating in the session,
never by proxies or other third parties Media Session
• Can be sent by either the caller or the called party in
a session
• May not contain a message body BYE
• Always increments the CSeq
200 OK
• A BYE sent for a pending request cancels the request,
but a final response must still be issued for the
INVITE by the UAS

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

 SIP: ACK

• Acknowledges final response to INVITE

request
• CSeq is never incremented for an ACK, but the
CSeq method is changed to ACK User Agent User Agent
• Stateful Proxy
May contain an application/sdp message A B
body if the initial INVITE didn’t contain a SDP 200 OK (E2E)
message body 200 OK (E2E)
• May not be used to modify a media description
that has been sent in the initial INVITE (use ACK (E2E)
re-INVITE) ACK (E2E)

• ACK is end-to-end for 2xx

response, but hop-by-hop for all 410 Gone (HbH)
other final responses 410 Gone (HbH)
ACK (HbH)
ACK (HbH)

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

 SIP: CANCEL • CANCEL is a hop-by-hop
• Terminates pending searches or call attempts request and receives a
• Can be generated by either user agents or response generated by next
proxy servers
stateful element
• CSeq is not incremented so that
proxies and user agents can
User Agent User Agent
match the CSeq of the CANCEL
Stateful Proxy
A B
with the CSeq of the pending
Request (E2E)
Request (E2E)
INVITE request
• A user agent confirms the
Response (E2E)
Response (E2E) cancellation with a 200 OK
response and replies to the
INVITE with a 487 Request
Request (HbH) Canceled response
Request (HbH) • May not contain a message
Response (HbH)
Response (HbH) body

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Race Condition in Call Cancellation

User INVITE Stateful Proxy

User
Agent A CSeq: 1 INVITE INVITE Agent B
CSeq: 1 INVITE
100 Trying
CSeq: 1 INVITE 100 Trying
CSeq: 1 INVITE

CANCEL 200 OK
CSeq: 1 CANCEL
CSeq: 1 INVITE
200 OK CANCEL
CSeq: 1 CANCEL CSeq: 1 CANCEL

200 OK 200 OK
CSeq: 1 INVITE CSeq: 1 CANCEL

ACK
CSeq: 1 ACK
BYE
CSeq: 2 BYE

200 OK
CSeq: 2 BYE

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

MESSAGE

• Instead of a session description, sip could send a human-

readable message.
• Instant messaging
• Same routing as for BYE

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SUBSCRIBE/NOTIFY

• Need for asynchronous notification of events.

• Presence service
• Multi-conference Unit Information

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP: OPTIONS
• Query a user agent or server • A proxy determines if an
about its capabilities and discover OPTIONS request is for itself by
its current availability examining the Request-URI
• Never generated by proxy – If Request-URI contains proxy
• A user agent or server responds address, the request is for the
proxy
to the request as it would to an
– Otherwise, the request is for
INVITE
another proxy or user agent and
• Capabilities are contained in the request is forwarded
success class (2xx) response • Extended usage: SIP layer ping
with supported methods (Allow), – Send OPTIONS periodically to
media types (Accept) and detect whether remote SIP entity
supported features (Supported) . is responsive.
• May not contain a message body

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP: INFO (RFC 2976)
• Sends call signaling • Carry certain PSTN mid-call
information to another user signaling information such as
agent with which it has an ISUP USR messages, DTMF
established media session digits, Falsh-hook events etc.
• Does not change the media
characteristics of the call (use
re-INVITE ) INFO sip:10.0.1.141:5060 SIP/2.0
Content-Type:application/broadsoft
• End-to-end, never initiated by Call-ID:BW1518@10.0.1.141
proxy CSeq:5 INFO
• Always increments the Cseq From: “Alex” <sip:3010050303@10.0.1.141>;tag=123
To: “Bob” <sip:0301@10.0.1.141>;tag=931
• Typically contains a message
Via:SIP/2.0/UDP 10.254.25.1:23072
body
Supported:100rel,timer
Max-Forwards:10 Content-Length:17
event flashhook

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

 INVITE
Supported: 100rel UAS
SIP: PRACK UAC CSeq: 1 INVITE

100 Trying
• Acknowledge receipt of reliably transported CSeq: 1 INVITE
provisional response 180 Ringing
• Some provisional response, such as 180 CSeq: 1 INVITE
Ringing, are critical in determining the call state, RSeq: 314
the receipt needs to be confirmed  180 Ringing T1
• PRACK applies to all provisional responses except CSeq: 1 INVITE
100 Trying RSeq: 314
• Generated by a UAC when a provisional response PRACK
has been received containing a RSeq reliable CSeq: 2 PRACK
sequence number and a Supported: rel100 RAck: 314 1 INVITE
header 200 OK
• Echoes the number in the RSeq and the CSeq in a CSeq: 2 PRACK
RAck header
• Always increments CSeq 200 OK
CSeq: 1 INVITE
ACK
CSeq: 1 ACK

Media Session

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Response Message

• A SIP response is a message generated • If a particular SIP response code is not

by a UAS or a SIP server to reply to a understood by a UAC, it must be
request generated by a UAC interpreted by the class of the response
• A response may be a simple • Reason codes in the range x00 - x79
acknowledgment to prevent were borrowed from HTTP, perhaps with
retransmission of the request by the
UAC or may contain additional headers a slightly different reason phrase
with information needed by the UAC • Reason codes created for SIP begin at
• Six classes of SIP responses x80
– 1xx to 5xx borrowed from HTTP • Reason phrase is for human
– 6xx created for SIP understanding only

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Response Classes
Class Description

1xx Informational: Indicates status of call prior to completion, also

called provisional

2xx Success: Request has succeeded

3xx Redirection: Server has returned possible locations

4xx Client error: The request has failed due to an error by the client

5xx Server failure: The request has failed due to an error by the server

6xx Global failure: The request has failed and will fail wherever it is
tried

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Response Code Examples
1xx Informational – 100 Trying
– 180 Ringing
– 181 Call is Being Forwarded
– 182 Queued
– 183 Session Progress

2xx Success – 200 OK

3xx Redirection – 301 Moved Permanently

– 302 Moved Temporarily

4xx Client Error – 401 Unauthorized

– 482 Loop Detected
– 486 Busy Here

5xx Server Failure – 500 Server Internal Error (Retry-after:5)

6xx Global Failure – 600 Busy Everywhere

– 604 Does not Exist Anywhere

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Headers

• Four Types of SIP Header

– General, Request, Response, Entity
• Header Syntax – header:field
– header – case-insensitive token representing header
– field – case-insensitive token containing the information
– A line starting with one or more space or tab character continues the header fields
• Order of headers is not significant
• Unrecognized headers are ignored by proxies
• Headers can be either end-to-end or hop-by-hop
• Proxy may only insert hop-by-hop headers, with a few exceptions
• A proxy should never change the header order

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

General Headers – Overview

• Can be present in both requests and responses

• Created by user agents and cannot be modified by proxies
• Includes all of the required headers in a SIP message
• Call-ID*, Contact*, Cseq*, Date, Encryption,
From*, Organization, Retry-After, Subject,
Supported, Timestamp, To*, User Agent, Via*

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

General Header: Via*

• Via: SIP/2.0/UDP 3gmsc6.ih.ericsson.com

– Required header to record the SIP route taken by a request and to route a response
back to the originator
– The Via header order is significant for routing
– A user agent generating a request records its own address in a Via header in the
request
– A proxy forwarding the request adds a Via header containing its own address to
the top of the list of Via headers
– A proxy or user agent generating a response to a request copies all the Via
headers from the request in order into the response, then returns the response to
the address specified in the top Via header
– Via header contains protocol name, version number, transport, and may contain
port number, and parameters such as received, hidden, branch, maddr, and
ttl

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Via Operation

Via: C
Via: B Via: B
Via: A Via: A Via: A
Proxy Proxy
UAC UAS
Via: A Via: B Via: C
Addr: A Addr: B Addr: C Addr: D
Via: A Via: B
Via: A

Request
Response

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Response received by server

Via Forwarding Decision Tree

Does the first NO
Via header match Discard
server address? message
maddr YES Forward response
parameter to multicast
YES present? address in maddr
Remove first
Via header NO

received YES Forward response

NO Response is parameter to address
Second
for this server present? in received
Via header?
to process
NO
YES
Forward response
to address in
Second Via header

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Request Headers – Overview

• Added to a request by a UAC to modify or give additional information about the request
• Accept, Accept-Encoding,
Accept-Language, Authorization, Hide,
In-Reply-To, Max-Forwards, Priority,
Proxy-Authorization, Proxy-Require,
Record-Route, Reject-Contact,
Request-Disposition, Require,
Response-Key, Route, RAck,
Session-Expires

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Response Headers – Overview

• Added to a response by a UAS or SIP server to give more information than just the
response code and reason phrase
• Not added to a request
• Proxy-Authenticate, Server, Unsupported,
Warning, WWW-Authenticate, RSeq

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Entity Headers – Overview

• Provide additional information about the message body or the resource requested
• In SIP, “entity” and “message body” are used interchangeably
• Allow, Content-Encoding,
Content Disposition, Content-Length*,
Content-Type , Expires, MIME-Version

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Acknowledgment of Messages

• Most SIP requests are end-to-end messages between user agents, except
– CANVEL method is a hop-to-hop request
– A 4xx, 5xx, or 6xx response is acknowledged on a hop-to-hop basis
• ACK messages are only sent to acknowledge responses to INVITE requests
• For responses to all other request types, there is no acknowledgement
• A lost response is detected by the UAS when the request is retransmitted

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

 SDP(Session Description Protocol)

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Message Bodies
• Message bodies in SIP may contain various types of information, which can be used
to describe media information or QoS or even security information
• The optional Content-Disposition header is used to indicate the intended use of
the message body
• Currently defined functions are
– session (default) – the message body describes a media session
– render – the message body should be presented to the user (could be used to pass a
JPEG image or a URL)
– icon – the message body contains an image suitable as an icon of the caller or callee
– alert – the message body contains information that should be rendered

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP Message Bodies (2)
• The format is indicated by the Content-Type header
– application/sdp MUST be supported
• The encoding scheme of the message body is indicated by the Content-Encoding
header
– text/plain is the default
• The message body can be encrypted with the encryption scheme indicated by the
Encryption header
• The Content-Length header is required and contains the number of octets in the
message body
– If there is no message body, the Content-Length header should have the value of 0
– If a Content-Length is not present, a user agent must assume that the message body
continues until the end of the UDP datagram, or until the TCP connection is closed
• Message bodies can have multiple parts using MIME

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SDP – Session Description Protocol
 IETF RFC 2327 - A general purpose
format for session description
 Can be used in other protocols like
SIP, SAP, MGCP, RTSP, Email,
Example:
HTTP, etc.
v=0
 Conveys information about media o=Pingtel 5 5 IN IP4 135.252.30.95
streams to enable joining and s=phone-call
participating in multimedia
c=IN IP4 135.252.30.95
sessions.
t=0 0
 SDP Syntax
m=audio 8766 RTP/AVP 0 8
 A number of lines in textual form
a=rtpmap:0 pcmu/8000/1
 Line form: type=<value> a=rtpmap:8 pcma/8000/1
 Lines are in fixed order a=sendrecv
 Session description
 Time description
 Media description(s)

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SDP example
Version ---> v=0
Origin ---> o=gonzalo 2987933615 2987933615 IN IP4 10.0.0.8
Session Name --> s=training course
Session URI --> u=http://standards.ericsson.net/sip
level E-mail address --> e=Gonzalo.Camarillo@ericsson.com
Phone number --> p=+358-9-299-3553 IP address where
Connection Data --> c=IN IP4 10.0.0.8
media is received
Times --> t=907165275 0
Media --> m=audio 3458 RTP/AVP 97 0
Attributes --> a=rtpmap:97 AMR
Media Attributes --> a=fmtp:97 mode-set=0,2,5,7; maxframes=2
level Media --> m=video 3459 RTP/AVP 98
Attributes --> a=rtpmap:98 H263 Codecs
Media --> m=application 32416 udp wb

Type of media Port number where

streams media is received

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

RTP/AVP codecs (RFC 1890)
PT Encoding Name Audio/Video PT Encoding Name Audio/Video

0 PCMU (u-law) A 16-23 unassigned A

1 1016 A 24 unassigned V

2 G721 A 25 CelB V

3 GSM A 26 JPEG V

4 unassigned A 27 unassigned V

5 DVI4 A 28 nv V

6 DVI4 A 29 unassigned V

7 LPC A 30 unassigned V

8 PCMA (a-law) A 31 H261 V

9 G722 A 32 MPV V

10 L16 A 33 MP2T AV

11 L16 A 34-71 unassigned ?

12, 13 unassigned A 72-76 reserved N/A

14 MPA A 77-95 unassigned ?

15 G728 A 96-127 dynamic ?

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP URL

• SIP addresses are URLs (Uniform Resource Locators) and URIs (Uniform Resource Indicators)
• Used in To, From, Contact, and Request-URI headers
• The information in a SIP URL indicates the way in which the resource (user) should be
contacted using SIP
• URL contains several components
– Scheme (sip:)
– Username@Hostname
– Optional Port sip:fei@ericsson.com:5060:transport=udp;
– Optional Password user=ip;method=INVITE;ttl=1;
– Parameters maddr=135.195.192.23?Subject=Sample
– Headers and Body
• SIP allows any URI types
– Telcom URIs
– HTTP URLs for redirect
– Mailto URLs

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP URL
• SIP uses Uniform Resource Identifiers (URIs). At least, SIP URIs and
SIPS URIs are supported, although others (such as TEL URL) are
commonly supported.
– sip:Gonzalo.Camarillo@ericsson.com
– sips:Gonzalo.Camarillo@ericsson.com
– tel:+358-9-299-3371
– sip:proxy.atlanta.com:5060
– sip:another-proxy.biloxi.com;transport=UDP
• SIP and SIPS URIs must include a host name, and may include
username, may include port numbers, may include parameters
• Address space is unlimited
• Non SIP/TEL URIs are also valid under certain circumstances: HTTP,
IM, PRES, MAILTO…

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP routing and Domain Name System
• SIP clients use DNS to route requests and find the next
hop to route the request
– By looking into a NAPTR (Naming Authority Pointer) record in DNS
– By looking into a SRV (Services) record in DNS
– By looking into A (IPv4) or AAAA (IPv6) records in DNS
SIP server DNS server
sip:user@example.com
NAPTR query: example.com

NAPTR response: _sip._tcp.example.com

SRV query: _sip._tcp.example.com

SRV response: server1.example.com

A or AAAA query: server1.example.com

SIP request sent to 10.8.2.1 A response: 10.8.2.1

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Reliability

• SIP has reliability mechanism defined to allow the use of unreliable transport layer
protocols such as UDP
• SIP user agent does not check to determine if a message has been corrupted in
transmission (UDP’s job)
• SIP user agent does check to make sure that the client has erred by creating a request
missing required headers
• Reliability mechanisms in SIP include:
– Retransmission timers
– Increasing command sequence CSeq numbers
– Positive acknowledgements

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

INVITE Reliability
User User
Agent A Agent B
INVITE
INVITE 
• Client retransmits INVITE with
exponential backoff INVITE 
•
– 500 ms, 1s, 2s, 4s, 8s, … 
Retransmissions cease when provisional
response (1xx) arrives INVITE
– Next hop should send 100 Trying to
stop retransmission 100 Trying
– Response retransmitted when request 
retransmissions arrive INVITE
• Final response retransmitted with
100 Trying
exponential backoff
• ACK sent on receipt of final response
200 OK
 200 OK
ACK

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Non INVITE Reliability
User Agent User Agent
A BYE B

BYE 
• Response should come quickly
– No need to ring phone

• Request retransmitted with exponential BYE
backoff, up to 4s
100 Trying
– If provisional response received, request
retransmitted at 4s intervals 
BYE
• After 4s, request retransmitted every 4 s
• Response retransmitted on receipt of 100 Trying
request
– That is why request must be BYE
retransmitted after provisional – protect
against response loss 200 OK
– No ACK 
BYE

200 OK

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Hop-by-Hop vs. End-to-End
User Agent User Agent
A INVITE Proxy Server B
100 Trying INVITE
• Hop-by-hop implies messages  INVITE 100 Trying
transmitted reliably between each entity
100 Trying
(UAC to proxy, proxy to UAS)
• End-to-end implies proxies simply 200 OK
200 OK
forward requests, reliability is assured
between UAC and UAS only
 200 OK

• Stateless proxies simply forward


200 OK
requests 200 OK
• 200 OK response to INVITE is end-to-
ACK
end reliable
– UAC must see all 200 OK
 200 OK
200 OK

ACK
ACK

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Authentication

• Two types of authentication

– Authentication of a user agent by a proxy, redirect, or registration server
– Authentication of a user agent by another user agent
– A proxy or redirect server may require authentication to allow a user agent to access service or
feature
– A registration server may require authentication to prevent income call hijacking
– User agents can authenticate each other to verify who they are talking to
• A proxy requiring authentication replies to an unauthenticated INVITE with a 407 Proxy
Authentication Required response containing a Proxy-Authenticate header
with the form of challenge

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Authentication Call Flow

UAC UAS
Stateful Proxy
INVITE

407 Proxy-Authorization Required

Proxy-Authenticate: 1
ACK
INVITE
Authorization: 1
INVITE
100 Trying
401 Unauthorized
401 Unauthorized WWW-Authenticate: 2
WWW-Authenticate: 2
ACK
ACK
INVITE
Authorization: 1, 2 INVITE
100 Trying Authorization: 2

200 OK
200 OK
ACK
ACK
Authorization: 1, 2
Authorization: 2

Media Session

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Encryption

• SIP messages intercepted during session setup reveal

– Both parties’ SIP URLs and IP addresses
– The fact that the two parties have established a call
– The IP addresses and port numbers associated with the media, allowing eavesdropping
• SIP supports the encryption of both message bodies and message headers
– Encryption of message bodies makes it more difficult for an eavesdropper to listen in
– Encryption of headers can hide the parties in a media session
– Headers used by proxies to route the requests and responses should not be hidden or the
messages will become unroutable
• Transport and Network Layer Security
– TLS and IPSec
– SIPS URI Scheme (sips:alice@atlanta.com)

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Extensibility Model

• Goal: Ensure baseline operation always works

• Protocol can be extended by
– Define new headers and semantics
– Define new parameters and semantics
– Define new methods
– define new bodies
• New parameters and headers can be optional
• Features that must be understood are given names
• Feature naming
– IANA registered
• Client can insist server understand a feature
• Server can place a feature in a response if client understands it

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Extensibility: New Methods
UAC UAS

• Methods define fundamental behavior

• Client can send request with new
method GOAWAY
To: John Doe
• UAS rejects requests with unknown
methods
– 405 response
– list allowed methods in Allow header 405 Method Not Allowed
• Proxies don’t care about methods Allow: INVITE, BYE,
OPTIONS, ACK,
– Proxy rules are independent of method
CANCEL

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Extensibility: New Bodies
UAC UAS

• Bodies convey non-SIP related

information about request
• Body types enumerated by IANA registry INVITE
Content-Type: text/foo
• Not all bodies known to a server Content-Length: 2
• When server receives request with
unknown body aa
– 415 Unsupported Media response
– Allow header lists valid MIME body types
• Only used by user agents 415 Unsupported Media
Accept: text/plain

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Proposed SIP Methods

Method Name Description

INFO Mid-call signaling information exchange
PRACK Acknowledgement of provisional response
REFER Call transfer
SUBSCRIBE Notification of Subscribed Call Event
NOTIFY Request Notification of Call Event
COMET Call Preconditions Met

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Proposed SIP Headers & Responses
Header Name Description

Accept-Contact Caller preference for allowed URIs for proxy operation

RAck Reliable provisional response acknowledgement number
Reject-Contact Caller preference for rejected URIs for proxy operation
Request-Disposition Caller preference for type of server operation
RSeq Reliable provisional response sequence number
Session-Expires Time limit on media session using session timer
Supported Lists options implemented by a User Agent or server
Refer-To URL for attended transfer

Response Code Description

183 Session Progress Carries message body prior to final response

421 Extension Required A proxy to require an extension

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

Protocol Zoo

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06

SIP & SDP Ericssonwide Internal Tom Qi 2009-08-06