SIP demystified

A bit of history
• The internet multimedia conferencing architecture still had
a missing piece: it did not have a way to explicitly invite
users to join a particular session.
• A multicast session could be announced but it was up to the
potential receiver to check through all of the announced
sessions periodically to find one he wanted to join.
• Inviting users to sessions was the original purpose of SIP.
The protocol has evolved steadily and SIP is currently used
to invite users to all types of sessions, including multicast
and point-to-point sessions.
 SIP functionality
• Establishment.
• Modification.
• Termination.

 Could invite users to an ongoing session or to a session that

is yet to be established.
 Supports negotiation to the parameters of the new session.
 Compatible with session description protocol to announce
the parameters of the session.
 SIP addressing
• Users in a SIP environment are identified by SIP Uniform
Resource Locators (URLs).
• SIP:Bob.Johnson@company.com.

 Registrations:
• A user may register on the proxy server using his current
location like : SIP:Bob.Johnson@131.160.1.112.com.
 SIP Entities
• User agents.
• Redirect Servers: Location server
– Group addresses
• Proxy Servers
– Forking proxies I am "Bob Johnson."
Today I will be reachable at:
– Group addresses sip: Bob@131.160.1.112
I am "Bob Johnson."
• Registrars Today I will be reachable at:
sip: Bob@131.160.1.112

• Location servers
Bob’s computer SIP server
(user agent) (registrar and proxy)
at company.com
 SIP features
• Interoperability.
• Future-proof.
• Separation between establishment and description of
session.
• Intelligence in end systems.
• Scalability.
• Service creation.
– Combined services and unified communication.
– Sane infrastructure for providing new services.
• Messages are human readable. As it is text based not
binary based.
 Client/Server Transactions

• SIP is based on the Web protocol Hypertext Transfer

Protocol (HTTP) and like HTTP, SIP is a request/response
protocol.

• A client is a SIP entity that generates requests. A server is a

SIP entity that receives requests and returns responses.

• A SIP request, together with the responses it triggers, is

referred to as a SIP transaction.
 SIP Responses
• Every response has a code that indicates the status of the
transaction.
• integers ranging from 100 to 699 and are grouped into
classes.
- 100—199 Informational
- 200—299 Success
- 300—399 Redirection
- 400—499 Client error
- 500—599 Server error
- 600—699 Global failure

• A response with a status code from 100 to 199 is

considered provisional. Responses from 200 to 699 are final
responses.
 SIP Requests
• The core SIP defines 6 methods:
 INVITE
 ACK
 OPTIONS
 BYE
 CANCEL
 REGISTER
 INVITE method
• Invites the user to a certain session.
• Body contains the description of the session in SDP format.
v=0
o=Bob 2890844526 2890842807 IN IP4 131.160.1.112
s=I want to know how you are doing
c=IN IP4 131.160.1.112
t=0 0
m=audio 49170 RTP/AVP 0

• The response contains the port number and the other info
reported by the accepting party.
v=0
o=Laura 2891234526 2812342807 IN IP4 138.85.27.10
s=I want to know how you are doing
c=IN IP4 138.85.27.10
t=0 0
m=audio 20000 RTP/AVP 0
 INVITE method

Bob Laura

INVITE

180 RINGING

200 OK
 ACK method
• Declares the reception of a final response.
• Providing a three way handshake.
• To avoid a retransmission of the requests.

Bob Laura

INVITE
INVITE
INVITE
INVITE

200 OK
 ACK method

Bob Laura

INVITE

180 RINGING

200 OK

Ack

Conversation
 CANCEL method
• Cancel pending transactions.
• the CANCEL request will have no effect on the transaction
after the final response.
Bob Laura

INVITE
180 RINGING

CANCEL
200 OK

487 TRANSACTION CANCELED

ACK
 CANCEL method
Bob
Laura Forking proxy Company.com 131.160.1.112 university.com
INVITE
INVITE
INVITE
INVITE

200 OK
200 OK
ACK

Conversation
CANCEL
200 OK
487 CANCELED
ACK

CANCEL
200 OK

487 CANCELED

ACK
 BYE and REGISTER methods
• BYE requests are used to abandon sessions.
• REGISTER requests to inform a server (in this case,
referred to as a registrar) about their current location.

Bob Laura

INVITE
Bob
REGISTRAR 180 RINGING
REGISTER
200 OK
200 OK
ACK

Conversation

