SIP Certification Rel 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

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

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

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.

Internet Multimedia Protocol Zoo
DIAMETER Media Encoding
(H.261, MPEG)
MGCP/Megaco TRIP
DNS RTP
SDP
H.323 COPS SIP RTSP RSVP RTCP
Transport
TCP UDP
Network
IPv4, IPv6
Data Link
PPP AAL3/4 AAL5 PPP

Physical
Sonet ATM Ethernet V.34

What Is SIP ?
o Application-layer signaling protocol for creating,
modifying, and terminating sessions with one or more
participants
Application Layer
o Sessions include Internet telephone calls, multimedia
distribution (voice, image, video, etc), and multimedia SIP
conferences
Transport Layer
o Session invitations carry session descriptions that (UDP, TCP, SCTP,
allow participants to agree on a set of compatible
media types. TLS)
o Uses proxy servers to help route requests to the Network Layer

user's current location, authenticate and authorize
users for services, implement provider call-routing (IP/ATM)
policies, and provide features to users (like presence,
mobility, hold, forward, transfer)
Data Layer
o Provides a registration function that allows users to
upload their current locations for use by proxy servers Physical Layer
o Runs on top of several different transport protocols
(UDP, TCP, SCTP, TLS)

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.
Brief History
Date Specifications Comments
1995 Work began in IETF mmusic WG
02/1996 draft-ietf-mmusic-sip-00 15 ASCII pages, one request type
12/1996 draft-ietf-mmusic-sip-01 30 ASCII pages, 2 request types
01/1999 draft-ietf-mmusic-sip-12 149 ASCII pages, 6 methods
03/1999 RFC 2543 153 ASCII pages, 6 methods
11/1999 SIP WG formed
11/2000 draft-ietf-sip-rfc2543bis-02 171 ASCII pages, 6 methods
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
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 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
Initiation Proposal feature using SIP, SIP-T, ISUP-SIP mapping, SIP Call flows, AAA requirements in SIP etc
Investigation)
SIMPLE (SIP for Instant 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
Messaging and Presence offered by SIMPLE), PIDF - Presence Info Data format, XCAP XML Configuration Access
Leveraging Extensions) Protocol etc
MMUSIC (Multiparty Chartered to specify protocol required for Internet conferencing and multimedia
communications. Specifies protocols such as SDP, RTP/RTCP, RTSP, Interactive
Multimedia Session Communication Establishment (ICE) for NAT discovery etc)
Control)
XCON (Centralized The focus of this working group is to develop a standardized suite of protocols for tightly-
coupled multimedia conferences, where strong security and authorization requirements are
Conferencing) integral to the solution. Standardizes protocols (based on SIP) like CPCP (conferencing
policy control protocol), BFCP (binary floor control protocol) etc
MIDCOM (Middle Box 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
communication)
ENUM (Electronic 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
Numbering) NAPTR (Naming Address Pointer) records for specifying the E.164 to URI conversion

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 Allows for services supported by IP network entities getting initiated from IN
(Intelligent Network) requests, as well as the protocol arrangements through which
PSTN/IN Requesting Internet PSTN (Public Switched Telephone network) can request actions to be carried out in
Services) 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
Other Related Bodies
3GPP (Third Generation Creation of technical specifications for 3rd Generation Mobile Systems
Partnership Project) 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 Developing abstract APIs for developing service creations across PSTN,
ATM, IP, etc.
Intelligent Network)
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
Network Architecture
SCP
SSP
DLC
STP
PSTN
PSTN GW
PBX
3rd Party
SIP/SIP-T Applications
DNS Location Application

Server Server
OSA
SIP Network Gateway
EBP SIP/SIP ISC

CMTS CMS/GC
SIP SIP/SIP ISC
User Application SIP/SIP-T CSCF
Agents Servers HSS
PacketCable Network
PCF
MGCF IM Subsystem
MTA MTA
WiFi/ VDSL FTTH

WiMax
CDMA/
GSM/UMTS
14
SIP "Trapezoid"
DNS Server Location Server
DNS
Outbound SIP Inbound

Proxy Server Proxy Server
SIP SIP
RTP
User Agent A User Agent B

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
SIP User Agent
o User Agent can be both SW and HW

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
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
SIP - Proxy Mode Operation
DNS Server LOCATION SERVER
subhodeep@192.219.223.160
#2
DNS Srv Query ? wipro.com
Callee
#3
Reply : IP Address of wipro.com SIP Server
subhodeep@wipro.com
INVITE sip:subhodeep@wipro.com INVITE sip:subhodeep@192.219.223.160

Caller@sip.com From: sip:Caller@sip.com From: sip:Caller@sip.com
To: sip:subhodeep@wipro.com To: sip:subhodeep@wipro.com
Call-ID: 345678@sip.com #1 #4
Call-ID: 345678@sip.com
200 OK 200 OK
#6 From: sip:Caller@sip.com #5
From: sip:Caller@sip.com
To: sip:subhodeep@wipro.com To: sip:subhodeep@wipro.com
Call-ID: 345678@sip.com
PROXY Call-ID: 345678@sip.com
#7 ACK sip:subhodeep@wipro.com
#8 Media Streams

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
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
Stateless Versus Stateful Proxy
Stateless Mode Stateful Mode
Usage
Good for heavy-load scenario, i.e. Core Good for implementing some services like
Network forward on no reply, i.e. Edge Network
Behavior
Proxies just receive messages, perform Proxies maintain state during entire
routing logic, send messages out transaction; they remember outgoing requests
as well as incoming requests until transaction
is over
Would result in new execution of SIP routing A forking proxy will be stateful
logic for every retransmission (caching routing
results can help reduce the overload)
No memory requirements Reduce retransmission time by acting on

behalf of sender closer to destination

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
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
SIP - Redirect Server Operation
LOCATION SERVER
Callee@home.com
#2
#3
Callee
Caller@sip.com
#1 INVITE Callee@example.com
302 Moved Temporarily

#4
Contact:Callee@home.com
PROXY
#5 ACK Callee@example.com
Callee@home.com
#6 INVITE Callee@home.com
#7 200 OK INVITE
#8 ACK Callee@home.com

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
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
SIP Registrar Operation
LOCATION SERVER
This registration example establishes presence

of user with address subhodeep@wipro.com and
subhodeep@192.219.223.160
binds this address to users current location

192.219.223.160
#2
REGISTER sip:register.wipro.com SIP/2.0

