SIP
Anna Sfairopoulou
Page 1
What we will see...
•
•
•
•
•
Signalling vs Media
SIP standarization and design principles
Message syntax
SIP addressing
SIP methods
– Request messages
– Response messages
• SIP entities (servers)
• Examples
Anna Sfairopoulou
Page 2
Why SIP
• SIP  VoIP + WLAN  competition to cellular
telephony?
• IMS component
• P2PSIP
• Application layer mobility using SIP
Anna Sfairopoulou
Page 3
The simplest voice call
Self-written Java code:
•Open socket
•Wait for UDP packets
•Playback voice samples
Self-written C code:
•Open socket
•Take voice samples from microphone
•Send voice samples in UDP packets
Bob
Alice
Internet
10.0.0.1
Knows
Knows
Knows
Knows
192.168.20.2
Listening on port 5060
Expecting UDP
Expecting CODEC PCM A-law
address 192.168.20.2
port 5060
UDP
CODEC PCM A-law
Anna Sfairopoulou
Page 4
What if...
•
•
•
•
•
•
Alice doesn't know Bob's IP address?
Alice uses a different codec?
Bob is busy in a previous call?
Bob is absent?
Other media desired (e.g. Video)?
Cesar would like to join in?
a Some form of call control (a.k.a. SIGNALING) is needed!
Anna Sfairopoulou
Page 5
Think about the road system...
Anna Sfairopoulou
Page 6
Media vs Signaling
• To interchange user data, transport protocols are
used
– UDP
– TCP
(+ RTP on top)
• To control that interchange, signaling protocols are
used
– RSVP
– SIP
– RTSP
Anna Sfairopoulou
Page 7
Signaling serves to...
•
•
•
•
•
•
•
Set up and tear down VoIP calls/sessions
Reserve bandwidth among routers
Establish secure connections over the Internet
Interchange routing information
Inform of network malfunctions
Configure network equipment remotely
Etc.
Anna Sfairopoulou
Page 8
The ATM cube revisited
Pl
an
es
Management
Control
er
g
en
s
s
Me
Use
r
Application
Presentation
Layers
p
O
HP
ew
i
enV
Session
Transport
Network
Data Link Layer
P
M
SN
P
P
D
I
U
S
P
D
P
U
/
T
IP t
P
R
C
e
T
n
r
P
e
I P E th
UD
t
e
n
er
IP
h
t
E
t
e
rn
e
h
Et
Physical
Anna Sfairopoulou
Page 9
Layers vs Planes
• Layering: Structures how data transport is done in
a network
• Planes: Define what purpose a data transfer
serves:
– User plane: Transfer of user info
– Control plane: Control the transfer of user info
– Management plane: Check and update status of network
elements (routers, servers, etc.)
Anna Sfairopoulou
Page 10
The purpose of signaling
• Interchange of control information for the
management of traffic aggregates and of the
network as a whole
• Signaling protocols represent a parallel network for
the purpose of network and traffic control
aThe complexity and the intelligence of the network
lies mainly here!
Anna Sfairopoulou
Page 11
The real “simplest” voice call
Anna Sfairopoulou
Page 12
The real “simplest” voice call
Database (MySQL)
DNS (Named)
SIP Express
Server (SER)
Twinkle
Anna Sfairopoulou
Page 13
Signalling
• Signalling serves to control user data transfer
across the network
– Data transfer is easy, signaling is hard!
• SIP is a session-layer signaling protocol
• RTP is a session-layer data transfer protocol
• UDP is the transport protocol mostly used to
transport both
Anna Sfairopoulou
Page 14
SIP standardization
• First designed by Henning Schulzrinne and Mark
Handley starting in 1996
• Standardized in IETF RFC 3261
– See also RFC 3551, 2327, 3219, 3761, 3525, 3398 ...
• Decentralized design
– The intelligence lies on the nodes
• Ongoing process
– Extensions
– Services
Anna Sfairopoulou
Page 15
SIP design principles (I)
• Modelled after HTTP
– Text-based
• Based on transactions
– Request / response
• Simple
– Less than 10 methods / packet types
• Only for call control
– No QoS, no media transfer, no application-specific
functions
Anna Sfairopoulou
Page 16
SIP design principles (II)
• Session-oriented
– Can manage any session-based service
•
•
•
•
•
Online gaming
Videoconferencing
Virtual reality
Chat
Etc
Anna Sfairopoulou
Page 17
The SIP-related protocol “Zoo”
• Loosely coupled to other Internet protocols
– SDP, DNS, SMTP, HTTP, RSVP, ...
• Defines complementary protocols to enable special
services
– TRIP, ENUM, SPIRITS, PINT, ...
• Any VoIP network needs a combination of
protocols to work
Anna Sfairopoulou
Page 18
VoIP protocol stack
Presentation
Layer
Signaling
Media Transport
Support
MPEG, H.261, etc.
Session
SIP
RTP
RTCP, TRIP, etc.
Transport
TCP / UDP / SCTP?
UDP
TCP / UDP?
Network
IP
Datalink
Fast/GigEth, ATM, 802.11 MAC/LLC, etc.
Physical
DSL, Phy GigEth,802.11 PHY etc.
Anna Sfairopoulou
Page 19
SIP fundamentals
• Which messages do we need to control a
VoIP call?
– Let's try to find out...
Anna Sfairopoulou
Page 20
A basic SIP call
Alice
Bob
|
|
|
INVITE
|
|----------------------->|
|
180 Ringing
|
|<-----------------------|
|
|
|
200 OK
|
|<-----------------------|
|
ACK
|
|----------------------->|
|
Both Way RTP Media
|
|<======================>|
|
|
|
BYE
|
|<-----------------------|
|
200 OK
|
|----------------------->|
|
|
INVITE sip:bob@biloxi.com SIP/2.0
From: Alice <sip:alice@atlanta.com>
To: Bob <sip:bob@biloxi.com>
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
SIP/2.0 200 OK
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Anna Sfairopoulou
Page 21
Message syntax (I)
Request Line
or
Status Line
Message
Headers
Payload
• SIP is request / response
• Every request carries a method indicating the
request type
INVITE sip:bob@biloxi.com SIP/2.0
• Every response carries a status code explaining
the answer
SIP/2.0 200 OK
Anna Sfairopoulou
Page 22
Message syntax (II)
• Both carry message headers with the parameters
– Variable depending on method / context
– Additional information about the message
– Ex: From: Alice <sip:alice@atlanta.com>
• Payload transports additional info (normally using
SDP)
– No user data!
– description of audio / video capabilities
– Ex: m=audio 3456 RTP/AVP 0
Anna Sfairopoulou
Page 23
SIP addressing
• SIP URL (Uniform Resource Locator)
–
–
–
–
Specify the location of a resource (user)
Email-like addresses
sip:User@Domain
But it is not an e-mail address!
• sip:alice@atlanta.com
• sip:33445566@google.com
• Non sip URLs can be also found in SIP messages
– mailto, tel. im …
Anna Sfairopoulou
Page 24
Original SIP methods (I)
• Six methods defined initially in the standard
– INVITE
– ACK
– BYE
– CANCEL
– OPTIONS
– REGISTER
Anna Sfairopoulou
Page 25
Original SIP methods (II)
• INVITE initiates sessions
– session description included in message body
– re-INVITEs used to change session state
• ACK confirms session establishment
– can only be used with INVITE
• BYE terminates sessions
Anna Sfairopoulou
Page 26
Original SIP methods (III)
• CANCEL cancels a pending INVITE
• OPTIONS capability inquiry
• REGISTER binds a permanent address to current
location
– may convey user data (CPL scripts)
Anna Sfairopoulou
Page 27
SIP methods extensions
•
•
•
•
•
•
•
INFO mid-call signaling
COMET preconditions met
PRACK provisional reliable responses ACK
SUBSCRIBE/NOTIFY/MESSAGE instant messaging
REFER call re-direction
UPDATE update call state
PUBLISH user info
Anna Sfairopoulou
Page 28
SIP responses (I)
• Borrowed from HTTP:
 xyz code + explanatory text
