SIP Tutoiral www.dynamicsoft.

com
 A Tutorial on SIP

Jonathan Rosenberg
Chief Scientist

SIP Tutoiral www.dynamicsoft.com

Introducing - Session Initiation Protocol (SIP)

 Developed in mmusic group in IETF  Main Features

 Proposed standard RFC2543, Feb. 1999  Personal mobility services
 Work began 1995
 Wide area operation
 Part of Internet Multimedia Conferencing Suite
 Session independence
 Main functions  voice, video, games, chat,
 Invitation of users to sessions
virtual reality, etc.
 Find the users current location to deliver
invitation  Leverages other Internet protocols
 Carry opaque session descriptions
 Modification of sessions
 Termination of sessions

SIP Tutoiral www.dynamicsoft.com

Basic Design
 SIP is a Client Server Protocol
 Clients send requests, receive responses
 Servers receive requests, send responses
request
Client Server
 Modelled after HTTP
response
 Each request invokes method on server
 Main purpose of request

 Messages contain bodies

SIP Tutoiral www.dynamicsoft.com

Transactions INVITE
100
 Fundamental unit of messaging exchange 200 Cseq: 1
 Request
 Zero or more provisional responses ACK
 Usually one final response
 Maybe ACK First Transaction

 All signaling composed of independent transactions

 Identified by Cseq BYE
 Sequence number
Cseq: 2
 Method tag 200

Second Transaction

C S

SIP Tutoiral www.dynamicsoft.com

Session Independence
 SIP
BodyBodies
of SIPare
message
MIME objects
used to establish call describes the session
 MIME = Multipurpose Internet Mail Extensions
 Session could be
 Mechanisms

Audio for describing and carrying opaque content
 Used

Video with HTTP and email
 SIP bodies can carry other information too!
 Game
 JPEG for caller ID
 SIP operation is independent of type of session
 HTML page for Web IVR

SIP Tutoiral www.dynamicsoft.com

Protocol Components
 User Agent Client (UAC)
 End systems  Redirect Server
 Send SIP requests  “Network” server; redirects users to try other
 User Agent Server (UAS) server
 Listens for call requests  Proxy Server
 Prompts user or executes program to  “Network Server” Proxies request to another
determine response server Can “fork” request to multiple
servers, creating a search tree
 User Agent
 Registrar
 UAC + UAS
 receives registrations regarding current user
locations

SIP Tutoiral www.dynamicsoft.com

SIP Addressing
 SIP addresses are URL’s
 URL contains several components
 Scheme (sip)
 Username
 Optional password
 Hostname
 Optional port
 Parameters
 Headers and Body
sip:[email protected]:5061;
 SIP allows any URI type
user=host?Subject=foo
 tel URIs
 http URLs for redirects
 mailto URLs
 leverage vast URI infrastructure

SIP Tutoiral www.dynamicsoft.com

Network Servers
 Main Function is routing LS
 Where should request go next?
 Can redirect or proxy there

 SIP does not dictate how routing

is done
 Location Service provides data Proxy
 Abstract concept
 LDAP, whois, whois++
 result of program execution (IN)

 End result is a mapping from one

SIP URI to another
 sip:[email protected] to
sip:[email protected]

SIP Tutoiral www.dynamicsoft.com

Proxies
 Requests can traverse
multiple proxies from
caller to callee LS
 Each proxy:
 receives request
 checks if domain in request sip:[email protected] sip:[email protected]
URI is its own Proxy Proxy

 Domain matches 200 OK 200 OK

 invokes location service
200 OK
 obtains new request URI
 looks up host portion in DNS
 forwards to next hop server sip:j_user@host.
 receives response eng.a.com
 forwards response

SIP Tutoiral www.dynamicsoft.com

DNS Usage DNS

 Take domain name of request

URI
A
 Look for SRV records DNS SRV A 100
Query B 200
 SRV records specify a list of IP
C 300
addresses for servers for a D 400
particular service B
 List includes priority values and