From: sip:subhodeep@wipro.com
To: 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
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
SIP B2BUA Operation
PSTN PSTN
VoIP Network
INVITE (Call-ID#1)
1 INVITE (Call-ID#2)
1
Calling Party Called Party
100 Trying 1
100 Trying
SIP Signaling 1
180 Ringing 1
& SDP Signaling 180 Ringing
1 Signaling
(UDP or TCP) 200 OK 1
200 OK 1
ACK
1
1
ACK
Bearer Or
Media (UDP) Media
RTP Stream

31
SIP Protocol Stack
o SIP is structured as a layered
protocol Transaction User
Lowest layer is syntax and encoding Transaction Layer
Second layer is the transport layer
Transport Layer
Third layer is the transaction layer
Layer above the transaction layer is called Syntax/Encoding
the transaction user (TU)
Transport Layer
Network Layer
Data Layer
Physical Layer

32
Syntax/Encoding Layer
o Lowest layer of SIP
Transaction User
o Responsible for encoding/decoding
and syntactical parsing of the Transaction Layer
messages Transport Layer
o Encoding is specified using an
Syntax/Encoding
augmented Backus-Naur Form
grammar (BNF)
Transport Layer
Network Layer
Data Layer
Physical Layer

33
Transport Layer
o Second layer of SIP
o Responsible for the actual Transaction User
transmission of requests and
responses over network transports Transaction Layer
o Responsible for managing persistent
Transport Layer
connections for transport protocols like
TCP, SCTP and TLS Syntax/Encoding
o Performs framing for message-oriented
transport like UDP Transport Layer
o Performs Error handling for request or
response message Network Layer
o All SIP elements contain a transport
layer Data Layer
o All SIP elements implement UDP and
TCP Physical Layer
o Recommended port - 5060 for UDP,
TCP and SCTP, 5061 for TLS over
TCP
34
Transaction Layer
o Third layer of SIP
o Handles application-layer retransmissions, Transaction User
matching of responses to requests, and Transaction Layer
application-layer timeouts
Transport Layer
o Consists of
Client transaction Syntax/Encoding
Server transaction
o Each component is represented by a finite Transport Layer
state machine that is constructed to
Network Layer
process a particular request
o Stateless proxies do not contain a Data Layer
transaction layer
Physical Layer

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
Transaction User (TU)
o Layer above the transaction layer
o To send a request, TU creates a client Transaction User
transaction instance and passes the Transaction Layer
request along with the destination IP
address, port, and transport to which Transport Layer
to send the request
Syntax/Encoding
o TU that creates a client transaction
can also cancel it Transport Layer
o Each of the SIP entities, except the
stateless proxy, is a transaction user Network Layer
Data Layer
Physical Layer

37
SIP PROTOCOL SPECIFIC

38
Contents
o SIP Messages
o Protocol Basics
o Message Bodies
o Headers
o Session Description Protocol (SDP)
o Offer-Answer Model
o SIP State Machine
o SIP Addressing
o SIP Routing
o SIP Extensions
o SIP Event Notification Framework

39
SIP Messages
Request Start Line Response Start Line
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 method URL SIP/2.0 SIP/2.0 status reason
of Via: SIP/2.0/ protocol host:port
Message Header
Start-Line From: user <sip:from_user@source>
One or more Header fields To: user <sip:to_user@destination>
An Empty Line indicating the Call-ID: localid@host
end of the header fields CSeq: seq# method
An optional Message Body ContentLength: length of body
ContentType:media type of body
o Uses the UTF-8 charset (RFC
Header: parameter ;par1=value ;par2="value"
2279)
o Request and Response Blank Line (CR LF)
messages use the basic format
V=0
Message Body
of RFC 2822 o=origin_user timestamp timestamp IN IP4 host
o Message and header field s=session name
syntax is very much identical to c=IN IP4 media destination address
HTTP/1.1 t=0 0
m= media type port RTP/AVP payload types

40
Request
o Distinguished by having a Request-Line for a start-
line
Protocol
o A Request-Line contains Request
Method Request-URI Version
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
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
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
Sample Requests
INVITE OPTIONS
OPTIONS sip:called@dmn.com SIP/2.0
INVITE sip:called@dmn.com SIP/2.0 From: sip:caller@clrdomain.com
From: sip:caller@clrdomain.com To: sip:called@clddomain.com
To: sip:called@clddomain.com CallID: 31415@clrdomain.com
CallID: 31415@clrdomain.com SIP CSeq: 1 OPTIONS
SIP
CSeq: 1 INVITE Via: SIP/2.0/UDP clrdomain.com;
Via: SIP/2.0/UDP clrdomain.com; branch=z9hG4bK776
branch=z9hG4bK776 Accept: application/sdp
Content-Type: application/sdp Content-Length: 0
Content-Length: 274
SDP
v=0 SDP
o=called 536 2337 IN IP4 h3.clddomain.com
s=session_name_1 INFO
c=IN IP4 192.213.229.147
t=0 0
m=audio 3456 RTP/AVP 0 INFO sip:called@dmn.com SIP/2.0
From: sip:caller@clrdomain.com
To: sip:called@clddomain.com
Contact: <sip:called@clddomain.com> SIP
CallID: 31415@clrdomain.com
Requests can CSeq: 1 INFO
Content-Length: 0
have headers
and SDP Requests may not
SDP
have SDP

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
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
302 Moved Temporarily
305 Use Proxy
380 Alternative Service

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
Sample Responses
Success 200 OK Failure 487 Request Terminated
SIP/2.0 200 OK
From: sip:caller@clrdomain.com SIP/2.0 487 Request Rerminated
To: sip:called@clddomain.com From: sip:caller@clrdomain.com
CallID: 31415@clrdomain.com To: sip:called@clddomain.com
SIP CallID: 31415@clrdomain.com SIP
CSeq: 1 OPTIONS
Accept: application/sdp CSeq: 1 INVITE
Accept-Encoding: gzip Content-Length: 0
Accept-Language: en
Content-Type: application/sdp
Content-Length: 274 SDP
v=0
o=called 536 2337 IN IP4 h3.clddomain.com
s=session_name_1 SDP Provisional 180 Ringing
c=IN IP4 192.213.229.147
t=0 0
m=audio 3456 RTP/AVP 0 SIP/2.0 180 Ringing
Contact: <sip:called@clddomain.com> SIP
Response can CSeq: 1 INVITE
Content-Length: 0
have headers
and SDP
Response may not SDP
have SDP

48
SIP Headers
o Similar to HTTP header fields in both syntax and
semantics
o Follow the [H4.2] definitions of syntax for the message-
header 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
Sample SIP Headers
Form Long Form Compact
From: sip:caller@clrdomain.com f: sip:caller@clrdomain.com

To: sip:called@clddomain.com t: sip:called@clddomain.com
CallID: 31415@clrdomain.com i: 31415@clrdomain.com
CSeq: 1 OPTIONS CSeq: 1 OPTIONS
Accept: application/sdp Accept: application/sdp
Accept-Encoding: gzip Accept-Encoding: gzip
Accept-Language: en Accept-Language: en
Content-Type: application/sdp c: application/sdp
Content-Length: 274 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
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
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
Sample SIP Message Bodies
Media - SDP
Application Message Summary
Content-Length: 274 Content-Type: application/message-summary
Content-Length: 98
v=0
o=called 536 2337 IN IP4 h3.clddomain.com Messages-Waiting: yes
s=session_name_1 Message-Account: sip:alice@vmail.example.com
c=IN IP4 192.213.229.147 Voice-Message: 2/8 (0/2)
t=0 0
m=audio 3456 RTP/AVP 0
Application - pkcs7-signature
Content-Type: application/pkcs7-signature; name=smime.p7s

Content-Transfer-Encoding: base64
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756

53
SIP Call Flow
Proxy Location
SIP UA (A) Server Services SIP UA (B)
INVITE (SDPo)
1 Location Lookup
2
Lookup Result 3
INVITE (SDPo)
4
100 Trying 5
Session
180 Ringing Initiation
6
180 Ringing
7
200 OK (SDPT)
8
200 OK (SDPT)
9
ACK
10
Session In
Two way Speech Path
Progress
11
BYE
Session
200 OK Teardown
12

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
SIP Transaction
Successful Call Scenario Failure Call Scenario
UAC UAS UAC UAS

First Transaction First Transaction
1
INVITE (CSeq:1 INVITE) 1
INVITE (CSeq:1 INVITE)
100 Trying (CSeq:1 INVITE) 2

100 Trying (CSeq:1 INVITE) 2
200 OK (Cseq:1 INVITE) 3 486 Busy Here (CSeq:1 INVITE) 3
4
ACK (CSeq:2 ACK) 4
ACK (CSeq:1 INVITE)
Second Transaction
5
BYE (CSeq:3 BYE)
200 OK (CSeq:3 BYE) 6

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
SIP Dialog
Single Dialog Scenario No Dialog Scenario
UAC UAS UAC UAS

Dialog First Transaction
First Transaction 1
INVITE
INVITE (F-Tag: Xxx)
1 100 Trying 2
100 Trying 2 486 Busy Here 3
200 OK (F-Tag: Xxx, T-Tag: Yyy)
3
4
ACK
4
ACK (F-Tag: Xxx, T-Tag: Yyy)
Second Transaction
5
BYE (F-Tag: Xxx, T-Tag: Yyy)
200 OK (F-Tag: Xxx, T-Tag: Yyy) 6

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
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
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
Request- Request-
URI URI
REGISTER sip:registrar.wipro.com SIP/2.0 INVITE sip:bob@ebay.com SIP/2.0

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 human-
user 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
To
To = ( "To" / "t" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )
o Supports Tag to identify the peer of the dialog

o Occur only once per message
o Compact form of the To header field is t
o Examples of valid To header fields:
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com
Display Addr Tag

Name spec Parameter
To : The Operator <sip:operator@cs.columbia.edu>;tag=287447

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
user interface

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 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 Addr Tag
Name spec Parameter
From: A. G. Bell <sip:agb@bell-telephone.com> ;tag=a48s

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
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
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
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
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
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
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/ Host Port Branch
Transport Parameter
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7

72
Branch Parameter
o Contain in Via header field value
o Used to identify the transaction created by that request
o Used by both the client and the server
o 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
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
Contact

user interface
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
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 Contact

Spec Parameters
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>;q=0.7; expires=3600

76
REGISTER Method
o Create bindings in a location
service for a particular domain
that associates an AOR URI with
REGISTER sip:registrar.biloxi.com SIP/2.0
one or more contact addresses Via: SIP/2.0/UDP bobspc.biloxi.com:5060;
o Sent from UAC to Registrar branch=z9hG4bKnashds7
Max-Forwards: 70
o Registrar identified in Request- To: Bob <sip:bob@biloxi.com>
From: Bob <sip:bob@biloxi.com>;tag=456248
URI Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
o Identifies registered user in To Contact: <sip:bob@192.0.2.4>
Expires: 7200
o Identifies person performing Content-Length: 0
registration in From (usually =
To)
o Contains list of current locations
in Contact headers

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 per-
binding basis
o Doesn't establish a dialog

78
REGISTER Response
o Check if domain is its own
o Authorize user in From
o Add address bindings of To to SIP/2.0 200 OK
Contact list Via: SIP/2.0/UDP bobspc.biloxi.com:5060;
branch=z9hG4bKnashds7
o Modify expiration time, if too long Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
o Return, in response, list of all From: Bob <sip:bob@biloxi.com>;tag=456248
current registrations Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
o Return, in response, expiration Contact: <sip:bob@192.0.2.4>
time for all registrations and Contact: <sip:bob@192.219.223.160>
Expires: 7200
respective priorities, if present Content-Length: 0

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
INVITE Method
o Used to signal the desire INVITE sip:bob@biloxi.com SIP/2.0
to open a session Via: SIP/2.0/UDP pc33.atlanta.com;
branch=z9hG4bK776asdhds
o Sent from UAC to UAS Max-Forwards: 70
o Mandatory header To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774 SIP
fields : Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
From Contact: <sip:alice@pc33.atlanta.com>
To Content-Type: application/sdp
Call-ID Content-Length: 142
CSeq v=0
Via o=user1 536 2337 IN IP4 h3.clrdomain.com
s=session_name_1
Max-Forward c=IN IP4 h3.clrdomain.com
SDP
o Can carry SDP to m=audio 3456 RTP/AVP 0 1

m=video 4000 RTP/AVP 38 39
exchange the media
capabilities

81
ACK Method
o ACK method is used to
confirm the final response ACK sip:bob@biloxi.com SIP/2.0
that was sent to the Via: SIP/2.0/UDP pc33.atlanta.com;
INVITE method branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
o Sent from UAC to UAS From: Alice <sip:alice@atlanta.com>;tag=88sja8x SIP
Max-Forwards: 70
o Indicates that the session Call-ID: 987asjd97y7atg
has been accepted CSeq: 986759 ACK
ContentType: application/sdp
o Can be used to indicate Content-Length: 138
SDP to the other entity;
not mandatory to contain v=0
o=user1 536 2337 IN IP4 h3.clrdomain.com
SDP info s=session_name_1 SDP
c=IN IP4 h3.clrdomain.com
m=audio 3456 RTP/AVP 0 1

82
Sample Call Flows ACK w/wo SDP
Fast Start Call Scenario Slow Start Call Scenario
UAC UAS UAC UAS

First Transaction First Transaction
INVITE (SDPO) 1
INVITE
1
100 Trying 100 Trying 2

2
200 OK (SDPT) 3
200 OK (SDPT) 3
ACK 4
ACK (SDPO)
4
Two way Speech Path Two way Speech Path

Second Transaction Second Transaction
5
BYE 5
BYE
200 OK 6
200 OK 6

83
OPTIONS Method
o Allows a UA to query
another UA or a proxy
server as to its capabilities
OPTIONS sip:carol@chicago.com SIP/2.0
o Capabilities: Via: SIP/2.0/UDP pc33.atlanta.com;
OPTIONS Request Method

branch=z9hG4bKhjhs8ass877
Supported methods Max-Forwards: 70
Content types To: <sip:carol@chicago.com>
Extensions From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Codecs CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
o Sent from UAC to UAS Accept: application/sdp
o Target identified in Request- Content-Length: 0
URI
o All UAs must support the
OPTIONS method

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
OPTIONS Response
o Allow, Accept, Accept-
Encoding, Accept-
Language, and Supported SIP/2.0 200 OK
header fields are Via: SIP/2.0/UDP pc33.atlanta.com;
OPTIONS Success Response

recommended branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
o 200 OK - if UAS is ready to To: <sip:carol@chicago.com>
accept a call From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
o 486 (Busy Here) if UAS is CSeq: 63104 OPTIONS
busy, etc Contact: <sip:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
o Allow header field should be Accept: application/sdp
Content-Length: 0
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

86
BYE Method
o Sent to signal the end of the
established session
o Sent from UAC to UAS
BYE sip:bob@biloxi.com SIP/2.0
o Can be initiated by any UAC Via: SIP/2.0/UDP pc33.atlanta.com;
which is a of the session branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
o Any session associated with From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
that dialog should terminate Call-ID: 987asjd97y7atg
CSeq: 986759 BYE
o All pending methods (if any) Content-Length: 0
should be terminated

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) CANCEL sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;
o No effect on a request for which a final branch=z9hG4bKkjshdyff
response has been received To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
o Stateful proxy responds to a CANCEL, From: Alice <sip:alice@atlanta.com>;tag=88sja8x
rather than simply forwarding Max-Forwards: 70
Call-ID: 987asjd97y7atg
o Referred to as a "hop-by-hop" request CSeq: 986759 INVITE
o Request-URI, Call-ID, To, the numeric Content-Length: 0
part of CSeq, and From header must be
identical to those in the request being
cancelled, including tags

88
Sample Call Flows BYE & CANCEL
Successful Call Scenario Failure Call Scenario
UAC UAS UAC UAS

First Transaction
First Transaction
INVITE
1
1
INVITE
100 Trying 2 100 Trying 2
200 OK 3
180 Ringing 3
ACK Second Transaction
4
4
CANCEL
Two way Speech Path
200 OK 5
Second Transaction
5
BYE 487 Request Terminated 6
200 OK 6 ACK
7

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

90
SIP State Transition - Client
Initial
7 INVITE sent
-
-
INVITE
T1*2n
INVITE
Calling give up
BYE
1xx
300-699 Call Proceeding 1xx

ACK
300-699 give up
ACK BYE
300-699 Completed
event ACK
32s (for proxy)
request sent
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
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 fully-
qualified 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
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
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
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
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.15
o Reverse the order of the digits
1.7.5.2.7.9.2.5.3.1.86
o Append the string .e164.arpato the end
1.7.5.2.7.9.2.5.3.1.8.e164.arpa

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 SIP
+4686859131 sip:ssarkar@wipro.com
Gateway
SIP Server

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
Locating User DNS SRV
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
o Service: Symbolic name of the desired service

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

SRV 1 0 5060 backup.ip-provider.net.
_sip._udp SRV 0 0 5060 sip-server.cs.columbia.edu.
SRV 1 0 5060 backup.ip-provider.net.

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
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 Indicates Loose

Spec Routing
Record-Route: <sip:server10.biloxi.com;lr>

102
BYE Message Flow W/WO Record Routing
Without Record Routing With Record Routing
UA1 SIP Proxy UA2 UA1 SIP Proxy UA2
BYE BYE
BYE
200 OK
200 OK
200 OK

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 Indicates Loose

Spec Routing
Route: <sip:server10.biloxi.com;lr>

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
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
A B C D
INVITE B
INVITE C
Route C,D Route D INVITE D

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
A B C D
INVITE D
INVITE D
Route B,C Route C INVITE D

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
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
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
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
o P1 Receives
o And sends

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
SIP Routing Response
192.219.223.160 172.16.16.120 172.16.16.160 192.219.223.197
UAC Proxy Proxy UAS

Via:192.219.223.160 Via:172.16.16.120 Via:172.16.16.160
Via:192.219.223.160 Via:172.16.16.120
Via:192.219.223.160
Via:172.16.16.160
Via:172.16.16.120
Via:172.16.16.120 Via:192.219.223.160
Via:192.219.223.160
Via:192.219.223.160
Request
Response

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
Parallel Forking - Example
Session setup request

forwarded to UAS 1
UAS1
3
IP Network 486 Busy Here
UAS Location 2
Query
Location
Session setup Server Session setup request
Request from Location Server forwarded to UAS 2
2 UAS2
the UAC
4
6 OK to connect
Connect to UAS 2
SIP
Proxy 2
1 Session setup request

5
forwarded to UAS 3
UAS3
CANCEL setup request

SIP Protocol
UAC Non-SIP Protocol
(Eg. Database Query)

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
Spiral
o SIP request that is routed to a proxy, forwarded
onwards, and arrives once again at that proxy
o Request's Request-URI differs from its previous arrival
o Not an error condition
o Typical cause for spiral is Call Forwarding
o Example of a valid SIP Spiral:
1. Foo calls joe@example.com
2. example.com proxy forwards it to Joe's PC
3. Joes PC forwards it to bob@example.com
4. New request is proxied back to the example.com proxy

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
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)
0 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
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
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
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
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
Answered SDP
a=rtpmap:32 MPV/90000 v=0
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
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
Reliability of Provisional Responses
SIP UA (A) SIP Proxy SIP UA (B)
INVITE (oSDP)
INVITE (oSDP)
100 Trying
180 Ringing (tSDP)
180 Ringing (tSDP)
Backwards Speech Path (audible ringing)
PRACK
PRACK
200 OK
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
PRACK Method
o UAC to UAS
PRACK sip:bob@biloxi.com SIP/2.0
o Each provisional response is Via: SIP/2.0/UDP pc33.atlanta.com;
given a sequence number, branch=z9hG4bK776asdhds
carried in the RSeq header, Max-Forwards: 70
contains a single numeric To: Bob <sip:bob@biloxi.com>
value from 1 to 2**32 - 1 From: Alice <sip:alice@atlanta.com>;tag=1928301774 SIP
Call-ID: a84b4c76e66710@pc33.atlanta.com
RSeq: 988789 CSeq: 314159 PRACK
o Contain an RAck header field, RAck: 83 1 INVITE
which indicates the sequence Contact: <sip:alice@pc33.atlanta.com>
number of the provisional Content-Type: application/sdp
Content-Length: 142
response that is being
acknowledged, contains two v=0
numbers and a method tag o=user1 536 2337 IN IP4 h3.clrdomain.com
s=session_name_1
RAck : 776656 1 INVITE
c=IN IP4 h3.clrdomain.com SDP
o Can optionally contain m=audio 3456 RTP/AVP 0 1
session description m=video 4000 RTP/AVP 38 39
RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method