• Receivers need to understand x
• 1yz Informational
– 100 Trying
– 180 Ringing
– 183 Session in progress
• 2yz Success
– 200 ok
Anna Sfairopoulou
Page 29
SIP responses (II)
• 3yz Redirection
– 300 Multiple choices
– 302 Moved temporarily
– 305 Use proxy
• 4yz Request failure
–
–
–
–
400
401
407
486
Bad Request
Unauthorized
Proxy authentication required
Busy Here
Anna Sfairopoulou
Page 30
SIP responses (III)
• 5yz Server failure
– 500 Server internal error
– 501 Not implemented
– 503 Service unavailable
• 6yz Global failure
– 600 Busy everywhere
– 606 Not acceptable
Anna Sfairopoulou
Page 31
A basic SIP call (again)
Alice
Bob
|
|
|
INVITE
|
|----------------------->|
|
180 Ringing
|
|<-----------------------|
|
|
|
200 OK
|
|<-----------------------|
|
ACK
|
|----------------------->|
|
Both Way RTP Media
|
|<======================>|
|
|
|
BYE
|
|<-----------------------|
|
200 OK
|
|----------------------->|
|
|
INVITE sip:bob@biloxi.com SIP/2.0
From: Alice <sip:alice@atlanta.com>
To: Bob <sip:bob@biloxi.com>
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
SIP/2.0 200 OK
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Anna Sfairopoulou
Page 32
SIP message headers
• Huge number of different headers
– See RFC 3261
– Nomenclature: SIP header = Other protocol's header
field
• Headers parameterize the request or response
• A SIP entity ignores headers it does not
understand
– Simplifies interworking
Anna Sfairopoulou
Page 33
Header types
• General headers
– Basic info to process the transaction
– E.g. “To”, “From” and “Call-ID” headers
• Request headers
– Additional info about request or sender
– E.g. The “Subject” header
• Response headers
– Additional info about response or receiver
– E.g. “Unsupported” and “Retry-After” header
• Entity headers
Anna Sfairopoulou
Page 34
A complete SIP message
Anna Sfairopoulou
Page 35
Example: Invite message
Starting Line
Headers
Separator
Message Body
Anna Sfairopoulou
Page 36
SIP entities: UAC & UAS
• User Agent Client (UAC)
– Places calls
– Sends requests
• User Agent Server (UAS)
– Waits for incoming calls
– Sends responses
• A SIP terminal is a UAC + UAS
– Beware of this special client/server terminology!
Anna Sfairopoulou
Page 37
SIP network entities
• Servers (UAS)
– Proxy server
– redirect server
– registrar
• Can be combined in a single device
 p.e. SER!!!