preferences for each address
 Try IP addresses in order of
Proxy C
preference, go to next if no
response
 If no SRV records present, use D
A records
 A records are standard hostname
to IP address records

SIP Tutoiral www.dynamicsoft.com

Local Outbound Proxies
 Can send a request to a
proxy without performing
DNS procedure INVITE [email protected]

 Result is that proxy receives

a request whose domain is
not its own
 Proxy then performs DNS
process just described to
forward request INVITE [email protected]

 May also provide additional

services
a.com
 Outbound screening
 Authorization
 Logging
 Firewall control

SIP Tutoiral www.dynamicsoft.com

SIP Methods
 INVITE  OPTIONS
 Invites a participant to a session  Queries a participant about their media
 idempotent - reINVITEs for session capabilities, and finds them, but
modification doesn’t invite

 BYE  ACK
 Ends a client’s participation in a session  For reliability and call acceptance

 CANCEL  REGISTER
 Terminates a search  Informs a SIP server about the location
of a user

SIP Tutoiral www.dynamicsoft.com

SIP Architecture
Request
Response
Media
SIP Redirect
Server Location Service
2
3

5
4
6
1
7
11
12 10
SIP Proxy
13 SIP Proxy
8
SIP UA 14 9

SIP UA
(User Agent Server)

SIP Tutoiral www.dynamicsoft.com

SIP Message Syntax
 Many header fields from INVITE sip:[email protected] SIP/2.0
http From: J. Rosenberg <sip:[email protected]>
Subject: SIP will be discussed, too
 Payload contains a media
To: A. Netravali <sip:[email protected]>
description Via: SIP/2.0/UDP pc13.dynamicsoft.com
 SDP - Session Call-ID: [email protected]
Description Protocol Content-type: application/sdp
CSeq: 4711 INVITE
Content-Length: 187

v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
[email protected]
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0

SIP Tutoiral www.dynamicsoft.com

SIP Address Fields
INVITE sip:[email protected] SIP/2.0
 Request-URI From: J. Rosenberg
 Contains address of next <sip:[email protected]>;tag=76ah
hop server Subject: SIP will be discussed, too
 Rewritten by proxies To: A. Netravali <sip:[email protected]>
based on result of Via: SIP/2.0/UDP pc13.dynamicsoft.com
Location Service Call-ID: [email protected]
 To Content-type: application/sdp
Contact: sip:[email protected]
 Address of original called
CSeq: 4711 INVITE
party Content-Length: 187
 Contains optional display
name v=0
 From o=user1 53655765 2353687637 IN IP4 128.3.4.5
 Address of calling party s=Mbone Audio
i=Discussion of Mbone Engineering Issues
 Optional display name
[email protected]
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0

SIP Tutoiral www.dynamicsoft.com

SIP Responses
 Look much
Status Codelike
Classes
requests
 Headers,
100 - 199 bodies
(1XX): Informational
 200 - 299 (2XX): Success
 Differ in top line

 300 - 399
Status (3XX): Redirection
Code
 400
 -Numeric,
499 (4XX):
100Client
- 699Error
 500
 -Meant
599 (5XX): Server Error
for computer processing
 600 - 699 (6XX): Global Failure
 Protocol behavior based on 100s digit

 Two groups
 Other digits give extra info

 Reason
100 - 199:
Phrase
Provisional
 Not
Textreliable
phrase for humans
 200
 -Can
699:be
Final,
anything
Definitive
 Example
 200 OK
 180 Ringing

SIP Tutoiral www.dynamicsoft.com

Example SIP Response
 Note how only difference
SIP/2.0 200 OK
is top line From: J. Rosenberg
<sip:[email protected]>;tag=76ah
 Rules for generating
To: A. Netravali <sip:[email protected]>;tag=112
responses Via: SIP/2.0/UDP pc13.dynamicsoft.com
 Call-ID, To, From, Cseq are Call-ID: [email protected]