RSeq = "RSeq" HCOLON response-num

127
UPDATE Methods
o Allows a client to update
parameters of a session UPDATE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;
(such as the set of media branch=z9hG4bK776asdhds
streams and their Max-Forwards: 70
codecs) From: Alice <sip:alice@atlanta.com>;tag=1928301774
SIP
o Target refresh request, it Call-ID: a84b4c76e66710@pc33.atlanta.com

CSeq: 314159 UPDATE
can update the remote Contact: <sip:alice@pc33.atlanta.com>
target of a dialog Content-Type: application/sdp
Content-Length: 142
o No impact on the state of
a dialog v=0
o Can be sent before the s=session_name_1
SDP
initial INVITE has been m=audio 3456 RTP/AVP 0 1
completed m=video 4000 RTP/AVP 38 39
o Very useful for updating
session parameters
within early dialogs

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) SIP UA (A) SIP UA (B)
with an answer to that offer
o User A generates a PRACK (3) to 1
INVITE (Offer 1)
acknowledge the 180 180 Ringing (Answer 1)
o User B answered the PRACK with a 2
200 OK (4) 3
PRACK
o User A generate an UPDATE request 200 OK 4
(5) with a new offer UPDATE (Offer 2)
5
o User B answered this offer in the 200
200 OK (Answer 2)
response to the UPDATE (6) 6
o User B generates an UPDATE request UPDATE (Offer 3) 7

(7) with an offer 8
200 OK (Answer 3)
o User A answer is sent in the 200 200 OK
response (8) 9
ACK
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)

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
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
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
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
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
SUBSCRIBE Methods
o Used to request asynchronous
notification of an event or set of events
at a later time
o UAC to UAS
o Used to request current state and state
updates from a remote node SUBSCRIBE sip:bob@biloxi.com SIP/2.0
o Should contain an "Expires" header Via: SIP/2.0/UDP pc33.atlanta.com;
o Dialog creating method, may contain branch=z9hG4bK776asdhds
"Accept" header Max-Forwards: 70
o Must include exactly one "Event" To: Bob <sip:bob@biloxi.com>
header From: Alice <sip:alice@atlanta.com>;tag=1928301774
o To keep subscriptions effective beyond Call-ID: a84b4c76e66710@pc33.atlanta.com
the duration communicated in the CSeq: 314159 SUBSCRIBE
"Expires" header, subscribers need to Contact: <sip:alice@pc33.atlanta.com>
refresh subscriptions on a periodic Event: message-summary
basis using a new request on the same Expires: 0
dialog Content-Length: 0
o To terminate subscription, refresh, with
the "Expires" header set to "0".
o Can optionally contain body, defined by
the event packages

