SIP Certification Rel.1.1

SIP/IMS Certification
Training
Copyright 2006 Wipro Ltd
Wipro confidential
Contents
o SIP Concept & Network Architecture
o SIP Protocol Specific
o SIP & Security
o SIP & QoS
o SIP & PSTN
o SIP & PacketCable
o SIP & 3GPP
o SIP & SIMPLE
o SIP & Services
o SIP Application Framework
SIP Certification Training 1.1 Copyright 2006 Wipro Ltd
22
SIP Concept & Network

Architecture
33
Contents
o Internet Telephony
o What Is SIP ?
o Why SIP ?
o SIP Working Groups (WGs)
o Network Architecture
o SIP Trapezoid
o SIP Building Blocks
o SIP Protocol Stack
44
Internet Telephony
o PC-to-PC (MS NetMeeting, appliances)
IP Network
o PC-to-Phone (net2phone.com)
IP Network
o Phone-to-Phone (Paegas)
IP Network
o Phone-to-PC as well
55
What Protocols Are Needed ?

o Signaling Protocol to establish presence,
locate users, set up, modify and tear down
sessions
o Media Transport Protocols for transmission of
packetized audio/video
o Supporting Protocols
Gateway Location, QoS, inter-domain AAA
(Authentication, Authorization, Accounting), address
translation, IP, etc.
66
Internet Multimedia Protocol Zoo

Media Encoding
(H.261, MPEG)
DIAMETER
TRIP
MGCP/Megaco
RTP
DNS
SDP
Transport
H.323
COPS
SIP
RTSP
TCP
RSVP
RTCP
Network
UDP
Data Link
PPP
Physical
IPv4, IPv6
Sonet
PPP
AAL5
AAL3/4
ATM
Ethernet
V.34
77
What Is SIP ?
o Application-layer signaling protocol for creating,
modifying, and terminating sessions with one or more
participants
o Sessions include Internet telephone calls, multimedia
distribution (voice, image, video, etc), and multimedia
conferences
o Session invitations carry session descriptions that
allow participants to agree on a set of compatible
media types.
o Uses proxy servers to help route requests to the
user's current location, authenticate and authorize
users for services, implement provider call-routing
policies, and provide features to users (like presence,
mobility, hold, forward, transfer)
o Provides a registration function that allows users to
upload their current locations for use by proxy servers
Application Layer
SIP
Transport Layer
(UDP, TCP, SCTP,
TLS)
Network Layer
(IP/ATM)
Data Layer
Physical Layer
o Runs on top of several different transport protocols

(UDP, TCP, SCTP, TLS)
88
Why SIP ?
o Open standards with larger development community
3GPP/SIP The future of communications is the seamless integration of wireline &
wireless
o Modular design & highly scalable
Textual encoding (telnet, tcpdump compatible)

Provides programmability
URL style addresses and syntax (Similar to HTTP)
Easily extendable
o Arbitrary services built on top of SIP

Redirect calls from unknown callers to secretary
Reply with a webpage if unavailable
Send a JPEG on invitation
o Not limited to Internet telephony

SIP establishes user presence
SIP messages can convey arbitrary signaling payload: session description,
instant messages, JPEGs, any MIME types
o Suitable for applications having a notion of session

Distributed virtual reality systems,
Network games (Quake II/III implementations),
Video conferencing, etc.
99
Brief History
Date
Specifications
1995
Comments
Work began in IETF mmusic WG
02/1996
draft-ietf-mmusic-sip-00
15 ASCII pages, one request type
12/1996
30 ASCII pages, 2 request types
01/1999
149 ASCII pages, 6 methods
03/1999
RFC 2543
11/1999
SIP WG formed
11/2000
draft-ietf-sip-rfc2543bis-02
12/2000
1 RFC, 18 I-Ds
It was recognized that the amount of

work on SIP WG was becoming
unmanageable
04/2001
Proposal for splitting SIP WG into SIP

and SIPPING announced
2001
SIP implementations widely available

http://www.cs.columbia.edu/~hgs/sip/implementations.html
http://www.pulver.com/sip/products.html
07/2002
RFC 3261
New SIP RFC published

10
10
SIP Working Groups

SIP
Deals with changes to the base SIP protocol and any key extensions that might have a
bearing (or that which might warrant a change) on the base SIP protocol
SIPPING (Session
Initiation Proposal
Investigation)
Deals with standardizing extension to SIP protocol that does not have a bearing on the base
SIP protocol - i.e., all SIP peripheral activities (like support of Message Waiting Indicator
feature using SIP, SIP-T, ISUP-SIP mapping, SIP Call flows, AAA requirements in SIP etc
SIMPLE (SIP for Instant

Messaging and Presence
Leveraging Extensions)
Deals with standardizing Presence and Instant Messaging (IM) using SIP (E.g., extensions
to MSRP protocol for Session Mode Messaging unlike the original page-mode messaging
offered by SIMPLE), PIDF - Presence Info Data format, XCAP XML Configuration Access
Protocol etc
MMUSIC (Multiparty
Multimedia Session
Control)
Chartered to specify protocol required for Internet conferencing and multimedia

communications. Specifies protocols such as SDP, RTP/RTCP, RTSP, Interactive
Communication Establishment (ICE) for NAT discovery etc)
XCON (Centralized
Conferencing)
The focus of this working group is to develop a standardized suite of protocols for tightlycoupled multimedia conferences, where strong security and authorization requirements are
integral to the solution. Standardizes protocols (based on SIP) like CPCP (conferencing
policy control protocol), BFCP (binary floor control protocol) etc
MIDCOM (Middle Box

communication)
Chartered to address NAT/Fire Traversal issues. Standardizes protocols like MIDCOM for
pin-hole management of NAT; STUN (simple traversal of UDP thru NATs) etc
ENUM (Electronic
Numbering)
Deals with converting E.164 numbers to routable URIs (similar to DNS). In fact, ENUM is a
nothing but a glorified DNS for VoIP. It uses the same building blocks of DNS like the
NAPTR (Naming Address Pointer) records for specifying the E.164 to URI conversion
11
11
SIP Working Groups

IPTEL (IP Telephony)
Deals with problems related to naming and routing for Voice over IP (VoIP) protocols
Standardizes protocols like TGREP (Telephony Gateway Registration Protocol) needed for dynamically registering new (sip) gateways and soft switches in a
Multimedia/VoIP network; TRIP (Telephony routing over IP) - TRIP's operation is
independent of any signaling protocol, hence TRIP can serve as the telephony
routing protocol for any signaling protocol
This WG also specified the Call Processing Language (CPL) - an XML based
scripting language to implement user features on a SIP Proxy
SPIRITS (Services in the

PSTN/IN Requesting Internet
Services)
Allows for services supported by IP network entities getting initiated from IN

(Intelligent Network) requests, as well as the protocol arrangements through which
PSTN (Public Switched Telephone network) can request actions to be carried out in
the IP networking response to events (IN Triggers) occurring within the PSTN/IN
For instance the SPIRITS protocol specifies some changes to the SIP URI scheme
and can be used for services such as Internet Call Waiting etc. I.e., this deals with
activating/ initiating services from the PSTN and rendering it over the Internet
PINT (PSTN Interworking)
This WG specifies a protocol to perform the corollary of the SPIRITS (described

above).
For instance this specifies SIP URI scheme changes to implement services such as
click-to-call (based on 3rd Party Call Control mechanism). I.e., this deals with
activating services from the Internet and rendering it over the PSTN
12
12
Other Related Bodies

3GPP (Third Generation
Partnership Project)
Creation of technical specifications for 3rd Generation Mobile Systems

Uses SIP as call signaling in IP networks
ITU-T SG 16
H.323 V1-V4 umbrella standard

H.248 (Megaco)
ETSI TISPAN
Concerned with IP/PSTN interoperability

Analysis of security threats, Open Settlement Protocol
SIP Forum
For promotion of SIP Technology
PacketCable
Established by CableLabs to look at cable technologies
JAIN (Java Advanced

Intelligent Network)
Developing abstract APIs for developing service creations across PSTN,

ATM, IP, etc.
PARLAY Group
Aims to intimately link IT applications with the capabilities of the

telecommunications world by specifying and promoting application
programming interfaces (APIs) that are secure, easy to use, rich in
functionality, and based on open standards.
Parlay integrates telecom network capabilities with IT applications via a
secure, measured, and billable interface.
and the list goes on

13
13
Network Architecture
SCP
SSP
DLC
STP
PSTN
PSTN GW
PBX
3rd Party
Applications
SIP/SIP-T
Location
Server
DNS
Application
Server
OSA
Gateway
SIP Network
CMTS
SIP/SIP ISC
EBP
CMS/GC
SIP
User
Agents
Application
Servers
SIP/SIP-T
SIP/SIP ISC
CSCF
HSS
PacketCable Network
MTA
MTA
MGCF
PCF
IM Subsystem
WiFi/
WiMax
VDSL
FTTH
CDMA/
GSM/UMTS
14
14
SIP "Trapezoid"
DNS Server
Location Server
DNS
Outbound
Proxy Server
SIP
SIP
Inbound
Proxy Server
SIP
RTP
User Agent A
User Agent B
15
15
SIP User Agent (UA)

o User Agent Client (UAC) :
Logical entity
Creates a new request (initiates a new call)
Uses the client transaction state machinery to send request
Role lasts only for the duration of that transaction
o User Agent Server (UAS) :
Logical entity
Generates a response to a SIP request (receives the call request)
Role lasts only for the duration of that transaction
SIP Redirect server is an example of UAS
o SIP User Agent (UA) :

Logical entity
Act as both a UAC and UAS
16
16
SIP User Agent

o User Agent can be both SW and HW
17
17
SIP Proxy
o Intermediary entity that acts as both a server and a client
for the purpose of making requests on behalf of other
clients
o Primarily plays the role of routing and is transparent to
end devices
o Interprets and, if necessary, rewrites a request message
before forwarding it
o Header fields that can be legitimately modified are:
Request-URI
Via
Record-Route
Route
Max-Forwards
Proxy- Authorization
18
18
SIP Proxy
o Can either maintain state information of transaction
(stateful proxy) or simply forward the requests (stateless
proxy)
o Can forward the requests one after the other sequentially
o Can fork the requests to multiple servers
o Useful for enforcing policy
o Authenticate and authorize users for services, implement
provider call-routing policies
19
19
SIP - Proxy Mode Operation

DNS Server
LOCATION SERVER
INVITE sip:subhodeep@wipro.com
Caller@sip.com From: sip:Caller@sip.com
To: sip:subhodeep@wipro.com
#1
Call-ID: 345678@sip.com
200 OK
#6 From: sip:Caller@sip.com
Callee
DNS Srv Query ? wipro.com

Reply : IP Address of wipro.com SIP Server
subhodeep@192.219.223.160
#2
PROXY
#3
subhodeep@wipro.com
INVITE sip:subhodeep@192.219.223.160
From: sip:Caller@sip.com
#4
200 OK
#5
From: sip:Caller@sip.com
#7 ACK sip:subhodeep@wipro.com
#8 Media Streams
20
20
SIP Stateful Proxy

o Logical entity that maintains the client and server
transaction state
o Creates a new server transaction for each new request
received
Validate the request
Preprocess routing information
Determine target(s) for the request
Forward the request to each target
Process all responses
o May generate a CANCEL request for pending INVITE client

transaction
o Can apply additional logic after response arrives
21
21
SIP Stateless Proxy

o Logical entity that does not maintain the client or server
transaction state
o Forwards every request it receives downstream and
every response it receives upstream
o Forward all retransmission, don't retransmit message of
their own
o Stateless proxy
Validate a request
Chose one and only one target from the target set
Forward the request to the chosen target
o Must not generate CANCEL request
22
22
Stateless Versus Stateful Proxy

Stateless Mode
Stateful Mode
Usage
Good for heavy-load scenario, i.e. Core
Network
Good for implementing some services like

forward on no reply, i.e. Edge Network
Behavior
Proxies just receive messages, perform
routing logic, send messages out
Proxies maintain state during entire

transaction; they remember outgoing requests
as well as incoming requests until transaction
is over
Would result in new execution of SIP routing

logic for every retransmission (caching routing
results can help reduce the overload)
A forking proxy will be stateful
No memory requirements
Reduce retransmission time by acting on

behalf of sender closer to destination
23
23
SIP Outbound Proxy

o Mostly used in presence of a firewall/NAT to handle the
signaling and media traffic across the firewall
o Serves one or more domain
o Receives requests from other domain
o Performs DNS process to forward request
o May also provide additional services
Outbound screening
Authorization
Logging
Firewall control
o Typically, a UA is manually configured with an outbound

proxy
24
24
SIP Redirect Server

o Aids in locating the target of the request
o Allows servers to push routing information for a request
back in a response to the client, scaling down processing
o UAS, that generates 3xx responses to requests it
receives, directing the client to contact an alternate set of
URIs
o Populates the list of alternate locations in a Contact
header in 3xx response
o Constituted of a server transaction layer and a TU that
has access to a location service
o Doesnt generate a SIP request of its own
25
25
SIP - Redirect Server Operation

LOCATION SERVER
Callee
Caller@sip.com
Callee@home.com
#2
#3
#1 INVITE Callee@example.com
#4
302 Moved Temporarily

Contact:Callee@home.com
#5 ACK Callee@example.com
#6 INVITE Callee@home.com
#7
200 OK INVITE
#8
ACK Callee@home.com
PROXY
Callee@home.com
26
26
SIP Server Redirect Versus Proxy

o A SIP Server may either proxy or redirect a request
o Which of the two method applies is a configuration issue.
It may be statically configured or dynamically determined
o Redirection useful if a user moves or changes his/her
provider - caller does not need to try the original server
next time
o Redirect Servers are stateless
o Proxy useful if forking, AAA, firewall control needed. In
general, proxying grants more control to the server
27
27
SIP Registrar
o Server that accepts REGISTER requests and places
information it receives in those requests into location
service for the domain it handles
o Provide location services to the SIP network
o Location Service is a DB containing the SIP URI and its
locations
o Location service is used by a SIP redirect or proxy server
to obtain information about a callee's possible locations
o DNS query is used to access location service (RFC 3263)
28
28
SIP Registrar Operation
#2
subhodeep@192.219.223.160
LOCATION SERVER
This registration example establishes presence
of user with address subhodeep@wipro.com and
binds this address to users current location
192.219.223.160
REGISTER sip:register.wipro.com SIP/2.0

From: sip:subhodeep@wipro.com
#1
Contact: <sip:192.219.223.160>
Expires: 7200
#3
SIP/2.0 200 OK
SIP REGISTRAR
(domain register.wipro.com)
29
29
SIP Back-to-Back User Agent (B2BUA)