CSeq: 4711 INVITE
mirrored in response to
Contact: sip:[email protected]
support matching
 Tag added to To field

SIP Tutoiral www.dynamicsoft.com

SIP Transport
 Reliability
SIP Messagesmechanisms
over UDPdepend
or TCP on SIP request method
 INVITE
 Reliability mechanisms defined for UDP
 anything except INVITE
 UDP Preferred
 Reason:
 Fasteroptimized for phone calls
 No connection state needed in kernel
 Multicast possible (later)

SIP Tutoiral www.dynamicsoft.com

INVITE reliability INV
INV
 Client retransmits INVITE with exponential backoff
 500ms, 1s, 2s, 4s, 8s….. INV
 Retransmissions cease when provisional response arrives
 Next hop should send 100 Trying to stop retransmissions
INV
 Response retransmitted when request retransmissions arrive
Ring...
 Final response retransmitted with exponential backoff up to 4s
 May take a long time to answer phone!!
100 Trying
INV
 ACK sent on receipt of final response
100 Trying

200 OK

200 OK

ACK

C S

SIP Tutoiral www.dynamicsoft.com

Non-INVITE Reliability BYE
BYE
 Responses should come quickly
BYE
 No need to ring phone
 Request retransmitted w/ exponential backoff, up to 4s 100 Trying
 If provisional response received, request retransmittedBYE
at 4s intervals
 After 4s, request retransmitted every 4s
 Response retransmitted on receipt of request
 BYE
That’s why request must be retransmitted after provisional - protect against response loss
 no ACK

200 OK
BYE

200 OK

C S

SIP Tutoiral www.dynamicsoft.com

TCP Transport
 Reliability rules for TCP same as UDP with one change
 Requests not retransmitted

 However, 2xx final responses still retransmitted

 ACK is still sent
 Reason?
 Handles case of a mix of UDP and TCP connections

SIP Tutoiral www.dynamicsoft.com

Hop by Hop vs. End to End INVITE
INVITE
 Reliability can be HBH or E2E 100 Trying 100 Trying
INVITE
 HBH implies message transmitted reliably between each entity (UAC to proxy, proxy to
UAS)
100
 E2E implies proxies simply forward requests, reliability Tryingbetween UAC and UAS only
assured
 SIP uses HBH reliability… almost 200 OK
200 OK
 Stateless proxies simply forward requests
200 OK
 200 OK response to INVITE is E2E reliable!!!
 UAC must see all 200 OK
200 OK
200 OK

ACK
200 OK
200 OK
ACK ACK

UAC Proxy UAS

SIP Tutoiral www.dynamicsoft.com

Registrations
 Proxy needs to know where
users are sitting
 SIP REGISTER message allows
clients to tell proxy servers
REGISTER sip:dynamicsoft.com SIP/2.0
 REGISTER properties To: Rosenberg <sip:[email protected]>
 Contains list of current locations in From: Claribel <sip:[email protected]>
Contact headers Call-ID: [email protected]
 Registrar identified in Request CSeq: 123 REGISTER
URI Contact: sip:[email protected]
 Identifies registered user in To Contact: http://www.cs.columbia.edu/~jdrosen
field Expires: 3600
 Identifies person performing
registration in From field (usually
= To)
 Expires header indicates desired
lifetime
 Can be different for each
Contact
 May be body
SIP Tutoiral www.dynamicsoft.com
Registration Responses
 Registrar behavior on
receiving REGISTER
 check if domain is its own
 authorize user in From field SIP/2.0 200 OK
To: Rosenberg <sip:[email protected]>
 Add address bindings of (To
From: Claribel <sip:[email protected]>
field) -> (Contact list) Call-ID: [email protected]
 Lower expiration time if too CSeq: 123 REGISTER
long Contact: sip:[email protected]
Contact: http://www.cs.columbia.edu/~jdrosen
 Return, in response, list of all
Contact: mailto:[email protected]
current registrations ;expires=“Thu, 01 Dec 2002 16:00:00 GMT”
 Return, in response, Expires: 3600