135
NOTIFY Methods
o Used to notify a SIP node that an event
which has been requested by an earlier
SUBSCRIBE method has occurred
o May also provide further details about NOTIFY sip:bob@biloxi.com SIP/2.0
the event Via: SIP/2.0/UDP pc33.atlanta.com;
o UAC to UAS branch=z9hG4bK776asdhds
o To inform subscribers of changes in Max-Forwards: 70
state to which the subscriber has a To: Bob <sip:bob@biloxi.com>
subscription From: Alice <sip:alice@atlanta.com>;tag=1928301774 SIP
o Must include exactly one "Event" Call-ID: a84b4c76e66710@pc33.atlanta.com
header CSeq: 314159 NOTIFY
o Must contain "Subscription-State" Event: message-summary
header Subscription-State: active
o NOTIFY are matched to such Contact: <sip:alice@pc33.atlanta.com>
SUBSCRIBE if they contain the same Content-Type: application/simple-message-summary
"Call-ID", a "To" header "tag" parameter Content-Length: 99
which matches the "From" header "tag"
parameter of the SUBSCRIBE, and the Messages-Waiting: yes
same "Event" header Message-Account: sip:alice@vmail.example.com MWT
o Contain body defined by the event Voice-Message: 4/8 (1/2)
packages

136
SIP Event Notification Sample Message Flow
UAC UAS
1
SUBSCRIBE (Event: Zxx, Expires:3600)
200 OK 2
NOTIFY (Subscription-State: Active) 3
200 OK Zxx Event

4
Occurred
200 OK Zxx Event

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

137
SIP & SECURITY

138
Contents
o Security Concerns
o Security Framework
o Security SIP Signalling
o Transport Layer Security (TLS)
o HTTP Digest Authentication
o Secured MIME (S/MIME)
o Security Real-Time Media
o Secure RTP (SRTP)
o NAT And SIP
o RTP Relay (TURN)
o DIAMETER Base Protocol
o AAA SIP Architecture Components

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
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
Security SIP Signaling
Authentication Methods:
Authentication
Confidentiality
PSK Pre-Shared Keys
Integrity
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
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
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
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_AES_128_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 TLS_RSA_WITH_AES_256_CBC_SHA
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
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
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
Digest Authentication And SIP
Initial INVITE Proxy Challenge
INVITE sip:bob@biloxi.example.com SIP/2.0 1
SIP/2.0 407 Proxy Authorization Required 2
Via: SIP/2.0/TCP client.atlanta.example.com:5060; Via: SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74b43 branch=z9hG4bK74b43
Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Route: <sip:ss1.atlanta.example.com;lr> To: Bob <sip:bob@biloxi.example.com>;tag=3flal12sf
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com
To: Bob <sip:bob@biloxi.example.com> CSeq: 1 INVITE
Call-ID: 3848276298220188511@atlanta.example.com Proxy-Authenticate: Digest realm="atlanta.example.com",
CSeq: 1 INVITE qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359",
Contact: <sip:alice@client.atlanta.example.com> opaque="", stale=FALSE, algorithm=MD5
Content-Length: 0 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>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.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
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
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
Security Real-Time Media
Authentication Methods:
Authentication
Confidentiality
PSK Pre-Shared Keys
Integrity
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
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
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
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
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
SIP NAT Traversal Reference Model
Public Private
Private
SIP Proxy
RTP/RTCP Media
Firewall/NAT
Firewall/NAT
Media
Signaling

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
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>
Signalling
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com> Actual IP
Content-Type: application/sdp Address and
Content-Length: 142 port it received
from
v=0
s=session_name_1 Media
m=audio 3456 RTP/AVP 0 1
m=video 4000 RTP/AVP 38 39 Internal IP
Address and
port it sent from

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
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
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
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
RTP Traversal RTP Relay (TURN)
NAT NAT Proxy
8 5
1
2 3 6 7
10
12
Voice Gateway
User
12
Agent
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
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
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
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
DIAMETER Based SIP Architecture
Diameter Server
R DIA
E TE ME
A M T ER
SIP DI SIP
Client Client
SIP SIP
SIP
SIP Server
IP Network SIP Server
DIA R
ME ETE
T ER IAM
D
Diameter
Subscriber Locator

167
SIP Server User Authentication
SIP SIP Diameter SIP
Terminal Server 1 Server Server 2
Successfully
1
REGISTER authenticates the user
2
UAR
UAA 3 Includes challenge in the
REGISTER response which is map to
4
WWW-Authenticate
MAR 5
6
MAA
401 Unauthorized
7
401 Unauthorized Successfully
8
9
10
UAR
UAA 11 Successfully
12
MAR 13
14
MAA
200 OK 15
200 OK
16

168
SIP Server Requests Authorization
SIP SIP Diameter SIP
Terminal Server Server Server
Includes challenge in the
response which is map to
1
INVITE WWW-Authenticate
2
MAR
MAA
407 Proxy 3
Authentication
Required
4
Successfully
5
INVITE authenticates the user
6
MAR
MAA 7
8
INVITE
200 OK 9
200 OK
16

169
SIP & QoS

170
Contents
o IP QoS Model
o SIP & QoS
o SIP Precondition
o Common Open Policy Service (COPS)
o COPS Based QoS SIP Architecture
o QoS SIP Architecture Components
o Q-SIP Call Flows

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
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
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/status-type
a particular stream is equal to (or better than) the desired
status for that stream

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
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
SIP Precondition End-To-End
o SDP1: A includes end-to-end quality of service SIP UA (A) SIP UA (B)
preconditions in the initial offer.
m=audio 20000 RTP/AVP 0 INVITE (SDP1)
c=IN IP4 192.0.2.1 1
a=curr:qos e2e none 183 Session Progress (SDP2)

a=des:qos mandatory e2e sendrecv 2
o SDP2: B uses RSVP, it can know when R PRACK R

3
E PATH
resources in its "send" direction are available, E
RSVP setup
S S
RESV
A to B
because it will receive RESV messages from the E
RSV-CONF
E
network. However, it does not know the status of R
V
R
the reservations in the other direction. B requests A 200 OK V

A 4
PATH
confirmation for resource reservations in its T T
RSVP setup
I RESV I
"recv" direction to the peer user agent A in its
B to A
O O
RSV-CONF
answer. N N
m=audio 30000 RTP/AVP 0 UPDATE (SDP3)
5
c=IN IP4 192.0.2.4 a=curr:qos e2e none
200 OK (SDP4)
a=des:qos mandatory e2e sendrecv 6
a=conf:qos e2e recv 180 Ringing 7

o After having sent the answer, B starts reserving PRACK
network resources for the media stream. When A 8
receives this answer (2), it starts performing 200 OK 9

resource reservation as well. Both UAs use 200 OK
RSVP, so A sends PATH messages towards B 10
and B sends PATH messages towards A. 11
ACK

177
SIP Precondition End-To-End
o As time passes, B receives RESV messages SIP UA (A) SIP UA (B)
confirming the reservation. However, B waits until
resources in the other direction are reserved as INVITE (SDP1)
well, since it did not receive any confirmation and 1
the preconditions still have not been met. 183 Session Progress (SDP2)
2
o SDP3: When A receives RESV messages, it
sends an updated offer (5) to B: R PRACK R
3
E PATH E
RSVP setup
S S
RESV
A to B
c=IN IP4 192.0.2.1 E
RSV-CONF
E
R R
a=curr:qos e2e send V
a=des:qos mandatory e2e sendrecv A 200 OK V
A 4
T PATH
o SDP4: B responds with an answer (6) which T
RSVP setup
I RESV I
B to A
contains the current status of the resource O
RSV-CONF
O
N
reservation (i.e., sendrecv): N
m=audio 30000 RTP/AVP 0 UPDATE (SDP3)

5
c=IN IP4 192.0.2.4 200 OK (SDP4) 6
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv 180 Ringing 7
o At this point in time, session establishment PRACK
8
resumes and B returns a 180 (Ringing) response
(7). 200 OK 9
200 OK
10
11
ACK