BYE
200 OK
 OPTIONS method

• OPTIONS requests query a server about its capabilities

including which methods and which session description
protocols it supports.

Bob SIP SERVER

OPTIONS

200 OK
 SIP request format
• Request line.
– Method.
– Request-URI (next hop).
– Protocol version.
• Several headers.
• Empty line.
• Message body.

– INVITE sip:Bob.Johnson@company.com SIP/2.0

 SIP Response Format
• Status line (SIP/2.0 180 Ringing)
– Protocol version.
– Status code.
– Reason phrase.
• Several headers.
• Empty line.
• Message body.
 SIP headers
• Headers provide information about the request (or
response) and about the body it contains.
• The header consists of the header name, followed by a
colon, followed by the header value.
– From: Bob Johnson sip:Bob.Johnson@company.com Laura
INVITE
Bob Call-ID: 1234@131.160.1.112
 Call-ID: 200 OK
Call-ID: 1234@131.160.1.112
ACK
Call-ID: 1234@131.160.1.112

INVITE
Call-ID: 5678@131.160.1.112
200 OK
Call-ID: 5678@131.160.1.112
ACK
Call-ID: 5678@131.160.1.112
Conversation
BYE
Call-ID: 5678@131.160.1.112
200 OK
Call-ID: 5678@131.160.1.112
 SIP headers
• Contact
– provides a URL where the user can be reached directly.

SIP proxy Bob

INVITE
LAURA SIP: Bob.Johnson@company.com SIP/2.0 INVITE
SIP: Bob@131.160.1.112.com SIP/2.0

200 OK
200 OK Contact: SIP: Bob@131.160.1.112
Contact: SIP: Bob@131.160.1.112

ACK
SIP: Bob@131.160.1.112 SIP/2.0

Conversation
BYE
SIP: Bob@131.160.1.112 SIP/2.0
200 OK
 SIP headers
Laura
INVITE
• Cseq (Cseq: 1 INVITE) Bob Cseq: 1 INVITE
200 OK
Cseq: 1 INVITE
ACK
Cseq: 1 ACK

INVITE
Cseq: 2 INVITE
200 OK
Cseq: 2 INVITE
ACK
Cseq: 2 ACK
Conversation
BYE
Cseq: 3 BYE
200 OK
Cseq: 3 BYE
• From:
– contains the initiator of the request and a SIP URL
 From: Bob Johnson <sip:Bob.Johnson@company.com>
 SIP headers
• TO
– Always contains the recipient of the request.
– Does not change through a session.
• Via
– Store all the proxies that handle the request.
– Used for detecting routing loops.
SIP proxy Bob
INVITE SIP: Bob.Johnson@company.com SIP/2.0
LAURA Via: SIP/2.0/UDP workstation1000.university.com: 5060 INVITE SIP:Bob@131.160.1.112 SIP/2.0
Via: SIP/2.0/UDP workstation1000.university.com: 5060
Via: SIP/2.0/UDP 131.160.1.100: 5060

200 OK
200 OK Via: SIP/2.0/UDP 131.160.1.100: 5060
Via: SIP/2.0/UDP workstation1000.university.com: 5060 Via: SIP/2.0/UDP workstation1000.university.com: 5060

ACK
Via: SIP/2.0/UDP workstation1000.university.com: 5060

Conversation
BYE
Via: SIP/2.0/UDP workstation1000.university.com: 5060
200 OK
Via: SIP/2.0/UDP workstation1000.university.com: 5060
 Record-Route and Route
• These two headers are used by proxies that want to be
in the signaling path for the entire session.
SIP proxy Bob
INVITE SIP: Bob.Johnson@company.com SIP/2.0
LAURA INVITE SIP:Bob@131.160.1.112 SIP/2.0
Record-Route:<SIP:Bob.Johnson@company.com;
maddr=131.160.1.112
200 OK
200 OK Contact: <SIP:Bob@131.160.1.112>
Contact:<SIP:Bob@131.160.1.112> Record-Route:<SIP:Bob.Johnson@company.com;
Record–Route:<SIP:Bob.Johnson@company.com; maddr=131.160.1.112
maddr=123.160.1.110
ACK
Route:<SIP:Bob@131.160.1.112> ACK
SIP:Bob@131.160.1.112 SIP/2.0

Conversation
BYE SIP: Bob.Johnson@company.com SIP/2.0
Route:<SIP: Bob@131.160.1.112
BYE SIP: Bob.Johnson@company.com SIP/2.0