expiration time for all
registrations

SIP Tutoiral www.dynamicsoft.com

Registration Details
 Querying
User Agent
list
must
of current
refreshregistrations
registrations by resending before expiration
 Send REGISTER with no Contact headers
 Each contact must be refreshed independently
 Response
 contains
Can place them listsame
all in of current registrations
REGISTER
 Distributed registrations
 Can use separate REGISTER for each
 Registrations for the same user (I.e., same To field) can come from different
 Deleting Registrations
hosts, each registering different contacts
 Send a refresh with Expires: 0
 Example: my cell phone registers itself, my PC registers itself

SIP Tutoiral www.dynamicsoft.com

Forking
 A proxy may have more than one address for a user
 Happens when more than one SIP URL is registered for a user
 Can happen based on static routing configuration INVITE user2@domain2
 In this case, proxy may fork
 Forking is when proxy sends request to more than one proxy at once
INVITE
 First 200 OK that is received is forwarded upstream
user@domain
 All other unanswered requests cancelled

INVITE user3@domain3

SIP Tutoiral www.dynamicsoft.com

More on Forking
 Many
Main benefits
proxies can fork, resulting in tree of proxies
 Allows rapid “search” for user at many locations
 “Best” response to forked request is chosen and forwarded upstream
 Phone
 rings
First 200 OKmore than one place at a time
received
 Two variations
 First 600 received if no 200 OK
 Lowest
Sequentialnumbered
Search:response
Try first address,
after all responses
only if that are
failsreceived,
try second
given
address
none was
 200 or 600
Parallel Search: Try all addresses at once (as in previous slide)
 Note usually only one response is forwarded upstream
 Hybrid approaches possible

SIP Tutoiral www.dynamicsoft.com

CANCEL
INV
INV
 CANCEL used to “take back”
100 100
a request INV
 Main application: stop
100
phones from ringing which
have not yet answered
200
 Semantics CANCEL
200
 Always refers to another
OK
request
 If you get a CANCEL, and
487
haven’t answered request,
answer request with 487. ACK
ACK
Answer CANCEL with 200.
 Can be generated by proxies or
UA - usually proxies
UAC Proxy UAS UAS

SIP Tutoiral www.dynamicsoft.com

Response Routing: Via
 Via
Responses
header reflected
take samein path
response
as requests
from UAS
 When
How does
proxy
server
receives
knowresponse
where to send response?
 check
Remember
if topmost
whereVia
request
is itselfcame from
 If
Place
yes, information
remove andincheck
request,
nextget
header
it back in response!!
 Send response to address in next Via
 Via Header
 If
 no next
Traces Via,
path ofresponse
request is for me
 “Stack” header
 Each proxy pushes its address in requests
 Pops its address in responses

SIP Tutoiral www.dynamicsoft.com

Via Operation

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

Request
Response

SIP Tutoiral www.dynamicsoft.com

Received Tags
INVITE sip:[email protected] SIP/2.0
 Many cases where address in viaFrom: sip:[email protected];tag=76ah
is wrong!
To: sip:[email protected]
 NAT Via: SIP/2.0/UDP
 Multihomed hosts pc13.dynamicsoft.com;received=12.3.2.1

 Rather, source address of packet is more correct

 Solution: receive tag
 If source address of packet doesn’t equal
 top viaresult
End address
 Proxy inserts received parameter into via header
 Responses sent to source IP
 Indicates source IP address address of request, but to port in
 That address is used to send responses via header
 Strange combination, but it works
well for multihomed hosts

SIP Tutoiral www.dynamicsoft.com

Stateful vs. Stateless Proxies
 A proxy must
Stateless be stateful
Proxy when
Definition

 It forks (thisrequest,
Receives requires special
acccess processing
location of responses
services, to “remember”
forwards best one)
request
 It sends a request using multicast

Forgets it even saw request after forwarding it
 It uses TCP
 When response comes, uses Via header to figure out where to send it
 Stateful vs. Stateless
 Stateful Proxy
 Stateless Definition