178
SIP Precondition Segmented
o SDP1: A includes local and remote QoS SIP UA (A) SIP UA (B)
preconditions in the initial offer. Before sending
the initial offer, A reserves resources in its access R
network. This is indicated in the local current E
S
status of the SDP below: E
m=audio 20000 RTP/AVP 0 8 R
V
c=IN IP4 192.0.2.1 A
a=curr:qos local sendrecv T
I
a=curr:qos remote none O
a=des:qos mandatory local sendrecv N
INVITE (SDP1)
a=des:qos mandatory remote sendrecv 1
R
o SDP2: B reserves resources in its access E
network and, since all the preconditions are met, S
E
returns an answer in a 180 (Ringing) response R
(3). V
A
m=audio 30000 RTP/AVP 0 8 T
c=IN IP4 192.0.2.4 I
O
a=curr:qos local sendrecv N
a=curr:qos remote sendrecv 180 Ringing (SDP2)
2
a=des:qos mandatory local sendrecv
PRACK
a=des:qos mandatory remote sendrecv 3
200 OK 4
200 OK 5
6
ACK

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
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
COPS Provisioning Model
Bandwidth Broker
Notifications ( 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
COPS Outsourcing Model
Bandwidth Broker
Query (2) ( Policy Decision Point)
Trigger
Events (1)
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
COPS Based QoS SIP Architecture
Bandwidth Broker
PDP
PDP PEP OPS PDP PEP

C
QoS-Enabled
SIP Client Network Client Network SIP
Client
Network Client
Access Edge Router Access Edge Router
PS CO
CO PS
SIP SIP
Q-SIP
Q-SIP Server Q-SIP Server

184
QoS SIP Architecture
o QoS reservation modes
Unidirectional Reservations
Caller-side Q-SIP Server makes reservation for the caller-to-
called 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
Q-SIP Call Flow - Unidirectional
SIP Q-SIP Edge Edge Q-SIP SIP
Terminal Server Router Router Server Terminal
1
INVITE
INVITE
2
3
INVITE
180 Ringing
180 Ringing 4
180 Ringing 6
5
200 OK INVITE 7
COPS REQ 8
9
COPS DEC
200 OK INVITE 10
11
COPS REQ
COPS DEC 12
200 OK INVITE 13
ACK
14 ACK
15
16
ACK

186
Q-SIP Call Flow - Bidirectional
SIP Q-SIP Edge Edge Q-SIP SIP
Terminal Server Router Router Server Terminal
1
INVITE
INVITE
2
3
INVITE
180 Ringing
180 Ringing 4
180 Ringing 6
5
200 OK INVITE 7
200 OK INVITE 8
9
COPS REQ
COPS DEC 10
200 OK INVITE 11
ACK
12 ACK
13
14
ACK

187
SIP & PSTN

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

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 in-
call ISUP signaling in IP networks

190
SCP
SSP
DLC
STP
PSTN
PSTN GW
PBX
3rd Party

Server Server
OSA
SIP Network Gateway
EBP SIP/SIP ISC

CMTS CMS/GC
SIP SIP/SIP ISC
Agents Servers HSS
PacketCable Network
PCF
MGCF IM Subsystem
MTA MTA
WiFi/ VDSL FTTH

WiMax
CDMA/
GSM/UMTS
191
SIP-T Call (SIP Bridging)
Switch A MGC A MGC B Switch B

IAM
1 INVITE (IAM, oSDP)
2
3
IAM
100 Trying 4
180 Ring. (ACM, tSDP) ACM 5

ACM 7
6

ANM
200 OK (ANM) 8
ANM 10
9
11
ACK
Two way Speech Path

REL
BYE (REL) 12
REL 13
14 RLC
200 OK 15
17 RLC 16

192
SIP-T Call (PSTN to SIP UA)
Switch A MGC A SIP Proxy SIP UA

IAM
INVITE (oSDP)
1
2
3 INVITE (oSDP)
100 Trying 4
180 Ringing
180 Ringing 6
5
ACM 7
Backwards Speech Path

(audible ringing) 200 OK (tSDP)
200 OK (tSDP)
8
9
ACK
ANM
10
12 11 ACK
Two way Speech Path
BYE
BYE 13
REL 15
14
200 OK
17 RLC 16
18 200 OK

193
SIP-T Call (SIP UA to PSTN)
SIP UA SIP Proxy MGC A Switch A

INVITE (oSDP)
INVITE (oSDP)
1
100 Trying
2
IAM
100 Trying 3
4
ACM
180 Ringing (tSDP) 180 Ringing (tSDP) 6
5
7
ANM
200 OK 8
200 OK 10
9
ACK
11
12 ACK
Two way Speech Path

REL
BYE
13
BYE 14
15 RLC
200 OK
17
16
18 200 OK

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
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
MIME Types ISUP
INVITE sip:13039263142@Den1.level3.com SIP/2.0
Via: SIP/2.0/UDP den3.level3.com
From: sip:13034513355@den3.level3.com
ISUP Base Values To: sip:13039263142@Den1.level3.com
Call-ID: DEN1231999021712095500999@Den1.level3.com
CSeq: 8348 INVITE
Base Protocol Contact: <sip:jpeterson@level3.com>
Content-Length: 436
Content-Type: multipart/mixed; boundary=unique-boundary-1
itu-t88 ITU-T Q.761-4 (1988) MIME-Version: 1.0
--unique-boundary-1
itu-t92 ITU-T Q.761-4 (1992) Content-Type: application/SDP; charset=ISO-10646
v=0
ansi88 ANSI T1.113-1988 o=jpeterson 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP seminar
c=IN IP4 MG122.level3.com
ansi00 ANSI T1.113-2000 t= 2873397496 2873404696
m=audio 9092 RTP/AVP 0 3 4
--unique-boundary-1
etsi121 ETS 300 121 Content-Type: application/ISUP; version=nxv3;base=etsi121
Content-Disposition: signal; handling=optional
etsi356 ETS 300 356 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
Content-Type Header
Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
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
Content-Disposition Header
Content-Disposition = "Content-Disposition" HCOLON disp-type *( SEMI disp-param )
disp-type = "render" / "session" / "icon" / "alert" / signal / disp-extension-token
disp-param = "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
SIP Profiles
SIP Profile A
SIP 3GPP Mobile
Network
PSTN/ISDN
PSTN/ISDN
SIP Profile C
SIP Profile B
SIP Terminating
Network

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
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
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
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 500 Server Internal Error
ANM 200 OK INVITE
GRS BYE
REL BYE
4xx, 5xx, 6xx
CGB BYE
CANCEL
RLC BYE
4xx, 5xx, 6xx
CANCEL

204
IAM/INVITE Mapping
INVITE IAM
Called Party Number (M)
E.164 encoded userinfo of Request-URI (sip:URI with Address Signal
user=phone)
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
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
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
Tel-URI - Examples
Global Phone Number (+358-555-1234567)
tel:+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
Number Mapping
o SIP-ISUP mapping frequently requires the representation
of telephone numbers in URIs (Request-URI, To, From, P-
Asserted-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
ISUP to TEL URI Mapping
ISUP SIP
Called Party/Calling Party Number
NPI : E.164 Telephone number digits to be appended unmodified to a 'tel:
NOA : International + string
CDN:17208881000 tel:+17208881000
NPI : E.164 Country code must be prefixed to the telephone number

NOA : National digits before they are committed to a tel URL
CDN:7208881000 tel:+17208881000 (assuming CC = 1)
NPI : E.164 Both a country code and any other numbering components
NOA : Subscriber necessary for the numbering plan in question may need to be
added in order for the number to be internationally significant
CDN:8881000
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
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 NPI : E.164
gateway, retain the country code and populate the digits field NOA : International
tel:+17208881000 CDN:17208881000
URI is in international format, the country code is local to the NPI : E.164
gateway, strip the country code from the URI before populating the NOA : National
digits field
CDN:7208881000
tel:+17208881000 (assuming CC = 1)
URI is not in international format, the gateway may treat the NPI : Unknown
telephone number within the URI as if it were appropriate to its NOA : Subscriber
national or network-specific dialing plan
CDN:8881000
sip:8881000@sip.example.net;user=phone
Calling Party Number

Presentation indicator should be set to 'presentation allowed' and PI : Presentation Allowed
the screening indicator to 'network provided', unless some service SI : Network Provided
provider policy or user profile specifically disallows presentation

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
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 P-
Asserted-Identity header field values
o Examples of valid P-Asserted-Identity header fields:
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>

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 network-
provided privacy is required
o Each legitimate priv-value can appear zero or one times in
a Privacy header

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
Privacy to CGN Mapping
SIP ISUP
Privacy header field absent PI : Presentation Allowed
Priv-value = none PI : Presentation Allowed
Priv-value = header PI : Presentation Restricted

Priv-value = user PI : Presentation Restricted
Priv-value = id PI : Presentation Restricted
ISUP SIP
PI : Presentation Allowed No Privacy header
PI : Presentation Restricted Privacy: id (included on if P-
Asserted-Id header is
included)

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
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
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
NP ISUP/SIP Mapping
SIP ISUP
Forward Call Indicator (M)
npdi=yes M bit = 'number translated
Called Party Number
'rn=' field is present Mapped to CDN
rn=+12025440000 CDN:12025440000
Generic Digit Parameter
Main telephone number in the tel URI Mapped to GAP
tel:+1-202-533-1234;rn=+1-202-544-0000; npdi GAP:12025331234
SIP ISUP
Forward Call Indicator (M)
M bit = 'number translated npdi appended to the tel URL
Called Party Number
CDN Mapped to 'rn=' field
CDN:12025440000 rn=+12025440000
Generic Digit Parameter
GAP Map to main telephone number in the tel URI
GAP:12025331234 tel:+1-202-533-1234;rn=+1-202-544-0000; npdi

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
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 Profile A : Not interworked
other value Profile B : Not interworked
Profile C : 183 Session Progress with encapsulated
ACM

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

183 Session Progress Profile A : CPG is not generated
Profile B : CPG is not generated
Profile C : Generated from the EI of
encapsulated CPG

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 Profile A : Not interworked
information available Profile B : Not interworked
Profile C : 183 Session Progress with encapsulated
CPG

224
200/ANM Mapping
SIP ISUP
200 OK INVITE Profile A : ANM
Profile B : ANM
Profile C : Generated ANM from the encapsulated ISUP
ISUP SIP
ANM Profile A : 200 OK INVITE
Profile B : 200 OK INVITE
Profile C : 200 OK INVITE with encapsulated ANM

225
Reason Header
Reason = "Reason" HCOLON reason-value *(COMMA reason-value)
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
Reason Header Usage Example
Third-Party Call Control ISUP Interworking
User A Controller User B User A Gateway User B
INVITE IAM
INVITE
200 OK (SDPO)
100 Trying
ACK (Hold SDP) REL (16)
INVITE
CANCEL (Q.8650:16)
486 Busy Here
200 OK
ACK
BYE (SIP:486)
200 OK

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 = protocol-
cause, 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
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 Profile A & B : Cause Value = protocol-
cause, Location = Network beyond
interworking point
encapsulated REL
REL Cause Value 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
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
What is Media Clipping ?
INVITE
INVITE
100 Trying
Media
200 OK (SDPT)
Clipping
Occurs
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
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
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
Early Media Gateway Model
INVITE (SDPo)
INVITE (SDPo)
100 Trying
200 OK (SDPT)
200 OK (SDPT)
Early Media Session
ACK ACK

INVITE
INVITE
100 Trying
183 Session Progress (SDPT)
183 Session Progress (SDPT)
PRACK (SDPo) PRACK (SDPo)

Early Media Session

234
Early Media AS Model
Content-Type: application/sdp Content-Disposition: session
v=0
SIP UA (A) SIP Proxy SIP UA (B) o=alice 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.1
t=0 0
INVITE (offer)
INVITE (offer)
Content-Type: multipart/mixed;boundary="boundary1"
100 Trying
Content-Length: 401
183 Session Progress --boundary1
183 Session Progress (answer, early offer) Content-Type: application/sdp
(answer, early offer) Content-Disposition: session
v=0
o=Bob 2890844725 2890844725 IN IP host.example.org
PRACK (early-answer) s=
PRACK (early-answer) c=IN IP4 192.0.2.2
t=0 0
200 OK m=audio 30000 RTP/AVP 0
200 OK --boundary1
Early Media Session v=0
o=Bob 2890844714 2890844714 IN IP4 host.example.org
200 OK INVITE s=
200 OK INVITE c=IN IP4 192.0.2.2
t=0 0
ACK ACK --boundary1--
v=0
o=alice 2890844717 2890844717 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.1
t=0 0

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

Two way Speech Path
INFO (SUS) SUS

SUS
200 OK
INFO (RES) RES

RES
200 OK

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
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
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
Overlap Signalling Call Flows
IAM
1 INVITE (IAM, oSDP)
IAM
SAM 1
2 INVITE (IAM, SAM 1, oSDP)
SAM 1
1 484 Address Incomplete
1 ACK
SAM 2
3 INVITE (IAM, SAM 1, SAM2,
oSDP)
SAM 2
2 484 Address Incomplete
2 ACK
ACM
3 180 Ring. (ACM, tSDP)
ACM
3 200 OK (ANM) ANM

ANM
3 ACK
Two way Speech Path

241
SIP & PacketCable

242
Contents
o Background
o Distributed Call Signalling Architecture
o PacketCable Architecture
o Call Management Server
o Service Provider Requirements
o SIP Proxy-To-Proxy Extensions
o CMS to CMS Call Flow
o CMS to MGC Call Flow

243
SCP
SSP
DLC
STP
PSTN
PSTN GW
PBX
3rd Party

Server Server
OSA
SIP Network Gateway
EBP SIP/SIP ISC

CMTS CMS/GC
SIP SIP/SIP ISC
Agents Servers HSS
PacketCable Network
PCF
MGCF IM Subsystem
MTA MTA
WiFi/ VDSL FTTH

WiMax
CDMA/
GSM/UMTS
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
Distributed Call Signaling Framework
DCS- DCS-
Proxy+GC Proxy+GC
Announcement
Server
MTA M Access ER Signaling Transport (IP) ER Access M MTA
Media transport (IP)

PSTN
GW
PSTN
MTA Media Terminal Adaptor Call State
M Cable Modem Connection State
ER Edge Router Transaction State
GC Gate Controller

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
PacketCable Architecture

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 un-
trusted 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
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
Call Management Server Interface
NCS/TGCP DCS/SIP
Translation, Congestion Control, PSTN,
DB access, Event recording, Routing
Call
Signaling
Call Agent DCS-Proxy
QoS
Gate Controller
Signaling
DQoS
COPS
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
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
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
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
Busy Line Verify (BLV) Call Flow
PSTN GW CMS/MGC DPT MTAT
1
NTFY
CRCX P-DCS-OSPS : BLV (Indicator of
MF Signal
2
ACK Busy Line Verification function)
3
INVITE (BLV)
4
INVITE (BLV)
5
183 Session Progress
183 Session Progress 7
6
PRACK Allocate
8
network
200 OK 9 resources
UPDATE
10
200 OK 11
Commit to
200 OK INVITE network
200 OK INVITE 12 resources
13
ACK
14
Busy Line Verification in Progress (one-way data transfer from MTA to Operator)

256
Emergency Interrupt (EI) Call Flow
PSTN GW CMS/MGC DPT MTAT
Busy Line Verification in Progress (one-way data transfer from MTA to Operator)
P-DCS-OSPS : EI (Indicates a
NTFY change to Emergency Interrupt)
15
INVITE (EI)
Interrupt
16
200 OK INVITE 16
ACK
14
Emergency Interrupt in Progress (two-way data transfer)

257
P-DCS-BILLING-INFO
P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON Billing-Correlation-ID "/" FEID *(SEMI Billing-Info-param)
Billing-Correlation-ID = 1*48(HEXDIG)
FEID = 1*16(HEXDIG) "@" host
Billing-Info-param = 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
CMS-CMS Call Flow

259
CMS-CMS Call Flow

260
CMS-MGC Call Flow

261
CMS-MGC Call Flow

262
SIP & IMS

263
Contents
o IP Multimedia Subsystem
o Call Session Control Function (CSCF)
o IMS Interfaces
o 3GPP SIP Overview
o Differences to IETF SIP
o 3GPP SIP requirements
o IMS Service Architecture
o IMS Service Control Interface (ISC)
o Convergence
o TISPAN
o Differences to NGN IMS
o SIP and Mobility

264
SCP
SSP
DLC
STP
PSTN
PSTN GW
PBX
3rd Party

Server Server
OSA
SIP Network Gateway
EBP SIP/SIP ISC

CMTS CMS/GC
SIP SIP/SIP ISC
Agents Servers HSS
PacketCable Network
PCF
MGCF IM Subsystem
MTA MTA
WiFi/ VDSL FTTH

WiMax
CDMA/
GSM/UMTS
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
comprisesallallCN
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
security roaming
Inter-
QoS Working
policy CS/PSTN
SIP
control
Basic
charging Call
Control
Service logic
APIs

267
IMS Building Blocks
o Applications Layer OSA-GW
End-user telephony service logic Telephony AS
AIN call trigger points Non-telephony AS
Non-telephony based services
APIs for enterprise & legacy applications
CSCF, BGCF
o Session Control Layer MGCF & MRFC
End Point Registration HSS
Session setup
QoS establishment
Media Gateway
o Transport & Endpoint Layer Media Server
Bearer Services, Media Conversion (PCM > IP),
Compression
Special functions: announcements, touch tones
collection, voice recognition, speech synthesis

268
IMS Architecture
Control Plane
The HSS holds the
Traffic Plane HSS IMS service profile of
I-CSCF
IMS Cx
the subscribers.
I-CSCF Other IP/

Cx
Mw IMS network
P-CSCF S-CSCF
Mm
Go Gi
Gi
CSCFs are the IMS entities

UTRAN S-CSCFthere
responsible of the call control: interconnects to external
IP networks
are 3 types of CSCFs depending onand other IMS
their role: networks.
P-CSCF (Proxy CSCF) IfThe THIG
PS isdomain
used by the operator to
provides
UE SGSN GGSN S-CSCF (Serving CSCF) hide
the IPitsbearer
internal
to configuration,
access to the
connections
the IMS, i.e. atoPDP
I-CSCF (Interrogating CSCF) external networks
context.
PS Domain goes through an I-CSCF.

269
IMS Architecture
Control Plane
Traffic Plane HSS

I-CSCF
IMS Cx
I-CSCF Other IP/

Cx
In Release 6, the PDF can Mw
The MRF is used
IMS network
be separated from the P- P-CSCF call S-CSCF
for multiparty Mm
CSCF. Those two entities Mk
control Mr
are then connected
Mi
through the Gq interface. MRF
Mg
Gq Go Gi
Mj BGCF
MGCF Those entities are
Gi
UTRAN IMS- SGW responsible for
PDF interworking
MGW Mn
Go Gi between IMS and
CS domain/PSTN
UE SGSN GGSN
PS Domain Legacy/
PSTN

270
3GPP/3GPP2 IMS Architecture
Web
Web Portal
Portal
Centralized
Centralized
Databases
Databases
Parlay
Parlay App
App SIP
SIP App
App HSS
HSS
Server
Server Server
Server Support
Support Systems
Systems
Application ter Billing
me Billing Mediation,
Mediation,
Layer Dia Fault
OSA
OSA SCS
SCS Fault Correlation,
Correlation,
Operations,
Operations,
Maintenance,
Maintenance,
SIP
S-CSCF
S-CSCF BGCF SIP
BGCF
Session SIP
SIP MGCF
MGCF
Control
I-CSCF
I-CSCF
Layer
MRFC P-CSCF
P-CSCF
MRFC PDF
PDF
COPS
SIP
H.248
IN
IN
Transport and Access
Access
End Point IP
IP SG
H.248
Media
Media SG
Layer Server
Server Signalling
Signalling
Converter
Converter
SIP
Media
Media
Gatewa
Gatewa
y
y SS7
SS7
PSTN
Legacy IP TDM Analog

Wireline and Wireless SIP Endpoints Endpoints & PBXs PBX Endpoint
GSM, UMTS, 802.11, Bluetooth, DSL, FTTP, H.323 and MGCP

271
IMS Standards
3GPP and 3GPP2 (3rd Have both defined the IP Multimedia Subsystem (IMS)
Generation Partnership The harmonization effort has kept the definitions as similar as possible.
Project/3rd Generation
Partnership Project 2)
IETF (Internet Engineering Provide the definitions for SIP, SDP and other protocols underlying IMS
Task Force) 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 Provides protocol definitions used by IMS

Telecommunication Union) H.248 for media control
Q.1912.SIP for SIP ISUP interworking (in conjunction with IETF)
ETSI (European TISPAN - TISPAN is merger of TIPHON (VoIP) and SPAN (fixed networks)
Telecommunications Agreement on reuse of 3GPP/3GPP2 IMS in comprehensive NGN plans
Standards Institute)
ANSI (American National Provides protocol definitions used by IMS
Standards Institute) T1.679 covers interworking between ANSI ISUP and SIP
ATIS (Alliance for Addressing end-to-end solutions over wireline and wireless
Telecommunications Industry Nearing agreement to use 3GPP/3GPP2 IMS
Solutions)

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
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
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
Interrogating CSCF (I-CSCF)
o Gateway between P-CSCF and S-CSCF
o Acts as a network entry point for SIP signaling
o Assigning a S-CSCF to a user performing SIP registration
o Route a SIP request received from another network towards
the S-CSCF
o 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
o Support Topology Hiding Inter-network Gateway (THIG) or
other techniques to hide the configuration, capacity, and
topology of the network from the outside
o Prevents roaming partners from discovering each others
network configurations
o Charging and resource utilisation
o Generation of CDRs

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
IMS Interfaces
Ut Home Network
Visited/Home Network HTTP
Ro
Rf DIAMETER
DIAMETER BG
Ro Sh AS Online
Offline Charging P-CSCF DIAMETER DIAMETER OCS Charging
Online
Gm Gq MRFC HSS
Mw
Charging Mr ISC
Compressed SIP DIAMETER SIP
(3GPP profile) SIP (3GPP profile) Mp Cx SIP (3GPP
PDF To I-CSCF or S- H.248 (3GPP DIAMETER profile)
CSCF profile)
GGSN
MRFP Rf
Go Mw DIAMETER
COPS-PR to GGSN I-CSCF S-CSCF Offline
for resource control P-CSCF interfaces Charging
Mi
S-CSCF interfaces SIP (3GPP Mm
profile) SIP
BG To external
BGCF
I-CSCF interfaces PDN
Mk Mj
Dh AS
SIP (3GPP profile) SIP (3GPP profile)
DIAMETER
Mm SLF HSS
SIP MGCF
Dx
To external PDN BGCF Mc
DIAMETER Cx H.248
DIAMETER
IM- MGW
Mw
I-CSCF
S-CSCF
Mw
All interfaces are IPv6
Rf Home Network
To P-CSCF
DIAMETER Offline Charging
IMS uses SIP, DIAMETER, H.248 and COPS-PR
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
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
Relationship of the Private and Public User Identities
Public
User Identity
IMS Private Public

Subscription User Identity User Identity
Public
User Identity
Public I
User Identity
Private I
User Identity
IMS Public II
Subscription User Identity
Private II
User Identity
Public III
User Identity

281
SIP Registration
Home
HSS
Location
Location Profile
Profile
4 Cx-Query Resp Cx-Pull/Put

3 Cx-Query 6 Cx-Pull/Put 7
Resp
8 200 OK
I-CSCF
I-CSCF S-CSCF
S-CSCF
5 REGISTER
2 REGISTER 9 200 OK
Visited P-CSCF
P-CSCF
1 REGISTER 10 200 OK
GGSN
GGSN
SGSN
SGSN
RadioAccess
Radio AccessNetwork
Network

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

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-ietf-
mmusic-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-ietf-
sipping-3gpp-r5-requirements) to IETF stating the
requirements identified by 3GPP to support SIP for IP
Multimedia Subsystem (IMS) in cellular networks.

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
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
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
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 S-
CSCF 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
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
IMS Service Architecture
Service
Logic All 3 types of AS
Native SIP behave as SIP AS on
Servlet/CPL/API
Services ISC interface towards
SIP S-CSCF
AS DIAMETER
ISC 3rd Party
(SIP+) Services
OSA
OSA/Parley Application
HSS Cx
S-CSCF
ISC Gateway OSA Server
(SIP+) API
ISC
(SIP+)
IM SSF S-CSCF Serving -Call Session Control