200 OK
200 OK
 Extending SIP
• Some implementations need functionality beyond the
core protocol, which means that SIP needs to be
enhanced somehow.
 Extension negotiation:
• Negotiation process is needed in order to determine the
extensions that will be used within any given session.
• The process of negotiating is conducted using two
headers: Require and Supported

Bob INVITE Laura

Require: foo1
Supported: foo2, foo3, foo4
200 OK
Require: foo1, foo2
Supported: foo4, foo5
ACK
 Mid-session Transactions That Do
Not
Change the State of the Session
• The core SIP specification provides a mean to change
the parameters of the sessions through re-INVITEs.
• Parties involved in a session may need to exchange
information that does not influence the state of the
session in any way
• A new SIP method called INFO was defined.
INVITE
Bob 200 OK Laura
ACK

INFO

200 OK

INFO

200 OK

BYE

200 OK
 Instant Messages
• If a message is need to be sent during a session.
• A new method (MESSAGE) was modified.

Bob Laura
INVITE

200 OK
ACK

MESSAGE

200 OK
 Preconditions to Be Fulfilled Before
Alerting
• For sessions needing special requirements, the way of
establishing a session immediately doesn’t work
properly.
• for sessions requiring a certain QoS a way was to be
done to guarantee the required QoS.
• A new method called preCOnditions
Bob MET (COMET) wasLaura
INVITE
defined.
QoS preconditions
183 session progress
PRACK
200 OK

QoS reservations
Bob performs

LAURA performs
QoS reservations
COMET
200 OK

180 ringing
 Call preferences

Bob's Bob's
mobile fixed
Laura
Proxy terminal terminal
(1) REGISTER
Contact: Bob@131.160.1.112;
mobility="fixed";
class="business"
200 OK

(3) REGISTER
Contact: Bob.Johnson@mobile.com;
mobility="mobile";
class="personal"
200 OK

(5) INVITE
Accept-Contact: *;mobility="fixed"
Reject-Contact: *;mobility="mobile"
Request-Disposition: no-fork
(6) INVITE
Accept-Contact: *;mobility="fixed"
Reject-Contact: *;mobility="mobile"
Request-Disposition: no-fork
Asynchronous Notification of
Events

Bob Laura
INVITE

484 busy here

ACK

SUBSCRIBE: Laura’s status

200 OK

Notify: Laura busy

ACK

Notify: Laura Available

ACK

INVITE
 Session transfer
Bob’s
INVITE secretary
Laura
200 OK Bob
ACK

Conversation
INVITE(hold)
200 OK
ACK
REFER
Refer-To: SIP: Bob.Johnson@company.com
Referred-By: SIP: Secretary@company.com

ACCEPTED

INVITE
Referred-By: SIP: Secretary@company.com
200 OK
ACK

NOTIFY

200 OK
BYE

200 OK

Conversation
 Third party call control
Bob
Bob’s Computer
Conference unit

INVITE
NO SDP

200 OK
SDP computer

INVITE
SDP computer

200 OK
SDP conference unit

ACK
SDP conference
unit
ACK
No SDP
 Types of proxies
• Call stateful proxy:
– Call stateful proxies need to be informed of all the SIP transactions
that occur during the session.
– These proxies store state information from the moment the
session is established until the moment it ends.
– Useful in call charging.
• Stateful Proxy:
– sometimes called transaction stateful proxies because the
transaction is their sole concern.
– Forking proxies are good examples of stateful proxies.
• Stateless Proxy:
– Stateless proxies don’t keep any state. They receive a request,
forward it to the next hop, and immediately delete all state related
to that request.
 Call Stateful proxies

Bob
Bob’s Computer
Conference unit

INVITE
INVITE

200 OK
200 OK

ACK
ACK

Conversation

BYE
BYE
200 OK
200 OK
E-mail

E-mail:Your last call

lasted five minutes
and twenty seconds
Distribution of Proxies

Call Stateful proxies

Stateful proxies

Core
Stateless proxies
 B2BUA

• A B2BUA is a logical entity acts as a user agent to both

ends of a SIP call. They remain in the path of the call
from establishment till termination.

• Used to implement prepaid services and charging.

 IMS