scales very well
 Remembers
 No memoryit saw the request after forwarding it
requirements
 Can apply
 Tiny additional
socket logic after response arrives
requirements
 Stateful is better for services
 Each proxy can independently decide which to be

 Call Stateful
 Remembers multiple transactions being associated with a call

SIP Tutoiral www.dynamicsoft.com

Loop Detection
 With all this forking and forwarding, request may hit the same proxy twice!
 Need mechanisms to prevent this from looping forever
 SIP provides two
 Max-Forwards
 Counter decremented by 1 on each hop
 Discard request when zero
 Via based loop prevention and detection
 Every proxy inserts address
 Check for my address when request comes

SIP Tutoiral www.dynamicsoft.com

Loop Detection: Details
 Branch
Spirals ID Component 1
 When a
request
proxy forks,
hits server
each twice,
fork has
butawith
different
different
component
request 1,
URIso response
 associated with forked requestforwards to [email protected]!
Example: [email protected]
 Branch IDerror
 Not an Component 2
 Hash
 Must of To,difference
detect From, Call-ID, Cseq and
between incoming
loop request URI
and spiral
 When you receive a request, check for Via headers with your own address
 Solution
 For those with that address, recompute hash, see if it matches value in branch ID
 Via header contains branch ID parameter
 If match, loop, if not, spiral
 Branch ID has two components

SIP Tutoiral www.dynamicsoft.com

Routing of Subsequent Requests
 Initial SIP request sent through many proxies
 No need per se for subsequent requests to go through proxies
Proxy
 Each proxy can decide whether it wants to receive subsequent
INVITE
requests
 Inserts Record-Route header containing its address
Proxy
 For subsequent requests, users insert Route header
 Contains sequence of proxies (and final user) that should receive request
BYE Proxy
UA1

UA2

SIP Tutoiral www.dynamicsoft.com

Construction of Route Header
 UAC
Each Constructs
proxy may insert
Route a RR
 Flips
Stackorder
property
of Route headers
 Places
Any URLContact
meetingfrom
two200
requirements
OK at bottom
 Result
 Routes
is Route
backset
to that server
 Identifies the target recipient in some way
 UAS Constructs Route
 UAS reflects
 Takes all RR
RR from in 200 OK Response
INVITE
 Adds
Proxies
Contact
can modify
from INVITE
RR theyatinserted
the end
 Allows Route for UAC/UAS to be different, which it should be!

SIP Tutoiral www.dynamicsoft.com

 Example Route Construction

INV sip:b@t3
INV sip:b@t2 m:sip:a@o
INV sip:b@t m:sip:a@o RR:sip:a@o;maddr=C
RR:sip:a@o;maddr=B RR:sip:a@o;maddr=B
m: sip:a@o
Proxy Proxy
UAC Addr: B Addr: C UAS
SIP/2.0 200 OK SIP/2.0 200 OK
SIP/2.0 200 OK Domain: t Domain: t2
Sip:a@o m:sip:b@t3 m:sip:b@t3 m:sip:b@t3 Sip:b@t3
RR:sip:b@t2;maddr=C RR:sip:a@o;maddr=C
RR:sip:b@t2;maddr=C
RR:sip:a@o;maddr=B RR:sip:a@o;maddr=B
RR:sip:b@t;maddr=B

UAC Route: UAS Route:

Sip:b@t;maddr=B, Sip:a@o;maddr=C,
Sip:b@t2;maddr=C Sip:a@o;maddr=B
Sip:b@t3 Sip:a@o

SIP Tutoiral www.dynamicsoft.com

Setting up the Session
 SDP
INVITE
also
contains
conveysthe
other
Session
information
Description
aboutProtocol
session(SDP) in the body
 Time it will take place
 SDP conveys the desired session from the callers perspective
 Who
 originated
Session consiststhe
of session
a number of media streams
 subject
 of thecan