MAP Function
Legacy IN IM SSF IP Multi-media Service
CAP Switching Function
Services
HSS Home Subscriber Store
CAMEL
Service ISC IMS Service Control Interface
Environment
290
IMS Service Architecture
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
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
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
Filter Criteria Triggering Example
1. User initiates a SIP session by sending a
SIP INVITE with header=A to its S-CSCF
2. S-CSCF evaluates the SPTs and finds a
match with the filter criteria X. S-CSCF
forwards request to AS1. Application Application
Server 1 Server 2
3. AS1 performs any needed service logic
and sends the SIP request back to the S- SIP message SIP message
CSCF with a service related modification, ISC Interface now with possibly
header=B modified
i.e. change header=A to header=B.
2 3 4 5
4. S-CSCF evaluates the SPTs and finds a
match with the filter criteria Y. S-CSCF
forwards the request to AS2. 1
INVITE Match Initial Filter Criteria
5. AS2 performs any needed service logic Incoming SIP Leg
S-CSCF Out-Going SIP Leg
and sends SIP request back to the S- INVITE Filter Criteria X to AS1 SPT HeaderA priority 1
CSCF. Header =A Filter criteria Y to AS2 SPT HeaderB priority 2
6. No more filter criteria, S-CSCF forwards

this request to the next hop based on the 6
route decision. SIP message forwarded by S-CSCF
7. 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.
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
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
Driving forces for Convergence
Convergence from two sides