• They deal only with signaling
• Media is transported end-to-end
– There are exceptions...
a Signaling controls media interchange: It is not necessary to
touch the media streams directly!
Anna Sfairopoulou
Page 38
SIP entities: Registrar
• Users register their contact info
– Keeps the info at a Location Server
• (Which is simply a database)
– SIP address, but also other addresses, with a type
indication:
sip:anna.sfairopoulou@upf.edu
sip:935422942@upf.edu, user = phone
– Enables personal and terminal mobility and user
behaviour patterns
Anna Sfairopoulou
Page 39
Registration example
Anna Sfairopoulou
Page 40
Registration example
• Contact could also be a specific location
e.x. pc1.grup2.labtel2.upf.edu
• Un-Register
– Send the same message but with
EXPIRE = 0
Anna Sfairopoulou
Page 41
SIP entities: Proxy server
• Proxy Server
– Acts on behalf of UAC
• Processing the request
• Responding to requests
• Forwarding requests
– Can impersonate the client
– Acts both as client and server
– Forking proxies
• Forwards an INVITE to several destinations in parallel
Anna Sfairopoulou
Page 42
Proxy example
Anna Sfairopoulou
Page 43
Stateless vs Stateful proxy
• In general
– Stateless: get a request, forward it, forget about it
– Stateful: remembers previous responses/requests of a
particular transaction
act more intelligently on subsequent requests!
• Record-Route: force future messages to pass from
this proxy
Anna Sfairopoulou
Page 44
SIP entites: Redirect server
• Maps destination SIP addresses to
“reachable” addresses
– SIP address, e-mail, telephone number, etc.
– Depending on user preferences
• Informs the client about them
– No message forwarding!
Anna Sfairopoulou
Page 45
Redirection example
Anna Sfairopoulou
Page 46
Additional examples
(taken from RFC 3665 and Collins)
Anna Sfairopoulou
Page 47
Session establishment through
two proxies
In this scenario, Alice completes a call to Bob using two proxies Proxy 1 and Proxy
2.
The initial INVITE (F1) contains a pre-loaded Route header with the address of
Proxy 1 (Proxy 1 is configured as a default outbound proxy for Alice). The
request does not contain the Authorization credentials Proxy 1 requires, so a
407 Proxy Authorization response is sent containing the challenge information.
A new INVITE (F4) is then sent containing the correct credentials and the call
proceeds.
The call terminates when Bob disconnects by initiating a BYE message.
Proxy 1 inserts a Record-Route header into the INVITE message to ensure that it is
present in all subsequent message exchanges. Proxy 2 also inserts itself into
the Record-Route header.
The ACK (F15) and BYE (F18) both have a Route header.
Anna Sfairopoulou
Page 48
Anna Sfairopoulou
Page 49
Unsuccessful temporarily
unavailable
In this scenario, Bob initially sends a 180 Ringing response to
Alice, indicating that alerting is taking place.
However, then a 480 Unavailable is then sent to Alice.
This response is acknowledged and then proxied back to
Alice.
Anna Sfairopoulou
Page 50
Alice
Proxy 1
Proxy 2
Bob
|
|
|
|
|
INVITE F1
|
|
|
|--------------->|
INVITE F2
|
|
| 100 Trying F3|--------------->|
INVITE F4
|
|<---------------|
100 F5
|--------------->|
|
|<---------------|
180 F6
|
|
|
180 F7
|<---------------|
| 180 Ringing F8|<---------------|
|
|<---------------|
|
480 F9
|
|
|
|<---------------|
|
|
|
ACK F10
|
|
|
480 F11
|--------------->|
|
|<---------------|
|
|
|
ACK F12
|
|
|480 Temporarily |--------------->|
|
| Unavailable F13|
|
|
|<---------------|
|
|
|
ACK F14
|
|
|
|--------------->|
|
|
|
|
|
|
Anna Sfairopoulou
Page 51
Forking proxy
• Used if a particular user is registered at several
locations
• Stateful!
– Proxy remembers that it has two sessions pending and it
cancels the one the moment the other responds
• The “branch” parameter in the “via” header allows
to distinguish among forked requests (and
responses)
Anna Sfairopoulou
Page 52
Anna Sfairopoulou
Page 53
SDP
• Session Description Protocol
– Which is not a protocol...
– ...but a description language for media flows
• Convey sufficient information to participate in a
multimedia session
• Independent of SIP
– But they work nicely together
Anna Sfairopoulou
Page 54
SDP message info
• SDP includes description of:
– Media to use
• Codec
• Sampling rate
– Media destination
• IP address and port number
– Session name and purpose
– Times the session is active
– Contact information
Anna Sfairopoulou
Page 55
SDP message example
v=0
o=alice 28908044538 289080890 IN IP4 193.175.132.118
s=Wedding Proposal
e=alice@atlanta.com
c=IN IP4 126.16.69.4
t=28908044900 28908045000
m=audio 49170 RTP/AVP 15 98
a=rtpmap:15 G728/8000
a=rtpmap:98 L16/11025/2
m=audio 4666 RTP/AVP 4
a=rtpmap:4 G723/8000
Anna Sfairopoulou
Page 56
SDP capability negotiation
• Caller offers set of possible media
• Callee accepts or rejects every one of them
– If several chosen, re-invite
• If none acceptable, warning sent back and re-invite
• Alternative: Use the OPTIONS method
– Query the callee's capabilities prior to INVITE
Anna Sfairopoulou
Page 57
SDP examples
1. Successful capability selection with SDP
2. Re-invite after capability exchange with SDP
3. Capability query with OPTIONS
(Taken from Collins)
Anna Sfairopoulou
Page 58
Example 1:
Successful
capability
selection
Anna Sfairopoulou
Page 59
Example 2:
Re-Invite after
capability
exchange
Anna Sfairopoulou
Page 60
Example 3:
capability
query with
OPTIONS
Anna Sfairopoulou
Page 61
For next class
Find an article on any of the following topics:
- SIP + WLANs
- Mobile P2PSIP
- Application layer mobility using SIP
Small presentation (5-10 slides) each during seminar
Short report (max. 2 pages) on paper send by Friday,
29 January
Anna Sfairopoulou
Page 62