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:
Self-written C code:
•Open socket
•Open socket
•Wait for UDP packets
•Take voice samples from microphone
•Playback voice samples
•Send voice samples in UDP packets
Bob
Alice

Internet

10.0.0.1
Knows address 192.168.20.2 192.168.20.2
Knows port 5060 Listening on port 5060
Expecting UDP
Knows UDP
Expecting CODEC PCM A-law
Knows 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?

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
(+ RTP on top)
– TCP

• 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

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
The 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 Signaling Media Transport Support
Layer
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 sip:[email protected] SIP/2.0
| INVITE | From: Alice <sip:[email protected]>
|----------------------->| To: Bob <sip:[email protected]>
| 180 Ringing | m=audio 49172 RTP/AVP 0
|<-----------------------| a=rtpmap:0 PCMU/8000
| |
| 200 OK |
|<-----------------------| SIP/2.0 200 OK
| ACK | m=audio 3456 RTP/AVP 0
|----------------------->| a=rtpmap:0 PCMU/8000
| Both Way RTP Media |
|<======================>|
| |
| BYE |
|<-----------------------|
| 200 OK |
|----------------------->|
| |
Anna Sfairopoulou Page 21
 Message syntax (I)
Request Line
Message
or Payload
Headers
Status Line

• SIP is request / response

• Every request carries a method indicating
the request type
INVITE sip:[email protected] 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:[email protected]>

• 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:[email protected]
• sip:[email protected]
• 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 Bad Request
– 401 Unauthorized
– 407 Proxy authentication required
– 486 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 sip:[email protected] SIP/2.0
| INVITE | From: Alice <sip:[email protected]>
|----------------------->| To: Bob <sip:[email protected]>
| 180 Ringing | m=audio 49172 RTP/AVP 0
|<-----------------------| a=rtpmap:0 PCMU/8000
| |
| 200 OK |
|<-----------------------| SIP/2.0 200 OK
| ACK | m=audio 3456 RTP/AVP 0
|----------------------->| a=rtpmap:0 PCMU/8000
| Both Way RTP Media |
|<======================>|
| |
| BYE |
|<-----------------------|
| 200 OK |
|----------------------->|
| |
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...

 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:[email protected]
sip:[email protected], 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
[email protected]
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