Service convergence
Fixed network Control convergence Mobile network

towards convergence towards convergence
Network convergence
Terminal convergence

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

Access Capability Transport Capability
Packet Switch
Packet Switch
Transport Capability
Access Capability
VoIP / VToA

297
Current Transition Trend
1 2 3
Softswitch AS AS Softswitch Softswitch

AS AS AS AS
LDAP LDAP LDAP LDAP LDAP LDAP LDAP LDAP LDAP
Common Session Control Common Session Control

HSS
VOIP IM IM
Session Session Session HSS
Adapter
SIP SIP SIP

Terminal Terminal Terminal SIP Terminals SIP Terminals
Integrated Vertical Structure Intermediate Horizontal Structure IMS Horizontal Structure

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
How to operate Convergence
Radio Access
Network
Base
Station
UMA-enabled Controller GSM/IMS Core
Dual Mode Service
Handset Architecture
WiFi
Tunneled
IMS stack GANC
(UMA)
Network
IP Access Network Controller
RG
Native IP IP Core Transport

Stack
VOIP
SIP SIP Server
Fixed/Wireless Telephone

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
TISPAN Architecture
Applications
Based on
3GPP IMS
IP Connectivity Other Multimedia

Access Network Data
Components
And related functionality Base
Streaming Services
(RTSP based)
Other Networks
ICF
IP Multimedia
Component (Core IMS)
(SIP based)
PSTN / ISDN Emulation
(SIP-I based)
Gq
PSTN / ISDN
Legacy interface
Legacy Terminals
Terminals
Network Attachment Resource and Admission
GW Functionality Control Functionality
NASS RACS
Legacy GW Go
Terminals interface TGW
NGN
Terminals Customer MBG
Networks IP Core transport
Access Transport
Network Network
NGN
Terminals
3GPP IP-CAN
3GPP Terminals

302
Network Access Attachment
Functions in other domains

NAAF Application Functions
RACF
CPE Transport Functions
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
Resource And Admission Control
Service Control Functions
SCPF SCF IBCF
Service Stratum
Transport Stratum Gq Gq
Resource And Admission Control Functions
Other NGNs
M-PDF Resource Mediation I-PDF
Rq
Rq Rq Rq
Network Access
Attachment A-TRCF C-TRCF I-TRCF
Functions Access Core
Ub
Go Rc Rc
Re Rc Re
R-BGF ANF ENF A-BGF I-BGF
CPN Access Transport Core Transport

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
PSTN/ISDN Emulation
ADF Next Generation ADF

Network
Originating Terminating
Legacy Terminal 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
PSTN/ISDN Simulation
NGN NGN NGN NGN NGN
SIP Originating Terminating SIP

Originating Core Transit Terminating
Client Subscribers Network Client
Network Network Subscribers
Home Network Home Network
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
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
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
NGN Mobility Requirements Scenarios
Access
Node Intra-AN
Border Intermediate
Gateway Node
Node
Access
Access Network Node
Inter-AN
NGN Core Network Border
Node
Access
Border Node
Node
Border Intermediate Access
Gateway Node Node
Node
Inter-CN
NNI Access Network
Border
Node
Border
Border Intermediate Access Inter-TE
NGN Core Network Gateway Node Node
Node Node
Access Network

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
SIP And Terminal Mobility
Home Network Home Network
Home Home
INVITE Re-INVITE
Proxy Proxy
#3 #5
T ER
#6 #2
TER
IS
V I TE
#2
REG
IS
TE
#4
N
#4
REG
Re-I
#6
INVI
#3
Re-INVITE
#5
INV Cell 2
I TE Cell 2 REGISTER
RE #1
Visited G IST Visited
Proxy #1 ER Proxy
Cell 1 Cell 1
Visited Network Visited Network

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
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
SIP & SIMPLE

315
Contents
o Presence
o SIP Extensions for Presence
o Instant Messaging (IM)
o SIP Extensions for IM

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
SIP Extension for Presence
SUBSCRIBE
REGISTER
NOTIFY
Subscriber Proxy Presence Agent + Proxy/Registrar Presentity
(Watcher) = Presence Server
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
SIP Extension for Presence
SUBSCRIBE
REGISTER
NOTIFY
Subscriber Proxy Presence Agent + Proxy/Registrar Presentity
(Watcher) = Presence Server
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
Presence Basic Operation
o Subscriber send SUBSCRIBE
o Routed to PA using normal SIP
o PA authorizes subscriber
o Acceptance contains presence state
o NOTIFY sent when state changes
o Routed using SIP Record-Route
NOTIFY sip:user@userpc.example.com
To: sip:user@example.com
From: sip:alice@wonderland.com
Call-ID: knsd08alas9dy@3.4.5.6
SUBSCRIBE sip:bob@wipro.com SIP/2.0 CSeq: 1 NOTIFY
Event: presence Content-Type: application/xpidf+xml
To: sip:bob@wipro.com
From: sip:user@example.com <?xml version="1.0"?>
Contact: sip:user@userpc.example.com <!DOCTYPE presence
Call-ID: knsd08alas9dy@3.4.5.6 PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
CSeq: 1 SUBSCRIBE <presence>
Expires: 3600 <presentity uri="sip:alice@wonderland.com;method="SUBSCRIBE">
Content-Length: 0 <atom id="779js0a98">
<address uri="sip:alice@wonderland.com;method=INVITE">
<status status="closed"/>
</address>
</atom>
</presentity>
</presence>

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
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
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
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
SIP & Services

325
Contents
o SIP REFER Method
o SIP Refer-To Header
o SIP Call Transfer Blind
o SIP Replaces Header
o SIP Call Transfer Attended
o SIP Message Summary/Waiting Indication
o Push To Talk Over Cellular (PoC)

326
REFER Method
o Indicates that the recipient (identified REFER sip:b@atlanta.example.com SIP/2.0
by the Request-URI) should contact a Via: SIP/2.0/UDP agenta.atlanta.example.com;
branch=z9hG4bK2293940223
third party using the contact To: <sip:b@atlanta.example.com>
information provided in the request From: <sip:a@atlanta.example.com>;tag=1234
Call-ID: 898234234@agenta.atlanta.example.com
o Contain exactly one Refer-To header CSeq: 93809823 REFER
field value Max-Forwards: 70
Refer-To: sip:alice@atlanta.example.com
o Request may be placed outside the Contact: sip:a@atlanta.example.com
scope of a dialog created with an Content-Length: 0
INVITE
o Implicitly establishes a subscription to
the refer event NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;
o Each NOTIFY must contain a body of branch=z9hG4bK9922ef992-25
type "message/sipfrag" To: <sip:a@atlanta.example.com>;tag=1234
From: <sip:b@atlanta.example.com>;tag=5678
o The body of a NOTIFY must begin Call-ID: 898234234@agenta.atlanta.example.com
with a SIP Response Status-Line CSeq: 1993402 NOTIFY
Max-Forwards: 70
o Can be used to enable many Event: refer
applications, including Call Transfer Subscription-State: active
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
SIP/2.0 100 Trying