Each stream session
be audio, video, text, application, etc.
 URL for more information
 Also contains information needed about the session
 SDP origins are multicast sessions on the mbone
 codecs
 Originator

addresses of INVITE
and ports is not originator of session

SIP Tutoiral www.dynamicsoft.com

Anatomy of SDP
 SDP contains informational
headers
 version (v) v=0
 origin(o) - unique ID o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
 information (I)
i=Discussion of Mbone Engineering Issues
 Time of the session [email protected]
t=0 0
 Followed by a sequence of m=audio 3456 RTP/AVP 0 78
media streams c=IN IP4 1.2.3.4
a=rtpmap:78 G723
 Each media stream contains an
m=video 4444 RTP/AVP 86
m line defining c=IN IP4 1.2.3.4
 port a=rtpmap:86 H263
 transport
 codecs
 Media Stream also contains c
line
 Address information

SIP Tutoiral www.dynamicsoft.com

Negotiating the Session
 Called party receives SDP offered by caller
 Each stream can be
 accepted
v=0
 rejected o=user2 16255765 8267374637 IN IP4 4.3.2.1
 Accepting involves generating an SDP t=0listing
0 same stream
m=audio 3456 RTP/AVP 0
 port number and address of called party
c=IN IP4 4.3.2.1
 subset of codecs from SDP in request m=video 0 RTP/AVP 86

 Rejecting indicated by setting port toc=IN zeroIP4 4.3.2.1

 Resulting SDP returned in 200 OK
Audio stream accepted, PCMU only.
 Media can now be exchanged
Video stream rejected

SIP Tutoiral www.dynamicsoft.com

Changing Session Parameters INVITE

 Once call is started, session can be modified 200

ACK
 Possible changes
 Add a stream
 Remove a stream
 Change codecs
INVITE
 Change address information
 Call hold is basically a session change 200 reINVITE
ACK
 Accomplished through a re-INVITE
 Same session negotiation as INVITE, except in middle of call
 Rejected re-INVITE - call still active!

C S

SIP Tutoiral www.dynamicsoft.com

Hanging Up INVITE

 How to hang up depends on when and who100

 After call is set up
 either party sends BYE request
Hangup CANCEL 200 OK Accept
 From caller, before call is accepted
 send CANCEL
200 OK
 BYE is bad since it may not reach the same set of users that got INVITE
 If call is accepted after CANCEL, then send BYE ACK

 From callee, before accepted BYE

 Reject with 486 Busy Here

200 OK

C S

SIP Tutoiral www.dynamicsoft.com

Calls, Call Legs and Transactions
 Call is a set of point to point SIP relationships
Call-ID
 Call-ID
local participant
 Call Leg (aka Dialog) is a point to point SIP relationship
 Call-ID + To + from

 Transaction is a request/response
 Call-ID + To + From + CSeq
Remote Remote
participant participant

CSeq CSeq CSeq CSeq

SIP Tutoiral www.dynamicsoft.com

Call Flow for basic call: UA to proxy to UA
INVITE
 Call setup INVITE
 100 trying hop by hop
100 Trying
 180 ringing 100 Trying
 200 OK acceptance 180 Ringing
180 Ringing
 Call parameter modification
 re-INVITE
200 OK
200 OK
 Same as initial INVITE, updated session description
ACK
 Termination RTP
 BYE method
BYE

200 OK

SIP Tutoiral www.dynamicsoft.com

Addressing Scalability
 Internet model for scalability CSF
Proxy
 Fast and simple in core CSF
CSF
Proxy
Proxy
 Smarter towards periphery
SF
 Example: RSVP vs. Diffserv SF
Proxy
Proxy
 SIP uses Internet Model CSF SL CSF
Proxy Proxy Proxy
 Stateless proxies in the core are
SF
fast SF Proxy
 Stateful proxies at periphery Proxy
CSF
CSF
 Call-stateful proxies at edge Proxy
Proxy
CSF
Proxy

CSF Call Stateful

SF Stateful
SL Stateless