• The 3GPP divided the UMTS architecture into Access
network (AN) and Core Network (CN). The Core Network
can be further split into:
– The Circuit-Switched (CS) Domain.
– The Packet-Switched (PS) Domain.
– The Internet Multimedia Subsystem (IMS).

CS-
• It relies on the IP connectivity Domain IMS
provided by the PS domain.
• The IMS is based on the SIP
protocol and architecture. PS-
Domain

CN
AN
 High-Level IMS Requirements
• IP Connectivity.
– terminal mobility.
– user mobility.
• Access Independence.
• Roaming Support.
• QoS support.
• Security Home IMS Visited IMS
(service (proxy)
control)
Home IMS Visited IMS
(service (proxy)
control)

Visited PS
Home
Domain
PS Domain
Visited PS
Domain
 Overview of IMS architecture
• S-CSCF:
– Serving Call Session Control Function.
– Authentication.
– User profiles (downloaded from HSS (Home Subscriber Server) via diameter
interface).
– Initiating Call control.
– Service control (through communicating with application servers(AS)).
– Prohibition of media types.

• P-CSCF:
– Integrity & confidentiality (through TLS & IPSEC SA)
– SIP messages compression.
– Prohibit codecs.
– Policy control.
 IMS Architecture
• I-CSCF:
– Receives both the registrations and the incoming requests.
– Interrogates the HSS to receive assistance for subsequent routing
to the proper S-CSCF.
– Forwards the SIP requests to the corresponding S-CSCF.
 IMS Architecture
HS 5.
S-
S an CSC
du F
do ser assi

(3) S-CSCF
assignment
wn pr gn
loa ofil ed
d e

(1) register P- (2) register (4) register S-

UE I-CSCF
CSCF CSCF

HS
S

(2) Query for

S-CSCF
(5) Invite P- (4) Invite S- (3) Invite (1) Invite
UE I-CSCF
CSCF CSCF
 The application server and the
media server AS
• Application server.

request
(3) SIP
request
(2) SIP
(1) SIP S- (4) SIP
• Media server: request
CSCF request

– MRFP.
AS
• media stream source
• media stream processing
SIP
• mixing of media streams
– MRFC. S- SIP
MRFC
CSCF

MEGACO

MRFP
 IMS Architecture
• All the depicted interfaces are based on SIP, except for:
– Mn and Mp: based on MEGACO
– Cx and Sh: based on Diameter
 Call Flows (register)
Home network
IP- P- I- S-
UE HSS
CAN
Access bearer
CSCF CSCF CSCF
set-up and
P-CSCF discovery
REGISTER

REGISTER
S-CSCF
assignment

REGISTER
retrieve
auth. vector
401 Unauthorized
401 Unauthorized
401 Unauthorized

REGISTER
REGISTER
REGISTER
Download
of user profile
200 OK

200 OK
 Registration (Roaming case)
Visited network Home network
IP- P- I- S-
UE HSS
CAN
Access bearer
CSCF CSCF CSCF
set-up and
P-CSCF discovery
REGISTER

REGISTER
S-CSCF
assignment

REGISTER
retrieve
auth. vector
401 Unauthorized
401 Unauthorized
401 Unauthorized

REGISTER
REGISTER
REGISTER
Download
of user profile
200 OK

200 OK
 Call Setup
Home network Visited network

U P- S- I- S- P- U
HSS
E CSCF CSCF CSCF CSCF CSCF E
INVITE
INVITE
INVITE S-CSCF
location
query
INVITE
INVITE
INVITE

183

183
183
183
183
183
 IMS Security
P- I- S-
UE HSS AUC
CSCF CSCF CSCF
REGISTER
REGISTER
REGISTER Authentication
request

Authentication Authentication
Answer info
401
RAND,AUTN,
Unauthorized
401 XRES, IK, CK
401 RAND, AUTN,
Unauthorized IK, CK
Unauthorized
RAND, AUTN,
RAND, AUTN,
IK, CK
IK, CK
AUTN
check
SAs
establishment
REGISTER
RES REGISTER
RES REGISTER
RES
RES=XR
ES?
User profile
200 OK download
200 OK 200 OK
 The IM call model
• The IMS standards divide the call execution flow into
two parts: originating and terminating. Associated with
each part is a service control entity:
– The service control in the originating part is done by the home S-
CSCF of the originator of the request.
– The service control in the terminating part is done by the home S-
CSCF of the recipient of the request.

Extern
al AS

AS

S-
SCSF
 The IM call model

AS1 AS2 AS3 AS4