327
Refer-To Header
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param)
o Request header field, appears only in a REFER request

o Provides a URL to reference
o May be encrypted as part of end-to-end encryption
o 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
SIP Call Transfer - Blind
Originator Recipient Final Recipient
User A User B User C
1
INVITE
200 OK 2
Call Transfer
Initiated using 3
ACK
REFER
Two way Speech Path
Call Transfer
4
REFER: Refer-To: C Success using
REFER
202 Accepted 5
6
INVITE
200 OK
NOTIFY : 200 OK 7
8
ACK
10
200 OK 9
Two way Speech Path

BYE 11
12
200 OK

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
SIP Call Transfer Attended (1)
User A INVITE/200/ACK User B User C
Call-ID:1;FromTag=11;ToTag=22
Two way Speech Path

INVITE (Hold)
200 OK
ACK
Call Transfer
INVITE Call-ID:2;FromTag=33
Initiated using
REFER 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
SIP Call Transfer Attended (2)
User A Call Transfer User B User C
Success using INVITE: Replaces:Call-ID:2;
REFER FromTag=33 ;ToTag=44
Call-ID:3;FromTag=55
NOTIFY : 200 OK 200 OK Call-ID:3;FromTag=55;ToTag=66

ACK Call-ID:3;FromTag=55;ToTag=66
200 OK
BYE Two way Speech Path

200 OK
BYE Call-ID:2;FromTag=33;ToTag=44
200 OK Call-ID:2;FromTag=33;ToTag=44

332
SIP Message Summary And Message-Waiting Indication
SMDI
PSTN Switch
VoiceMail
User A 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
SIP Message Summary And Message-Waiting Indication
SIP IP Network SIP

PSTN Switch VoiceMail
User A Server
SIP
Switch can act as a SIP SIP-Based Voice Mail
SIP UA on behalf of
Client System
TDM clients
User B
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
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-message-
summary"
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
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 MWI NOTIFY (ON)
CSeq: 4 SUBSCRIBE NOTIFY sip:alice@alice-phone.example.com SIP/2.0
Max-Forwards: 70 To: <sip:alice@example.com>;tag=78923
Contact: <sip:alice@alice-phone.example.com> From: <sip:alice@example.com>;tag=4442
Event: message-summary Call-Id: 1349882@alice-phone.example.com
Expires: 86400 CSeq: 20 NOTIFY
Accept: application/simple-message-summary Contact: <sip:alice@vmail.example.com>
Content-Length: 0 Event: message-summary
MWI NOTIFY (OFF) Content-Type: application/simple-message-summary
NOTIFY sip:alice@alice-phone.example.com SIP/2.0 Content-Length: 99
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442 Messages-Waiting: yes
Call-Id: 1349882@alice-phone.example.com Message-Account: sip:alice@vmail.example.com Voice-
CSeq: 20 NOTIFY Message: 2/8 (0/2)
Contact: <sip:alice@vmail.example.com>
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 20
Messages-Waiting: no

336
SIP MWT Sample Call Flow
Originator Subscriber Notifier
User A User B subscribes User B Voice Mail Server
for MWT Notification
SUBSCRIBE : message-summary
200 OK
User B is not
available to receive NOTIFY : MWT=NO
the call from User A
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 NOTIFY : MWT=YES

MWT YES
Notification
200 OK
User B retrieves the message from the Voice Mail Server
User B receives NOTIFY : MWT=NO

MWT NO
Notification 200 OK

337
Pre-paid on the SIP B2BUA
Sta
rt B
illin SIP Controller
RADIUS / En
g
B2BUA Application
Billing Server dC
all
e
hon
P
P
SI IN V
of IT E
P s ip
SD GW
200 :91
w/ P- OK 939
00
0 SI w/
SD
210
00
1 P w/
72 SD Po
fS SD
94 w/ I P- P
:91 K AC GW
si p 0O K
TE 20
VI
IN
Pre-Paid Client
PSTN

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
PoC 1-to-Many Group Session
Member A
Wireless Network
Member E
Member B
Member D
Member C

340
Logical Architecture of PoC

341
PoC Client Functionality
o Allow session initiation, participation and release
o Perform registration with the SIP/IP Core
o Authentication of the PoC User to the SIP/IP Core
o Generate and send Talk Bursts by recording and encoding
audio
o Receive Talk Bursts and generate audio by decoding the
received Talk Bursts.
o 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
o Support receiving of Instant Personal Alert
o May provide group advertisement
o Request privacy of User Identity

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
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
Ad-hoc Group Session Invitation
PoC SIP/IP PoC Server A
Client A Core (Participating & Controlling)
1
INVITE
INVITE
2 Invitations to invited
POC subscriber
ALERTING First ALERTING

3
Response
ALERTING 4
OK First accepted
7
invitation
OK 8
Talk Burst Confirms 9
10 Media

345
Pre-Arranged Group Session Setup
POC Client A Home Network Controlling Network
PoC SIP/IP PoC Server A PoC Server X SIP/IP
Client A Core A (Participating) (Controlling) Core X
INVITE
1
2
INVITE
INVITE 3
4
INVITE
INVITE 5 Invitations to the
group members
First ALERTING
ALERTING
6 Response
ALERTING 7
8
ALERTING First accepted
invitation
ALERTING 9 11
OK
ALERTING 10 OK 12
13
OK
OK 14
OK 15

346
Pre-Arranged Group Session Setup
POC Client A Home Network Controlling Network
PoC SIP/IP PoC Server A PoC Server X SIP/IP
Client A Core A (Participating) (Controlling) Core X
INVITE
1
2
INVITE
INVITE 3
4
INVITE
INVITE 5 Invitations to the
group members
First ALERTING
ALERTING
6 Response
ALERTING 7
8
ALERTING First accepted
invitation
ALERTING 9 11
OK
ALERTING 10 OK 12
13
OK
OK 14
OK 15

347
SIP Application
Framework

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
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
JAIN SIP Object Architecture
createListener() getInstance()
SIP Factory SIP Listener SIP Factory
createStack()
Event
Registration createProvider()
SIP Provider SIP Stack
Proprietary Proprietary
Network
SIP Stack SIP Stack

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
JAIN SIP Messaging Architecture
Application
SipListener SipListener
SIP Messages SIP Events SIP Messages SIP Events
SipProvider SipProvider
Listening Point Listening Point
Stack Network Stack

353
JAIN SIP 3rd Party Call Control
Client SIP SIP
SipListener SipFactory SipProvider Transaction Dialog A Dialog B
Party A Party B
createReq(INVITE, -)
createClientTransaction(inviteA)
new()
sendRequest() new() null
INVITE(SipListener, A)
confirmed 200OK(offerA)
createReq(INVITE, offerA)
createClientTransaction(inviteB)
new()
sendRequest() null
new()
INVITE(SipListener, B)
ACK(offerA)
confirmed 200OK(offerB)
ACK(offerB)
createReq(re-INVITE)-setBody(offerB)
createClientTransaction(inviteC)
sendRequest(clientTransC)
Re-INVITE(offerB)
200OK(offerB)
ACK(offerB) RTP

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 java-
enabled 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
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
SIP Servlet - Call Schedule on Busy or No Answer
Alices Web Alices Converged Bobs
Browser SIP UA Servlet Container SIP UA
INVITE
1
2
INVITE
100 Trying 3 486 Busy
302 Moved Temporarily 5
4
6
ACK ACK
8
HTTP GET 7
200 OK 9
HTTP POST
10
11
SUBSCRIBE
200 OK
200 OK 12
13
NOTIFY 14
15
200 OK
INVITE 16
17
200 OK
ACK 18
19
INVITE
200 OK
INVITE 21
20
22
200 OK
23
ACK
ACK 23
RTP
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
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
End to End architectures using the SIP APIs
SIP Lite
SIP for J2ME Visited Home

HSS
Network Network
MGCF
SIP Servlet
SIP for J2ME
JAIN SIP JAIN SIP
P-CSCF
I-CSCF
S-CSCF
SIP Servlet
JAIN SIP Application
SIP Servlet Server
Application MGW
Server SIP Servlet
SIP Lite
Application
Server
SIP Lite

360
Questions ?

361

SIP Certification Rel 1

Uploaded by

Copyright:

Available Formats

SIP Certification Rel 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SIP Certification Rel 1

Uploaded by

Copyright:

Available Formats

SIP/IMS Certification

Copyright 2006 Wipro Ltd Wipro confidential

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 33

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 44

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 55

o Signaling Protocol to establish presence,

o Media Transport Protocols for transmission of

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 66

PPP AAL3/4 AAL5 PPP

Sonet ATM Ethernet V.34

o Uses proxy servers to help route requests to the Network Layer

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 88

07/2002 RFC 3261 New SIP RFC published

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 10

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 11

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 12

ITU-T SG 16 H.323 V1-V4 umbrella standard

ETSI TISPAN Concerned with IP/PSTN interoperability

SIP Forum For promotion of SIP Technology

PacketCable Established by CableLabs to look at cable technologies

and the list goes on

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 13

DNS Location Application

EBP SIP/SIP ISC

WiFi/ VDSL FTTH

Outbound SIP Inbound

User Agent A User Agent B

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 15

o User Agent Server (UAS) :

o SIP User Agent (UA) :

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 16

o User Agent can be both SW and HW

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 17

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 18

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 19

DNS Srv Query ? wipro.com

INVITE sip:subhodeep@wipro.com INVITE sip:subhodeep@192.219.223.160

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 20

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 21

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 22

No memory requirements Reduce retransmission time by acting on

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 23

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 24

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 25

302 Moved Temporarily

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 26

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 27

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 28

This registration example establishes presence

binds this address to users current location

REGISTER sip:register.wipro.com SIP/2.0

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 29

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 30

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 31

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 32

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 33

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 35

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 36

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 37

SIP Certification Training 1.1 Copyright 2006 Wipro Ltd 38