SIP Tutoiral www.dynamicsoft.com

Fault Tolerance
 DCS
Server
State
crashes
Header
have little effect
 Under
No calls
development
terminated, even for Call Stateful proxies running TCP
 Much
Transactions
like httpincookies
progress complete if a backup is available (SRV)
 Will allow proxies to ask for data back in subsequent requests
 Protocol State stored in messages
 Allows
 fully call
Responses stateful
always servers
routed back that are highly recoverable!!
 TCP connections may even be re-opened to send responses!
 Branch parameter as a tool of the proxy

SIP Tutoiral www.dynamicsoft.com

Extensibility Model
 Goal: Ensure baseline operation always works that must be
 Features
 Protocol can be extended by understood are given names
 Defining new headers and semantics 
Feature naming
 Defining new parameters and semantics
 IANA registered
 Defining new methods
 com.microsoft.featurefoo naming
 Defining new bodies
 New parameters and headers can be Clients can insist server
 optional
 Safely ignored by recipient understand a feature
 Spec mandates that unknown headersand paramscan
Server are place
ignoreda feature
in a
 Maximizes interoperability
response if client understands
it

SIP Tutoiral www.dynamicsoft.com

Extensibility: Client requests Feature
INVITE
Foo: blah-blah
 Feature represented by new header, parameter and/or new behavior
Bar: la-la
 Client places needed feature in special header in request
Require: foo, bar
 Require: want UAS to understand feature
 Proxy-require: want proxies to understand feature
420 Bad Extension
Unsupported:
 If UAS or proxy doesn’t know feature, it responds foo and lists
with error
unknown features in Unsupported header
 Client can resubmit request
INVITE
Bar: la-la
Require: bar

C S

SIP Tutoiral www.dynamicsoft.com

Extensibility: Server wants feature
 Client indicates features it understands in Supported header in
request
INVITE
 All features must be listed Supported: foo, bar
 Always place header in every request

 Server can use feature if its listed

201 OK
 If server applies feature in response, it includes a Require header
Foo: blah-blah
indicating the feature Require: foo

C S

SIP Tutoiral www.dynamicsoft.com

Extensibility: New Methods
 Methods define fundamental behavior
 Client can send request with new method GOAWAY
To: joe
 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

C S

SIP Tutoiral www.dynamicsoft.com

Extensibility: New Bodies
 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
 Accept header lists valid MIME body types

 Only used by UA! 415 Unsupported Media

Accept: text/plain

C S

SIP Tutoiral www.dynamicsoft.com

Security
 Leverage existing mechanisms
 HTTP
 Basic authentication
 Digest authentication

 PGP
 S/MIME
 Transport Mechanisms

SIP Tutoiral www.dynamicsoft.com

HTTP Basic and Digest
 Credentials
Challenge Response
can be cached
 Subsequent
Client sends requests
request to the same server can contain same credentials
 If
Server
they expire,
respondsserver
withissues
401 or401/407
407 with “challenge”
 Client ACKs
 Two relationships
 Client

Proxy sends
Serverrequest again
challenges (higher Cseq) with credentials
UAC
 If

UASOK,challenges
server processes,
UAC else sends 401/407 again
 Mechanism
 is Stateless
Multiple credentials
 Don’t
 need toofknow
Any number thatand
proxies a challenge
a UAS canwas issued
issue challenge
 Requests
 just
Credentials arecontain credentials
accumulated

SIP Tutoiral www.dynamicsoft.com

HTTP Basic Authentication
INVITE
 Cleartext Password
 Base64 encoded
401 Authorize Yourself
 Not useful alone WWW-Authenticate:
Basic realm=“mufasa”
 May be useful within a TLS connection from client to server
 Emulates http usage of client authentication

 Not widely implemented

INVITE
 Depecated from bis Authorization: Basic
QWxhZGRpbjpvcGVuI==

200 OK

SIP Tutoiral www.dynamicsoft.com

HTTP Digest Authentication
 Why