S-CSCF
iFC 1 and 4 are met
iFC 2and 3 not met
 Charging
• Offline Charging:
– All the IMS elements (P/I/S-CSCF, BGCF, MGCF, MRFC, SIP AS) can
generate offline charging information. The charging information is
sent via Diameter protocol to a Charging Collection Function (Rf
interface). The CCF processes the received information, and
generates billing records that are sent via FTP to the billing system
(Bi interface).
P- S- I- M M
BGCF AS
CSCF CSCF CSCF GCF RFC

Rf

CCF

Bi
Billin
g
syste
m
 Online Charging
• The S-CSCF, AS, and MRFC support a Diameter-based
charging interface (Ro) toward an Online Charging Function
(OCF). The OCF is a functional element capable of charging
in realtime. It performs mainly three functions:
– Charging control.
– Account balance management.
– Rating.

S- M
AS
CSCF RFC

Ro

OCF
New Requirements on SIP due
to IMS
• Service Route Discovery During Registration:

pcscf1.ocean.com scscf1.ocean.com

P- I- S-
UE CSCF CSCF CSCF
REGISTER
REGISTER
REGISTER

200 OK
200 OK Service-Route:
Service-Route: scscf1.ocean.com
200 OK
Service-Route: scscf1.ocean.com
scscf1.ocean.com
INVITE
Route: pcscf1.ocean.com;
scscf1.ocean.com INVITE
Route: scscf1.ocean.com
New Requirements on SIP due
to IMS
• Discovering Adjacent Contacts:

pcscf1.ocean.com scscf1.ocean.com
230.40.45.12
P- I- S-
UE CSCF CSCF CSCF
REGISTER

REGISTER
Path: pcscf1.ocean.com REGISTER
Path: pcscf1.ocean.com
200 OK
200 OK
200 OK
INVITE
INVITE R-U: john@ocean.com
INVITE R-U: john@230.40.45.12
R-U: john@230.40.45.12 Route: pcscf1.ocean.com
 Private SIP Extensions for
3GPP IMS
• P-Visited-Network-ID Header.
• P-Access-Network-Info Header
• P-Charging-Function-Address Header
• P-Charging-Vector Header
• P-Associated-URI
• P-Called-Party-ID
 Voice XML (VXML)
• Standard XML format for specifying interactive voice
dialogues between a human and a computer.
• VoiceXML is designed for:
– Creating audio dialogs that feature synthesized speech
– Digitized audio
– Recognition of spoken and DTMF key input
– Recording of spoken input, telephony, and mixed initiative
conversations
– Its major goal is to bring the advantages of Web-based development
and content delivery to interactive voice response applications.
• HTTP is used as the transport protocol for fetching
VoiceXML pages.
• Associated with other standards like:
– Speech recognition grammar specification (SRGS).
– Speech synthesis markup language (SSML).
– Pronunciation lexicon specification (PLS).
– Call control extensible markup language (CCXML).
 VXML applications
• Order inquiry.
• package tracking.
• emergency notification.
• flight tracking.
• voice access to email.
• customer relationship management.
• prescription refilling.
• audio newsmagazines.
• voice dialing.
• real-estate information and national directory assistance applications.
 SIP IVR
• SIP protocol can be used as a signaling mean for an IVR.
• A session between the IVR and the Transmission delivery
station ought to be established using SIP.
• Voice and DTMF signals should be described in the session
description in the invite method.
• Voice and DTMF signals are made to be transferred in
separate sessions.
• Next follows an example of SDP that offers support for
DTMF:
– m = audio 42000 RTP/AVP 100. IV
Transmissi Session establishment R
– a = rtpmap:100 telephone-event/8000.on (containing voice and DTMF
delivery signals) using SIP
station
 ISUP to SIP converter
• May be used for the interaction between IP based systems
and PSTN/PLMN.

• Signaling Plane:
- An IP/PSTN gateway can perform two operations at the signaling plane:
– Protocol translation back and forth between ISUP and SIP.
– ISUP encapsulation in SIP messages, and ISUP decapsulation from SIP messages.
 ISUP to SIP converter
• Media plane:
– In the media plane, the conversion occurs between RTP, in the
IP side, and TDM in the PSTN side.
– TDM and RTP will still contain PCM 6 -encoded voice.

GW
 ISUP to SIP converter
• Example:
– PSTN to PSTN call via IP:
Thank you