o Logical entity that receives a request and processes it as
a user agent server
o It acts as a user agent client and generates requests
o Maintains dialog state and must participate in all requests
sent on the dialogs it has established
o Provides third-party call control
o Useful for services and anonymity
30
30
SIP B2BUA Operation
PSTN
PSTN
VoIP Network
1
INVITE (Call-ID#1)
INVITE (Call-ID#2)
1
Calling Party
100 Trying
SIP Signaling
& SDP Signaling
(UDP or TCP)
180 Ringing
200 OK
1
1
1
180 Ringing
200 OK
Called Party
Signaling
1
ACK
1
Media (UDP)
100 Trying
RTP Stream
ACK
Bearer Or
Media
31
31
SIP Protocol Stack

o SIP is structured as a layered
protocol
Lowest layer is syntax and encoding

Second layer is the transport layer
Third layer is the transaction layer
Layer above the transaction layer is called
the transaction user (TU)
Transaction User
Transaction Layer
Transport Layer
Syntax/Encoding
Transport Layer
Network Layer
Data Layer
Physical Layer
32
32
Syntax/Encoding Layer
o Lowest layer of SIP
o Responsible for encoding/decoding
and syntactical parsing of the
messages
o Encoding is specified using an
augmented Backus-Naur Form
grammar (BNF)
Transaction User
Transaction Layer
Transport Layer
Syntax/Encoding
Transport Layer
Network Layer
Data Layer
Physical Layer
33
33
Transport Layer
o Second layer of SIP
o Responsible for the actual
transmission of requests and
responses over network transports
o Responsible for managing persistent
connections for transport protocols like
TCP, SCTP and TLS
o Performs framing for message-oriented
transport like UDP
o Performs Error handling for request or
response message
o All SIP elements contain a transport
layer
o All SIP elements implement UDP and
TCP
o Recommended port - 5060 for UDP,
TCP and SCTP, 5061 for TLS over
TCP
Transaction User
Transaction Layer
Transport Layer
Syntax/Encoding
Transport Layer
Network Layer
Data Layer
Physical Layer
34
34
Transaction Layer
o Third layer of SIP
o Handles application-layer retransmissions,
matching of responses to requests, and
application-layer timeouts
o Consists of
Client transaction
Server transaction
Transaction User
Transaction Layer
Transport Layer
Syntax/Encoding
o Each component is represented by a finite

state machine that is constructed to
process a particular request
o Stateless proxies do not contain a
transaction layer
Transport Layer
Network Layer
Data Layer
Physical Layer
35
35
Transaction Layer
o Client transaction:
Responsible for sending the request
Responsible for receiving responses from the
transport layer and delivering them to the TU
Filtering out any response retransmissions or
disallowed responses (e.g. a response to ACK)
o Server transaction:
Responsible for sending the response
Responsible to receive requests from the transport
layer and deliver them to the TU
Filters any request retransmissions from the network
Accepts responses from the TU and delivers them to
the transport layer for transmission over the network
36
36
Transaction User (TU)

o Layer above the transaction layer
o To send a request, TU creates a client
transaction instance and passes the
request along with the destination IP
address, port, and transport to which
to send the request
o TU that creates a client transaction
can also cancel it
o Each of the SIP entities, except the
stateless proxy, is a transaction user
Transaction User
Transaction Layer
Transport Layer
Syntax/Encoding
Transport Layer
Network Layer
Data Layer
Physical Layer
37
37
SIP PROTOCOL SPECIFIC
38
38
Contents
o
o
o
o
o
o
o
o
o
o
o
SIP Messages
Protocol Basics
Message Bodies
Headers
Session Description Protocol (SDP)
Offer-Answer Model
SIP State Machine
SIP Addressing
SIP Routing
SIP Extensions
SIP Event Notification Framework
39
39
SIP Messages
Start-Line
One or more Header fields
An Empty Line indicating the
end of the header fields
An optional Message Body
Response Start Line
method URL SIP/2.0
SIP/2.0 status reason
Via: SIP/2.0/ protocol host:port

From: user <sip:from_user@source>
To: user <sip:to_user@destination>
Call-ID: localid@host
CSeq: seq# method
ContentLength: length of body
ContentType:media type of body
Header: parameter ;par1=value ;par2="value"
Blank Line (CR LF)
V=0
o=origin_user timestamp timestamp IN IP4 host
s=session name
c=IN IP4 media destination address
t=0 0
m= media type port RTP/AVP payload types
Message Body
o Uses the UTF-8 charset (RFC

2279)
o Request and Response
messages use the basic format
of RFC 2822
o Message and header field
syntax is very much identical to
HTTP/1.1
Request Start Line
Message Header
o Either a Request from a client to

a server, or a Response from a
server to a client
o Both types of messages consist
of
40
40
Request
o Distinguished by having a Request-Line for a startline
Protocol
Request
o A Request-Line contains
Request-URI
Version
Method
Method name
Request-URI
INVITE sip:called@dmn.com SIP/2.0
Protocol version
separated by a single space (SP) character
o The Request-Line ends with CRLF. No CR or LF

are allowed except in the end-of-line CRLF
sequence
o No linear white space (LWS) is allowed in any of
the elements.
41
41
SIP Signalling - METHODS

o INVITE initiates sessions
session description included in message body
re-INVITEs used to change session state
o ACK confirms session establishment

can only be used with INVITE
o BYE terminates sessions

o CANCEL cancels a pending INVITE
o OPTIONS capability inquiry
o REGISTER binds a permanent address to current
location; may convey user data (CPL scripts)
42
42
SIP Signalling Extension METHODS

o INFO - mid-call signaling (RFC 2976)
o UPDATE - Allows a client to update parameters of a
session (such as the set of media streams and their
codec's) but has no impact on the state of a dialog (RFC
3311)
o PRACK provisional reliable responses acknowledgement
(RFC 3262)
o SUBSCRIBE/NOTIFY To provide an extensible
framework by which SIP nodes can request notification
from remote nodes indicating that certain events have
occurred (RFC 3256)
o MESSAGE Instant Messaging (RFC 3428)
43
43
Sample Requests
OPTIONS
INVITE
INVITE sip:called@dmn.com SIP/2.0
From: sip:caller@clrdomain.com
To: sip:called@clddomain.com
CallID: 31415@clrdomain.com
CSeq: 1 INVITE
Via: SIP/2.0/UDP clrdomain.com;
branch=z9hG4bK776
Content-Type: application/sdp
Content-Length: 274
v=0
o=called 536 2337 IN IP4 h3.clddomain.com
s=session_name_1
c=IN IP4 192.213.229.147
t=0 0
m=audio 3456 RTP/AVP 0
Requests can
have headers
and SDP
Requests may not

have SDP
SIP
OPTIONS sip:called@dmn.com SIP/2.0

CSeq: 1 OPTIONS
Via: SIP/2.0/UDP clrdomain.com;
branch=z9hG4bK776
Accept: application/sdp
Content-Length: 0
SIP
SDP
SDP
INFO
INFO sip:called@dmn.com SIP/2.0
Contact: <sip:called@clddomain.com>
CSeq: 1 INFO
Content-Length: 0
SIP
SDP
44
44
Response
o Distinguished from requests by having a Status-Line as
their start-line
Protocol Status Textual
o A Status-Line consists of
Version Code Phrase
Protocol version
Numeric Status-Code
SIP/2.0 180 Ringing
Associated textual phrase
with each element separated by a single SP character.
o No CR or LF is allowed except in the final CRLF sequence
45
45
SIP Signalling Response Code

o Borrowed from HTTP: xyz explanatory text
Receivers need to understand x
x80 and higher codes avoid conflicts with future HTTP response
codes
o 1yz Informational
100 Trying
180 Ringing
181 Call is Being Forwarded
182 Queued
o 2yz Success
200 Ok
o 3yz Redirection
300 Multiple Choices

301 Moved Permanently
305 Use Proxy
380 Alternative Service
46
46
SIP Signalling Response Code

o 4yz Client Error
400 Bad Request

401 Unauthorized
482 Loop Detected
486 Busy Here
o 5yz Server Failure

500 Server Internal Error
o 6yz Global Failure

600 Busy Everywhere
47
47
Sample Responses
Success 200 OK
SIP/2.0 200 OK
CSeq: 1 OPTIONS
Accept-Encoding: gzip
Accept-Language: en
Content-Length: 274
SIP
SIP/2.0 487 Request Rerminated

CSeq: 1 INVITE
Content-Length: 0
SIP
SDP
v=0
s=session_name_1
c=IN IP4 192.213.229.147
t=0 0
Response can
have headers
and SDP
Failure 487 Request Terminated
Response may not

have SDP
SDP
Provisional 180 Ringing

SIP/2.0 180 Ringing
Contact: <sip:called@clddomain.com>
CSeq: 1 INVITE
Content-Length: 0
SIP
SDP
48
48
SIP Headers
o Similar to HTTP header fields in both syntax and
semantics
o Follow the [H4.2] definitions of syntax for the messageheader and the rules for extending header fields over
multiple lines
o Multiple header fields of the same field name whose
value is a comma-separated list can be combined into
one header field
o Provides a mechanism to represent common header field
names in an abbreviated form
header = "header-name" HCOLON header-value *(COMMA header-value)
49
49
Sample SIP Headers

Form Compact
Form Long
CSeq: 1 OPTIONS
Accept-Language: en
Content-Length: 274
f: sip:caller@clrdomain.com
t: sip:called@clddomain.com
i: 31415@clrdomain.com
CSeq: 1 OPTIONS
Accept-Language: en
c: application/sdp
l: 274
Multiple Headers Field Rows

CSeq: 1 OPTIONS
Contact: <sip:alice@atlanta.com>;expires=3600
Contact:<sip:alice@chicago.com>
Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
<sip:bob@biloxi.com>
50
50
SIP Message Bodies

o Requests may contain message bodies (binary/text
object), interpreted depending on the request method.
Typically contains session (media) description
o Responses may contain message bodies (binary/text
object), the request method and the response status
code determine the type and interpretation of any
message body. Typically contains session (media)
description on success, HTML or plain text on failure
o Should include
Message Body Type
Message Body Length
51
51
SIP Message Bodies

o Message Body Type:
Indicated by Content-Type Header (text/html, application/sdp)
Encoding (if performed) is indicated using Content-Encoding
Header
Multipart MIME may be used in the message body
(multipart/mixed) for carrying opaque content
o Message Body Length:

Indicated by Content-Length Header
o Media Type:
Indicated by Accept Header
o Language of Response:
Indicated by Accept-Language Header
52
52
Sample SIP Message Bodies

Media - SDP
Content-Length: 274
v=0
s=session_name_1
c=IN IP4 192.213.229.147
t=0 0
Application Message Summary

Content-Type: application/message-summary
Content-Length: 98
Messages-Waiting: yes
Message-Account: sip:alice@vmail.example.com
Voice-Message: 2/8 (0/2)
Application - pkcs7-signature
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
53
53
SIP Call Flow

SIP UA (A)
1
Location
Services
Proxy
Server
INVITE (SDPo)
2
Location Lookup
Lookup Result
100 Trying
180 Ringing
200 OK (SDPT)
10
4
5
7
SIP UA (B)
INVITE (SDPo)
180 Ringing
200 OK (SDPT)
6
8
ACK
Session In
Progress
Two way Speech Path

11
Session
Initiation
BYE
200 OK
12
Session
Teardown
54
54
SIP Transaction
o Fundamental unit of message exchange
o Request Response cycle
o Consists of a single request and any responses to that
request, which include
Zero or more provisional responses
Usually one final responses
Maybe ACK
o Exist within user agents and stateful proxy servers

o Identified by CSeq (sequence number and method tag)
and branch parameter
o For INVITE transaction, the transaction includes the ACK
only if the final response was not a 2xx response
o If the response was a 2xx, the ACK is not considered
part of the transaction
55
55
SIP Transaction
Successful Call Scenario
UAC
1
First Transaction
INVITE (CSeq:1 INVITE)
100 Trying (CSeq:1 INVITE)

200 OK (Cseq:1 INVITE)
4
Failure Call Scenario
UAS
UAC
1
100 Trying (CSeq:1 INVITE)
486 Busy Here (CSeq:1 INVITE) 3
ACK (CSeq:2 ACK)
First Transaction
INVITE (CSeq:1 INVITE)
UAS
ACK (CSeq:1 INVITE)
Second Transaction
5
BYE (CSeq:3 BYE)

200 OK (CSeq:3 BYE)
56
56
SIP Dialog
o Represents a peer-to-peer SIP relationship between two
user agents
o SIP-level conversation between two endpoints
o Facilitates sequencing of messages between the user
agents and proper routing of requests between both of
them
o Created through the generation of non-failure responses to
requests with specific methods
2xx and 101-199 responses with a To tag, where the request was
INVITE, will establish a dialog
o When a UA sends a request, it contains a From tag only,

providing "half" of the dialog ID. The dialog is completed
from the response(s), each of which contributes the
second half in the To header field.
o Dialog terminations are METHOD specific
57
57
SIP 0
Single Dialog Scenario
UAC
1
Dialog
First Transaction
INVITE (F-Tag: Xxx)
No Dialog Scenario
UAS
100 Trying
200 OK (F-Tag: Xxx, T-Tag: Yyy)
4
UAC
1
2
3
4
ACK (F-Tag: Xxx, T-Tag: Yyy)
First Transaction
INVITE
UAS
100 Trying
486 Busy Here
ACK
Second Transaction
5
BYE (F-Tag: Xxx, T-Tag: Yyy)

200 OK (F-Tag: Xxx, T-Tag: Yyy)
58
58
SIP Dialog
o Identified at each UA with a dialog ID, which consists of
a Call-ID value, a local tag and a remote tag
o A dialog ID is associated with all responses and with any
request that contains a tag in the To field
o Rules for computing the dialog ID of a message:
For UAC,
Call-ID = Call-ID
Remote tag = tag in the To field
Local tag = tag in the From field
For UAS,
Call-ID = Call-ID
Remote tag = tag in the From field
Local tag = tag in the To field
59
59
SIP Session
o A session is the exchange of media between two or
more endpoints
o Most common form of a session uses the RTP protocol
for exchange of voice media
o Can also be used to exchange text, video, game
information and other types of media
o Sessions are described using the Session Description
Protocol (SDP) and generally consist of multiple RTP
streams between two endpoints
o SIP is used in the setup of sessions, but sessions can be
setup without SIP
o Exchange of SIP messages does not always result in a
session being set up
o There can be dialogs without SIP sessions
60
60
Request-URI
o Indicates the user or service to which this request is
being addressed
o Supports SIP or SIPS or TEL URI or any generic URI
o Current destination, may change along the signaling
path
o Initial value of the URI is set as the To field
o For REGISTER method,
Names the domain of the location service for which the
registration is meant
"userinfo" and "@" components of the SIP URI not present
RequestURI
REGISTER sip:registrar.wipro.com SIP/2.0
RequestURI
INVITE sip:bob@ebay.com SIP/2.0
61
61
To
To = ( "To" / "t" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )
o Specifies the desired "logical" recipient of the request, or

the address-of-record of the user or resource that is the
target of this request
o Can be populated through a human interface
o Allows for a display-name to be rendered by a humanuser interface
The URI including all URI parameters is enclosed in "<" and ">
If no "<" and ">" are present, all parameters after the URI are
header parameters, not URI parameters
62
62
To
To = ( "To" / "t" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )
o
o
o
o
Supports Tag to identify the peer of the dialog

Occur only once per message
Compact form of the To header field is t
Examples of valid To header fields:
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com
Display
Name
Addr
spec
Tag
Parameter
To : The Operator <sip:operator@cs.columbia.edu>;tag=287447
63
63
From
From = ( From" / f" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )
o Indicates the logical identity of the initiator of the request,

possibly the user's address-of-record
o Populated value is pre-provisioned by the user or by the
administrators of the user's local domain
64
64
From
From = ( From" / f" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )
o Use display name "Anonymous" if the identity of the

client is to remain hidden
o Supports Tag to identify the peer of the dialog
o Occur only once per message
o Compact form of the From header field is f
o Examples of valid From header fields:
From: A. G. Bell <sip:agb@bell-telephone.com> ;tag=a48s
From: sip:+12125551212@server.phone2net.com;tag=887s
f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
Display
Name
Addr
spec
Tag
Parameter
From: A. G. Bell <sip:agb@bell-telephone.com> ;tag=a48s
65
65
Tags
o Used in the To and From header fields of SIP messages
o Serves as a general mechanism to identify a dialog,
which is the combination of
Call-ID
Two tags (remote and local), one from each participant in the
dialog
o Must be globally unique and cryptographically random

o Algorithm for generating a tag is implementation-specific
66
66
Call-ID
Call-ID = ( "Call-ID" / "i" ) HCOLON word [ "@" word ]
o Acts as a unique identifier to group together a series of

messages spread across transactions and dialogs
o Must be the same for all requests and responses sent by
either UA in a dialog
o Must be the same in each registration refresh from a UA
o Must be selected by the UAC as a globally unique
identifier over space and time, cryptographically random
identifiers is recommended
o Call-IDs are case-sensitive and are simply compared
byte-by-byte
o Compact form of the Call-ID header field is i
o Examples of valid Call-ID header fields:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
67
67
CSeq
CSeq = "CSeq" HCOLON 1*DIGIT LWS Method
o Serves as a way to identify and order transactions

o Differentiator between new requests and request
retransmissions
o Consists of a single decimal sequence number and a
method
o The method must match that of the request
o Requests within a dialog contain strictly monotonically
increasing and contiguous CSeq sequence numbers in
each direction
o Exception for ACK and CANCEL, whose numbers equal
the requests being acknowledged or cancelled
68
68
CSeq
CSeq = "CSeq" HCOLON 1*DIGIT LWS Method
o For non-REGISTER requests outside of a dialog, the

sequence number value is arbitrary
o The sequence number value must be expressible as a
32-bit unsigned integer and be less than 2**31
o Two header fields are considered equal if the sequence
number and the request method are identical
o Examples of valid CSeq header fields:
CSeq: 231 BYE
CSeq: 314159 INVITE
Digit Method
CSeq: 231 BYE

69
69
Max-Forwards
Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT
o Serves to limit the number of hops a request can transit

on the way to its destination
o Consists of an integer in the range of 0-255 that is
decremented by one at each hop
o Must be used with any SIP method to limit the number of
proxies or gateways that can forward the request to the
next downstream server
o Max-Forwards value of 0 before the request reaches its
destination, will be rejected with a 483 Too Many Hops
error response
o UAC insert a Max-Forwards header field into each
request it originates with a value of 70
o Examples of valid Max-Forwards header fields:
Max-Forwards: 6
70
70
Via
Via = ("Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
via-parm = "SIP" SLASH 2.0 SLASH "UDP" / "TCP" / "TLS" / "SCTP" LWS host [ COLON port ] *( SEMI via-params )
via-params = "ttl" EQUAL 1*3DIGIT ; 0 to 255 / "maddr" EQUAL host / via-received / "branch" EQUAL token
via-received = "received" EQUAL (IPv4address / IPv6address)
o Indicates the path taken by the request and identifies the

location where the response is to be sent
o Indicates the transport used for the transaction
o Added only after the transport that will be used to reach
the next hop has been selected
o Must contain a branch parameter used to
Identify the transaction created by that request
Proxies to detect loops
o Protocol name and version in the header field is set to

SIP and 2.0 respectively
o Contain parameters such as "maddr", "ttl", "received",
and "branch
71
71
Via
Via = ("Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
via-parm = "SIP" SLASH 2.0 SLASH "UDP" / "TCP" / "TLS" / "SCTP" LWS host [ COLON port ] *( SEMI via-params )
via-params = "ttl" EQUAL 1*3DIGIT ; 0 to 255 / "maddr" EQUAL host / via-received / "branch" EQUAL token
via-received = "received" EQUAL (IPv4address / IPv6address)
o Occur one or more per message

o The compact form of the Via header field is v
o Two header fields are equal
If sent-protocol = sent-by fields
Both have the same set of parameters, and
The values of all parameters are equal
o Examples of valid Via header fields:

Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.20;branch=z9hG4bK77asjd
Protocol/Version/
Transport
Host
Port
Branch
Parameter
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7

72
72
Branch Parameter
o
o
o
o
Contain in Via header field value

Used to identify the transaction created by that request
Used by both the client and the server
Value is unique across space and time for all requests
sent by the UA
o The exceptions to this rule are CANCEL and ACK for
non-2xx responses
CANCEL request will have the same value of the branch
parameter as the request it cancels.
ACK for a non-2xx response will also have the same branch ID
as the INVITE whose response it acknowledges
o The branch ID inserted by an element always begin with

the characters "z9hG4bK (magic cookie)
Via: SIP/2.0/UDP sip.wipro.com;branch=z9hG4bK776asdhds
73
73
Contact
Contact =
("Contact" / "m" ) HCOLON ( STAR / ((name-addr / addr-spec) *(SEMI "q" EQUAL ( "0" [ "." 0*3DIGIT ] ) /
( "1" [ "." 0*3("0") ] ) / "expires" EQUAL 1*DIGIT ) *(COMMA (name-addr / addr-spec) *(SEMI "q" EQUAL
( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) / "expires" EQUAL 1*DIGIT ) )))
o Provides a SIP or SIPS URI that can be used to contact

that specific instance of the UA for subsequent requests
o Must be present and contain exactly one SIP or SIPS
URI in any request that can result in the establishment of
a dialog
o Contains the URI at which the UA would like to receive
requests, and this URI is valid even if used in
subsequent requests outside of any dialogs
o Must use SIPS URI if the Request-URI or top Route
header field value contains a SIPS URI
74
74
Contact
Contact =

o "q" and "expires parameters are only used when the

Contact is present in a REGISTER request or response,
or in a 3xx response
o For Request forwarding, targets are processed from
highest q value to lowest, equal q values may be
processed in parallel
o expires" parameter indicates expiration of the URI
75
75
Contact
Contact =
o Occur zero or one per message

o Compact form of the Contact header field is m (for
"moved")
o Examples of valid Contact header fields:
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>;q=0.7;
expires=3600,"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
m: <sips:bob@192.0.2.4>;expires=60
Display Name
Address
Spec
Contact
Parameters
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>;q=0.7; expires=3600
76
76
REGISTER Method
o Create bindings in a location
service for a particular domain
that associates an AOR URI with
one or more contact addresses
o Sent from UAC to Registrar
o Registrar identified in RequestURI
o Identifies registered user in To
o Identifies person performing
registration in From (usually =
To)
o Contains list of current locations
in Contact headers
REGISTER sip:registrar.biloxi.com SIP/2.0

Via: SIP/2.0/UDP bobspc.biloxi.com:5060;
branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length: 0
77
77
REGISTER Method
o Prioritized with the "q" parameter in the Contact header field
(indicative of priority)
o Includes an expiration interval that indicates the desired
lifetime of validity of the client registration
Two ways to suggest an expiration interval for a binding:
Expires : Expiration interval for all Contact header
"expires" Contact header parameter : Expiration intervals on a perbinding basis
o Doesn't establish a dialog
78
78
REGISTER Response
o Check if domain is its own
o Authorize user in From
o Add address bindings of To to
Contact list
o Modify expiration time, if too long
o Return, in response, list of all
current registrations
o Return, in response, expiration
time for all registrations and
respective priorities, if present
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;
branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Contact: <sip:bob@192.219.223.160>
Expires: 7200
Content-Length: 0
79
79
Registration Details
o Registration is used for routing incoming SIP requests and
has no role in authorizing outgoing requests
o Authorization and authentication are handled in SIP either
on a request-by-request basis with a challenge/response
o UA must refresh registrations by resending before
expiration
o Should use the same Call-ID for registration refresh
o Each contact must be refreshed independently
Can place them all in same REGISTER
Can use separate REGISTER for each
o Send Expires header to 0 for registration cancellation

o Querying list of current registrations
Send REGISTER with no Contact headers
Response contains list of current registrations
80
80
INVITE Method
o Used to signal the desire
to open a session
o Sent from UAC to UAS
o Mandatory header
fields :
From
To
Call-ID
CSeq
Via
Max-Forward
o Can carry SDP to

exchange the media
capabilities
INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;
branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Length: 142
v=0
o=user1 536 2337 IN IP4 h3.clrdomain.com
s=session_name_1
c=IN IP4 h3.clrdomain.com
m=audio 3456 RTP/AVP 0 1
m=video 4000 RTP/AVP 38 39
SIP
SDP
81
81
ACK Method
o ACK method is used to
confirm the final response
that was sent to the
INVITE method
o Indicates that the session
has been accepted
o Can be used to indicate
SDP to the other entity;
not mandatory to contain
SDP info
ACK sip:bob@biloxi.com SIP/2.0

branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 ACK
ContentType: application/sdp
Content-Length: 138
SIP
v=0
s=session_name_1
SDP
82
82
Sample Call Flows ACK w/wo SDP

Slow Start Call Scenario
Fast Start Call Scenario
UAC
1
First Transaction
INVITE (SDPO)
100 Trying
200 OK (SDPT)
UAS
200 OK (SDPT)
Two way Speech Path

Second Transaction
BYE
6
First Transaction
INVITE
100 Trying
ACK
200 OK
UAC
ACK (SDPO)
Two way Speech Path

Second Transaction
BYE
200 OK
UAS
2
3
83
83
o Allows a UA to query
another UA or a proxy
server as to its capabilities
o Capabilities:
Supported methods
Content types
Extensions
Codecs

o Target identified in RequestURI
o All UAs must support the
OPTIONS method
OPTIONS Request Method
OPTIONS Method
OPTIONS sip:carol@chicago.com SIP/2.0
branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Content-Length: 0
84
84
OPTIONS Method
o May be sent as part of an established dialog to query the
peer on capabilities
o Accept header field included to indicate the type of
message body the UAC wishes to receive in the response
o Typically, set to a format that is used to describe the
media capabilities of a UA
o Contact header field may be present in an OPTIONS
85
85
o Allow, Accept, AcceptEncoding, AcceptLanguage, and Supported

header fields are
recommended
o 200 OK - if UAS is ready to
accept a call
o 486 (Busy Here) if UAS is
busy, etc
o Allow header field should be
omitted, if generated by a
proxy
o Message body may be sent,
the type of which is
determined by the Accept
header field in the request
OPTIONS Success Response
OPTIONS Response
SIP/2.0 200 OK
branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Content-Length: 0
86
86
BYE Method
o Sent to signal the end of the
established session
o Can be initiated by any UAC
which is a of the session
o Any session associated with
that dialog should terminate
o All pending methods (if any)
should be terminated
BYE sip:bob@biloxi.com SIP/2.0

Max-Forwards: 70
CSeq: 986759 BYE
Content-Length: 0
87
87
CANCEL Method
o Sent to cancel a previously sent
method
o UAC to UAS
o Cancels pending request and
generates error response method (487:
Request Terminated)
o No effect on a request for which a final
response has been received
o Stateful proxy responds to a CANCEL,
rather than simply forwarding
o Referred to as a "hop-by-hop" request
o Request-URI, Call-ID, To, the numeric
part of CSeq, and From header must be
identical to those in the request being
cancelled, including tags
CANCEL sip:bob@biloxi.com SIP/2.0

Max-Forwards: 70
CSeq: 986759 INVITE
Content-Length: 0
88
88
Sample Call Flows BYE & CANCEL

Successful Call Scenario
UAC
1
First Transaction
INVITE
100 Trying
200 OK
Failure Call Scenario
UAS
UAC
1
100 Trying
2
3
ACK
4
Two way Speech Path

Second Transaction
BYE
200 OK
First Transaction
INVITE
180 Ringing
Second Transaction
CANCEL
200 OK
487 Request Terminated
ACK
UAS
2
3
89
89
SIP State Transition - Server

Initial
INVITE
1xx
CANCEL
200
INVITE
status
INVITE
1xx
event
message sent
Call Proceeding
INVITE
status
max(T1*2n, T2)
status
Success
BYE
200
ACK
ACK
-
BYE
200
Callee Answer
2xx
failure
>= 300
Failure
32s
-
status change
1xx
Confirmed
BYE
200
90
90
SIP State Transition - Client

Initial
7 INVITE sent
T1*2n
INVITE
INVITE
Calling
give up
BYE
1xx
300-699
ACK
Call Proceeding
300-699
ACK
event
request sent
300-699
ACK
1xx
give up
BYE
Completed
32s (for proxy)
91
91
SIP Addressing
o Uses Uniform Resource Indicator (URI) for addressing an
entity in the network
o Allows any URI type
sip/sips URIs
tel URIs
http URLs for Redirect Service (for example)
maito URLs
o Two URI schemes

sip:subhodeep@sip.wipro.com is a SIP URI
sips:subhodeep@sip.wipro.com is a Secure SIP URI (Requires
TLS over TCP as transport for security)
o Two types of SIP URIs:

Address of Record (AOR) (identifies a user)
sip:subhodeep@sip.wipro.com (Need DNS SRV records to locate

SIP Servers for sip.wipro.com domain)
Fully Qualified Domain Name (FQDN) (identifies a device)
sip:subhodeep@192.219.223.160
92
92
SIP Addressing
sip/sips:user:password@host:port;uri-parameters?headers
o User: Identifier of a particular resource at the host being

addressed
o Password: Associated with the user (in a text format), its
use is not recommended
o Host: Provides the SIP resource, contains either a fullyqualified domain name or numeric IPv4 or IPv6 address
o Port: Port number where the request is to be sent
o URI parameters: Parameters affecting a request
constructed from the URI.
Parameters are added after the host port component and are
separated by semi-colons
Parameters take the form:
parameter-name "=" parameter-value
93
93
SIP Addressing
sip/sips:user:password@host:port;uri-parameters?headers
o URI Parameters:
transport: Determines the transport mechanism to be
used for sending SIP messages (i.e. UDP, TCP, TLS,
SCTP)
maddr: Indicates the server address to be contacted for
this user, overriding any address derived from the host
field
ttl: Determines the time-to-live value of the UDP
multicast packet
lr: Indicates that the element responsible for this
resource implements the loose routing mechanisms used in the Record-Route header
94
94
SIP Addressing - Example

sip:+919845202688@airtel.kk.com:5060;user=phone?Subject=SIP
Headers and Body (Subject=SIP)

Parameters (user=phone)
Optional Port (5060)
Hostname (airtel.kk.com)
Username (+919845202688)
Schema (sip)
95
95
ENUM (E.164 Number Mapping)

o Transforms E.164 telephone numbers into Internet
resource addresses (URI)
o Used for SIP, HTTP, SMTP, etc.
o Mapping is performed by DNS lookup
o End users (Applications) can select URI according
to their preference
o Standardization by cooperation of IETF and ITU-T
(RFC 2916)
o Defines how to map E.164 number to DNS NAPTR
resource record
o Designates e164.arpa for ENUM infrastructure in
DNS
o Defines new E2U+sip ENUM service for SIP
96
96
E.164 Domain Name Conversion

o Check if E.164 is complete
E.g. +81-3-5297-25712
o Remove all non-digit except for leading +

+81352972571
This form is remained as AUS (Application Unique String)
for applying regular expression in NAPTR
o Remove leading +
813529725714
o Put dots (.) between each digit.

8.1.3.5.2.9.7.2.5.7.1
o Reverse the order of the digits

1.7.5.2.7.9.2.5.3.1.8
o Append the string .e164.arpato the end

1.7.5.2.7.9.2.5.3.1.8.e164.arpa
97
97
PSTN to VOIP Call Via SIP
DNS-Server
Query
1.3.1.9.5.8.6.8.6.4.e164.arpa.?
Response
sip:ssarkar@wipro.com
Call setup
Dial
+4686859131
SIP
sip:ssarkar@wipro.com
Gateway
SIP Server
98
98
Locating User DNS SRV

o Use a newer record for general-purpose mapping, SRV
(RFC 2782)
o Mapping from service and transport protocol to one or
more service, including protocols
o Take domain name of Request-URI
o Look for SRV records
SRV records specify a list of IP addresses for servers for a
particular service
List includes priority values and preferences for each address
o Try IP addresses in order of preference, go to next if no

response
o If no SRV records present, use A records
A records are standard hostname to IP address records
o Allows administrators to use several servers for a single

domain, to move services from host to host
99
99
Locating User DNS SRV

_Service._Proto.Name
o
o
o
o
o
o
o
o
o
TTL Class SRV Priority Weight Port Target
Service: Symbolic name of the desired service

Proto: Symbolic name of the desired protocol
Name: Domain this RR refers to
TTL: Time interval that the resource record may be cached before
the source of the information should again be consulted
Class: RR CLASS codes. SRV records occur in the IN Class
Priority: Priority of this target host
Weight: Server selection mechanism, specifies a relative weight for
entries with the same priority
Port: Port on this target host of this service
Target: Domain name of the target host
_sip._tcp
_sip._udp
SRV 0 0 5060 sip-server.cs.columbia.edu.

SRV 1 0 5060 backup.ip-provider.net.
SRV 0 0 5060 sip-server.cs.columbia.edu.
SRV 1 0 5060 backup.ip-provider.net.
100
100
SIP Routing Headers

o Request-URI: Current destination, may change along
signaling path
o Contact: Appears in INVITE / OPTIONS / ACK / REGISTER
requests and in responses. It indicates direct response
address to which subsequent transactions are sent.
o Via: Identifies the location where the response is to be sent
o Record-Route: Inserted by proxies in a request to force
future requests in the dialog to be routed through the proxy
o Route: Used to force routing for a request through the listed
set of proxies
101
101
Record-Route
Record-Route =
"Record-Route" HCOLON name-addr *( SEMI rr-param )

*(COMMA name-addr *( SEMI rr-param ) )
o Inserted by proxies in a request to force future requests

in the dialog to be routed through the proxy
o Response containing Record-Route header field value
originally provided by the proxy, may choose to rewrite
the value before forwarding the response - useful for
multi-homed hosts
o Examples of valid Record-Route header fields:
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
Address
Spec
Indicates Loose
Routing
Record-Route: <sip:server10.biloxi.com;lr>
102
102
BYE Message Flow W/WO Record Routing

Without Record Routing
UA1
With Record Routing

UA2
SIP Proxy
BYE
UA1
UA2
SIP Proxy
BYE
BYE
200 OK
200 OK
200 OK
103
103
Route
Route =
"Route" HCOLON name-addr *( SEMI rr-param ) *(COMMA name-addr *( SEMI rr-param ) )
o Used to force routing for a request through the listed set

of proxies
o INVITE request whose response is being acknowledged
had Route header fields, those header fields must
appear in the ACK
o Examples of valid Route header fields:
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
Address
Spec
Indicates Loose
Routing
Route: <sip:server10.biloxi.com;lr>
104
104
SIP Routing - Request

o Send requests to local proxy or host in Request-URI
o Determined by route set which can be learned, through
headers like Record-Route or can be pre-configured
o Two types of SIP Request routing
Strict Routing
Loose Routing
o Proxy will inspect the Request-URI. Proxy will replace it with

the results of running a location service if it indicates this
proxy, otherwise, will not change the Request-URI
o Proxy will inspect the URI in the topmost Route header field
value. Proxy removes it from the Route header field if it
indicates this proxy
o Proxy will forward the request to the resource indicated by
the URI in the topmost Route header field value or in the
Request-URI if no Route header field is present.
105
105
Strict Routing
o Proxy is said to be strict routing if it follows the Route
processing rules of RFC 2543-bis05
o Proxies destroy the contents of the Request-URI when a
Route header field was present
o Strict routing conflates the request target with the next
hop destination
o Brittle system failure if any element misroutes
o Proxies that perform strict routing are also known as
strict routers
B
A
INVITE B
Route C,D
C
INVITE C
Route D
INVITE D
106
106
Loose Routing
o Proxy is said to be loose routing if it follows the
procedures defined in RFC 3261 for processing of the
Route header
o Keep request target (Request-URI) and next route
destination (Route header) separate
o Allow each route destination to determine when it has
been reached
o Add mechanism to provide backwards-compatibility with
strict routing SIP elements through lr parameter
o Proxy compliant to these mechanisms is known as a
loose router
B
A
INVITE D
Route B,C
C
INVITE D
Route C
INVITE D
107
107
Loose Routing - Processing

o If its a strict router, follow old (RFC 2543bis-05)
Route/Record-Route rules
o If the Request-URI of a request matches a URI
previously placed in a Record-Route header field, the
previous element is a strict router. Rewrite the message
before further processing:
Move the last Route header field into the Request-URI
o If a Route header field exists in a message about to

send:
If the top Route header field value matches, remove it
If the new top Route header field value indicates loose route
support, forward the request to it
Otherwise, rewrite the message as follows:
Place Request-URI at the bottom of Route header list
Place the first Route header into the Request-URI
Forward the request based on the Request-URI
108
108
Loose Routing - Example

U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements
o The INVITE arriving at U2 contains

INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
o U2 sends a BYE
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
109
109

o P4 receives
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
o And sends
BYE sip:p3.middle.com SIP/2.0
Route: <sip:caller@u1.example.com>
110
110

o P3 receives
BYE sip:p3.middle.com SIP/2.0
o And sends
BYE sip:p2.example.com;lr
o P2 sees a URI it provided in the Request-URI so it rewrites this to

BYE sip:caller@u1.example.com
o And sends it to P1
111
111

o P1 Receives
o And sends
112
112
SIP Routing - Response

o Response traces back request route without proxy
server state
o Each proxy pre-pends a Via header with own address in
request and removes the address in response
o When proxy receives response
Check if topmost Via is itself

If yes, remove and check next header
Forward to host, port in next Via
If no next Via, response is for the proxy
o TCP: re-use connection if possible, create new one if

needed
o UDP: may send responses to same port as requests
113
113
SIP Routing Response

192.219.223.160
172.16.16.120
Proxy
UAC
Via:192.219.223.160
Via:192.219.223.160
172.16.16.160
Proxy
Via:172.16.16.120
Via:192.219.223.160
Via:172.16.16.120
Via:192.219.223.160
192.219.223.197
UAS
Via:172.16.16.160
Via:172.16.16.120
Via:192.219.223.160
Via:172.16.16.160
Via:172.16.16.120
Via:192.219.223.160
Request
Response
114
114
Forking
o Forking is when proxy sends request to more than one
target at once
o User can register multiple locations for incoming calls
(alternatively, based on static routing configuration)
o Requires stateful proxy for forking
o First 200 OK that is received is forwarded upstream
o All other unanswered requests cancelled
o Allows rapid search for user at many locations
o Two variations
Sequential Search: Try first address, only if that fails try second
address
Parallel Search: Try all addresses at once
115
115
Parallel Forking - Example

Session setup request
forwarded to UAS 1
3
IP Network
486 Busy Here

2
UAS Location
Query
Session setup
Request from
the UAC
UAS1
Location
Server
Location Server

forwarded to UAS 2
UAS2
4
6
Connect to UAS 2
OK to connect
SIP
Proxy
1
SIP Protocol
UAC

forwarded to UAS 3
UAS3
CANCEL setup request
Non-SIP Protocol
(Eg. Database Query)
116
116
Loop
o Request that arrives at a proxy, is forwarded, and later
arrives back at the same proxy
o Looped requests are errors
o SIP provides couple of loop prevention and detection
mechanism
Max-Forwards
Counter decremented by 1 on each hop
Discard request when zero
Via
Every proxy inserts address
Check for my address when request comes
o Loop can be identified

Via Header branch parameter value matches to previous
requests by the proxy
117
117
Spiral
o
o
o
o
o
SIP request that is routed to a proxy, forwarded

onwards, and arrives once again at that proxy
Request's Request-URI differs from its previous arrival
Not an error condition
Typical cause for spiral is Call Forwarding
Example of a valid SIP Spiral:
1.
2.
3.
4.
Foo calls joe@example.com

example.com proxy forwards it to Joe's PC
Joes PC forwards it to bob@example.com
New request is proxied back to the example.com proxy
118
118
Session Description Protocol (SDP)

o Originally for Mbone session advertisements, used for
Mbone tools (sdr), RTSP, H.332
o Caller and callee indicate receive capabilities and
receive address/port
o Convey sufficient information to enable participation in a
multimedia session
o Text messages using the ISO 10646 character set in
UTF-8 encoding
o 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
o SDP is a data format rather than a protocol

119
119
SDP Anatomy
originator
Session ID and version timestamp
originating host
connection information (multicast address)
Conference Total, Max 64kb/s bandwidth
start time (NTP timestamp)
stop time (NTP timestamp)
PCM audio using RTP port 3456

Variable rate DVI4, codeword 1,
speech bit rate 8kb/s
H.261 video using RTP port 3458
whiteboard application on port 32416
whiteboard application is in portrait mode
120
120
Offer-Answer Model
o Mechanism by which two entities can make use of the
SDP to arrive at a common view of a multimedia session
between them
o One participant offers the other a description of the
desired session from their perspective, and the other
participant answers with the desired session from their
perspective
o Most useful in unicast sessions where information from
both participants is needed for the complete view of the
session
o Mandatory baseline mechanism used by the SIP
o Operation begins when one agent sends an initial offer to
another agent
o Agent receiving the offer
Generate an answer
Reject the offer
121
121
Offer-Answer Protocol Operation

o At any time, either agent can generate a new offer that
updates the session
o Must not generate a new offer
If it has received an offer which it has not yet answered or
rejected
If it has generated an offer for which it has not yet received an
answer or a rejection
o Offer will contain zero or more media streams (i.e. "m="

line)
o Zero media streams implies that the offerer wishes to
communicate, but that the streams for the session will be
added at a later time through a modified offer
o The formats in the "m=" line must be listed in order of
preference, with the first format listed being preferred
o Answer must contain exactly the same number of "m="
lines as the offer
122
122
Offer-Answer Protocol Operation

o To reject an offered stream, the port number in the
corresponding stream in the answer must be set to zero
o New media streams are created by
New additional media descriptions below the existing ones, or
Reusing the "slot" used by an old media stream which had been
disabled by setting its port to zero
o Existing media streams are removed by creating a new

SDP with the port number for that stream set to zero
o Media stream can be put "on hold", i.e., request that it
temporarily stops sending one or more unicast media
streams by
Marking a previously a sendrecv media stream as sendonly
Marking a previously a recvonly media stream as inactive
123
123
Offer-Answer Examples
Offered SDP
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
v=0
Answered SDP
o=bob 2890844730 2890844730 IN IP4 host.example.com

s=
c=IN IP4 host.example.com
t=0 0
a=rtpmap:32 MPV/90000
124
124
Reliability of Provisional Responses

o An extension to the SIP providing reliable provisional
response messages
o Uses the option tag 100rel to indicate support
o Uses the Provisional Response ACKnowledgement (PRACK)
method
o Reliable provisional responses are retransmitted by the TU
exponentially
o Retransmissions stops when a PRACK message is received
o Reliability is ensured hop-by-hop through each stateful proxy
o A single outstanding provisional response at a time, for
purposes of congestion control
o UAS send any non-100 provisional response reliably if the
initial request contained a Require header field with the
option tag 100rel
125
125
Reliability of Provisional Responses

SIP UA (A)
SIP Proxy
INVITE (oSDP)
100 Trying
180 Ringing (tSDP)
SIP UA (B)
INVITE (oSDP)
180 Ringing (tSDP)
Backwards Speech Path (audible ringing)
PRACK
200 OK
PRACK
200 OK
o UAS may send any non-100 provisional response to INVITE reliably, so

long as the initial INVITE request contained a Supported header field with
the option tag 100rel
o UAC on receipt of reliable provisional response with an offer, generates
an answer in the PRACK
o UAS on receipt of a PRACK with an offer, generates the answer in the
2xx to the PRACK
126
126
PRACK Method
o UAC to UAS
o Each provisional response is
given a sequence number,
carried in the RSeq header,
contains a single numeric
value from 1 to 2**32 - 1
RSeq: 988789
o Contain an RAck header field,

which indicates the sequence
number of the provisional
response that is being
acknowledged, contains two
numbers and a method tag
RAck : 776656 1 INVITE
o Can optionally contain

session description
PRACK sip:bob@biloxi.com SIP/2.0

Max-Forwards: 70
CSeq: 314159 PRACK
RAck: 83 1 INVITE
Content-Length: 142
v=0
s=session_name_1
SIP
SDP
RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method

RSeq = "RSeq" HCOLON response-num
127
127
UPDATE Methods
o Allows a client to update
parameters of a session
(such as the set of media
streams and their
codecs)
o Target refresh request, it
can update the remote
target of a dialog
o No impact on the state of
a dialog
o Can be sent before the
initial INVITE has been
completed
o Very useful for updating
session parameters
within early dialogs
UPDATE sip:bob@biloxi.com SIP/2.0

Max-Forwards: 70
CSeq: 314159 UPDATE
Content-Length: 142
v=0
s=session_name_1
SIP
SDP
128
128
UPDATE Example Call Flow

o User A sends an initial INVITE (1)
which contains an offer
o User B generates a 180 response (2)
with an answer to that offer
o User A generates a PRACK (3) to
acknowledge the 180
o User B answered the PRACK with a
200 OK (4)
o User A generate an UPDATE request
(5) with a new offer
o User B answered this offer in the 200
response to the UPDATE (6)
o User B generates an UPDATE request
(7) with an offer
o User A answer is sent in the 200
response (8)
o Finally, User B answers the call,
resulting in a 200 OK response to the
INVITE (9)
o User B then sends an ACK (10)
SIP UA (B)
SIP UA (A)
1
INVITE (Offer 1)
180 Ringing (Answer 1)
PRACK
200 OK
UPDATE (Offer 2)
200 OK (Answer 2)
UPDATE (Offer 3)
200 OK (Answer 3)
200 OK
ACK
129
129
SIP Event Notification Framework

o Provide an extensible framework by which SIP nodes can
request notification from remote nodes indicating that certain
events have occurred
o Examples of such services include automatic callback
services (based on terminal state events), buddy lists (based
on user presence events), message waiting indications
(based on mailbox state change events)
o Entities in the network can subscribe to resource or call state
for various resources or calls in the network, and those
entities (or entities acting on their behalf) can send
notifications when those states change
o Defines couple of new METHODs for this purpose:
SUBSCRIBE
NOTIFY
130
130
Event Package
o Defines a set of state information to be reported by a notifier
to a subscriber
o Define further syntax and semantics based on the framework
to convey such state information
o Define parameters for the Event header and their semantics
for such parameters
o Define syntax and semantics for SUBSCRIBE method
bodies
o Define semantics associated with the body of their NOTIFY
requests
131
131
Event Package
o Optionally, define a suggested range of times considered
reasonable for the duration of a subscription
o Optionally, define MIME type is to be assumed for NOTIFY
bodies
o Define processing of SUBSCRIBE and NOTIFY request
o Specify whether forked SUBSCRIBE requests are allowed to
install multiple subscriptions
o Defines an absolute maximum on the rate at which
notifications are allowed to be generated by a single notifier
o Define a throttle mechanism which allows subscribers to limit
the rate of notification
132
132
Event Header
Event = ( "Event" / "o" ) HCOLON event-package *( "." event-template ) *( SEMI "id" EQUAL token )
o Indicates which event or class of events been subscribed

o Contain a token which indicates the type of state for which a subscription
is being requested
o May contain "id" parameter, which identifies the specific subscription
within a dialog
o One event type is allowed per header
o Multiple events per message is disallowed
o Compared byte-by-byte to match NOTIFY messages with SUBSCRIBE
messages
o The "id" parameter token (if present) is also compared byte-by-byte
o "Event" header containing an "id" parameter is not equal to "Event"
header without an "id" parameter
o Compact form of the Event header field is o
o Examples of valid Event header fields:
Event: foo; id=1234
o: foo
133
133
Subscription-State Header
Subscription-State =
"Subscription-State" HCOLON substate-value

*( SEMI ("reason" EQUAL event-reason-value)
/ ("expires" EQUAL delta-seconds) / ("retry-after" EQUAL delta-seconds) )
o Indicate the status of the subscription

o Contain a token which indicates the subscription state for which a subscription is
being requested
Active: Subscription has been accepted and has been authorized
Pending: Subscription has been received by the notifier, but there is insufficient policy
information to grant or deny the subscription yet
Terminated: Subscriber should consider the subscription terminated
o May contain parameters,

Expires: Subscriber should take it as the subscription duration
Retry-After: Client should not attempt re-subscription until after the number of seconds
specified
Reason: Reason for termination of subscription (deactivated, probation, rejected,
timeout, giveup, noresource)
o NOTIFY must contain "Subscription-State" headers

o Examples of valid Subscription-State header fields:
Subscription-State: active
Subscription-State: terminated;reason=timeout
134
134
SUBSCRIBE Methods
o
o
o
o
o
o
o
o
o
Used to request asynchronous

notification of an event or set of events
at a later time
UAC to UAS
Used to request current state and state
updates from a remote node
Should contain an "Expires" header
Dialog creating method, may contain
"Accept" header
Must include exactly one "Event"
header
To keep subscriptions effective beyond
the duration communicated in the
"Expires" header, subscribers need to
refresh subscriptions on a periodic
basis using a new request on the same
dialog
To terminate subscription, refresh, with
the "Expires" header set to "0".
Can optionally contain body, defined by
the event packages
SUBSCRIBE sip:bob@biloxi.com SIP/2.0

Max-Forwards: 70
CSeq: 314159 SUBSCRIBE
Event: message-summary
Expires: 0
Content-Length: 0
135
135
NOTIFY Methods
o
o
o
o
o
o
o
Used to notify a SIP node that an event

which has been requested by an earlier
SUBSCRIBE method has occurred
May also provide further details about
the event
UAC to UAS
To inform subscribers of changes in
state to which the subscriber has a
subscription
Must include exactly one "Event"
header
Must contain "Subscription-State"
header
NOTIFY are matched to such
SUBSCRIBE if they contain the same
"Call-ID", a "To" header "tag" parameter
which matches the "From" header "tag"
parameter of the SUBSCRIBE, and the
same "Event" header
Contain body defined by the event
packages
NOTIFY sip:bob@biloxi.com SIP/2.0

Max-Forwards: 70
CSeq: 314159 NOTIFY
Content-Type: application/simple-message-summary
Content-Length: 99
Message-Account: sip:alice@vmail.example.com
Voice-Message: 4/8 (1/2)
SIP
MWT
136
136
SIP Event Notification Sample Message Flow

UAC
1
UAS
SUBSCRIBE (Event: Zxx, Expires:3600)

200 OK
NOTIFY (Subscription-State: Active)
Terminate
Subscription
200 OK
200 OK
Zxx Event
Occurred
Zxx Event
Occurred
200 OK
SUBSCRIBE (Event: Zxx, Expires:0)
200 OK
10
NOTIFY (Subscription-State: Terminated) 11

12
200 OK
137
137
SIP & SECURITY
138
138
Contents
o
o
o
o
o
o
o
o
o
o
o
o
Security Concerns
Security Framework
Security SIP Signalling
Transport Layer Security (TLS)
HTTP Digest Authentication
Secured MIME (S/MIME)
Security Real-Time Media
Secure RTP (SRTP)
NAT And SIP
RTP Relay (TURN)
DIAMETER Base Protocol
AAA SIP Architecture Components
139
139
Security Concerns
o Registration Hijacking
Registration hijacking occurs when an attacker impersonates a valid UA
to a registrar and replaces the legitimate registration with its own
address. This attack causes all incoming calls to be sent to the UA
registered by the attacker.
o Server Impersonation
A UA contacts a Proxy server to deliver requests. The server could be
impersonated by an attacker
o Message Tampering
Occurs when an attacker intercepts and modifies packets exchanged
between SIP components. Can occur through registration hijacking,
proxy impersonation, or an attack on any component trusted to process
SIP messages, such as proxy, media gateway, or firewall
o Session Tear Down

When an attacker observes the signaling for a call, and then sends
spoofed SIP BYE messages to the participating UAs, tearing down the
call
o Denial of Service (DoS) Attacks

DoS attacks focus on rendering a particular network element
unavailable, usually by directing an excessive amount of network traffic
at its interfaces
140
140
Security Framework
Authentication
Means of identifying another entity. There are many ways to

authenticate another entity, but the typical computer based methods
involve user ID/password or digitally signing a set of bytes using a
keyed hash
Confidentiality
Cryptographic confidentiality means that only the intended recipients

will be able to determine the contents of the confidential area
Integrity
A message integrity check is means of insuring that a message in

transit was not altered
Authorization
Once identification of a correspondent is achieved, a decision must

be made as to whether that identity should be granted access for the
requested services. This is the act of authorization. This is often done
using access control lists (ACL)
Privacy
They want to make sure others do not know what they are doing or
transmitting. Some people prefer anonymity. In a higher education
environment, faculty and student reserve the right to privacy
Administration
Billing and accounting, maintenance of Call Data Records (CDRs)
141
141
Security SIP Signaling

Confidentiality
Integrity
Authentication
Authentication Methods:
PSK Pre-Shared Keys
PKI Public Key Infrastructure
HTTP 1.0 Basic Authentication
PSK
Deprecated by SIP 2.0

Insecure transmission of password
HTTP 1.1 Digest Authentication
PSK
Challenge/response exchange based

on MD5 hash of [strong] password
Pretty Good Privacy (PGP)
PKI
Deprecated by SIP 2.0
Secure MIME (S/MIME)
PKI
For encryption the public key of the

recipient user agent must be known
SIPS URI (TLS)
PKI
SIP application and proxies must

tightly integrate TLS
IP Security (IPSec)
PKI
Integration with SIP application not

required but proxies must be trusted
142
142
Transport Layer Security (TLS)

o Primary goal is to provide privacy and data integrity between
two communicating applications
o Composed of two layers
TLS Record Protocol provides connection security that has two
basic properties
Connection is private - symmetric cryptography is used for data
encryption
Connection is reliable - includes message integrity check using a keyed
MAC
TLS Handshake Protocol allows the server and client to

authenticate each other and to negotiate an encryption algorithm and
cryptographic keys. Provides connection security that has three
basic properties
Peer's identity can be authenticated using asymmetric or public key
cryptography (e.g. RSA, DSS)
Negotiation of a shared secret is secure
Negotiation is reliable
143
143
TLS And SIP

o All SIP elements that support TLS must also support the
Secure SIP URI scheme - Specified with a Universal
Resource Indicator (URI) that begins with sips:.
o All SIP elements that support TLS
Must have a mechanism for validating certificates received during
TLS negotiation
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite be supported at
a minimum
o TLS only allows SIP entities to authenticate servers to which

they are adjacent
o TLS requires the use of TCP as a transport protocol and
necessitates a public key infrastructure
o Drawbacks
TLS offers strictly hop-by-hop security between UAs/proxies or
between proxies since each hop adds route information
Key distribution makes mutual authentication impractical (so far)
144
144
TLS And SIP Sample Call Flow

New TCP connection #1: a.example.com(5071) <-> b.example.com(5081)
1 1 0.0015 (0.0015) C>SV3.1(49) Handshake
ClientHello
Version 3.1
random[32]= 3f 1d 41 76 31 6f af f1 42 fa 7b 57 c7 79 49 2b d4 21 9c be e9 8b 85 83 56 4b 36 cb f2 99 ef b2
cipher suites
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
compression methods
NULL
1 2 0.4307 (0.4292) S>CV3.1(74) Handshake
ServerHello
Version 3.1
random[32]= 3f 1d 41 77 92 f5 55 a3 97 69 cf b5 7a 0a 3c 00 bc 0c 59 91 1c 6b 2b 4a 0e 98 40 21 a9 b5 4b 6f
session_id[32]= 10 3c 8c aa 75 d8 62 0b c3 5b ad 24 c1 7f 4f 80 25 b7 1c 40 a3 3c e1 85 0d b5 29 d3 15 40 51 d3
cipherSuite
compressionMethod
NULL
1 3 0.4307 (0.0000) S>CV3.1(822) Handshake
Certificate
Subject
C=US
ST=California
L=San Jose
O=sipit
CN=b.example.com
145
145
TLS And SIP Sample Call Flow

Issuer
C=US
ST=California
L=San Jose
O=sipit
OU=Sipit Test Certificate Authority
Serial
01
Extensions
Extension: X509v3 Subject Alternative Name
Extension: X509v3 Basic Constraints
Extension: X509v3 Subject Key Identifier
Extension: X509v3 Authority Key Identifier
1 4 0.4307 (0.0000) S>CV3.1(4) Handshake
ServerHelloDone
1 5 0.4594 (0.0286) C>SV3.1(134) Handshake
ClientKeyExchange
1 6 0.5498 (0.0903) C>SV3.1(1) ChangeCipherSpec
1 7 0.5498 (0.0000) C>SV3.1(48) Handshake
1 8 0.5505 (0.0007) S>CV3.1(1) ChangeCipherSpec
1 9 0.5505 (0.0000) S>CV3.1(48) Handshake
Once the TLS session is set up, the normal call setup will continue from
a.example.com to b.example.com, with the URI has a SIPS URL and that
the Via indicates that TLS was used
146
146
HTTP Digest Authentication

o Provides a simple challenge-response authentication mechanism (using
a nonce value ) used by a server to challenge a client request (at least
one challenge applicable to the requested resource) and by a client to
provide authentication information
401 (Unauthorized) response message is used by an origin server to
challenge the authorization of a user agent, include a WWW-Authenticate
header field
407 (Proxy Authentication Required) response message is used by a proxy to
challenge the authorization of a client, include a Proxy- Authenticate header
field
o Transmits an MD5 or SHA-1 digest of both the secret password and a

random challenge string (i.e., nonce value) in place of the vulnerable
password in clear text
o Valid response contains a checksum of the username, the password, the
given nonce value, the HTTP method, and the requested URI
o Drawbacks
Authenticating a request to more than one element is problematic
Leaks hash to elements in the path
Only good for authenticating to the first hop
147
147
Digest Authentication And SIP

Initial INVITE
Proxy Challenge
INVITE sip:bob@biloxi.example.com SIP/2.0

1
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74b43
Max-Forwards: 70
Route: <sip:ss1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Content-Length: 0
SIP/2.0 407 Proxy Authorization Required

2
Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74b43
To: Bob <sip:bob@biloxi.example.com>;tag=3flal12sf
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="atlanta.example.com",
qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
Content-Length: 0
Authenticated INVITE
INVITE sip:bob@biloxi.example.com SIP/2.0
3
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <sip:ss1.atlanta.example.com;lr>
To: Bob <sip:bob@biloxi.example.com>
CSeq: 2 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Proxy-Authorization: Digest username="alice",
realm="atlanta.example.com",nonce="wf84f1ceczx41ae6cbe5aea9c8e88d359",opaque="",uri="sip:bob@biloxi.example.com",
response="42ce3cef44b22f50c6a6071bc8"
Content-Length: 0
148
148
Secured MIME (S/MIME)

o Provides end-to-end integrity protection and encryption of the body
and parts of the message header
o MIME standard includes mechanisms for securing MIME contents to
ensure both integrity and confidentiality (including the
'multipart/signed' and 'application/pkcs7-mime' MIME types)
o S/MIME certificates are used to identify an end-user - associated
with keys that are used to sign or encrypt bodies of SIP messages
o Bodies are signed with the private key of the sender, but bodies are
encrypted with the public key of the intended recipient
o S/MIME implementations at a minimum support SHA1 as a digital
signature algorithm, and 3DES as an encryption algorithm
o Each S/MIME body in a SIP message should be signed with only
one certificate
o For integrity or confidentiality for SIP header fields, S/MIME can
encapsulate entire SIP messages within MIME bodies of type
"message/sip
o Drawbacks
Key distribution makes mutual authentication impractical
149
149
S/MIME And SIP

Encrypted and Signed using S/MIME
INVITE sip:bob@zhwin.ch SIP/2.0
Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904
To: Bob <sip:bob@zhwin.ch>
From: Alice <sip:alice@zhwin.ch>;tag=daa21162
Call-ID: 392c3f2b568e92a8eb37d448886edd1a@160.85.170.139
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@dskt6816.zhwin.ch:5060>
Content-Type: multipart/signed;boundary=992d915fef419824;micalg=sha1;protocol=application/pkcs7-signature
Content-Length: 3088
--992d915fef419824
Content-Type: application/pkcs7-mime;smime-type=envelopeddata; name=smime.p7m
Content-Disposition: attachment;handling=required;filename=smime.p7m
Content-Transfer-Encoding: binary
<envelopedData object encapsulating encrypted SDP attachment not shown>
--992d915fef419824
Content-Type: application/pkcs7-signature;name=smime.p7s
Content-Disposition: attachment;handling=required;filename=smime.p7s
Content-Transfer-Encoding: binary
<signedData object containing signature not shown>
--992d915fef419824--
150
150
Security Real-Time Media

Confidentiality
Integrity
Authentication
Authentication Methods:
PSK Pre-Shared Keys
PKI Public Key Infrastructure
Secure RTP (SRTP)
PSK
Uses master key which must be

distributed by other means
IP Security (IPsec)
PKI
Integration with SIP application not

required but peer must be trusted
151
151
Security RTP (SRTP)

o An extension to the RTP Audio/Video profile
o Provides confidentiality, message authentication, and
replay protection to the RTP and RTCP traffic
o Encrypts individual media packets using a symmetric
session key
o Session key must be securely exchanged - Current
recommendation is to use S/MIME in the signaling
INVITE sip:bob@zhwin.ch SIP/2.0
Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904
To: Bob <sip:bob@zhwin.ch>
From: Alice <sip:alice@zhwin.ch>;tag=daa21162
Call-ID: 392c3f2b568e92a8eb37d448886edd1a@160.85.170.139
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@dskt6816.zhwin.ch:5060>
Content-Length: 239
v=0
c=IN IP4 160.85.170.139
k=clear:910bc4defa71eb6190008762fca6ae2f1d959e87cdf3c0c5c5076ad38ee8
152
152
SIP Enabled FIREWALL/NAT

o Part of Private and Enterprise IP network security policy
o Simplifies management
o Single point of control for policy enforcement and
administration
o No need for every SIP Endpoint in network to be
configured with security policies
o Help to preserve public IP Addresses
o Firewall/NAT logically coexist in single node
o Intelligent enough to understand the importance of ports
in SIP calls
153
153
Network Address Translation (NAT)

o Convert Network Address (and Port) between private and
public realm
o Creates address binding between internal private and
external public address
o Binding is valid for some predefined time (typically < 1
minutes) after which, in the absence of network traffic
between the two communicating parties, mapping may be
removed
o Modifies IP Addresses/Ports in packets
o Short-term solution to IP depletion issues
o Transparent to Application
o Works in Layer 3 (i.e. Network Layer)
o Four types
Full Cone
Restricted Cone
Port Restricted Cone
Symmetric
154
154
Types of NAT
o Full Cone
Once the mapping is established and anyone from the public
Internet that wants to reach a client behind a NAT, needs only to
know the mapping scheme in order to send packets to it
o Restricted Cone
External IP:port pair is only opened up once the internal network
entity sends out data to a specific destination IP
o Port Restricted Cone

Almost identical to a restricted cone, but in this case the NAT will
block all packets unless the client had previously sent out a
packet to the IP and port that is sending to the NAT
o Symmetric
A specific mapping of internal IP:port to the NATs public IP:port
is dependant on the destination IP address that the packet is
sent to
155
155
SIP NAT Traversal Reference Model
Public
Private
Private
SIP Proxy
RTP/RTCP Media
Firewall/NAT
Firewall/NAT
Media
Signaling
156
156
SIP Outbound NAT Traversal

o SIP signaling traverse NATs in a straightforward way,
since there is typically one proxy, the first hop away from
NAT, that receives messages from the client (through the
NAT) and then returns messages to the same place
o SIP over UDP is not NAT friendly
Uses port number from Via header
Proxy needs to return packets on the same port it received them
to the IP:port that the packets were sent from
o SIP has tags that tell the proxy where to return to (i.e.
SIP Responses)
received tag keeps the specific IP
rport tag keeps the port
157
157

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;received=202.123.211.25;rport=12345
Max-Forwards: 70
From: Alice <sip:alice@atlanta.com>
CSeq: 314159 INVITE
Content-Length: 142
v=0
s=session_name_1
Signalling
Actual IP
Address and
port it received
from
Media
Internal IP
Address and
port it sent from
158
158

o SIP over TCP is NAT friendly
TCP is inherently bidirectional, uses common local
transmit and receive ports - when a TCP connection
is established from host A with source TCP port "a" to
a remote host, the remote host sends packets back to
host A's source TCP port "a"
Endpoints behind a NAT/Firewall nail up a TCP or
TLS connection to a server in the public Internet
TCP connection is opened through the NAT directly
from client to proxy
Send response to existing connection on which
request was received
Keep persistent connection to minimize setup delay
159
159
SIP Inbound Traversal

o Proxy to UAS routing is through registrations
Registration has Contact header containing address to send to
which is not NAT friendly
o Registrar that can save the IP:port in the registration

information based on the port and IP that it sees as the
source of the SIP message
o UA that is aware of its external mapped IP:port and can
insert them into the Contact information as the IP:port to
receive SIP messages
o Registration sent over TCP connection to proxy, so same
connection is used for incoming INVITEs
o Registration interval needs to be shorter than the keep alive
time for the NAT binding to persists
160
160
RTP Traversal
o The RTP that must traverse a NAT does not allow as
easy a solution as the signaling
o The message body (SDP) contains the information of the
RTP details that the endpoints need in order to
communicate directly with each other
o Client sitting behind a NAT knows only its internal
IP:port, and that is what it puts in the SDP body of the
outgoing SIP message
o When the destination endpoint wants to start sending
packets to the originating endpoint, it will use the
received SDP information containing the internal IP:port
of the originating endpoint and the packets never get
there
161
161
RTP Traversal Solutions

o Universal Plug and Play (UPnP)
Client queries the NAT via UPnP asking what mapping it should
use if it wants to receive on port x
NAT responds with the IP:port pair that someone on the public
Internet should use to reach the client on that port
One problem is that it will not work in the case of cascading
NATs
o External Query
Client to determine its external IP:port is to ask a server sitting
outside the NAT on the public Internet how it sees the source of
a packet coming from this client
o Simple Traversal of UDP Through NAT (STUN)

Allows Client to Discover Presence of NAT
Allows Client to Discover Type of NAT
162
162
RTP Traversal RTP Relay (TURN)

NAT Proxy
NAT
4
8
9
10
User
Agent
12
Voice Gateway
12
RTP Relay
o RTP Relay (TURN - Traversal Using Relay NAT) acts as the second
endpoint to each of the actual endpoints that are attempting to
communicate with each other
o A server in the middle of the SIP flow that would manipulate the SDP in
such a way as to instruct the endpoints to send RTP to the Relay instead
of directly to each other
o RTP Relay set up its own internal mapping of a session, noting the source
IP:port of each endpoint sending it RTP packets
o Uses that mapping to forward the RTP from endpoint to endpoint
163
163
RTP Relay - Considerations

o Client will always need to send and receive RTP on the
same port
o Increase overall voice latency
o Introduce another point of failure
o Incur additional costs to providers
o Calling party is behind a NAT cannot establish RTP
connection until 200 OK introduces additional clipping Can be solved through early media
o Client will not hear any voice until the first packet is sent
to the RTP Relay - cause problems when the gateway
opens a backward one-way media stream and passes
network announcements over that stream
164
164
RTP Traversal Interactive Connectivity Establishment

o Recommended method for traversal of NAT
o Methodology for using existing technologies such as
STUN, TURN and any other UNSAF compliant protocol to
provide a unified solution
o Achieved by obtaining as many representative IP
address/port combinations as possible using technologies
such as STUN/TURN etc
o Accumulated addresses, are all included in the SDP
exchange in a new media attribute called 'candidate' which
includes
Media Addresses (including optional RTCP information)

Priority
Username/Password
Unique Session ID
o Client will undertake connectivity checks on all addresses

being advertised using ICE to ensure successful media
exchange
165
165
DIAMETER Base Protocol

o Provide an Authentication, Authorization and
Accounting (AAA) framework for applications such
as network access or IP mobility
o Work in both local Authentication, Authorization &
Accounting and roaming situations
o Uses TCP, SCTP to provide reliable exchange of
messages
o Supports application-layer acknowledgements,
failover, capability negotiation, peer discovery, error
notification, handling of user sessions or accounting
166
166
DIAMETER Based SIP Architecture

Diameter Server
SIP
Client
E
M
A
DI
DIA
ME
T
R
TE
ER
SIP
Client
SIP
SIP
SIP
SIP Server
IP Network
DIA
ME
T
ER
SIP Server
TE
E
M
A
I
D
Diameter
Subscriber Locator
167
167
SIP Server User Authentication

SIP
Server 1
SIP
Terminal
REGISTER
2
Diameter
Server
UAR
UAA
REGISTER
Successfully
authenticates the user
REGISTER
MAR
MAA
401 Unauthorized
10
12
UAR
UAA
REGISTER
Successfully
Successfully
11
14
200 OK
Includes challenge in the

response which is map to
WWW-Authenticate
401 Unauthorized
SIP
Server 2
MAR
MAA
200 OK
13
15
16
168
168
SIP Server Requests Authorization

SIP
Server
SIP
Terminal
INVITE
2
407 Proxy
Authentication
Required
5
MAR
MAA
SIP
Server
MAR
MAA
Includes challenge in the

response which is map to
WWW-Authenticate
INVITE
200 OK
Diameter
Server
Successfully
7
INVITE
200 OK
16
169
169
SIP & QoS
170
170
Contents
o
o
o
o
o
o
o
IP QoS Model
SIP & QoS
SIP Precondition
Common Open Policy Service (COPS)
COPS Based QoS SIP Architecture
QoS SIP Architecture Components
Q-SIP Call Flows
171
171
IP QoS Model
o Integrated Services (IntServ)
Signaling mechanism and admission control framework
Add policy control on top of the signaling and admission control
framework
Strictly based on the use of RSVP
o Differentiated Services (DiffServ)

Long-term agreements between customer and network provider
Extension to COPS to support the provisioning of resources within
network elements
172
172
SIP & QoS

o SIP doesnt provide Quality of Service (QoS)
support
o QoS is coupled with SIP through the notion of
preconditions
Objective is to ensure that resources are made
available before the phone rings
SIP extended method (UPDATE) indicates the success
or failure of the preconditions
o Common Open Policy Service (COPS) Protocol

Based QoS model
To eliminate the need for a specific QoS protocol in the
terminals
All the QoS-related functions can be moved from the terminal to
local SIP proxy servers
173
173
SIP Precondition
o A set of constraints about the session which are
introduced in the offer
o Preconditions require that the participant reserve network
resources before continuing with the session
o Preconditions are carried with SDP and treated as state
variables
o The offer/answer model is used
o SIP end users are not advised until preconditions are met
(resources are reserved)
o Known through a local event (such as a confirmation of a
resource reservation), or through a new offer sent by the
caller
o Preconditions are met when precondition-type/statustype a particular stream is equal to (or better than) the
desired status for that stream
174
174
SIP Precondition SDP Extensions

current-status = "a=curr:" qos SP ("e2e" | "local" | "remote") SP ("none" | "send" | "recv" | "sendrecv")
desired-status = "a=des:" qos SP strength-tag SP ("e2e" | "local" | "remote") SP ("none" | "send" | "recv" | "sendrecv")
confirm-status = "a=conf:" qos SP ("e2e" | "local" | "remote") SP ("none" | "send" | "recv" | "sendrecv")
strength-tag = ("mandatory" | "optional" | "none" = | "failure" | "unknown")
o Current status: Carries the current status of network

resources for a particular media stream
o Desired status: Carries the preconditions for a
particular media stream
o Confirmation status: Carries threshold conditions for a
media stream
o Precondition type: Quality of Service
o Strength tag: Indicates whether or not the callee can be
alerted, in case the network fails to meet the
preconditions
175
175
SIP Precondition SDP Extensions

current-status = "a=curr:" qos SP ("e2e" | "local" | "remote") SP ("none" | "send" | "recv" | "sendrecv")
desired-status = "a=des:" qos SP strength-tag SP ("e2e" | "local" | "remote") SP ("none" | "send" | "recv" | "sendrecv")
confirm-status = "a=conf:" qos SP ("e2e" | "local" | "remote") SP ("none" | "send" | "recv" | "sendrecv")
strength-tag = ("mandatory" | "optional" | "none" = | "failure" | "unknown")
o Status type: Define two types of status:

End-to-end : Reflects the status of the end-to-end reservation of
resources
Corresponds to the tag "e2e
Useful when end-to-end resource reservation mechanisms are
available
Segmented : Reflects the status of the access network

reservations of both user agents
Corresponds to the tag "local" and "remote
Useful when one or both UAs perform resource reservations on their
respective access networks
o Direction tag: Indicates the direction in which a

particular attribute (current, desired or confirmation
status) is applicable to
176
176
SIP Precondition End-To-End

SDP1: A includes end-to-end quality of service
preconditions in the initial offer.
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
SDP2: B uses RSVP, it can know when

resources in its "send" direction are available,
because it will receive RESV messages from the
network. However, it does not know the status of
the reservations in the other direction. B requests
confirmation for resource reservations in its
"recv" direction to the peer user agent A in its
answer.
c=IN IP4 192.0.2.4 a=curr:qos e2e none
a=conf:qos e2e recv
After having sent the answer, B starts reserving

network resources for the media stream. When A
receives this answer (2), it starts performing
resource reservation as well. Both UAs use
RSVP, so A sends PATH messages towards B
and B sends PATH messages towards A.
INVITE (SDP1)
183 Session Progress (SDP2)

3
RSVP setup
A to B
SIP UA (B)
SIP UA (A)
R
E
S
E
R
V
A
T
I
O
N
PRACK
PATH
RESV
RSV-CONF
200 OK
PATH
RESV
RSV-CONF
UPDATE (SDP3)
200 OK (SDP4)
180 Ringing
PRACK
200 OK
200 OK
11
R
E
S
E
R
V
A
T
I
O
N
RSVP setup
B to A
9
10
ACK
177
177
SIP Precondition End-To-End

c=IN IP4 192.0.2.1
a=curr:qos e2e send
At this point in time, session establishment

resumes and B returns a 180 (Ringing) response
(7).
INVITE (SDP1)
183 Session Progress (SDP2)

3
SDP4: B responds with an answer (6) which

contains the current status of the resource
reservation (i.e., sendrecv):
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
SIP UA (B)
SIP UA (A)
R
E
S
E
R
V
A
T
I
O
N
PRACK
PATH
RESV
RSV-CONF
200 OK
PATH
RESV
RSV-CONF
UPDATE (SDP3)
200 OK (SDP4)
180 Ringing
PRACK
200 OK
200 OK
11
R
E
S
E
R
V
A
T
I
O
N
RSVP setup
B to A
As time passes, B receives RESV messages

confirming the reservation. However, B waits until
resources in the other direction are reserved as
well, since it did not receive any confirmation and
the preconditions still have not been met.
SDP3: When A receives RESV messages, it
sends an updated offer (5) to B:
RSVP setup
A to B
9
10
ACK
178
178
SIP Precondition Segmented

o
SDP1: A includes local and remote QoS

preconditions in the initial offer. Before sending
the initial offer, A reserves resources in its access
network. This is indicated in the local current
status of the SDP below:
c=IN IP4 192.0.2.1
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
SIP UA (B)
SIP UA (A)
R
E
S
E
R
V
A
T
I
O
N
1
INVITE (SDP1)
SDP2: B reserves resources in its access

network and, since all the preconditions are met,
returns an answer in a 180 (Ringing) response
(3).
c=IN IP4 192.0.2.4
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
180 Ringing (SDP2)

3
PRACK
200 OK
200 OK
ACK
R
E
S
E
R
V
A
T
I
O
N
2
4
5
179
179
DiffServ Based Solution

o Precondition approach poses too much processing load
on user agents
Cleints must handle QoS and session establishment
functionalities
Issue, especially when they are implemented in lightweight
portable terminals and have limited power
o Proposal where the terminals are not aware at all about

QoS provisioning functions
o QoS architecture used is DiffServ, combined with a
dynamic resource allocation mechanism by means of the
COPS protocol
180
180
Common Open Policy Service (COPS)

o A simple query-response protocol that allows policy
servers (Policy Decision Points - PDPs) to communicate
policy decisions to network devices (Policy Enforcement
Points - PEPs)
o To support policy control in an IP QoS environment
o Uses TCP to provide reliable exchange of messages
o Provides the means
To establish and maintain a dialogue between the client and the
server
To identify the requests
181
181
COPS Provisioning Model
Notifications
Bandwidth Broker
( Policy Decision Point)
Events
Configuration
Commands
Edge Router
(Policy Enforcement Point)
o Trigger events, notifications, and configuration commands

are asynchronous
o More scalable
o Not flexible - difficult to handle modification of
configurations
o Not explicitly customized to handle dynamic DiffServ QoS
182
182
COPS Outsourcing Model
Trigger
Events (1)
Bandwidth Broker
( Policy Decision Point)
Query (2)
Response (3)
Edge Router
(Policy Enforcement Point)
o Trigger events generates queries and responses

o Interface between QoS client and provider
QoS client
Sends QoS reservation requests to the provider
QoS provider
Accepting or rejecting the request
Only outsourcing
183
183
COPS Based QoS SIP Architecture

Bandwidth Broker
PDP
PDP
SIP
Client
Client Network
PS
O
C
PEP
PS
O
C
QoS-Enabled
Network
Access Edge Router
PDP
PEP
Client Network
Access Edge Router
SIP
Client
CO
PS
SIP
SIP
Q-SIP
Q-SIP Server
Q-SIP Server
184
184
QoS SIP Architecture

o QoS reservation modes
Unidirectional Reservations
Caller-side Q-SIP Server makes reservation for the caller-tocalled traffic flow, while the Called-side Q-SIP server reserves
resources for the called-to-caller flow
Bidirectional Reservations
The caller-side Q-SIP Server performs resource reservation for
both directions
o QoS models
QoS-Assured
Session should not be established if resources are not
available, i.e. QoS should be setup before alerting the user
QoS-Enabled
Session is established regardless of the availability of QoS
resources, eventually the user may be signaled about the
presence of QoS
185
185
Q-SIP Call Flow - Unidirectional

Q-SIP
Server
SIP
Terminal
Edge
Router
INVITE
Edge
Router
Q-SIP
Server
INVITE
INVITE
180 Ringing
180 Ringing
180 Ringing
COPS REQ
11
COPS REQ
COPS DEC
200 OK INVITE
SIP
Terminal
200 OK INVITE 7
8
COPS DEC
10
12
200 OK INVITE 13
14
ACK
15
ACK
16
ACK
186
186
Q-SIP Call Flow - Bidirectional

Q-SIP
Server
SIP
Terminal
Edge
Router
INVITE
Edge
Router
Q-SIP
Server
INVITE
INVITE
180 Ringing
180 Ringing
6
200 OK INVITE
9
COPS REQ
COPS DEC
SIP
Terminal
180 Ringing
200 OK INVITE 7
8
10
200 OK INVITE 11
12
ACK
13
ACK
14
ACK
187
187
SIP & PSTN
188
188
Contents
o
o
o
o
o
o
o
o
o
o
o
SIP For Telephony (SIP-T)

MIME Types
SIP Profiles
ISUP-SIP Mapping
TEL URI
P-Asserted-Identity
Privacy
Number Portability
Early Media
INFO Method
Overlap Signalling
189
189
SIP For Telephony (SIP-T)

o A set of mechanisms for interfacing traditional telephone
signaling with SIP
o Provide protocol translation and feature transparency
across points of PSTN-SIP interconnection
o SIP to be used for call setup between SS7 based public
switched telephone networks (PSTN) and SIP based IP
telephony networks
o Carries ISUP message payload in the body of a SIP
message (SIP Bridging)
o Map ISUP message contents to fields in the SIP header
for inter-working with pure SIP agents
o SIP header carries translated ISUP routing information
o Specifies the use of the SIP INFO method for effecting incall ISUP signaling in IP networks
190
190
SCP
SSP
DLC
STP
PSTN
PSTN GW
PBX
3rd Party
Applications
SIP/SIP-T
Location
Server
DNS
Application
Server
OSA
Gateway
SIP Network
CMTS
SIP/SIP ISC
EBP
CMS/GC
SIP
User
Agents
Application
Servers
SIP/SIP-T
SIP/SIP ISC
CSCF
HSS
PacketCable Network
MTA
MTA
MGCF
PCF
IM Subsystem
WiFi/
WiMax
VDSL
FTTH
CDMA/
GSM/UMTS
191
191
SIP-T Call (SIP Bridging)

Switch A
1
MGC B
MGC A
IAM
2
INVITE (IAM, oSDP)
ACM
180 Ring. (ACM, tSDP)

7
IAM
100 Trying
Switch B
ACM
ANM
REL
12
ANM
200 OK (ANM)
10
11
ACK
Two way Speech Path
REL
17
RLC
BYE (REL)
14
16
200 OK
13
15
RLC
192
192
SIP-T Call (PSTN to SIP UA)

Switch A
1
SIP Proxy
MGC A
IAM
2
INVITE (oSDP)
100 Trying
180 Ringing
ACM
INVITE (oSDP)
180 Ringing
200 OK (tSDP)
Backwards Speech Path

(audible ringing)
ANM
SIP UA
10
12
200 OK (tSDP)
ACK
9
11
ACK
Two way Speech Path
REL
17
RLC
BYE
15
16
200 OK
BYE
13
14
18
200 OK
193
193
SIP-T Call (SIP UA to PSTN)

SIP UA
1
MGC A
SIP Proxy
INVITE (oSDP)
100 Trying
180 Ringing (tSDP)
INVITE (oSDP)
100 Trying
3
4
180 Ringing (tSDP)
Switch A
IAM
ACM
ANM
REL
13
11
200 OK
ACK
200 OK
10
12
ACK
Two way Speech Path
16
BYE
200 OK
BYE
15
18
200 OK
14
17
RLC
194
194
Multipurpose Internet Mail Extensions (MIME) Types

o Defines a message representation protocol specifying
considerable detail about US-ASCII message headers,
and leaves the message content, or message body, as flat
US-ASCII text
o Defines new MIME types for ISUP and QSIG objects
within a SIP message
ISUP : application/ISUP
QSIG : application/QSIG
o ISUP and QSIG messages are composed of arbitrary

binary data that is transparent to SIP processing
o Binary encoding is used
195
195
MIME Types ISUP

o Media type defined :
Media type name: application
Media subtype name: ISUP
Required parameters: version
Optional parameters: base
Encoding scheme: binary
o ISUP message is encapsulated beginning with the

Message Type Code (i.e., omitting Routing Label and
Circuit ID Code)
o Two parameters are defined :
version : Allows network administrators to identify specific
versions of ISUP that will be exchanged on a bilateral basis
base : Optionally be included in some cases to specify that the
encapsulated ISUP can also be processed using the identified
'base' specification
196
196
MIME Types ISUP

ISUP Base Values
Base
Protocol
itu-t88
ITU-T Q.761-4 (1988)
itu-t92
ITU-T Q.761-4 (1992)
ansi88
ANSI T1.113-1988
ansi00
ANSI T1.113-2000
etsi121
ETS 300 121
etsi356
ETS 300 356
INVITE sip:13039263142@Den1.level3.com SIP/2.0

Via: SIP/2.0/UDP den3.level3.com
From: sip:13034513355@den3.level3.com
To: sip:13039263142@Den1.level3.com
Call-ID: DEN1231999021712095500999@Den1.level3.com
CSeq: 8348 INVITE
Contact: <sip:jpeterson@level3.com>
Content-Length: 436
Content-Type: multipart/mixed; boundary=unique-boundary-1
MIME-Version: 1.0
--unique-boundary-1
Content-Type: application/SDP; charset=ISO-10646
v=0
o=jpeterson 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP seminar
c=IN IP4 MG122.level3.com
t= 2873397496 2873404696
m=audio 9092 RTP/AVP 0 3 4
--unique-boundary-1
Content-Type: application/ISUP; version=nxv3;base=etsi121
Content-Disposition: signal; handling=optional
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
--unique-boundary-1--
Content-Type: application/ISUP; version=nxv3; base=etsi121

Base (etsi121)
Optional Version (X-NetxProprietaryISUPv3)
MIME Type (application/ISUP)
SIP Header (Content-Type)
197
197
Content-Type Header
Content-Type
media-type
= ( "Content-Type" / "c" ) HCOLON media-type

= "text" / "image" / "audio" / "video" / "application" /
"message" / "multipart" SLASH m-subtype *(SEMI m-parameter)
o Indicates the media type of the message-body sent to the

recipient
o Must be present if the body is not empty
o If the body is empty, and header field is present, it
indicates that the body of the specific type has zero length
o Compact form of the header field is c
o Examples of valid Content-Type header fields:
c: application/ISUP; version=nxv3; base=etsi121
198
198
Content-Disposition Header
Content-Disposition
disp-type
disp-param
= "Content-Disposition" HCOLON disp-type *( SEMI disp-param )

= "render" / "session" / "icon" / "alert" / signal / disp-extension-token
= "handling" EQUAL ( "optional" / "required" / other-handling )
o Describes how the message body or, for multipart

messages, a message body part is to be interpreted by
the UAC or UAS
o Consists of disposition-types to indicate the interpretation
o Consists of handling parameter, indicates how the UAS
should react if it receives a message body whose content
type or disposition type it does not understand, default
handling is required
o Examples of valid Content-Disposition header fields:
Content-Disposition: session
Content-Disposition: signal; handling=optional
199
199
SIP Profiles
SIP Profile A
SIP 3GPP Mobile
Network
PSTN/ISDN
SIP Profile C
PSTN/ISDN
SIP Profile B
SIP Terminating
Network
200
200
SIP Profile - A
o Defined to satisfy the demand represented by 3GPP in
TS.24.229 V5.1.0 (2002-06)
o Work on this protocol was driven by mobile operators and
vendors
o Support traffic that terminates within the SIP network
o Pre-conditions are being used on the SIP network
201
201
SIP Profile - B
o Signalling is used at PSTN/SIP gateway, where all
signalling information to be transferred has to be coded
from a signalling system to another
o At sending when mandatory information is missing default values are used
o At receiving the incompatible information is deleted
o Support traffic that terminates within the SIP network
o Pre-conditions are not used on the SIP network
202
202
SIP Profile - C
o Signaling is used at PSTN/SIP gateway, when the ISUP
signaling between two PSTN networks is conveyed over
IP using SIP signaling
o Supports the trunking of traffic via transit SIP networks
using MIME encoded encapsulated ISUP
203
203
SIP-ISUP Mapping
ISUP
SIP
ISUP
SIP
IAM
INVITE
SUS
INFO (Profile C)
SAM
INVITE
RES
INFO (Profile C)
ACM
18x
COT
200 OK INVITE
CPG
18x
RSC
BYE
CON
200 OK INVITE
ANM
200 OK INVITE
REL
BYE
4xx, 5xx, 6xx
CANCEL
RLC

GRS
BYE
CGB
BYE
BYE
4xx, 5xx, 6xx
CANCEL
204
204
IAM/INVITE Mapping
INVITE
IAM
Called Party Number (M)

E.164 encoded userinfo of Request-URI (sip:URI with
user=phone)
Address Signal
Calling Party Category (M)

Profile A & B : Oridinary Calling
Subscriber
Profile C : Generated from the CPC of
encapsulated ISUP
Nature of Connection Indicators (M)

Profile A & B : Default values
Profile C : Generated from the NOC of
encapsulated ISUP
Forward Call Indicators (M)

Profile A : D = 1, F = 0, HG = 01, I = 0. All
other bits are default values.
Profile B : Determined based on analysis
of various parameters
Profile C : Generated from the FCI of
encapsulated ISUP
205
205
IAM/INVITE Mapping
INVITE
IAM
Transmission Medium Requirement (M)

SDP payload
Profile A : 3.1 kHz audio

Profile B : Derived from SDP
Profile C : Generated from the
TMR of encapsulated ISUP
User Service Information (O)

SDP payload
Profile A : No mapping
Profile B : Derived from SDP
Profile C : Generated from the USI
of encapsulated ISUP
Calling Party/Generic Number (O)

E.164 encoded userinfo of From/P-Asserted-Identity header
Profile A & B :Address Signal

CGN of encapsulated ISUP
Privacy header
Profile A & B : Address

Presentation Restricted Indicator
(APRI)
CGN of encapsulated ISUP
206
206
Tel-URI
telephone-url = "tel" ":" global-phone-number / local-phone-number
o Describes a connection to a terminal that handles normal

voice telephone calls, a voice mailbox or another voice
messaging system or a service that can be operated using
DTMF tones
o URL contains the phone number of the remote entity
which
Can contain subaddresses which are used to identify different
remote entities under the same phone number
Can contain a post-dial sequence used with voice mailboxes and
other services, describes what and when the local entity should
send to the phone line
o Phone numbers can be either "global" or "local

Global numbers are unambiguous everywhere
Local numbers are usable only within a certain area, which is
called "context"
207
207
Tel-URI - Examples
tel:+358-555-1234567
Global Phone Number (+358-555-1234567)
Visual Separator (-)

E.164 Number (3585551234567)
Indicative of global number (+)
URI Schema (tel)
Local Phone Number (+1-213-456-7890)

tel:456-7890;phone-context=213
Context (Area Code = 213)

Visual Separator (-)
Local Number (4567890)
URI Schema (tel)
208
208
Number Mapping
o SIP-ISUP mapping frequently requires the representation
of telephone numbers in URIs (Request-URI, To, From, PAsserted-Identity)
o Most common format used in SIP for the representation of
telephone numbers is the tel URL
o tel URL constitute the entirety of a URI field
To: tel:+17208881000
o sip URL constitute the user-portion of a URI field

To: sip:+17208881000@level3.com
o +' sign preceding the number in tel URLs indicates that the
digits which follow constitute a fully-qualified E.164
number
o When the '+' sign is not present, but a telephone number
is represented by the user portion of the URI, the SIP URI
should contain the optional ';user=phone' parameter
To: sip:83000@sip.example.net;user=phone
209
209
ISUP to TEL URI Mapping

ISUP
SIP
Called Party/Calling Party Number

NPI : E.164
NOA : International
CDN:17208881000
Telephone number digits to be appended unmodified to a 'tel:

+ string
tel:+17208881000
NPI : E.164
NOA : National
CDN:7208881000
Country code must be prefixed to the telephone number

digits before they are committed to a tel URL
tel:+17208881000 (assuming CC = 1)
NPI : E.164
NOA : Subscriber
CDN:8881000
Both a country code and any other numbering components

necessary for the numbering plan in question may need to be
added in order for the number to be internationally significant
tel:+17208881000 (assuming CC = 1, NPA = 720)
sip:8881000@sip.example.net;user=phone
Calling Party Number

PI : Restricted
Special SIP URI is created by the gateway which

communicates to the far end that the caller's identity has
been omitted, i.e. with a display-name and username of
'Anonymous
From: Anonymous <sip:anonymous@anonymous.invalid>
210
210
TEL URI to ISUP Mapping

SIP
ISUP
Called Party/Calling Party Number

URI is in international format, the country code is not local to the
gateway, retain the country code and populate the digits field
tel:+17208881000
NPI : E.164
NOA : International
CDN:17208881000
URI is in international format, the country code is local to the

gateway, strip the country code from the URI before populating the
digits field
tel:+17208881000 (assuming CC = 1)
NPI : E.164
NOA : National
CDN:7208881000
URI is not in international format, the gateway may treat the

telephone number within the URI as if it were appropriate to its
national or network-specific dialing plan
sip:8881000@sip.example.net;user=phone
NPI : Unknown
NOA : Subscriber
CDN:8881000
Calling Party Number

Presentation indicator should be set to 'presentation allowed' and
the screening indicator to 'network provided', unless some service
provider policy or user profile specifically disallows presentation
PI : Presentation Allowed
SI : Network Provided
211
211
P-Asserted-ID Header
o Private extensions to SIP that enable a network of trusted
SIP servers to assert the identity of end users or end
systems, and to convey indications of end-user requested
privacy
o Use of these extensions is only applicable inside an
administrative domain with previously agreed-upon
policies for generation, transport and usage of such
information
o Use to deliver basic regulatory services like Calling
Identity Delivery, Calling Identity Delivery Blocking, and
Malicious Call Trace
o Defines a new header field called 'P-Asserted-Identity' that
contains a URI (commonly a SIP URI) and an optional
display-name
o Used among trusted SIP entities to carry the identity of the
user sending a SIP message as it was verified by
authentication
212
212
P-Asserted-ID Header
PAssertedID = "P-Asserted-Identity" HCOLON name-addr / addr-spec
o Must consist of exactly one name-addr or addr-spec

o May contain one or two P-Asserted-Identity values
One value must be a sip, sips, or tel URI
Two values - one must be a sip or sips URI and the other must be
a tel URI
o Proxy server after authenticating the originating user (e.g.

Digest authentication), insert P-Asserted-Identity header
field into the message and forward it to other trusted
proxies
o Proxy that is about to forward a message to a proxy
server or UA that it does not trust must remove all the PAsserted-Identity header field values
o Examples of valid P-Asserted-Identity header fields:
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
213
213
Privacy Header
o Provides privacy requirements and mechanisms for the
SIP
o Two types of privacy mechanism:
User provided :
A user agent populates the From header field of a request with an
anonymous value
A user agent can encrypt SIP bodies end-to-end in order to prevent
intermediaries from inspecting them
Network Provided :
A user can request privacy from intermediaries
o Defines a new header, Privacy, that can be used to specify

privacy handling for requests and responses
o User agents include a Privacy header when networkprovided privacy is required
o Each legitimate priv-value can appear zero or one times in
a Privacy header
214
214
Privacy Header
Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value)
priv-value = "header" / "session" / "user" / "none" / "critical" / id
o Must consist of either the value 'none', or one or more of

the values 'user', 'header', 'id' and 'session' (each of which
must appear at most once) - in turn be followed by the
'critical' indicator
o Examples of valid Privacy header fields:
Privacy: id;critical
215
215
Privacy to CGN Mapping

SIP
ISUP
Privacy header field absent
Priv-value = none
Priv-value = header
PI : Presentation Restricted
Priv-value = user
Priv-value = id
ISUP
SIP
No Privacy header
Privacy: id (included on if PAsserted-Id header is

included)
216
216
Number Portability (NP)

o Ability of users of telecommunications services to retain,
at the same location, existing telecommunications
numbers without impairment of quality, reliability, or
convenience when switching from one
telecommunications carrier to another
o Allows subscribers to switch to a new provider while
keeping their existing telephone numbers
o NP-related information includes :
Dialed Directory Number (DN) : Needed at the terminating
switch so that the call can be terminated to the called party
Routing Number (RN) : Allows the network, to route the call to
the network or switch that currently serves the dialed directory
number
Number Portability Dip Indicator (NPDI) : Indicates whether a
query to the NP Database (NPDB) has been performed
217
217
Number Portability (NP)

o The "tel" URL has been extended to carry the routing
number for the ported geographical numbers
o DN is present in the "tel" URL before the NPDB dip is
performed i.e., right after the "tel:
o Two new parameters are required to support NP :
First parameter "rn," which stands for "routing number," carries the
routing number used for call routing
Second parameter "npdi," which stands for "NPDB dip indicator,"
indicates whether NPDB dip has been performed
o "rn," if present, is used for making routing decisions, else

the phone number after "tel:" is used for call routing
o NP tel URI example :
INVITE tel:+1-202-533-1234;rn=+1-202-544-0000; npdi SIP/2.0
218
218
Number Portability (NP) - Example

o SIP server receives an INVITE message as shown below
where +1-202-533-1234 is the dialed called party number
and has been ported out of the donor network
INVITE tel:+1-202-533-1234 SIP/2.0
o SIP server is set to perform the NPDB query - perform a

NPDB query (since no npdi parameter is present)
o After receiving a successful response back from the
queried NPDB, it formulates the following SIP INVITE
message
INVITE tel:+1-202-533-1234;rn=+1-202-544-0000; npdi SIP/2.0
o SIP server then uses the "rn" parameter to make the

routing decisions
219
219
NP ISUP/SIP Mapping
SIP
ISUP
Forward Call Indicator (M)

npdi=yes
M bit = 'number translated
Called Party Number

'rn=' field is present
rn=+12025440000
Mapped to CDN
CDN:12025440000
Generic Digit Parameter

Main telephone number in the tel URI
tel:+1-202-533-1234;rn=+1-202-544-0000; npdi
Mapped to GAP
GAP:12025331234
SIP
ISUP
Forward Call Indicator (M)

M bit = 'number translated
npdi appended to the tel URL
Called Party Number

CDN
CDN:12025440000
Mapped to 'rn=' field

rn=+12025440000
Generic Digit Parameter

GAP
GAP:12025331234
Map to main telephone number in the tel URI

tel:+1-202-533-1234;rn=+1-202-544-0000; npdi
220
220
18x/ACM Mapping
SIP
ISUP
Backward Call Indicators (M)

180 Ringing
Profile A : Called Party Status Indicator =

subscriber free. I = 1, K= 0, M = 0.
Profile B : Called Party Status Indicator =
subscriber free. Other fields are
determined based on analysis of various
parameters
Profile C : Generated from the BCI of
encapsulated ACM

183 Session Progress
Profile A : ACM is not generated

Profile B : ACM is not generated
Profile C : Generated from the BCI of
encapsulated ACM
221
221
18x/ACM Mapping
ISUP
SIP
Backward Call Indicators

Called Party Status = subscriber free
Profile A : 180 Ringing

Profile B : 180 Ringing
Profile C : 180 Ringing with encapsulated ACM

Called Party Status = no indication or any
other value
Profile A : Not interworked

Profile B : Not interworked
Profile C : 183 Session Progress with encapsulated
ACM
222
222
18x/CPG Mapping
SIP
ISUP
Event Information (M)

180 Ringing
Profile A : Event Indicator = alerting.

Other indicators in the Event Information
parameter are set according to ISUP
procedures
Profile B : Event Indicator = alerting.
Other indicators in the Event Information
parameter are set according to ISUP
procedures
Profile C : Generated from the EI of
encapsulated CPG

Profile A : CPG is not generated

Profile B : CPG is not generated
Profile C : Generated from the EI of
encapsulated CPG
223
223
18x/CPG Mapping
ISUP
SIP

Event Indicator = alerting
Profile A : 180 Ringing

Profile B : 180 Ringing
Profile C : 180 Ringing with encapsulated CPG

Called Party Status = progress or in-band
information available
Profile A : Not interworked

Profile B : Not interworked
Profile C : 183 Session Progress with encapsulated
CPG
224
224
200/ANM Mapping
SIP
200 OK INVITE
ISUP
ANM
ISUP
Profile A : ANM
Profile B : ANM
Profile C : Generated ANM from the encapsulated ISUP
SIP
Profile A : 200 OK INVITE
Profile B : 200 OK INVITE
Profile C : 200 OK INVITE with encapsulated ANM
225
225
Reason Header
Reason
reason-value
= "Reason" HCOLON reason-value *(COMMA reason-value)

= "SIP" / "Q.850" *(SEMI protocol-cause / reason-text )
o Provides the information on why a SIP request was issued

o Useful in creating services like Third-Party Call Control,
ISUP interworking
o Also intended to be used to encapsulate a final status
code in a provisional response
o Appear in any request within a dialog, in any CANCEL
request and in any response whose status code explicitly
allows the presence of this header field
o May contain more than one Reason value, but all of them
must have different protocol values
o Examples of valid Reason header fields:
Reason: SIP ;cause=200 ;text="Call completed elsewhere
Reason: Q.850 ;cause=16 ;text="Terminated"
226
226
Reason Header Usage Example

Third-Party Call Control
User A
ISUP Interworking
User B
Controller
INVITE
User A
User B
Gateway
IAM
INVITE
200 OK (SDPO)
ACK (Hold SDP)
100 Trying
INVITE
486 Busy Here
BYE (SIP:486)
ACK
REL (16)
CANCEL (Q.8650:16)
200 OK
200 OK
227
227
BYE/4xx/5xx/6xx/REL Mapping
SIP
ISUP
Cause Indicator (M)

BYE Reason header not present
Profile A & B: Cause Value = 16 (normal

clearing), Location = Network beyond
interworking point
Profile C : Generated from the CI of
encapsulated REL
CANCEL Reason header not present
Profile A & B: Cause Value = 16 (normal

clearing), Location = Network beyond
interworking point
Profile C : Cause Value = 31 (normal
unspecified), Location = Network beyond
interworking point
Cause Indicator (M)

BYE Reason header present
Profile A & B : Cause Value = protocolcause, Location = Network beyond

interworking point
encapsulated REL
CANCEL Reason header present
Profile A, B & C : Cause Value =

protocol-cause, Location = Network
beyond interworking point
228
228
SIP
ISUP
Cause Indicator (M)

4xx/5xx/6xx Reason header not present
Profile A & B: Cause Value = Status

Code Mapping, Location = Network
beyond interworking point
encapsulated REL
Cause Indicator (M)

4xx/5xx/6xx Reason header present
REL Cause Value
Profile A & B : Cause Value = protocolcause, Location = Network beyond

interworking point
encapsulated REL
4xx/5xx/6xx SIP Messages
127 Interworking
400 Bad Request
1 Unallocated Number
404 Not Found
20 Subscriber absent
480 Temporarily Unavailable
17 User busy
486 Busy Here
229
229
ISUP
SIP
Cause Indicator (M)

Forward REL Before Answer
Profile A, B & C : CANCEL with Reason

Header (Q.850)
Forward REL After Answer
Profile A & B : BYE with Reason Header

(Q.850)
Profile C : BYE with Reason Header
(Q.850) & encapsulated REL
Cause Indicator (M)

Backward REL Before Answer
Profile A, B & C : SIP Status Code with

Reason Header (Q.850)
Backward REL After Answer
Profile A & B : BYE with Reason Header

(Q.850)
Profile C : BYE with Reason Header
(Q.850) & encapsulated REL
230
230
What is Media Clipping ?

SIP UA (A)
INVITE
INVITE
100 Trying
Media
Clipping
Occurs
SIP UA (B)
SIP Proxy
200 OK (SDPT)
200 OK (SDPT)
Media Flow from B to A
ACK (SDPo)
ACK (SDPo)
o Occurs when the user believes that the media session is

already established, but the establishment process has
not finished yet
o Offer/answer exchange takes place in the 200 OK
response and in the ACK - called user starts speaking at
the same time the 200 OK is sent, but the UAS cannot
send any media until the answer from the UAC arrives in
the ACK
231
231
Early Media
o Denotes the capability to play media (audio for telephony)
before a SIP session has been established (before a 2xx
response code has been sent)
o Within a dialog, early media occurs from the moment the
initial INVITE is sent until the UAS generates a final
response
o Early media can be unidirectional or bi-directional and can
be generated by the caller or/and the callee
o Generated by the callee are ringback tone and
announcements (e.g., queuing status)
o Generated by the caller consists of voice commands or
dual tone multi-frequency (DTMF) tones to drive
interactive voice response (IVR) systems
o INVITE almost always contains the SDP required to send
media in the backwards direction
232
232
Early Media
o Two Models :
Gateway Model
SIP uses the offer/answer model to negotiate session parameters
Manages early media sessions using offer/answer exchanges in
reliable provisional responses, PRACKs, and UPDATEs
Acceptable in situations where the UA cannot distinguish between
early media and regular media (e.g. PSTN gateway)
Application Server (AS) Model

UAS behave as an application server to establish early media
sessions with the UAC
UAC indicates support for the early-session disposition type using the
early-session option tag
Content-Disposition: early-session
233
233
Early Media Gateway Model

SIP UA (A)
SIP UA (B)
SIP Proxy
INVITE (SDPo)
100 Trying
200 OK (SDPT)
INVITE (SDPo)
200 OK (SDPT)
Early Media Session
ACK
SIP UA (A)
ACK
SIP UA (B)
SIP Proxy
INVITE
100 Trying
183 Session Progress (SDPT)
PRACK (SDPo)
INVITE
183 Session Progress (SDPT)
PRACK (SDPo)
Early Media Session

234
234
Early Media AS Model

SIP UA (A)
SIP UA (B)
SIP Proxy
INVITE (offer)
100 Trying
(answer, early offer)
PRACK (early-answer)
INVITE (offer)
(answer, early offer)
PRACK (early-answer)
200 OK
200 OK
Early Media Session

200 OK INVITE
ACK
200 OK INVITE
ACK
Content-Type: application/sdp Content-Disposition: session

v=0
o=alice 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.1
t=0 0
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 401
--boundary1
Content-Disposition: session
v=0
o=Bob 2890844725 2890844725 IN IP host.example.org
s=
c=IN IP4 192.0.2.2
t=0 0
--boundary1
v=0
o=Bob 2890844714 2890844714 IN IP4 host.example.org
s=
c=IN IP4 192.0.2.2
t=0 0
--boundary1-Content-Type: application/sdp
v=0
o=alice 2890844717 2890844717 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.1
t=0 0
235
235
INFO Method
o Used for communicating mid-session signaling information
along the signaling path for the call
o Not used to change the state of SIP calls, nor does it
change the state of sessions initiated by SIP
o Signaling path is the path established as a result of the call
setup - can be either direct signaling or involving SIP proxy
servers
o Mid-session information can be communicated in either an
INFO message header or as part of a message body
o Potential uses of the INFO message
Carrying mid-call PSTN signaling messages between PSTN
gateways (ISUP SUS/RES)
Carrying DTMF digits generated during a SIP session
Carrying account balance information
236
236
ISUP SUS/RES
ISUP
SIP
SUS
Profile A & B : Not interworked

Profile C : INFO with encapsulated SUS
RES
Profile A & B : Not interworked

Profile C : INFO with encapsulated RES
Switch A
MGC B
MGC A
Switch B
Two way Speech Path
SUS
RES
INFO (SUS)
SUS
200 OK
INFO (RES)
RES
200 OK
237
237
DTMF
o DTMF was designed to provide address signaling to CO
in PSTN at start of call
o Created simple, universal user input mechanism for all
devices on the PSTN network
o PSTN service and application vendors used DTMF for
application control
o Universal User Input mechanism - DTMF has become the
standard user input mechanism for all types of PSTN
voice terminals to interact with services and applications
o Edge applications
IVR
Voicemail
o Network applications
Calling Card
Universal Messaging
238
238
DTMF
o Original function of DTMF (address signaling) is not needed
in packet network
o Preferred support mechanism
SIP INFO Method
RTP Stream
Other SDP session protocol
o SIP INFO Method
Can be sent along the call signaling path

Text-based encoding of DTMF
No out-of-order issues
RFC 2833 Encoded Data
Guaranteed delivery of Single Events
o RTP Stream
Uses Existing protocol
Guaranteed sequencing
Focused on PSTN to Packet to PSTN - DTMF transport
239
239
Overlap Signalling
o Consists of sending only some digits of the callee's number in the first
signaling message
o Further digits are sent in subsequent signaling messages
o SIP uses en-bloc signaling - Request-URI of an INVITE always contains
the whole address of the callee
o Preferred solution for a gateway handling PSTN overlap signaling and
SIP is to convert the PSTN overlap signaling into SIP en-bloc signaling
using number analysis and timers
o Sending overlap signaling to a SIP Network, multiple INVITEs are
generated
Gateway on receipt of an IAM and possibly one or more SAMs that provide
more than the minimum amount of digits build and sends an INVITE
SAM arrives to the gateway, a new INVITE with the new digits received is
sent
Call-ID as the first INVITE

From header including the tag as the first INVITE
Request-URI contains all the digits received so far
To header contains all the digits as well, but has no tag
For Profile C, place the IAM and all the SAMs received so far in INVITE
240
240
Overlap Signalling Call Flows

Switch A
MGC B
MGC A
IAM
SAM 1
1 INVITE (IAM, oSDP)
IAM
2 INVITE (IAM, SAM 1, oSDP)
SAM 1
1 484 Address Incomplete

SAM 2
Switch B
1 ACK
3 INVITE (IAM, SAM 1, SAM2,
oSDP)
SAM 2
2 484 Address Incomplete

2 ACK
ACM
ACM
3 180 Ring. (ACM, tSDP)

ANM
3 200 OK (ANM)
ANM
3 ACK
Two way Speech Path
241
241
SIP & PacketCable
242
242
Contents
o
o
o
o
o
o
o
o
Background
Distributed Call Signalling Architecture
PacketCable Architecture
Call Management Server
Service Provider Requirements
SIP Proxy-To-Proxy Extensions
CMS to CMS Call Flow
CMS to MGC Call Flow
243
243
SCP
SSP
DLC
STP
PSTN
PSTN GW
PBX
3rd Party
Applications
SIP/SIP-T
Location
Server
DNS
Application
Server
OSA
Gateway
SIP Network
CMTS
SIP/SIP ISC
EBP
CMS/GC
SIP
User
Agents
Application
Servers
SIP/SIP-T
SIP/SIP ISC
CSCF
HSS
PacketCable Network
MTA
MTA
MGCF
PCF
IM Subsystem
WiFi/
WiMax
VDSL
FTTH
CDMA/
GSM/UMTS
244
244
Background
o CableLabs-led initiative that is aimed at developing
interoperable interface specifications for delivering
advanced, real-time multimedia services over two-way cable
plant
o Built on top of cable modem infrastructure, PacketCable
networks
o Use IP technology to enable a wide range of multimedia
services
IP telephony
Multimedia conferencing
Interactive gaming
o Distributed signaling paradigm is SIP (PacketCable 1.1)

o Protocols and architecture developed for DOCSIS-based
cable, but applicable to other broadband access network
technologies
245
245
Distributed Call Signaling Framework

DCSProxy+GC
DCSProxy+GC
Announcement
Server
MTA
Access
ER
Signaling Transport (IP)

Media transport (IP)
ER
Access
MTA
PSTN
GW
PSTN
MTA
Media Terminal Adaptor
Call State
Cable Modem
Connection State
ER
Edge Router
Transaction State
GC
Gate Controller
246
246
DCS Architecture
o Designed as a complete end-to-end signaling architecture

DCS-Proxy designed to be scalable transaction server
Resource management protocol provides necessary semantics for
telephony
Gates at network edge avoid theft of service
o Enhances SIP with Carrier-Class features

Adds Resource Management, Privacy Mechanisms, Authorization
and Billing
Makes use of end-point intelligence
Takes advantage of SIP feature support in endpoints and proxies
o Tight coupling between Call Signaling and QoS Control

Authorize a call and allocate resources precisely when needed
Prevent call defects, dont ring the phone if resources are unavailable
Provide the ability to bill for usage, without trusting end-points

Prevent theft of service, associate usage recording and resource
allocation, ensuring non-repudiation
o Distribution of State
Clients keep Call-State
Edge Routers keep Connection-State
DCS-Proxy keeps Transaction-State
247
247
PacketCable Architecture
248
248
Call Management Server (CMS)

o Architectural entity that performs services necessary to
enable endpoints to establish IP multimedia sessions
o Act a SIP User Agent (UA)
o Support session signaling, call routing, feature support and
service-specific admission control
o Trusted decision point, establishes calls on behalf of an untrusted endpoint, e.g., an Multimedia Terminal Adapters
(MTA), in the customer premise
o Act as a proxy
Interior Border Proxy (IBP) : Used for inter-realm (intra-domain)
signaling
Exterior Border Proxy (EBP) : Used for inter-domain signaling
Tandem Proxy
o Coordinate with Gate Controllers (GC) to control resource

reservations and media flows
249
249
Call Management Server (CMS)

o Uses SIP with extensions - referred to as the Call
Management Server Signaling (CMSS) protocol for inter-CMS
communication
o Controls Network based Call Signaling (NCS) endpoints
o Controls PSTN Gateway Call Signaling (TGCP) endpoints,
used between the Media Gateway Controller (MGC) and
Trunking gateways (TGW), uses SIP for CMS-MGC
communication
o Establishes connections
On its own behalf i.e. voicemail and conference bridge servers
On behalf of a non-SIP endpoint i.e. Call Agent (CA), MGC,
Announcement Controller (ANC)
o Support of billing functions

o Support operator services such as Busy Line Verification and
Emergency Interrupt
250
250
Call Management Server Interface

NCS/TGCP
Call
Signaling
Translation, Congestion Control, PSTN,

DB access, Event recording, Routing
Call Agent
QoS
Signaling
DCS/SIP
DCS-Proxy
Gate Controller
DQoS
COPS
251
251
Service Provider Requirements

o Need for differentiated QoS is fundamental
Must support resource reservation and admission control
SIP enables lots of new services; also desire to meet needs of
current users
o Allow for authentication and authorization on a call-by-call

basis
o Need to guarantee privacy and accuracy of feature
information (e.g. Caller ID, Caller ID-block, Calling Name,
Called Party)
o Protect the network from fraud and theft of service
o Must be able to operate in large scale, cost-effectively
End-points keep state associated with their own calls, and not
proxies
252
252
SIP Proxy-To-Proxy Extensions

o Support the exchange of customer information and billing
information between trusted entities
P-DCS-BILLING-INFO
o Provide mechanisms for access network coordination to

prevent theft of service, customer originated trace of
harassing calls
P-DCS-TRACE-PARTY-ID
o Support operator services

Want to reuse existing operator services facilities and
infrastructure
Ability to indicate that special call processing Busy Line Verify
(BLV) and Emergency Interrupt (EI) is to be applied
BLV and EI invades privacy and should only be extended to
operators
P-DCS-OSPS to signal special operator services operations
o Only applicable within closed administrative domains, or

among federations of administrative domains with
previously agreed-upon policies where coordination of
charging and other functions is required
253
253
P-DCS-TRACE-PARTY-ID
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr
o To initiate a customer-originated-trace from an un-trusted

UAC
o Un-trusted UAC includes in the INVITE Request
o Entity addressed by the Request-URI performs the
service-provider-specific functions of recording and
reporting the caller identity in the P-DCS-Trace-Party-ID
for law enforcement action
o Trusted UAC does not use this header
o Must not appear in any request or response sent to an
un-trusted endpoint
254
254
P-DCS-OSPS
P-DCS-OSPS = "P-DCS-OSPS" HCOLON "BLV" / "EI"
o Busy Line Verification (BLV) and Emergency Interrupt (EI) services

initiated by an operator from an Operator Services Position System
(OSPS) on the PSTN network
o To inform the SIP user agent that special treatment should be given to
a call
o Two values been defined:
"BLV" for busy line verification
"EI" for emergency interrupt
o Typically inserted by a MGC that is controlling a TGW with special

trunks to a PSTN OSPS system - include the OSPS header in SIP
INVITE
o BLV and EI invades privacy and should only be extended to operators
Allow operator, and only operator, to listen in
Allow operator, and only operator, to break in
o An active endpoint receiving an INVITE containing OSPS header does

not return 486 Busy Here
255
255
Busy Line Verify (BLV) Call Flow

MF Signal
PSTN GW
1
NTFY
CRCX
ACK
P-DCS-OSPS : BLV (Indicator of

Busy Line Verification function)
INVITE (BLV)
5

8
MTAT
DPT
CMS/MGC
INVITE (BLV)
PRACK
200 OK
10
UPDATE
200 OK
200 OK INVITE
14
200 OK INVITE
11
12
Allocate
network
resources
Commit to
network
resources
13
ACK
Busy Line Verification in Progress (one-way data transfer from MTA to Operator)
256
256
Emergency Interrupt (EI) Call Flow

PSTN GW
MTAT
DPT
CMS/MGC
Busy Line Verification in Progress (one-way data transfer from MTA to Operator)
Interrupt
15
P-DCS-OSPS : EI (Indicates a
change to Emergency Interrupt)
NTFY
16
INVITE (EI)
200 OK INVITE
14
16
ACK
Emergency Interrupt in Progress (two-way data transfer)
257
257
P-DCS-BILLING-INFO
P-DCS-Billing-Info =
Billing-Correlation-ID =
FEID =
Billing-Info-param =
"P-DCS-Billing-Info" HCOLON Billing-Correlation-ID "/" FEID *(SEMI Billing-Info-param)

1*48(HEXDIG)
1*16(HEXDIG) "@" host
RKS-Group-ID-param / Charge-param / Calling-param / Called-param /
Routing-param / Loc-Routing-param
o Contains an identifier that can be used by an event

recorder to associate multiple usage records, possibly
from different sources, with a billable account
o Contains the subscriber account information, and other
information necessary for accurate billing of the service
o Only used on requests and responses between proxies
and trusted User Agents
o In addition to SIP general header for the capture of billing
information and billing identification for the duration of the
call
258
258
CMS-CMS Call Flow
259
259
CMS-CMS Call Flow
260
260
CMS-MGC Call Flow
261
261
CMS-MGC Call Flow
262
262
SIP & IMS
263
263
Contents
o
o
o
o
o
o
o
o
o
o
o
o
IP Multimedia Subsystem
Call Session Control Function (CSCF)
IMS Interfaces
3GPP SIP Overview
Differences to IETF SIP
3GPP SIP requirements
IMS Service Architecture
IMS Service Control Interface (ISC)
Convergence
TISPAN
Differences to NGN IMS
SIP and Mobility
264
264
SCP
SSP
DLC
STP
PSTN
PSTN GW
PBX
3rd Party
Applications
SIP/SIP-T
Location
Server
DNS
Application
Server
OSA
Gateway
SIP Network
CMTS
SIP/SIP ISC
EBP
CMS/GC
SIP
User
Agents
Application
Servers
SIP/SIP-T
SIP/SIP ISC
CSCF
HSS
PacketCable Network
MTA
MTA
MGCF
PCF
IM Subsystem
WiFi/
WiMax
VDSL
FTTH
CDMA/
GSM/UMTS
265
265
IP Multimedia Subsystem (IMS)

Original
Original(late
(late90s/early
90s/early00s)
00s)definition
definitionper
per3GPP
3GPPTS
TS23.228:
23.228:
The
TheIPIPMultimedia
MultimediaCN
CNsubsystem
subsystemcomprises
comprisesall
allCN
CNelements
elementsfor
forprovision
provisionofof
multimedia
multimediaservices.
services.This
Thisincludes
includesthe
thecollection
collectionofofsignaling
signalingand
andbearer
bearerrelated
related
network
networkelements
elements
o An overlay to the PS-domain using SIP technology to provide

multimedia services over IP
o Layered architecture, comprises a set of interfaces, SIP proxies and
servers (such as media servers), and media gateways (for
connections to circuit core or the PSTN)
o Supports a wide range of IP-based services (e.g Directory services,
instant messaging (IM), push-to-talk (PTT), video streaming) over
both packet and circuit-switched networks, employing a range of
different wireless and fixed access technologies
o Key features :
Open Systems Architecture (OSA)

Access Independence
Terminal and user mobility
Extensive IP-based services
SIP Certification Training1.1 Copyright 2006 Wipro Ltd
266
266
IP Multimedia Subsystem (IMS)

User Ids
User profile
roaming
security
QoS
policy
control
SIP
InterWorking
CS/PSTN
Basic
Call
Control
charging
Service logic
APIs
267
267
IMS Building Blocks

o Applications Layer
OSA-GW
End-user telephony service logic

AIN call trigger points
Non-telephony based services
APIs for enterprise & legacy applications
Telephony AS
Non-telephony AS
CSCF, BGCF
o Session Control Layer
MGCF & MRFC
End Point Registration

Session setup
QoS establishment
HSS
Media Gateway
o Transport & Endpoint Layer

Bearer Services, Media Conversion (PCM > IP),
Compression
Special functions: announcements, touch tones
collection, voice recognition, speech synthesis
Media Server
268
268
IMS Architecture
Control Plane
Traffic Plane
HSS
IMS
Cx
I-CSCF
Mw
P-CSCF
Go
UTRAN
UE
SGSN
PS Domain
GGSN
Gi
The HSS holds the

IMS service profile of
I-CSCF
the subscribers.
Other IP/
IMS network
Cx
S-CSCF
Mm
Gi
CSCFs are the IMS entities

S-CSCFthere
interconnects to external
responsible of the call control:
IP networks
are 3 types of CSCFs depending
onand other IMS
networks.
their role:
THIG
used by
the operator to
PS isdomain
provides
P-CSCF (Proxy CSCF) IfThe
hide
internal
the
the IPitsbearer
to configuration,
access to
S-CSCF (Serving CSCF)
connections
external
networks
the IMS, i.e. atoPDP
context.
I-CSCF (Interrogating CSCF)
goes through an I-CSCF.
269
269
IMS Architecture
Control Plane
Traffic Plane
HSS
IMS
Cx
I-CSCF
In Release 6, the PDF can
be separated from the PCSCF. Those two entities
are then connected
through the Gq interface.
Mw
S-CSCF
Mm
Mr
Mk
Mi
MRF
Gi
Other IP/
IMS network
Cx
The MRF is used

P-CSCF call
for multiparty
control
Gq Go
I-CSCF
Mg
Mj
UTRAN
Gi
PDF
Go
UE
SGSN
PS Domain
Gi
GGSN
IMSMGW
MGCF
Mn
BGCF
Those entities are

SGW responsible for
interworking
between IMS and
CS domain/PSTN
Legacy/
PSTN
270
270
3GPP/3GPP2 IMS Architecture

Web
Portal
Web Portal
Parlay
Parlay App
App
Server
Server
Application
Layer
SIP
SIP App
App
Server
Server
Centralized
Centralized
Databases
Databases
HSS
HSS
Support
Support Systems
Systems
Billing
Billing Mediation,
Mediation,
Fault
Fault Correlation,
Correlation,
Operations,
Operations,
Maintenance,
Maintenance,
ter
me
a
i
D
OSA
OSA SCS
SCS
SIP
S-CSCF
S-CSCF
SIP
SIP
MGCF
MGCF
COPS
PDF
PDF
Media
Media
Server
Server
SIP
Transport and
End Point
Layer
I-CSCF
I-CSCF
P-CSCF
P-CSCF
H.248
MRFC
MRFC
SIP
BGCF
BGCF
SIP
IN
IN
Access
Access
IP
IP
Signalling
Signalling
Converter
Converter
SG
SG
H.248
Session
Control
Layer
Media
Media
Gatewa
Gatewa
y
y
PSTN
Wireline and Wireless SIP Endpoints
GSM, UMTS, 802.11, Bluetooth, DSL, FTTP,
Legacy IP
Endpoints & PBXs
H.323 and MGCP
TDM
PBX
SS7
SS7
Analog
Endpoint
271
271
IMS Standards
3GPP and 3GPP2 (3rd
Generation Partnership
Project/3rd Generation
Partnership Project 2)
Have both defined the IP Multimedia Subsystem (IMS)

The harmonization effort has kept the definitions as similar as possible.
IETF (Internet Engineering

Task Force)
Provide the definitions for SIP, SDP and other protocols underlying IMS
IMS is driving some of the work in IETF
OMA (Open Mobile Alliance)
Defining services for IMS architecture, e.g. Instant Messaging, Push-to-Talk
ITU (International
Telecommunication Union)
Provides protocol definitions used by IMS

H.248 for media control
Q.1912.SIP for SIP ISUP interworking (in conjunction with IETF)
ETSI (European
Telecommunications
Standards Institute)
TISPAN - TISPAN is merger of TIPHON (VoIP) and SPAN (fixed networks)

Agreement on reuse of 3GPP/3GPP2 IMS in comprehensive NGN plans
ANSI (American National

Standards Institute)
Provides protocol definitions used by IMS

T1.679 covers interworking between ANSI ISUP and SIP
ATIS (Alliance for

Telecommunications Industry
Solutions)
Addressing end-to-end solutions over wireline and wireless

Nearing agreement to use 3GPP/3GPP2 IMS
272
272
Advantages of IMS
o Layered architecture that separates transport, control and
applications
o Independent of the access mechanism
Seamless services provisioning across the heterogeneous fixed
(i.e., PSTN, ISDN, PSDN, WAN/LAN/CATV, etc.) and evolving
mobile networks
o Mobility provided by underlying access mechanism

Access technology independent User Identity Module (UIM)
o Functionality apportioned between visited network and

home network
o Home network control of services
o Unified Handling and flexible resource utilization
Easy Mixing of Media and Parties
Mix of Network and Terminal Based Resources
o Open Interfaces
Sourcing applications from anywhere
Common for all user equipment and all application servers
273
273
Call Session Control Function (CSCF)

o SIP server which authenticates users and routes user SIP
messages
o Manages sessions for voice, video, file transfer,
messaging, shared whiteboard services, roaming, etc
o Coordinates with other network elements for session
control, feature/service control and resource allocation
o Manage subscriber data in co-operation with HSS
o Generate detailed billing records
o Ensure appropriate Security & QoS policy for each session
o Support value-added services through to Interface to
External App Servers
o Can act as
Proxy CSCF (P-CSCF)
Serving CSCF (S-CSCF)
Interrogating CSCF (I-CSCF)
274
274
Proxy CSCF (P-CSCF)

o First contact point within the IMS for the subscriber
o Forward SIP requests from the UE to an appropriate
network entry point (I-CSCF or S-CSCF)
SIP REGISTER request received from the UE to an ICSCF by
determining the home domain name
SIP messages received from the UE to the SIP server (e.g.
SCSCF) whose name the PCSCF has received as a result of the
registration procedure
o Identify entry point address based on originating UE

domain name (local tables and/or DNS)
o Detect and handle an emergency session establishment
o Perform SIP message compression/decompression
o Maintain security association between P-CSCF and UE
o Interface to PCF to manage QoS and resources
authorization
o Generation of CDRs
275
275
Interrogating CSCF (I-CSCF)

o
o
o
o
o
o
o
o
o
Gateway between P-CSCF and S-CSCF

Acts as a network entry point for SIP signaling
Assigning a S-CSCF to a user performing SIP registration
Route a SIP request received from another network towards
the S-CSCF
Contact point within an operator's network for all connections
destined for a user of that network, or for a roaming user
currently located within that network's service area
Support Topology Hiding Inter-network Gateway (THIG) or
other techniques to hide the configuration, capacity, and
topology of the network from the outside
Prevents roaming partners from discovering each others
network configurations
Charging and resource utilisation
Generation of CDRs
276
276
Serving CSCF (S-CSCF)

o Core SIP signaling control (e.g. registration, session
management, event subscriptions, etc.). Can act on behalf of
user originating or terminating attempts
o Performs user registration and authentication (via HSS)
o Service profile retrieval from HSS, service filtering and
triggering and invokes corresponding services
o Hosts end users network services, either locally or via SIP
(ISC) interface to external service platforms
o Selecting access to the home network application server,
and providing access to that server
o Provide endpoints with service event related information
(e.g. notification of tones/announcement together with
location of additional media resources, billing notification)
o Control service resource functions (e.g. audio server)
o Primary agent for service billing
277
277
IMS Interfaces
DIAMETER
Offline Charging
BG
P-CSCF
Gm
Gq
Compressed SIP
(3GPP profile)
GGSN
DIAMETER
PDF
Mw
SIP (3GPP profile)
To I-CSCF or SCSCF
Sh
DIAMETER
Online
Charging
DIAMETER
MRFC
Mp
H.248
MRFP
Mr
Cx
DIAMETER
Mw
SIP (3GPP
profile)
Mm
SIP
To external PDN
SLF
HSS
Dx
Cx
DIAMETER
I-CSCF
Mj
SIP (3GPP profile)
DIAMETER
DIAMETER
BGCF
Mk
AS
S-CSCF
Mi
BG
Dh
Mw
ISC
SIP (3GPP
profile)
Rf
S-CSCF interfaces
I-CSCF interfaces
AS
OCS
DIAMETER
Online
Charging
HSS
SIP
(3GPP
profile)
I-CSCF
P-CSCF interfaces
Ro
Ro
Go
COPS-PR to GGSN
for resource control
Home Network
HTTP
Visited/Home Network
Rf
Ut
DIAMETER
Offline
Charging
Mm
SIP
To external
PDN
SIP (3GPP profile)

MGCF
BGCF
Mc
H.248
IM- MGW
S-CSCF
Mw
To P-CSCF
Rf
Home Network
DIAMETER Offline Charging
All interfaces are IPv6

IMS uses SIP, DIAMETER, H.248 and COPS-PR
278
278
IMS Identities
o Users have to be identified uniquely
o Two new types of user identities
Private User Identity
Public User Identities
o Private User Identity

IMS user has one Private User Identity
Assigned by the home operator and identifies the subscription of
the user in databases, e.g. the HSS
Globally unique
Have the format of a Network Access Identifier
Similar to the IMSI (International Mobile Subscriber
Identification) in a GSM environment
Used for Registration, Authorization, Administration and
Accounting purposes
Not used for routing of SIP messages
279
279
IMS Identities
o Public User Identities
Have one or more public user identities
Uniquely identifies a user of the IMS
Similar to a MS-ISDN in a GSM environment
User always have a SIP URL as public user identity
User can additionally have an E.164 number (which is translated
in an URL with ENUM) for PSTN/ISDN interoperability
Used for routing the SIP messages and setting up the SIP
session.
280
280
Relationship of the Private and Public User Identities

Public
User Identity
IMS
Subscription
Private
User Identity
Public
User Identity
Public
User Identity
Public I
User Identity
Private I
User Identity
IMS
Subscription
Public II
User Identity
Private II
User Identity
Public III
User Identity
281
281
SIP Registration
Home
HSS
Location
Location
Profile
Profile
4 Cx-Query Resp
3 Cx-Query
I-CSCF
I-CSCF
200 OK
Cx-Pull/Put
Cx-Pull/Put
Resp
S-CSCF
S-CSCF
5 REGISTER
2 REGISTER
Visited
1 REGISTER
200 OK
P-CSCF
P-CSCF
10
200 OK
GGSN
GGSN
SGSN
SGSN
RadioAccess
AccessNetwork
Network
Radio
282
282
IMS Origination to PSTN/PLMN

Home
HSS
HSS
4 Cx-Query Resp
S-CSCF
S-CSCF
6 INVITE
Visited
10
PSTN
IAM
11 ANM
17 Media
MGCF/
MGCF/
T-SGW
T-SGW
MGW
MGW
5 INVITE
3 Cx-Query
I-CSCF
I-CSCF
14 200 OK
13 200 OK
9 INVITE
INVITE
sip:info@visited
15 200 OK
I-CSCF
I-CSCF
12 200 OK
7 Cx-Query
HSS
HSS
P-CSCF
P-CSCF
8 Cx-Query Resp
16 200 OK
GGSN
GGSN
SGSN
SGSN
1 INVITE tel:1411
RadioAccess
AccessNetwork
Network
Radio
283
283
3GPP SIP Overview

o 3GPP SIP is based on:
IETF RFC 3261 SIP: Session Initiation Protocol,
Other relevant IETF RFCs and drafts, and
Any additional enhancements required to support 3GPPs needs.
3GPP specific extensions or modifications are included in the 3GPP
Specifications.
o 3GPP SDP is a subset of IETF RFC 2327 SDP: Session

Description Protocol and the new SDP draft (draft-ietfmmusic-sdp-new).
o The usage of 3GPP SIP and SDP is described in 3GPP TS
24.229. Example flows are shown in 3GPP TS 24.228.
o 3GPP submitted a 3GPP requirements draft (draft-ietfsipping-3gpp-r5-requirements) to IETF stating the
requirements identified by 3GPP to support SIP for IP
Multimedia Subsystem (IMS) in cellular networks.
284
284
Differences to IETF SIP

o 3GPP CSCFs are not pure (as defined in the IETF SIP standard) SIP proxies
o User identification: Every 3GPP user must have a private user identity and one
or more public user identities.
o 3GPP UEs must register before initiating or terminating a session, except for
Emergency sessions.
o User authentication is performed via SIP Registration procedures.
o 3GPP provides the capability for an operator to hide the topology of its network
from other networks.
3GPP agreed a Topology Hiding Inter-network Gateway (THIG) function in
the I-CSCF.
This was required by AWS only and has become optional
o Network Initiated De-registration and Re-authentication: The network must be

able to de-register a user and request the user to re-authenticate at any time.
3GPP agreed using the SUBSCRIBE/NOTIFY procedure for informing the UE
of de-registrations and re-authentications.
o Loss of radio contact with the UE.
3GPP agreed to allow the P-CSCF to send BYE requests on behalf of the UE
285
285
3GPP SIP Requirements

o Pre-conditions for resource reservation
Reliability of Provisional responses (RFC 3262)
Support of the PRACK method. Provides a means for sending provisional
responses reliably.
SIP UPDATE method (RFC 3311)

Support of the UPDATE method.
Integration of Resource Management and SIP (RFC 3312)

Setting of QoS resources in SDP.
o Control of message routing through P-CSCF

SIP extension for registering non-adjacent contact (RFC 3327)
Support of the Path header in the REGISTER method
o Extensions for Policy control

SIP extensions for Media Authorization (RFC 3313)
Support of the P-Media-Authorization header.
Grouping of media lines (RFC 3388):

General-purpose grouping of several m= lines using SDP.
Mapping of Media Streams to Resource Reservation Flows

(RFC 3524)
Defines how SDP is used to do indicate flows that need to be kept
separate
286
286

o Miscellaneous
Security mechanism agreement for SIP (RFC 3329)
Security headers used to negotiate security mechanisms and
parameters. "ipsec-3gpp" security mechanism
Signaling Compression (SigComp) (RFC 3320)

Support of signaling compression is mandatory in the UE and P-CSCF
New auth-param parameter defined for WWW-authenticate header,

which is used to pass the Integrity Key and Cipher Key during the
registration process that sets up the integrity protected relationship
between the UE and P-CSCF
New tokenized-by parameter, which is used to carry encrypt/decrypt
strings within the SIP headers to implement the I-CSCF THIG
function
o Extensions to support multiple public identities

P-Associated-URI
Transports the implicitly registered public identities to the P-CSCF in the
200 OK response to REGISTER. Then P-CSCF knows which identifies
this user is allowed to use
P-Called-Party-ID
Transport of the originally dialed SIP URL to the UE for an incoming call.
Then terminating UE knows which identity the call was directed to
287
287

o Extensions for roaming & cellular network support
P-Visited-Network-ID
Transport of Visited Domain name to the home network in order to check for
roaming agreements between the home and visited network.
P-Access-Network-Info
Transport of Access Network and Cell-Id information to the serving proxies in the
home network.
P-Service-Route
Passes S-CSCF identity to UE, so outgoing calls will be routed corrected to SCSCF via P-CSCF
o Support for reliable identification of called and calling parties

P-Preferred-Identity
Used by UE in request messages to provide a hint of its identity to the network.
P-Asserted-Identity
Used by P-CSCF to convey the identity of the sender towards the S-CSCF.
o Extensions to support charging

P-Charging-Function-Addresses
Transport the Charging Collection Function (CCF) and Event Charging Function
(ECF) addresses from S-CSCF to P-CSCF.
P-Charging-Vector
Transport the charging correlation information from P-CSCF to S-CSCF.
288
288
Services on IMS
o 3GPP standardizes IMS Service Capabilities NOT
Services
3GPP defines mechanisms for services based on Presence,
MMS, Streaming, but those services that would use these are
not defined
o Services that can be built on IMS
Presence
Instant Messaging
Streaming
Combinations and integration of these
o Services are implemented in Home Network

Service knowledge not required in Visited Network
o Three Service Platforms

CAMEL/INAP (IMS-SSF)
OSA (OSA-SCS)
SIP (SIP-AS)
289
289

Service
Logic
Native SIP
Services
All 3 types of AS
behave as SIP AS on
ISC interface towards
S-CSCF
Servlet/CPL/API
SIP
AS
DIAMETER
ISC
(SIP+)
HSS
Cx
S-CSCF
ISC
(SIP+)
IM SSF
MAP
Legacy IN
Services
CAP
CAMEL
Service
Environment
3rd Party
Services
ISC
(SIP+)
OSA/Parley
Gateway
S-CSCF
OSA
API
OSA
Application
Server
Serving -Call Session Control

Function
IM SSF
IP Multi-media Service
Switching Function
HSS
Home Subscriber Store
ISC
IMS Service Control Interface
290
290

o Networks may contain more than one application server
o Application Server (AS) may be specialized to certain
services
o S-CSCF communicates with AS via the IP multimedia
service control (ISC) interface
o ISC makes use of SIP - pure SIP like other IMS
interfaces
o Application Server can be in the own network or in third
party networks
o AS can either act as originating UA, terminating UA, SIP
proxy, SIP redirect server or B2BUA
o Functionality of proxy depends on situation, parameters
and configuration as well as on application itself
o AS may or may not remain in signaling path
291
291
IMS Application Server (AS)

o Can be an End-User Service that includes
communication service logic & client software
o Can be a Service Enabler that can be called and shared
by many end-user services
o Includes Software Development Kit (SDK) to allow
Service Providers and developers to easily deploy new
services
o Can interact with other AS to generate new composite
services via Service Orchestration Framework
o Pure IMS Applications the new presence based IMS
services (e.g. push-to-talk, push-to-video, push-to-text)
o Hybrid applications bridging between traditional telecom
and IMS domain
292
292
IMS Service Control Interface (ISC)

o SIP based interface between the S-CSCF and the
service platforms
o Support subscription to event notifications between the
AS and SCSCF
o Transport presence related messages, according to the
Presence Service Platform
o Allow the AS to be notified of the implicit registered
Public User Identities, Registration State and UE
capabilities and characteristics
o SCSCF perform any filtering (based on information
received from the HSS) for ISC interaction
o Shall be able to convey charging information
293
293
Filter Criteria Triggering Example

1.
2.
3.
4.
5.
6.
7.
User initiates a SIP session by sending a

SIP INVITE with header=A to its S-CSCF
S-CSCF evaluates the SPTs and finds a
match with the filter criteria X. S-CSCF
forwards request to AS1.
AS1 performs any needed service logic
and sends the SIP request back to the SCSCF with a service related modification,
i.e. change header=A to header=B.
S-CSCF evaluates the SPTs and finds a
match with the filter criteria Y. S-CSCF
forwards the request to AS2.
AS2 performs any needed service logic
and sends SIP request back to the SCSCF.
No more filter criteria, S-CSCF forwards
this request to the next hop based on the
route decision.
If in step 3, the header was not changed
by AS1, then S-CSCF evaluates the
SPTs and does not find a match and
routes the request to the next hop.
Application
Application
Server 1
Server 2
SIP message
now with
header=B
ISC Interface
2
Incoming SIP Leg
SIP message
possibly
modified
4
INVITE Match Initial Filter Criteria

Out-Going SIP Leg
S-CSCF
INVITE
Filter Criteria X to AS1 SPT HeaderA priority 1
Header =A
Filter criteria Y to AS2 SPT HeaderB priority 2
SIP message forwarded by S-CSCF
Same logic for Mobile origination and Mobile termination. On registration,

the S-CSCF also checks filter criteria. If there is a match, S-CSCF
performs 3rd party registration to the AS which may execute services.
294
294
Need For Convergence

o Carriers are pursuing opportunities to improve financial
performance and create differentiated service offerings
o Users are expecting services that are:
Independent of access
Have the same look and feel
With rich media content
Can be delivered to different types of devices
Convenience and ease of use
o Integration of wireline & wireless experience can result in

Lower customer churn
Lower operational & capital costs
Higher revenue per subscriber
o Evolution to VoIP offers the opportunity to provide new

services, such as Presence-enabled services,
multimedia services, collaboration services, etc
295
295
Driving forces for Convergence
Convergence from two sides

Service convergence
Fixed network
towards convergence
Control convergence
Mobile network
towards convergence
Network convergence
Terminal convergence
296
296
Expected Future Transition Trend

Past : Separate of Voice & Data Transport
Circuit Switch
Access
Capability
Circuit Switch
Transport Capability
Packet Switch
Present : Separate of V & D Access
Circuit Switch
Access Capability
Packet Switch
Access Capability
Circuit Switch
Packet Switch
xDSL / FTTx
Future : Integration of V & D Access and Transport
Near Future : Integration of V & D Transport

Circuit Switch
Access Capability
Packet Switch
Access Capability
Packet Switch
Packet Switch
Access Capability
Circuit Switch
Packet Switch
VoIP / VToA
297
297
Current Transition Trend

1
Softswitch
AS
AS
LDAP
LDAP
LDAP
Softswitch
LDAP
AS
AS
LDAP
LDAP
Common Session Control
Softswitch
LDAP
AS
AS
LDAP
LDAP
Common Session Control

HSS
VOIP
Session
IM
Session
IM
Session
HSS
Adapter
SIP
Terminal
SIP
Terminal
SIP
Terminal
Integrated Vertical Structure
SIP Terminals
SIP Terminals
Intermediate Horizontal Structure IMS Horizontal Structure

298
298
Converged Architecture
o Separation of access & transport layers from service
layer
o Session management across multiple real-time
communication devices
o Interworking with legacy TDM networks
o Blending of real-time and non-real-time communication
services
o Consistency in sharing user profiles across services
o Consistent authentication & billing mechanism
o Consistent user interface
o Open standards & APIs for new services
299
299
How to operate Convergence

Radio Access
Network
Base
Station
Controller
UMA-enabled
Dual Mode
Handset
GSM/IMS Core
Service
Architecture
WiFi
Tunneled
IMS stack
IP Access Network
GANC
(UMA)
Network
Controller
RG
Native IP
Stack
SIP
Fixed/Wireless Telephone
IP Core Transport
VOIP
SIP Server
300
300
TISPAN Basic Objectives

o TISPAN NGN project launched at Dec 2003.
o Simplification of IMS for use over fixed networks
o Adds a series of sub-systems that better meets the border
needs to those transitioning to next generation networks
A resource and admission control subsystem
A network attachment subsystem
o Add new concepts, key to convergence/migration

PSTN/ISDN Emulation
PSTN/ISDN Simulation
o Regulatory related features according to the EU framework

directive (e.g. E112 Emergency Services, Malicious Call
Identification, Anonymous Call Rejection)
o Uses MGCP/H.248 at the edge & SIP in the core
o Management and operational needs including charging and
accounting
301
301
TISPAN Architecture
Applications
Based on
3GPP IMS
IP Connectivity
Access Network
And related functionality
Data
Base
Other Multimedia
Components
Streaming Services
(RTSP based)
PSTN / ISDN Emulation

(SIP-I based)
Network Attachment
Functionality
NASS
GW
NGN
Terminals
Customer
Networks
NGN
Terminals
Resource and Admission

Control Functionality
RACS
Go
interface
GW
Legacy
Terminals
IP
Access Transport
Network
PSTN / ISDN
Legacy
Terminals
Gq
interface
Legacy
Terminals
TGW
Core transport
Network
Other Networks
ICF
IP Multimedia
Component (Core IMS)
(SIP based)
MBG
3GPP IP-CAN
3GPP Terminals
302
302
Network Access Attachment

Application Functions
RACF
CPE
Transport Functions
Functions in other domains
NAAF
o Dynamic provision of IP address and other user equipment

configuration parameters
o Authentication of user access network, prior or during the IP
address allocation procedure
o Authorization of user access network, based on user profiles
o Access network configuration, based on user profiles
o Location management
303
303
Resource And Admission Control

Service Control Functions
SCPF
Service Stratum
SCF
Gq
Gq
Transport Stratum
IBCF
Resource And Admission Control Functions
Rq
Network Access
Attachment
Functions
Access
CPN
A-TRCF
Core
Rq
C-TRCF
Rq
I-TRCF
Ub
Re
R-BGF
Rq
I-PDF
Other NGNs
Resource Mediation
M-PDF
ANF
Rc
Re
ENF
Access Transport
Go
Rc
A-BGF
Rc
I-BGF
Core Transport
304
304
Resource And Admission Control

o Covers procedures for the control of QoS (including
resource reservation, admission control and gate
control), control of NAPT and Firewall traversal
Maps the service QoS parameters received from the SCF to
network QoS parameters (transport technology independent)
Maps the network QoS parameters to transport technology TRCF
dependent QoS parameters (transport technology dependent)
Controls network address translation for both near end NA(P)T
and far end NA(P)T
o Admission control involves checking authorization based

on user profiles, SLAs, operator specific policy rules, and
resource availability within access and core transport
Performs the policy decisions in terms of network resources and
admission control, based on request information from the SCF
Controls resources at the element level (such as control of
policing and shaping)
o Acts as the arbitrator for resource negotiation and

allocation between Application Functions and Transport
Functions
305
305
PSTN/ISDN Emulation
ADF
Originating
Legacy Terminal
Next Generation
Network
ADF
Terminating
Legacy Terminal
ADF = Adaptive Function
o Provides PSTN/ISDN-like service capabilities using session

control over IP interface and infrastructure
o Mimicking a PSTN/ISDN network from legacy users
perspective by an IP network using gateways, thereby
making existing PSTN/ISDN services available and
identical
o H.248 is used by the Emulation Application Server to
control the Gateway
306
306
PSTN/ISDN Simulation
SIP
Client
NGN
NGN
NGN
NGN
NGN
Originating
Network
Originating
Subscribers
Home Network
Core Transit
Network
Terminating
Subscribers
Home Network
Terminating
Network
SIP
Client
NGN = Next Generation Network
o Provides PSTN/ISDN service capabilities & interfaces

using adaptation to and IP infrastructure
o Provisioning PSTN/ISDN services to IP phones or IP
interfaces, thereby providing PSTN/ISDN user experience
to advanced users
o Uses pure SIP mechanism, (or 3GPP / TISPAN versions)
and shares capabilities with a range of new services
307
307
Differences - NGN and 3GPP IMS

o Wireline versus Wireless
Constraints in terms of bandwidth scarcity, security, transmission delay are
different
o Terminals
Different requirements placed on NGN terminals (e.g. support of IPv6,
availability of UICC device)
o Location Information
Location information different in nature and usually not available at the
terminal
o Resource management
Explicit resource reservation signalling not available in terminals and access
network edge points
Common resources shared between the signalling and media flows
o Regulatory issues
Different constraints
308
308
NGN Mobility Requirements

o Ability to change access point and/or terminal, i.e.
support for terminal mobility
o Ability to get access from any network access point,
including all access technologies identified i.e. support
for personal mobility
o Ability to get services in a consistent manner, subject to
the constraints experienced in their current situations i.e.
support for service mobility
o User availability and reach ability should be known to
network functions and possibly to services and
applications (including by a third party) i.e. support for
personal and service mobility
309
309
NGN Mobility Requirements Scenarios

Access
Node
Intermediate
Node
Border
Gateway
Node
Access Network
NGN Core Network
Border
Node
Border
Gateway
Node
NNI
NGN Core Network
Access
Node
Inter-AN
Access
Node
Border
Node
Intermediate
Node
Access
Node
Inter-CN
Access Network
Border
Node
Border
Node
Intra-AN
Border
Gateway
Node
Intermediate
Node
Access
Node
Inter-TE
Access Network
310
310
SIP And Terminal Mobility

o Terminal can move between sub networks
o Issues to consider
Handoff performance
Redirection authentication
o Mobile hosts (MH) inform their home proxy (HP) about

their new locations using REGISTER
o Mid-call mobility (Session mobility) is dealt with using
Re-INVITE
311
311
SIP And Terminal Mobility

Home Network
Home Network
Home
Proxy
V I TE
#2
Re-I
N
TE
TER
#6
INVI
#6
REG
IS
#2
#5
T ER
#3
Home
Proxy
Re-INVITE
REG
IS
INVITE
#4
#4
#3
Re-INVITE
#5
INV
Visited
Proxy
RE
G
#1
IST
I TE
ER
Visited Network
Cell 2
Cell 1
REGISTER
Visited
Proxy
Cell 2
#1
Cell 1
Visited Network
312
312
SIP And Personal Mobility

o Person uses different Devices and possibly address
o REGISTER binds a person to a device
o Proxy and redirect translate address to location and
device
o Issues to consider:
Authentication
Binding different addresses to single person
313
313
SIP And Service Mobility

o Use same services from different locations and devices
Speed dial, address book, media preferences, call handling
o Services located at home server

RECORD-ROUTE home proxy to force calls to be processed by
home servers
Services located at end systems retrieve with REGISTER
o Issues to consider
Services need to be device independent
User recognition and authentication
314
314
SIP & SIMPLE
315
315
Contents
o Presence
o SIP Extensions for Presence
o Instant Messaging (IM)
o SIP Extensions for IM
316
316
Presence
o Also known as Buddy Lists
o Indicates Online/Offline status
Busy, Not At My Desk
Willingness
Only if urgent
Try cell phone first, then business line
Always send email
o Largely to enable Instant Messaging (IM)

o Users subscribe to Friends List
When friends Log On/Off, notifications are sent
o Access Control
User-based
Time-based
Location-Based
317
317
SIP Extension for Presence

SUBSCRIBE
Subscriber
(Watcher)
REGISTER
Proxy
NOTIFY
Presence Agent + Proxy/Registrar
= Presence Server
Presentity
o Watcher
Client of the system that asks for information about another user
in the system
o Presentity
User of the system that a watcher can ask about
o Presence Agent (PA)
Purely logical entity

Knows presence state of user
Receives SUBSCRIBE requests
Generates NOTIFY requests
Co-located with proxy/registrar or User Agent
318
318
SIP Extension for Presence

SUBSCRIBE
Subscriber
(Watcher)
REGISTER
Proxy
NOTIFY
Presence Agent + Proxy/Registrar
= Presence Server
Presentity
o Presence User Agent (PUA)

Manipulates presence information for a presentity
Allow multiple PUAs (e.g. cell phone and Personal Digital
Assistant) per presentity
Each is independently generating a component of the overall
presence information for a presentity
Push data into the presence system
o Presence Server
Physical entity that can act as either a presence agent or as a
proxy server for SUBSCRIBE requests
Aware of the presence information of the presentity when acting
as a PA
SUBSCRIBE requests are proxied to another entity that may act
as a PA, when acting as a proxy
319
319
Presence Basic Operation

o
o
o
o
o
o
Subscriber send SUBSCRIBE

Routed to PA using normal SIP
PA authorizes subscriber
Acceptance contains presence state
NOTIFY sent when state changes
Routed using SIP Record-Route
SUBSCRIBE sip:bob@wipro.com SIP/2.0

Event: presence
To: sip:bob@wipro.com
From: sip:user@example.com
Contact: sip:user@userpc.example.com
Call-ID: knsd08alas9dy@3.4.5.6
CSeq: 1 SUBSCRIBE
Expires: 3600
Content-Length: 0
NOTIFY sip:user@userpc.example.com
To: sip:user@example.com
From: sip:alice@wonderland.com
Call-ID: knsd08alas9dy@3.4.5.6
CSeq: 1 NOTIFY
Content-Type: application/xpidf+xml
<?xml version="1.0"?>
<!DOCTYPE presence
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:alice@wonderland.com;method="SUBSCRIBE">
<atom id="779js0a98">
<address uri="sip:alice@wonderland.com;method=INVITE">
<status status="closed"/>
</address>
</atom>
</presentity>
</presence>
320
320
Instant Messaging (IM)

o Defined as the exchange of content between a set of
participants in near real time
o Content is short text messages
o User can choose to send an IM to a contact, or he can
choose to invite one or more contacts to join a
conversation
o May or may not be stored (similar to Email)
o Tied to Presence
321
321
SIP Extension for Instant Messaging

o Operation of Extension
Messages carried in SIP messages
New method - MESSAGE
Routed to recipient using normal SIP techniques
o Features
Associates an IM with an existing call

Any MIME data can be sent
TCP for large messages
Routed by existing proxies and registrars
Possible to have a different client for IM and other types of
communications
322
322
IM - Basic Operation
o Sender formulates and issues a SIP request using the
new MESSAGE method
o Body of the request will contain the message to be
delivered
o Request may traverse a set of SIP Proxies, before
reaching its destination
o Provisional and final response will be sent to the sender
MESSAGE sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/TCP uac.example.com;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=1234
Call-ID: d432fa84b4c76e66710
CSeq: 1 MESSAGE
Content-Type:text/plain
Content-Length: 15
Hello World
323
323
Advantages of Using SIP/SIMPLE

o Unifies major communications services
Voice/video
IM
Presence
o Increases call completion rate

Drastically improves efficiency of IP communications
o Improves the user experience

o Dissociate concept of presence from a specific
application and apply it to virtually any application
o Reduces Management Costs
324
324
SIP & Services
325
325
Contents
o
o
o
o
o
o
o
SIP REFER Method

SIP Refer-To Header
SIP Call Transfer Blind
SIP Replaces Header
SIP Call Transfer Attended
SIP Message Summary/Waiting Indication
Push To Talk Over Cellular (PoC)
326
326
REFER Method
o Indicates that the recipient (identified
by the Request-URI) should contact a
third party using the contact
information provided in the request
o Contain exactly one Refer-To header
field value
o Request may be placed outside the
scope of a dialog created with an
INVITE
o Implicitly establishes a subscription to
the refer event
o Each NOTIFY must contain a body of
type "message/sipfrag"
o The body of a NOTIFY must begin
with a SIP Response Status-Line
o Can be used to enable many
applications, including Call Transfer
REFER sip:b@atlanta.example.com SIP/2.0

Via: SIP/2.0/UDP agenta.atlanta.example.com;
branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=1234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: sip:alice@atlanta.example.com
Contact: sip:a@atlanta.example.com
Content-Length: 0
NOTIFY sip:a@atlanta.example.com SIP/2.0

Via: SIP/2.0/UDP agentb.atlanta.example.com;
branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=1234
From: <sip:b@atlanta.example.com>;tag=5678
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
SIP/2.0 100 Trying
327
327
Refer-To Header
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param)
o
o
o
o
Request header field, appears only in a REFER request

Provides a URL to reference
May be encrypted as part of end-to-end encryption
Resource identified by the URI is contacted using the
normal mechanisms for that URI type
o Compact form of the Refer-To header field is r
o Examples of valid Refer-To header fields:
Refer-To: sip:alice@atlanta.example.com
r: <sip:carol@india.example.org;method=SUBSCRIBE>
328
328
SIP Call Transfer - Blind

Originator
User A
1
Call Transfer
Initiated using
REFER
Recipient
User B
INVITE
200 OK
ACK
Two way Speech Path
Call Transfer
Success using
REFER
REFER: Refer-To: C
202 Accepted
5
6
NOTIFY : 200 OK
10
200 OK
BYE
12
Final Recipient
User C
INVITE
200 OK
8
9
ACK
Two way Speech Path
11
200 OK
329
329
Replaces Header
Replaces = "Replaces" HCOLON callid *(SEMI "to-tag" EQUAL token / "from-tag" EQUAL token / "early-only"
o Used to logically replace an existing SIP dialog with a new

SIP dialog
o Replace one participant with another in a multimedia
conversation
o Useful in peer-to-peer call control environments like
Attended Call Transfer, Call Pickup
o Contains information used to match an existing SIP dialog
(call-id, to-tag, and from-tag)
o Must contain exactly one to-tag and exactly one from-tag,
as they are required for unique dialog matching
o Examples of valid Refer-To header fields:
Replaces: 87134@171.161.34.23;to-tag=24796;from-tag=0
Replaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321;early-only
330
330
SIP Call Transfer Attended (1)

Originator
User A INVITE/200/ACK
Final Recipient
User C
Recipient
User B
Call-ID:1;FromTag=11;ToTag=22
Two way Speech Path
INVITE (Hold)
200 OK
ACK
Call Transfer
Initiated using
REFER
INVITE Call-ID:2;FromTag=33
200 OK Call-ID:2;FromTag=33;ToTag=44
ACK Call-ID:2;FromTag=33;ToTag=44
REFER: Refer-To: <Final
Recipient?Replaces:Call-ID:2;
FromTag=33 ;ToTag=44
202 Accepted
331
331
SIP Call Transfer Attended (2)

Originator
User A
Call Transfer
Success using
REFER
NOTIFY : 200 OK
200 OK
Final Recipient
User C
Recipient
User B
INVITE: Replaces:Call-ID:2;
FromTag=33 ;ToTag=44
Call-ID:3;FromTag=55
ACK Call-ID:3;FromTag=55;ToTag=66
Two way Speech Path
BYE
200 OK
BYE Call-ID:2;FromTag=33;ToTag=44
332
332
SIP Message Summary And Message-Waiting Indication

PSTN
Switch
User A
SMDI
VoiceMail
Server
Traditional Voice Mail System

User B
o Typically involves an audible or visible indication that

messages are waiting
Playing a special dial tone (which in telephone networks is called
message-waiting dial tone)
Lighting a light or indicator on the phone,
Displaying icons or text
333
333
SIP Message Summary And Message-Waiting Indication

PSTN
Switch
IP Network
SIP
VoiceMail
Server
SIP
User A
SIP
Switch can act as a

SIP UA on behalf of
TDM clients
User B
SIP
Client
SIP-Based Voice Mail

System
o Using SIP-Specific Event Notification, UA subscribes to the

status of their messages
o SIP UA acting on behalf of the user's messaging system
then notifies the Subscriber each time the messaging
account's messages have changed.
o The Notifier sends a message summary in the body of a
NOTIFY, encoded in a new MIME type
o User Agent can also explicitly fetch the current status
334
334
Message Summary/Waiting Indication Payload

o Defined new event-package "message-summary"
o Defined a simple text-based NOTIFY body
o Defined new MIME type "application/simple-messagesummary"
o Messages are separated by message-context class (e.g.
voice-message, fax-message, etc)
o Begins with a simple status line (allows messaging
systems or messaging gateways to provide the traditional
boolean message waiting notification), and optionally a
summary line per message-context-class
o For each message-context-class, the total number of new
and old messages is reported in the new and old fields
335
335
Message Summary/Waiting Indication Payload

MWI SUBSCRIBE
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
To: <sip:alice@example.com>
From: <sip:alice@example.com>;tag=78923
Call-Id: 1349882@alice-phone.example.com
CSeq: 4 SUBSCRIBE
Max-Forwards: 70
Contact: <sip:alice@alice-phone.example.com>
Expires: 86400
Accept: application/simple-message-summary
Content-Length: 0
MWI NOTIFY (OFF)

NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
CSeq: 20 NOTIFY
Contact: <sip:alice@vmail.example.com>
Content-Length: 20
MWI NOTIFY (ON)

NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
CSeq: 20 NOTIFY
Contact: <sip:alice@vmail.example.com>
Content-Length: 99
Message-Account: sip:alice@vmail.example.com VoiceMessage: 2/8 (0/2)
Messages-Waiting: no
336
336
SIP MWT Sample Call Flow

Originator
User A
User B subscribes
for MWT Notification
Notifier
Voice Mail Server
Subscriber
User B
SUBSCRIBE : message-summary
200 OK
User B is not
available to receive
the call from User A
NOTIFY : MWT=NO
200 OK
User A calls User B (CFD) forwarded to Voice Mail Server. User A leaves a message for User B and disconnects the call
User B receives
MWT YES
Notification
NOTIFY : MWT=YES
200 OK
User B retrieves the message from the Voice Mail Server
User B receives
MWT NO
Notification
NOTIFY : MWT=NO
200 OK
337
337
Pre-paid on the SIP B2BUA

Sta
RADIUS /
Billing Server
VI
IN
TE
si
94
91
:
p
En
dC
0
00
1
72
w/
rt B
SIP Controller
B2BUA Application
illin
g
all
P
SD
20
of
K
0O
P
SI
w/
e
on
h
P
P
SD
SI
GW
P-
200
IN V
IT E
OK
w/
s ip
:91
SD
Po
fS
AC
K
939
I PGW
210
00
w/
SD
Pre-Paid Client
PSTN
338
338
Push-To-Talk Over Cellular (PoC)

o Method of conversing on half-duplex communication lines,
including two-way radio, by pushing a button in order to
send, allowing voice communication to be transmitted,
and releasing to let voice communication be received
o Only one person at a time can talk, by pressing a PTT
button, and one or several others can listen instantly
o Intended to provide rapid communications for business
and consumer customers of mobile networks
o Allow user voice and data communications shared with a
single recipient, (1-to-1) or between groups of recipients
as in a group chat session
339
339
PoC 1-to-Many Group Session
Member A
Wireless Network
Member E
Member B
Member D
Member C
340
340
Logical Architecture of PoC
341
341
PoC Client Functionality

o
o
o
o
o
o
o
o
o
Allow session initiation, participation and release

Perform registration with the SIP/IP Core
Authentication of the PoC User to the SIP/IP Core
Generate and send Talk Bursts by recording and encoding
audio
Receive Talk Bursts and generate audio by decoding the
received Talk Bursts.
Support the capability of a PoC User to set the Answer
Mode Indication (Manual, Automatic), Incoming PoC
Session Barring and Incoming Instant Personal Alert
Barring
Support receiving of Instant Personal Alert
May provide group advertisement
Request privacy of User Identity
342
342
PoC Server Functionality
o Performs a Controlling PoC Function and/or Participating

PoC Function
o Determination of the PoC Server role takes place during
the Session setup and lasts for the duration of the whole
Session
343
343
PoC Server Functionality

o Controlling PoC Function
Only one per session
Provides centralized PoC session handling
Provides the centralized media distribution
Provides SIP Session handling, such as SIP Session origination,
release, etc.
Provides policy enforcement for participation in Group Sessions
Provides centralized charging reports
o Participating PoC Function

One or more per session
Provides PoC session handling
Provides SIP Session handling, such as origination, release, on
behalf of the represented PoC Client
Provides policy enforcement for incoming PoC session (e.g. Access
Control, Incoming PoC Session Barring, availability status, etc)
Provides the Participant charging reports
344
344
Ad-hoc Group Session Invitation

PoC
Client A
1
SIP/IP
Core
PoC Server A
(Participating & Controlling)
INVITE
2
ALERTING
INVITE
ALERTING
First ALERTING
Response
OK
First accepted
invitation
OK
Talk Burst Confirms
10
Invitations to invited
POC subscriber
Media
345
345
Pre-Arranged Group Session Setup

PoC
Client A
1
POC Client A Home Network
PoC Server A
(Participating)
SIP/IP
Core A
INVITE
2
Controlling Network
PoC Server X
(Controlling)
SIP/IP
Core X
INVITE
INVITE
INVITE
INVITE
ALERTING
ALERTING
11
OK
OK
OK
OK
10
13
OK
ALERTING
Invitations to the
group members
First ALERTING
Response
ALERTING
ALERTING
First accepted
invitation
12
14
15
Talk Burst Confirms 16

Talk Burst Confirms
16
346
346
Pre-Arranged Group Session Setup

PoC
Client A
1
POC Client A Home Network
PoC Server A
(Participating)
SIP/IP
Core A
INVITE
2
Controlling Network
PoC Server X
(Controlling)
SIP/IP
Core X
INVITE
INVITE
INVITE
INVITE
ALERTING
ALERTING
11
OK
OK
OK
OK
10
13
OK
ALERTING
Invitations to the
group members
First ALERTING
Response
ALERTING
ALERTING
First accepted
invitation
12
14
15
Talk Burst Confirms 16

Talk Burst Confirms
16
347
347
SIP Application
Framework
348
348
Contents
o JAIN SIP
o JAIN SIP 3PCC Call Flow
o SIP Servlet
o SIP Servlet CSBNA Call Flow
o SIP Lite
o SIP for J2ME
o End to End architectures using the SIP
APIs
349
349
JAIN SIP
o Java-standard interface to a SIP signaling stack
Standardizes the interface to the stack

Standardizes message interface
Standardizes events and event semantics
Application portability
o Designed for developers who require powerful

access to the SIP protocol for desktop and server
applications
o Can be utilized in a user agent, proxy, registrar or
imbedded into a service container
o Enables transaction stateless, transaction stateful
and dialog stateful control over the protocol
350
350
JAIN SIP Object Architecture
SIP Listener
getInstance()
Event
Registration
createProvider()
SIP Provider
Proprietary
SIP Stack
Network
SIP Factory
createStack()
SIP Factory
createListener()
SIP Stack
Proprietary
SIP Stack
351
351
JAIN SIP - Responsibilities

o Provide methods to format SIP messages
o Provides ability for an application to send and
receive SIP messages
o Parse incoming messages and enable application
access to fields via a standardized Java interface
o Invoke appropriate application handlers when
protocol significant
Message arrivals and Transaction time-outs
o Provide Transaction support and manage

Transaction state and lifetime on behalf of a user
application
o Provide Dialog support and manage Dialog state
and lifetime on behalf on a user application
352
352
JAIN SIP Messaging Architecture

Application
SipListener
SipListener
SIP Messages
SIP Messages
SIP Events
SIP Events
SipProvider
SipProvider
Listening Point
Listening Point
Stack
Network
Stack
353
353
JAIN SIP 3rd Party Call Control

SipListener
SipFactory
SipProvider
createReq(INVITE, -)
createClientTransaction(inviteA)
sendRequest()
Client
Transaction
Dialog A
Dialog B
SIP
Party A
SIP
Party B
new()
new()
null
INVITE(SipListener, A)
createReq(INVITE, offerA)
createClientTransaction(inviteB)
sendRequest()
confirmed
new()
200OK(offerA)
null
new()
INVITE(SipListener, B)
ACK(offerA)
ACK(offerB)
confirmed
200OK(offerB)
createReq(re-INVITE)-setBody(offerB)
createClientTransaction(inviteC)
sendRequest(clientTransC)
Re-INVITE(offerB)
200OK(offerB)
ACK(offerB)
RTP
354
354
SIP Servlet
o Java-based application component which is
managed by a SIP servlet container and which
performs SIP signaling
o Platform independent Java classes that can be
loaded dynamically into and run by a javaenabled SIP application server
o Containers, sometimes called servlet engines, are
server extensions that provide servlet functionality
o Servlets interact with (SIP) clients by exchanging
request and response messages through the
servlet container
355
355
SIP Servlet - Responsibilities

o SIP Signaling
Allows applications to perform functionality of user agent client (UAC),
user agent server (UAS), and proxy
o Simplicity
Containers handle non-essential complexity such as managing network
listen points, retransmissions, CSeq, Call-ID and Via headers, routes, etc
o Converged applications
Containers to support converged applications (e.g. Web, telephony,
Presence)
o Third party application development

An XML deployment descriptor is used to communicate application
information from the application developer to deployers
o Application composition
Several applications to execute independently on the same incoming or
outgoing request or response in a well-defined and orderly fashion
o Carrier grade
Application data stored in container managed session objects may persist
and/or replicate to achieve high availability
356
356
SIP Servlet - Call Schedule on Busy or No Answer

Alices Web
Browser
10
HTTP GET
200 OK
HTTP POST
Bobs
SIP UA
Converged
Servlet Container
Alices
SIP UA
INVITE
100 Trying
ACK
INVITE
486 Busy
5
7
ACK
9
11
200 OK
13
17
22
INVITE
200 OK
ACK
INVITE
200 OK
ACK
15
SUBSCRIBE
200 OK
NOTIFY
200 OK
12
14
16
18
19
INVITE
200 OK
20
21
23
23
ACK
RTP
357
357
SIP Lite
o An abstracted view of the SIP protocol that provides a SIP
programming environment for developers
o API specification is primarily developed for the J2SE
platform to provide a rich object model that may be
suitable for midsize devices with more processing power
and memory than mobile handsets, i.e. PDAs and SIP
phones
o Defines a three-tier architecture, where the Listener exists
for a Dialog, a Call and a CallProvider - listen for incoming
messages, dialogs and calls respectively
o Define a single Message interface identified based on
Request and Response constants
o Defines the concept of a Call and Dialog interface within
which a Call may contain multiple Dialogs
o Specification designed specifically for User Agent
applications
358
358
SIP For J2ME

o Defines a SIP interface for small platforms
o Specification is based on the Connected
Limited Device Configuration (CLDC)
framework within the J2ME platform
o Follows the simple and lightweight structure
used in conjunction with the Mobile
Information Device Profile (MIDP)
o Defined at the transaction level
359
359
End to End architectures using the SIP APIs

SIP Lite
Visited
Network
SIP for J2ME
SIP for J2ME
HSS
Home
Network
MGCF
SIP Servlet
JAIN SIP
P-CSCF
I-CSCF
JAIN SIP
S-CSCF
SIP Servlet
JAIN SIP
Application
Server
SIP Servlet
SIP Lite
Application
Server
SIP Servlet
Application
Server
MGW
SIP Lite
360
360
Questions ?
361
361

SIP Certification Rel.1.1

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SIP Certification Rel.1.1

Загружено:

Авторское право:

Доступные форматы

SIP/IMS Certification

Copyright 2006 Wipro Ltd

SIP Concept & Network

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

What Protocols Are Needed ?

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

Internet Multimedia Protocol Zoo

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

o Runs on top of several different transport protocols

o Modular design & highly scalable

Textual encoding (telnet, tcpdump compatible)

o Arbitrary services built on top of SIP

o Not limited to Internet telephony

o Suitable for applications having a notion of session

15 ASCII pages, one request type

30 ASCII pages, 2 request types

149 ASCII pages, 6 methods

153 ASCII pages, 6 methods

171 ASCII pages, 6 methods

It was recognized that the amount of

Proposal for splitting SIP WG into SIP

SIP implementations widely available

New SIP RFC published

SIP Working Groups

SIMPLE (SIP for Instant

Chartered to specify protocol required for Internet conferencing and multimedia

MIDCOM (Middle Box

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

SIP Working Groups

SPIRITS (Services in the

Allows for services supported by IP network entities getting initiated from IN

PINT (PSTN Interworking)

This WG specifies a protocol to perform the corollary of the SPIRITS (described

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

Other Related Bodies

Creation of technical specifications for 3rd Generation Mobile Systems

H.323 V1-V4 umbrella standard

Concerned with IP/PSTN interoperability

For promotion of SIP Technology

Established by CableLabs to look at cable technologies

JAIN (Java Advanced

Developing abstract APIs for developing service creations across PSTN,

Aims to intimately link IT applications with the capabilities of the

and the list goes on

SIP User Agent (UA)

o User Agent Server (UAS) :

o SIP User Agent (UA) :

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

SIP User Agent

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

SIP - Proxy Mode Operation

DNS Srv Query ? wipro.com

SIP Stateful Proxy

o May generate a CANCEL request for pending INVITE client

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

SIP Stateless Proxy

o Must not generate CANCEL request

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd

Stateless Versus Stateful Proxy

Good for implementing some services like