Server
double
challenge
hashing?
 Server
Realm (keyword
can store for
H(user:realm:pass);
password) doesn’t change
 Computes
Nonce (random
H(method:URI)
number, rotates
combines
periodically)
with first
 No password or username on disk!
 UAC Response
 Response
 Hash of Authorization
username, password, realm and nonce, and also method
 Responses
Can also include
can also
body
contain
in hash
credetials that authenticate caller
 Specifically, its H(H(username:realm:password):nonce:H(method:URI))

SIP Tutoiral www.dynamicsoft.com

PGP
 Requires
RFC2543 specified
request tosecurity
be “canonicalized”
based on PGP
 Standardized format over which signature is computed
 Provided
 Requires
 devices
Client to server to maintain order of headers and parameters
authentication
 Deprecated!
 Client to server encryption
 No
Server
implementations
to client authentication
 Canonicalization
Server to client encryption
a pain
 Other approaches more mature
 Uses public keys
 Requires PGP community
 General problem with PGP

SIP Tutoiral www.dynamicsoft.com

Coming soon: S/MIME
INVITE sip:u@h SIP/2.0
From: sip:bob@foo
 S/MIME is an IETF standard for email security To: sip:a@c
Content-Type: multipart
 Provides authentication and encryption
 Based on X.409 Public Key Certificates
 The kind you get from Verisign SDP
 Some infrastructure in place
 Can be shipped with message INVITE sip:u@h SIP/2.0
From: sip:bob@foo
 Big overhead To: sip:a@c
Content-Type: SDP
 Message contains payload, signed piece, and signature, maybe certificate
SDP text
 Requires multipart

signature

certificate

SIP Tutoiral www.dynamicsoft.com

Transport Security
 Previous mechanisms allow for E2E Security
 Works through any number of proxies
Proxy
 Proxies don’t need to be trusted
 Security within SIP layer

 Hop by Hop Security Possible as well

Proxy
 Proxies have trust relationship with each other
 E2E security by transitivity
 Relies on all hops doing security Proxy
UA1

Secure UA2
Tunnel

SIP Tutoiral www.dynamicsoft.com

Transport Security
 Requires
IPSec no SIP extensions
 UDP also
 Several techniques
 Not
 widely implemented
TLS/SSL
 IKE
 barely supported
IPSec
 Resides in OS
 TLS/SSL
 Firewall and NAT Traversal
 Widely implemented
 Key exchange works
 Resides in application layer
 TCP only

SIP Tutoiral www.dynamicsoft.com

What about QoS?
 QoS is handled orthogonally by  Voice will be negligible
other protocols compared to data anyway
 Signaling path isn’t same as media
path at all!!
 Even set of ISPs is different
 Separation allows yahoo to be a
phone company
 Many other apps need QOS, keep
one mechanism

SIP Tutoiral www.dynamicsoft.com

Models of QoS for SIP
 Diffserv  RSVP/diffserv core w/ ringing
 users mark TOS byte in their RTP holdback
packets  don’t ring unless resources
 olympic service model reserved
 total separation  use RSVP in periphery
 no  resource reservations starts after
 admission control INVITE
 ringing and continued signaling
 end to end signaling
after RSVP done
 per call minute metering

SIP Tutoiral www.dynamicsoft.com

Quality of Service INV

183 Progress
 SIP is “not” a Reservation Protocol, but. . .
PRACK
 Need Coupling Between Signaling and
Reservation
Resource Reservation
 Do not ring phone until resources reserved

 Uses a new extension to SIP

COMET
 INVITE contains a header that indicates there
is a precondition to ringing the phone 200 OK Ringing
 Preconditions include
200 OK
 QoS establishment Pickup
 Security ACK

 When preconditions met, COMET request is

sent Media

 Phone can then ring

Caller Callee

SIP Tutoiral www.dynamicsoft.com

Information Resource
 Jonathan Rosenberg
 [email protected]
 +1 973-952-5000

SIP Tutoiral www.dynamicsoft.com