Sip Tutorialv2

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

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

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

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

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 Addressing
 SIP addresses are URL’s
 URL contains several components
 Scheme (sip)
 Username
 Optional password
 Hostname
 Optional port
 Parameters
 Headers and Body
sip:jdrosen@dynamicsoft.com:5061;
 SIP allows any URI type
user=host?Subject=foo
 tel URIs
 http URLs for redirects
 mailto URLs
 leverage vast URI infrastructure

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:jdrosen@dynamicsoft.com to
sip:jdrosen@eagle.dynamicsoft.com

Proxies
 Requests can traverse
multiple proxies from
caller to callee LS
 Each proxy:
 receives request
 checks if domain in request sip:joe@a.com sip:j_user@eng.a.com
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

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

Local Outbound Proxies
 Can send a request to a
proxy without performing
DNS procedure INVITE joe@b.edu
 Result is that proxy receives

a request whose domain is
not its own
 Proxy then performs DNS
process just described to
forward request INVITE joe@b.edu
 May also provide additional

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

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 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 Message Syntax
 Many header fields from INVITE sip:ann@lucent.com SIP/2.0
http From: J. Rosenberg <sip:jdrosen@dynamicsoft.com>
Subject: SIP will be discussed, too
 Payload contains a media
To: A. Netravali <sip:ann@lucent.com>
description Via: SIP/2.0/UDP pc13.dynamicsoft.com
 SDP - Session Call-ID: 1997234505.56.78@122.3.44.12
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
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0

SIP Address Fields
INVITE sip:ann@lucent.com SIP/2.0
 Request-URI From: J. Rosenberg
 Contains address of next <sip:jdrosen@dynamicsoft.com>;tag=76ah
hop server Subject: SIP will be discussed, too
 Rewritten by proxies To: A. Netravali <sip:ann@lucent.com>
based on result of Via: SIP/2.0/UDP pc13.dynamicsoft.com
Location Service Call-ID: 1997234505.56.78@122.3.44.12
 To Content-type: application/sdp
Contact: sip:jdrosen@pc13.dynamicsoft.com
 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
 Optional display name
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0

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

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

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)

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

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

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

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

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:jdrosen@dynamicsoft.com>
 Contains list of current locations in From: Claribel <sip:cpena@dynamicsoft.com>
Contact headers Call-ID: 1997234505.56.78@122.3.44.12
 Registrar identified in Request CSeq: 123 REGISTER
URI Contact: sip:jdrosen@pc33.dynamicsoft.com
 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
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:jdrosen@dynamicsoft.com>
 Add address bindings of (To
From: Claribel <sip:cpena@dynamicsoft.com>
field) -> (Contact list) Call-ID: 1997234505.56.78@122.3.44.12
 Lower expiration time if too CSeq: 123 REGISTER
long Contact: sip:jdrosen@pc33.dynamicsoft.com
Contact: http://www.cs.columbia.edu/~jdrosen
 Return, in response, list of all
Contact: mailto:jdrosen@dynamicsoft.com
current registrations ;expires=“Thu, 01 Dec 2002 16:00:00 GMT”
 Return, in response, Expires: 3600
expiration time for all
registrations

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

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

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

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

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

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

Received Tags
INVITE sip:ann@lucent.com SIP/2.0
 Many cases where address in viaFrom: sip:jdrosen@dynamicsoft.com;tag=76ah
is wrong!
To: sip:ann@lucent.com
 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

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

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

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 bob@example.com!
Example: joe@example.com
 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

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

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!

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

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

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)
 Time of the session e=mbone@somewhere.com
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

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

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

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

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

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

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

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

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

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

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

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

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

Security
 Leverage existing mechanisms
 HTTP
 Basic authentication
 Digest authentication
 PGP
 S/MIME
 Transport Mechanisms

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

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

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

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

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

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

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

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

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

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

Information Resource
 Jonathan Rosenberg
 jdrosen@dynamicsoft.com
 +1 973-952-5000

Sip Tutorialv2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sip Tutorialv2

Uploaded by

Copyright:

Available Formats

SIP Tutoiral www.dynamicsoft.

SIP Tutoiral www.dynamicsoft.com

 Developed in mmusic group in IETF  Main Features

SIP Tutoiral www.dynamicsoft.com

 Messages contain bodies

SIP Tutoiral www.dynamicsoft.com

 All signaling composed of independent transactions

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

 SIP does not dictate how routing

 End result is a mapping from one

SIP Tutoiral www.dynamicsoft.com

 Domain matches 200 OK 200 OK

SIP Tutoiral www.dynamicsoft.com

 Take domain name of request

SIP Tutoiral www.dynamicsoft.com

 Result is that proxy receives

 May also provide additional

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

 However, 2xx final responses still retransmitted

SIP Tutoiral www.dynamicsoft.com

UAC Proxy UAS

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

 Rather, source address of packet is more correct

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

UAC Route: UAS Route:

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

 Rejecting indicated by setting port toc=IN zeroIP4 4.3.2.1

SIP Tutoiral www.dynamicsoft.com

 Once call is started, session can be modified 200

SIP Tutoiral www.dynamicsoft.com

 How to hang up depends on when and who100

 From callee, before accepted BYE

 Reject with 486 Busy Here

SIP Tutoiral www.dynamicsoft.com

CSeq CSeq CSeq CSeq

SIP Tutoiral www.dynamicsoft.com

SIP Tutoiral www.dynamicsoft.com

CSF Call Stateful