SIP Certification Rel.1

© Copyright 2006 Wipro Ltd Wipro confidential

SIP/IMS Certification

Training

2SIP Certification Training 1.1 © Copyright 2006 Wipro Ltd 2

o SIP Concept & Network Architectureo SIP Protocol Specifico SIP & Securityo SIP & QoSo SIP & PSTNo SIP & PacketCableo SIP & 3GPPo SIP & SIMPLEo SIP & Serviceso SIP Application Framework

ContentsContents


SIP Concept & Network SIP Concept & Network ArchitectureArchitecture


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

ContentsContents


o PC-to-PC (MS NetMeeting, appliances)

o PC-to-Phone (net2phone.com)

o Phone-to-Phone (Paegas)

o Phone-to-PC as well

Internet TelephonyInternet Telephony

IP Network

IP Network

IP Network


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.

What Protocols Are Needed ?What Protocols Are Needed ?


Internet Multimedia Protocol ZooInternet Multimedia Protocol Zoo

IPv4, IPv6

PPP AAL3/4 AAL5 PPP

ATMSonet V.34Ethernet

TCP UDP

H.323 SIP

SDP

MGCP/Megaco

COPS

DNS

RTSP

DIAMETER

RSVP RTCP

RTP

Media Encoding (H.261, MPEG)

TRIP

Phys

ical

Dat

a Li

nkN

etw

ork

Tran

spor

t


o Application-layer signaling protocol for creating, modifying, and terminating sessions with one or more participants

o Sessions include Internet telephone calls, multimedia distribution (voice, image, video, etc), and multimedia conferences

o Session invitations carry session descriptions that allow participants to agree on a set of compatible media types.

o Uses proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users (like presence, mobility, hold, forward, transfer)

o Provides a registration function that allows users to upload their current locations for use by proxy servers

o Runs on top of several different transport protocols (UDP, TCP, SCTP, TLS)

Physical Layer

Data Layer

Network Layer (IP/ATM)

Transport Layer (UDP, TCP, SCTP,

TLS)

Application LayerSIP

What Is SIP ?What Is 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.

Why SIP ?Why SIP ?


Brief HistoryBrief History

Date Specifications Comments1995 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 availablehttp://www.cs.columbia.edu/~hgs/sip/implementations.html

http://www.pulver.com/sip/products.html

07/2002 RFC 3261 New SIP RFC published


SIP Working GroupsSIP Working GroupsSIP Deals with changes to the base SIP protocol and any key extensions that might have a

bearing (or that which might warrant a change) on the base SIP protocol

SIPPING (Session Initiation Proposal Investigation)

Deals with standardizing extension to SIP protocol that does not have a bearing on the base SIP protocol - i.e., all SIP peripheral activities (like support of Message Waiting Indicator feature using SIP, SIP-T, ISUP-SIP mapping, SIP Call flows, AAA requirements in SIP etc

SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions)

Deals with standardizing Presence and Instant Messaging (IM) using SIP (E.g., extensions to MSRP protocol for Session Mode Messaging unlike the original page-mode messaging offered by SIMPLE), PIDF - Presence Info Data format, XCAP – XML Configuration Access Protocol etc

MMUSIC (Multiparty Multimedia Session Control)

Chartered to specify protocol required for Internet conferencing and multimedia communications. Specifies protocols such as SDP, RTP/RTCP, RTSP, Interactive Communication Establishment (ICE) for NAT discovery etc)

XCON (Centralized Conferencing)

The focus of this working group is to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Standardizes protocols (based on SIP) like CPCP (conferencing policy control protocol), BFCP (binary floor control protocol) etc

MIDCOM (Middle Box communication)

Chartered to address NAT/Fire Traversal issues. Standardizes protocols like MIDCOM for pin-hole management of NAT; STUN (simple traversal of UDP thru NATs) etc

ENUM (Electronic Numbering)

Deals with converting E.164 numbers to routable URIs (similar to DNS). In fact, ENUM is a nothing but a glorified DNS for VoIP. It uses the same building blocks of DNS like the NAPTR (Naming Address Pointer) records for specifying the E.164 to URI conversion


SIP Working GroupsSIP Working GroupsIPTEL (IP Telephony) Deals with problems related to naming and routing for Voice over IP (VoIP)

protocols

Standardizes protocols like TGREP (Telephony Gateway Registration Protocol) - needed for dynamically registering new (sip) gateways and soft switches in a Multimedia/VoIP network; TRIP (Telephony routing over IP) - TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol

This WG also specified the Call Processing Language (CPL) - an XML based scripting language to implement user features on a SIP Proxy

SPIRITS (Services in the PSTN/IN Requesting Internet Services)

Allows for services supported by IP network entities getting initiated from IN (Intelligent Network) requests, as well as the protocol arrangements through which PSTN (Public Switched Telephone network) can request actions to be carried out in the IP networking response to events (IN Triggers) occurring within the PSTN/IN

For instance the SPIRITS protocol specifies some changes to the SIP URI scheme and can be used for services such as Internet Call Waiting etc. I.e., this deals with activating/ initiating services from the PSTN and rendering it over the Internet

PINT (PSTN Interworking) This WG specifies a protocol to perform the corollary of the SPIRITS (described above).

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


Other Related BodiesOther Related Bodies3GPP (Third Generation Partnership Project)

Creation of technical specifications for 3rd Generation Mobile Systems

Uses SIP as call signaling in IP networks

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

H.248 (Megaco)

ETSI TISPAN Concerned with IP/PSTN interoperability

Analysis of security threats, Open Settlement Protocol

SIP Forum For promotion of SIP Technology

PacketCable Established by CableLabs to look at cable technologies

JAIN (Java Advanced Intelligent Network)

Developing abstract APIs for developing service creations across PSTN, ATM, IP, etc.

PARLAY Group Aims to intimately link IT applications with the capabilities of the telecommunications world by specifying and promoting application programming interfaces (APIs) that are secure, easy to use, rich in functionality, and based on open standards.

Parlay integrates telecom network capabilities with IT applications via a secure, measured, and billable interface.

…and the list goes on


Network ArchitectureNetwork Architecture

IM SubsystemMGCF

CSCFHSS

Application Server

3rd Party Applications

OSA Gateway

SIP/SIP-T

SIP/SIP ISC

SIP/SIP ISC

PCF

WiFi/ WiMax

VDSL FTTH

CDMA/ GSM/UMTS

PacketCable Network

MTA

CMTS

MTA

CMS/GC EBP

PSTNSTP

SSPDLC

SCP

PBX

SIP/SIP-T

PSTN GW

SIP Network

SIP

DNS Location Server

User Agents

Application Servers


SIP "Trapezoid"SIP "Trapezoid"

Location ServerDNS Server

Outbound Proxy Server

Inbound Proxy Server

User Agent A User Agent B

SIP SIP

SIP

DNS

RTP


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

SIP User Agent (UA)SIP User Agent (UA)


SIP User AgentSIP User Agent

o User Agent can be both SW and HW


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

SIP ProxySIP 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 sequentiallyo Can fork the requests to multiple servers

o Useful for enforcing policy

o Authenticate and authorize users for services, implement provider call-routing policies

SIP ProxySIP Proxy


SIP - Proxy Mode OperationSIP - Proxy Mode Operation

#1

PROXY

LOCATION SERVER

Calle

e

#2

[email protected]

#3

#7 ACK sip:[email protected]

#8

INVITE sip:[email protected]: sip:[email protected]: sip:[email protected] Call-ID: [email protected]

INVITE sip:[email protected]: sip:[email protected]: sip:[email protected] Call-ID: [email protected] #4

200 OKFrom: sip:[email protected]: sip:[email protected] Call-ID: [email protected]

#5200 OKFrom: sip:[email protected]: sip:[email protected] Call-ID: [email protected]

#6

Media Streams

[email protected]

[email protected]

DNS Srv Query ? wipro.comReply : IP Address of wipro.com SIP Server

DNS Server


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

SIP Stateful ProxySIP Stateful 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

SIP Stateless ProxySIP Stateless Proxy


Stateless Versus Stateful ProxyStateless Versus Stateful Proxy

Stateless Mode Stateful ModeUsageGood for heavy-load scenario, i.e. Core Network

Good for implementing some services like “forward on no reply”, i.e. Edge Network

BehaviorProxies just receive messages, perform routing logic, send messages out

Proxies maintain state during entire transaction; they remember outgoing requests as well as incoming requests until transaction is over

Would result in new execution of SIP routing logic for every retransmission (caching routing results can help reduce the overload)

A forking proxy will be stateful

No memory requirements Reduce retransmission time by acting on behalf of sender closer to destination


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

SIP Outbound ProxySIP Outbound Proxy


o Aids in locating the target of the requesto Allows servers to push routing information for a request

back in a response to the client, scaling down processingo 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 Doesn’t generate a SIP request of it’s own

SIP Redirect ServerSIP Redirect Server


SIP - Redirect Server OperationSIP - Redirect Server Operation

[email protected]#1

PROXY

LOCATION SERVER

[email protected]

INVITE [email protected]

#4 302 Moved TemporarilyContact:[email protected]

#5 ACK [email protected]

Calle

e

#2

Callee@hom

e.com

#3

#6 INVITE [email protected]

#7 200 OK INVITE

#8 ACK [email protected]


o A SIP Server may either proxy or redirect a requesto Which of the two method applies is a configuration issue.

It may be statically configured or dynamically determinedo 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 statelesso Proxy useful if forking, AAA, firewall control needed. In

general, proxying grants more control to the server

SIP Server – Redirect Versus ProxySIP Server – Redirect Versus Proxy


SIP RegistrarSIP Registraro 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 networko Location Service is a DB containing the SIP URI and its

locationso Location service is used by a SIP redirect or proxy server

to obtain information about a callee's possible locationso DNS query is used to access location service (RFC 3263)


SIP – Registrar OperationSIP – Registrar Operation

REGISTER sip:register.wipro.com SIP/2.0From: sip:[email protected]: sip:[email protected]: <sip:192.219.223.160>Expires: 7200

#1

subh

odee

p@19

2.21

9.22

3.16

0

#2

SIP REGISTRAR(domain register.wipro.com)

LOCATION SERVER

SIP/2.0 200 OK#3

This registration example establishes presence of user with address [email protected] and binds this address to user’s current location 192.219.223.160


SIP Back-to-Back User Agent (B2BUA)SIP Back-to-Back User Agent (B2BUA)o Logical entity that receives a request and processes it as

a user agent servero It acts as a user agent client and generates requestso Maintains dialog state and must participate in all requests

sent on the dialogs it has establishedo Provides “third-party call control”o Useful for services and anonymity


SIP – B2BUA OperationSIP – B2BUA Operation

VoIP VoIP NetworkNetworkVoIP VoIP NetworkNetwork

Calling Party

PSTN

Called Party

PSTN

SignalingSignaling

Bearer Or Media

Bearer Or MediaMedia (UDP)

100 Trying

180 Ringing100 Trying

RTP StreamRTP Stream

200 OK200 OK

180 Ringing

ACKACK

SIP Signaling & SDP Signaling(UDP or TCP)

INVITE (Call-ID#1)INVITE (Call-ID#2)

11

1

1

1

1

1

1

11


o SIP is structured as a layered protocol Lowest layer is syntax and encoding Second layer is the transport layer Third layer is the transaction layer Layer above the transaction layer is called

the transaction user (TU)

SIP Protocol StackSIP Protocol Stack

Syntax/Encoding

Transport Layer

Transaction Layer

Transaction User

Physical Layer

Data Layer

Network Layer

Transport Layer


o Lowest layer of SIPo Responsible for encoding/decoding

and syntactical parsing of the messages

o Encoding is specified using an augmented Backus-Naur Form grammar (BNF)

Syntax/Encoding LayerSyntax/Encoding Layer

Syntax/Encoding

Transport Layer

Transaction Layer

Transaction User

Physical Layer

Data Layer

Network Layer

Transport Layer


o Second layer of SIPo Responsible for the actual

transmission of requests and responses over network transports

o Responsible for managing persistent connections for transport protocols like TCP, SCTP and TLS

o Performs framing for message-oriented transport like UDP

o Performs Error handling for request or response message

o All SIP elements contain a transport layer

o All SIP elements implement UDP and TCP

o Recommended port - 5060 for UDP, TCP and SCTP, 5061 for TLS over TCP

Transport LayerTransport Layer

Syntax/Encoding

Transport Layer

Transaction Layer

Transaction User

Physical Layer

Data Layer

Network Layer

Transport Layer


o Third layer of SIPo Handles application-layer retransmissions,

matching of responses to requests, and application-layer timeouts

o Consists of Client transaction Server transaction

o Each component is represented by a finite state machine that is constructed to process a particular request

o Stateless proxies do not contain a transaction layer

Transaction LayerTransaction Layer

Syntax/Encoding

Transport Layer

Transaction Layer

Transaction User

Physical Layer

Data Layer

Network Layer

Transport Layer


Transaction LayerTransaction Layero 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


o Layer above the transaction layero To send a request, TU creates a client

transaction instance and passes the request along with the destination IP address, port, and transport to which to send the request

o TU that creates a client transaction can also cancel it

o Each of the SIP entities, except the stateless proxy, is a transaction user

Transaction User (TU)Transaction User (TU)

Syntax/Encoding

Transport Layer

Transaction Layer

Transaction User

Physical Layer

Data Layer

Network Layer

Transport Layer


SIP PROTOCOL SPECIFICSIP PROTOCOL SPECIFIC


o SIP Messageso Protocol Basicso Message Bodieso Headerso Session Description Protocol (SDP)o Offer-Answer Modelo SIP State Machineo SIP Addressingo SIP Routingo SIP Extensionso SIP Event Notification Framework

ContentsContents


SIP MessagesSIP Messageso Either a Request from a client to

a server, or a Response from a server to a client

o Both types of messages consist of Start-Line One or more Header fields An Empty Line indicating the

end of the header fields An optional Message Body

o Uses the UTF-8 charset (RFC 2279)

o Request and Response messages use the basic format of RFC 2822

o Message and header field syntax is very much identical to HTTP/1.1

V=0o=origin_user timestamp timestamp IN IP4 host s=session namec=IN IP4 media destination addresst=0 0m= media type port RTP/AVP payload types

Via: SIP/2.0/ protocol host:portFrom: user <sip:from_user@source>To: user <sip:to_user@destination>Call-ID: localid@hostCSeq: seq# methodContent−Length: length of body Content−Type:media type of bodyHeader: parameter ;par1=value ;par2="value"

Messa

ge Head

er

SIP/2.0 status reasonmethod URL SIP/2.0

Blank Line (CR LF)

Messa

ge Body

Request Start Line Response Start Line


RequestRequesto Distinguished by having a Request-Line for a start-

lineo A Request-Line contains

Method name Request-URI 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.

INVITE sip:[email protected] SIP/2.0

Request Method Request-URI

Protocol Version


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)

SIP Signalling - METHODSSIP Signalling - 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)

SIP Signalling – Extension METHODSSIP Signalling – Extension METHODS


INVITE OPTIONS

OPTIONS sip:[email protected] SIP/2.0From: sip:[email protected]: sip:[email protected]−ID: [email protected]: 1 OPTIONSVia: SIP/2.0/UDP clrdomain.com;branch=z9hG4bK776Accept: application/sdpContent-Length: 0

SIP

SDP

INFO

INFO sip:[email protected] SIP/2.0From: sip:[email protected]: sip:[email protected]: <sip:[email protected]>Call−ID: [email protected]: 1 INFOContent-Length: 0

SIP

SDP

INVITE sip:[email protected] SIP/2.0From: sip:[email protected]: sip:[email protected]−ID: [email protected]: 1 INVITEVia: SIP/2.0/UDP clrdomain.com;branch=z9hG4bK776Content-Type: application/sdpContent-Length: 274

v=0 o=called 536 2337 IN IP4 h3.clddomain.com s=session_name_1c=IN IP4 192.213.229.147 t=0 0 m=audio 3456 RTP/AVP 0

SIP

SDP

Requests can have headers and SDP Requests may not

have SDP

Sample RequestsSample Requests


ResponseResponseo Distinguished from requests by having a Status-Line as

their start-lineo A Status-Line consists of

Protocol version Numeric Status-Code Associated textual phrasewith each element separated by a single SP character.

o No CR or LF is allowed except in the final CRLF sequence

SIP/2.0 180 Ringing

Textual Phrase

Status Code

Protocol Version


o Borrowed from HTTP: xyz explanatory text Receivers need to understand x x80 and higher codes avoid conflicts with future HTTP response

codeso 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

SIP Signalling – Response CodeSIP 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

SIP Signalling – Response CodeSIP Signalling – Response Code


Success – 200 OK Failure – 487 Request Terminated

SIP/2.0 487 Request RerminatedFrom: sip:[email protected]: sip:[email protected]−ID: [email protected]: 1 INVITEContent-Length: 0

SIP

SDP

Provisional – 180 Ringing

SIP/2.0 180 RingingFrom: sip:[email protected]: sip:[email protected]: <sip:[email protected]>Call−ID: [email protected]: 1 INVITEContent-Length: 0

SIP

SDP

SIP/2.0 200 OKFrom: sip:[email protected]: sip:[email protected]−ID: [email protected]: 1 OPTIONSAccept: application/sdpAccept-Encoding: gzipAccept-Language: enContent-Type: application/sdpContent-Length: 274


SIP

SDP

Response can have headers and SDP

Response may not have SDP

Sample ResponsesSample Responses


SIP – HeadersSIP – Headerso Similar to HTTP header fields in both syntax and

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


Sample SIP HeadersSample SIP Headers

From: sip:[email protected]: sip:[email protected]−ID: [email protected]: 1 OPTIONSAccept: application/sdpAccept-Encoding: gzipAccept-Language: enContent-Type: application/sdpContent-Length: 274

f: sip:[email protected]: sip:[email protected]: [email protected]: 1 OPTIONSAccept: application/sdpAccept-Encoding: gzipAccept-Language: enc: application/sdpl: 274

Form – Long Form – Compact

From: sip:[email protected]: sip:[email protected]−ID: [email protected]: 1 OPTIONSContact: <sip:[email protected]>;expires=3600Contact:<sip:[email protected]>Route: <sip:[email protected]>,<sip:[email protected]>, <sip:[email protected]>

Multiple Headers Field Rows


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

SIP – Message BodiesSIP – Message Bodies


SIP – Message BodiesSIP – Message Bodieso 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


Sample SIP Message BodiesSample SIP Message Bodies

Content-Type: application/sdpContent-Length: 274


Content-Type: application/message-summaryContent-Length: 98

Messages-Waiting: yesMessage-Account: sip:[email protected]: 2/8 (0/2)

Media - SDPApplication – Message Summary

Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756

Application - pkcs7-signature


SIP Call FlowSIP Call Flow

Proxy Server

LocationServicesSIP UA (A) SIP UA (B)

INVITE (SDPo)Location Lookup

Lookup Result

INVITE (SDPo)

200 OK (SDPT)200 OK (SDPT)

ACK

BYE

12

3

89

10

11

Session In Progress

SessionInitiation

SessionTeardown

12200 OK

180 Ringing6180 Ringing

7

Two way Speech Path

100 Trying 54


SIP – TransactionSIP – Transactiono Fundamental unit of message exchangeo Request Response cycleo 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 serverso 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 responseo If the response was a 2xx, the ACK is not considered

part of the transaction


SIP – TransactionSIP – Transaction

INVITE (CSeq:1 INVITE)

100 Trying (CSeq:1 INVITE)

UAC UAS

200 OK (Cseq:1 INVITE)

ACK (CSeq:2 ACK)

BYE (CSeq:3 BYE)

200 OK (CSeq:3 BYE)

1

2

3

4

5

6

First Transaction

Second Transaction

INVITE (CSeq:1 INVITE)

100 Trying (CSeq:1 INVITE)

UAC UAS

486 Busy Here (CSeq:1 INVITE)

ACK (CSeq:1 INVITE)

1

2

3

4

First Transaction

Successful Call Scenario Failure Call Scenario


SIP – DialogSIP – Dialogo Represents a peer-to-peer SIP relationship between two

user agents o SIP-level conversation between two endpointso 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


SIP – DialogSIP – Dialog

INVITE

100 Trying

UAC UAS

486 Busy Here

ACK

1

2

3

4

First Transaction

Single Dialog Scenario No Dialog Scenario

INVITE (F-Tag: Xxx)

100 Trying

UAC UAS

200 OK (F-Tag: Xxx, T-Tag: Yyy)

ACK (F-Tag: Xxx, T-Tag: Yyy)

BYE (F-Tag: Xxx, T-Tag: Yyy)

200 OK (F-Tag: Xxx, T-Tag: Yyy)

1

2

3

4

5

6

First Transaction

Second Transaction

Dialog


SIP – DialogSIP – Dialogo Identified at each UA with a dialog ID, which consists of

a Call-ID value, a local tag and a remote tago A dialog ID is associated with all responses and with any

request that contains a tag in the To fieldo 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


SIP – SessionSIP – Sessiono A session is the exchange of media between two or

more endpointso Most common form of a session uses the RTP protocol

for exchange of voice mediao Can also be used to exchange text, video, game

information and other types of mediao 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


Request-URIRequest-URIo Indicates the user or service to which this request is

being addressedo Supports SIP or SIPS or TEL URI or any generic URIo Current destination, may change along the signaling patho 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

REGISTER sip:registrar.wipro.com SIP/2.0

Request-URI

INVITE sip:[email protected] SIP/2.0

Request-URI


ToTo

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 Supports SIP or SIPS or TEL URI or any generic URIo Can be populated through a human interfaceo 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

To = ( "To" / "t" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )


ToTo

o Supports “Tag” to identify the peer of the dialogo Occur only once per messageo Compact form of the To header field is to Examples of valid To header fields:

To: The Operator <sip:[email protected]>;tag=287447 t: sip:[email protected]

To = ( "To" / "t" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )

To : The Operator <sip:[email protected]>;tag=287447

Tag Parameter

Addr spec

Display Name


FromFrom

o Indicates the logical identity of the initiator of the request, possibly the user's address-of-record

o Supports SIP or SIPS or TEL URI or any generic URIo Populated value is pre-provisioned by the user or by the

administrators of the user's local domaino 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

From = ( “From" / “f" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )


FromFrom

o Use display name "Anonymous" if the identity of the client is to remain hidden

o Supports “Tag” to identify the peer of the dialogo Occur only once per messageo Compact form of the From header field is fo Examples of valid From header fields:

From: A. G. Bell <sip:[email protected]> ;tag=a48s From: sip:[email protected];tag=887s f: Anonymous <sip:[email protected]>;tag=hyh8

From = ( “From" / “f" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )

From: A. G. Bell <sip:[email protected]> ;tag=a48s

Tag Parameter

Addr spec

Display Name


o Used in the To and From header fields of SIP messageso 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

dialogo Must be globally unique and cryptographically randomo Algorithm for generating a tag is implementation-specific

TagsTags


Call-IDCall-ID

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 UAo 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 Occur only once per messageo Compact form of the Call-ID header field is io Examples of valid Call-ID header fields:

Call-ID: [email protected]:[email protected]

Call-ID = ( "Call-ID" / "i" ) HCOLON word [ "@" word ]


CSeqCSeq

o Serves as a way to identify and order transactionso Differentiator between new requests and request

retransmissions o Consists of a single decimal sequence number and a

methodo The method must match that of the requesto 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

CSeq = "CSeq" HCOLON 1*DIGIT LWS Method


CSeqCSeq

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 Occur only once per messageo Examples of valid CSeq header fields:

CSeq: 231 BYECSeq: 314159 INVITE

CSeq = "CSeq" HCOLON 1*DIGIT LWS Method

CSeq: 231 BYE

MethodDigit


Max-ForwardsMax-Forwards

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 Occur only once per messageo Examples of valid Max-Forwards header fields:

Max-Forwards: 6

Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT


ViaVia

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

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 tokenvia-received = "received" EQUAL (IPv4address / IPv6address)


ViaVia

o Occur one or more per messageo The compact form of the Via header field is vo 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=z9hG4bK87asdks7Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.20;branch=z9hG4bK77asjd

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 tokenvia-received = "received" EQUAL (IPv4address / IPv6address)

Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7

Branch Parameter

HostProtocol/Version/Transport

Port


Branch ParameterBranch Parametero Contain in Via header field valueo Used to identify the transaction created by that requesto Used by both the client and the servero Value is unique across space and time for all requests

sent by the UAo 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 acknowledgeso 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


ContactContact

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

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


ContactContact

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



ContactContact

o Occur zero or one per messageo Compact form of the Contact header field is m (for

"moved")o Examples of valid Contact header fields:

Contact: "Mr. Watson" <sip:[email protected]>;q=0.7; expires=3600,"Mr. Watson" <mailto:[email protected]> ;q=0.1

m: <sips:[email protected]>;expires=60


Contact: "Mr. Watson" <sip:[email protected]>;q=0.7; expires=3600

Contact Parameters

Address Spec

Display Name


REGISTER sip:registrar.biloxi.com SIP/2.0Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7Max-Forwards: 70To: Bob <sip:[email protected]>From: Bob <sip:[email protected]>;tag=456248Call-ID: 843817637684230@998sdasdh09CSeq: 1826 REGISTERContact: <sip:[email protected]>Expires: 7200Content-Length: 0

REGISTER MethodREGISTER Methodo Create bindings in a location

service for a particular domain that associates an AOR URI with one or more contact addresses

o Sent from UAC to Registraro Registrar identified in Request-

URIo Identifies registered user in Too Identifies person performing

registration in From (usually = To)

o Contains list of current locations in Contact headers


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

REGISTER MethodREGISTER Method


REGISTER ResponseREGISTER Response

SIP/2.0 200 OKVia: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7Max-Forwards: 70To: Bob <sip:[email protected]>From: Bob <sip:[email protected]>;tag=456248Call-ID: 843817637684230@998sdasdh09CSeq: 1826 REGISTERContact: <sip:[email protected]>Contact: <sip:[email protected]>Expires: 7200Content-Length: 0

o Check if domain is its owno Authorize user in Fromo Add address bindings of “To” to

Contact listo Modify expiration time, if too longo Return, in response, list of all

current registrationso Return, in response, expiration

time for all registrations and respective priorities, if present


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 refresho 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 cancellationo Querying list of current registrations

Send REGISTER with no Contact headers Response contains list of current registrations

Registration DetailsRegistration Details


INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: [email protected]: 314159 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 142

v=0o=user1 536 2337 IN IP4 h3.clrdomain.coms=session_name_1c=IN IP4 h3.clrdomain.comm=audio 3456 RTP/AVP 0 1m=video 4000 RTP/AVP 38 39

SIP

SDP

INVITE MethodINVITE Methodo Used to signal the desire

to open a sessiono Sent from UAC to UASo Mandatory header

fields : From To Call-ID CSeq Via Max-Forward

o Can carry SDP to exchange the media capabilities


ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyffTo: Bob <sip:[email protected]>;tag=99sa0xkFrom: Alice <sip:[email protected]>;tag=88sja8xMax-Forwards: 70Call-ID: 987asjd97y7atgCSeq: 986759 ACKContent−Type: application/sdpContent-Length: 138

v=0o=user1 536 2337 IN IP4 h3.clrdomain.coms=session_name_1c=IN IP4 h3.clrdomain.comm=audio 3456 RTP/AVP 0 1

SIP

SDP

o ACK method is used to confirm the final response that was sent to the INVITE method

o Sent from UAC to UASo Indicates that the session

has been acceptedo Can be used to indicate

SDP to the other entity; not mandatory to contain SDP info

ACK MethodACK Method


Sample Call Flows – ACK w/wo SDPSample Call Flows – ACK w/wo SDP

INVITE (SDPO)

100 Trying

UAC UAS

200 OK (SDPT)

ACK

BYE

200 OK

1

2

3

4

5

6

Fast Start Call Scenario

Two way Speech Path

First Transaction

Second Transaction

INVITE

100 Trying

UAC UAS

200 OK (SDPT)

ACK (SDPO)

BYE

200 OK

1

2

3

4

5

6

Slow Start Call Scenario

Two way Speech Path

First Transaction

Second Transaction


o Allows a UA to query another UA or a proxy server as to its capabilities

o Capabilities: Supported methods Content types Extensions Codecs

o Sent from UAC to UASo Target identified in

Request-URIo All UAs must support the

OPTIONS method

OPTIONS sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877Max-Forwards: 70To: <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 63104 OPTIONSContact: <sip:[email protected]>Accept: application/sdpContent-Length: 0O

PT

ION

S R

eq

ue

st M

eth

od

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

OPTIONS MethodOPTIONS Method


o Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields are recommended

o 200 OK - if UAS is ready to accept a call

o 486 (Busy Here) – if UAS is busy, etc

o Allow header field should be omitted, if generated by a proxy

o Message body may be sent, the type of which is determined by the Accept header field in the request

OPTIONS ResponseOPTIONS Response

SIP/2.0 200 OKVia: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877Max-Forwards: 70To: <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: a84b4c76e66710CSeq: 63104 OPTIONSContact: <sip:[email protected]>Allow: INVITE, ACK, CANCEL, OPTIONS, BYEAccept: application/sdpContent-Length: 0

OP

TIO

NS

Su

cce

ss R

esp

on

se


o Sent to signal the end of the established session

o Sent from UAC to UASo Can be initiated by any UAC

which is a of the sessiono Any session associated with

that dialog should terminate o All pending methods (if any)

should be terminated

BYE MethodBYE Method

BYE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyffTo: Bob <sip:[email protected]>;tag=99sa0xkFrom: Alice <sip:[email protected]>;tag=88sja8xMax-Forwards: 70Call-ID: 987asjd97y7atgCSeq: 986759 BYEContent-Length: 0


o Sent to cancel a previously sent method

o UAC to UASo Cancels pending request and

generates error response method (487: Request Terminated)

o No effect on a request for which a final response has been received

o Stateful proxy responds to a CANCEL, rather than simply forwarding

o Referred to as a "hop-by-hop" request o Request-URI, Call-ID, To, the numeric

part of CSeq, and From header must be identical to those in the request being cancelled, including tags

CANCEL MethodCANCEL Method

CANCEL sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyffTo: Bob <sip:[email protected]>;tag=99sa0xkFrom: Alice <sip:[email protected]>;tag=88sja8xMax-Forwards: 70Call-ID: 987asjd97y7atgCSeq: 986759 INVITEContent-Length: 0


Sample Call Flows – BYE & CANCELSample Call Flows – BYE & CANCEL

INVITE

100 Trying

UAC UAS

200 OK

ACK

BYE

200 OK

1

2

3

4

5

6

Successful Call Scenario

Two way Speech Path

First Transaction

Second Transaction

INVITE

100 Trying

UAC UAS

180 Ringing

CANCEL

1

2

3

4

Failure Call Scenario

200 OK

487 Request Terminated

5

6

ACK7

Second Transaction

First Transaction


SIP State Transition - ServerSIP State Transition - Server

eventmessage sent

Initial

Call Proceeding

Confirmed

Failure Success

INVITE1xx

INVITE1xx

CANCEL200

status change1xx BYE

200

failure>= 300INVITE

status INVITEstatus

Callee Answer2xx

ACK-

ACK- BYE

200

BYE20032s

-

max(T1*2n, T2)status


SIP State Transition - ClientSIP State Transition - ClientInitial

Call Proceeding

Completed

Calling

-INVITE

7 INVITE sent-

give upBYE

300-699ACKevent

request sent

T1*2n

INVITE

1xx

1xx

300-699ACK

give upBYE

32s (for proxy)

300-699ACK


SIP AddressingSIP Addressingo 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:[email protected] is a SIP URI sips:[email protected] 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:[email protected] (Need DNS SRV records to locate

SIP Servers for sip.wipro.com domain) Fully Qualified Domain Name (FQDN) (identifies a device)

• sip:[email protected]


SIP AddressingSIP Addressing

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

sip/sips:user:password@host:port;uri-parameters?headers


SIP AddressingSIP Addressing

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

sip/sips:user:password@host:port;uri-parameters?headers


SIP Addressing - ExampleSIP Addressing - Example

sip:[email protected]:5060;user=phone?Subject=SIP

Headers and Body (Subject=SIP)Parameters (user=phone)Optional Port (5060)Hostname (airtel.kk.com)Username (+919845202688)Schema (sip)


ENUM (E.164 Number Mapping)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 lookupo End users (Applications) can select URI according

to their preferenceo Standardization by cooperation of IETF and ITU-T

(RFC 2916)o Defines how to map E.164 number to DNS NAPTR

resource recordo Designates “e164.arpa” for ENUM infrastructure in

DNSo Defines new E2U+sip ENUM service for SIP


E.164 Domain Name ConversionE.164 Domain Name Conversiono Check if E.164 is complete

E.g. +81-3-5297-25712o Remove all non-digit except for leading ‘+’

+81352972571 This form is remained as AUS (Application Unique String)

for applying regular expression in NAPTRo Remove leading ‘+’

813529725714o Put dots (“.”) between each digit.

8.1.3.5.2.9.7.2.5.7.15o Reverse the order of the digits

1.7.5.2.7.9.2.5.3.1.86o Append the string “.e164.arpa”to the end

1.7.5.2.7.9.2.5.3.1.8.e164.arpa


PSTN to VOIP Call Via SIPPSTN to VOIP Call Via SIP

“Call setup”

SIPsip:[email protected]

Query1.3.1.9.5.8.6.8.6.4.e164.arpa.?

Dial+4686859131

Responsesip:[email protected]

SIP ServerGateway

DNS-Server


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-URIo 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 addresso Try IP addresses in order of preference, go to next if no

responseo If no SRV records present, use A records

A records are standard hostname to IP address recordso Allows administrators to use several servers for a single

domain, to move services from host to host

Locating User – DNS SRVLocating User – DNS SRV


o Service: Symbolic name of the desired service o Proto: Symbolic name of the desired protocolo Name: Domain this RR refers too 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 Classo Priority: Priority of this target hosto Weight: Server selection mechanism, specifies a relative weight for

entries with the same priorityo Port: Port on this target host of this serviceo Target: Domain name of the target host

Locating User – DNS SRVLocating User – DNS SRV_Service._Proto.Name TTL Class SRV Priority Weight Port Target

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


SIP Routing HeadersSIP Routing Headerso Request-URI: Current destination, may change along

signaling patho 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 sento Record-Route: Inserted by proxies in a request to force

future requests in the dialog to be routed through the proxyo Route: Used to force routing for a request through the listed

set of proxies


Record-RouteRecord-Route

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>

Record-Route = "Record-Route" HCOLON name-addr *( SEMI rr-param ) *(COMMA name-addr *( SEMI rr-param ) )

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

Indicates Loose Routing

Address Spec


BYE Message Flow – W/WO Record RoutingBYE Message Flow – W/WO Record Routing

BYE

200 OK

UA1 SIP Proxy UA2

BYE

200 OK

UA1 SIP Proxy UA2

200 OK

BYE

Without Record Routing With Record Routing


RouteRoute

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>

Route = "Route" HCOLON name-addr *( SEMI rr-param ) *(COMMA name-addr *( SEMI rr-param ) )

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

Indicates Loose Routing

Address Spec


SIP Routing - RequestSIP Routing - Requesto Send requests to local proxy or host in Request-URIo Determined by route set which can be learned, through

headers like Record-Route or can be pre-configuredo 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.


Strict RoutingStrict Routingo Proxy is said to be strict routing if it follows the Route

processing rules of RFC 2543-bis05o Proxies destroy the contents of the Request-URI when a

Route header field was presento Strict routing conflates the request target with the next

hop destinationo Brittle system failure if any element misrouteso Proxies that perform strict routing are also known as

strict routers

INVITE B

A DB C

INVITE CRoute C,D Route D INVITE D


Loose RoutingLoose Routingo 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

INVITE D

A DB C

INVITE DRoute B,C Route C INVITE D


Loose Routing - ProcessingLoose Routing - Processingo If it’s a strict router, follow old (RFC 2543bis-05)

Route/Record-Route ruleso 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


o The INVITE arriving at U2 containsINVITE sip:[email protected] SIP/2.0Contact: sip:[email protected]: <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 BYEBYE sip:[email protected] SIP/2.0Route: <sip:p4.domain.com;lr>Route: <sip:p3.middle.com>Route: <sip:p2.example.com;lr>Route: <sip:p1.example.com;lr>

Loose Routing - ExampleLoose Routing - ExampleU1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements


o P4 receives BYE sip:[email protected] SIP/2.0 Route: <sip:p4.domain.com;lr> Route: <sip:p3.middle.com> Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr>

o And sends BYE sip:p3.middle.com SIP/2.0 Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr> Route: <sip:[email protected]>



o P3 receives BYE sip:p3.middle.com SIP/2.0 Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr> Route: <sip:[email protected]>

o And sendsBYE sip:p2.example.com;lrRoute: <sip:p1.example.com;lr>Route: <sip:[email protected]>

o P2 sees a URI it provided in the Request-URI so it rewrites this toBYE sip:[email protected]: <sip:p1.example.com;lr>

o And sends it to P1



o P1 ReceivesBYE sip:[email protected]: <sip:p1.example.com;lr>

o And sendsBYE sip:[email protected]



SIP Routing - ResponseSIP Routing - Responseo Response traces back request route without proxy

server stateo Each proxy pre-pends a Via header with own address in

request and removes the address in responseo 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


SIP Routing – ResponseSIP Routing – Response

Via:192.219.223.160

UAC UASProxy Proxy 192.219.223.160 172.16.16.120 172.16.16.160 192.219.223.197

Via:172.16.16.120Via:192.219.223.160

Via:172.16.16.160Via:172.16.16.120Via:192.219.223.160

Via:192.219.223.160

Via:172.16.16.120Via:192.219.223.160

Via:172.16.16.160Via:172.16.16.120Via:192.219.223.160

RequestResponse


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 forkingo First 200 OK that is received is forwarded upstreamo All other unanswered requests cancelledo Allows rapid “search” for user at many locationso Two variations

Sequential Search: Try first address, only if that fails try second address

Parallel Search: Try all addresses at once

ForkingForking


Parallel Forking - ExampleParallel Forking - Example

SIP Protocol

Non-SIP Protocol(Eg. Database Query)

Location ServerSession setup

Request from the UAC

IP Network

CANCEL setup request

UAS LocationQuery

Session setup request forwarded to UAS 2


486 Busy Here


Connect to UAS 2

1

OK to connect

2

2

2

3

4

5

Location Server

SIP Proxy

UAC

UAS1

UAS2

UAS3

6


LoopLoopo Request that arrives at a proxy, is forwarded, and later

arrives back at the same proxyo Looped requests are errorso 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


SpiralSpiral

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 arrivalo Not an error conditiono Typical cause for spiral is Call Forwardingo Example of a valid SIP Spiral:

1. Foo calls [email protected]. example.com proxy forwards it to Joe's PC3. Joe’s PC forwards it to [email protected]. New request is proxied back to the example.com proxy


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

Session Description Protocol (SDP)Session Description Protocol (SDP)


SDP AnatomySDP Anatomyoriginator

Session ID and version timestamp

originating host

connection information (multicast address)

start time (NTP timestamp)

stop time (NTP timestamp)

PCM audio using RTP port 3456

Variable rate DVI4, codeword 1, speech bit rate 8kb/s

H.261 video using RTP port 3458

whiteboard application on port 32416

whiteboard application is in portrait mode

Conference Total, Max 64kb/s bandwidth

0


Offer-Answer ModelOffer-Answer Modelo 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 SIPo Operation begins when one agent sends an initial offer

to another agent o Agent receiving the offer

Generate an answer Reject the offer


Offer-Answer – Protocol Operation Offer-Answer – Protocol Operation o At any time, either agent can generate a new offer that

updates the sessiono 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


Offer-Answer – Protocol Operation Offer-Answer – Protocol Operation o To reject an offered stream, the port number in the

corresponding stream in the answer must be set to zeroo 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 zeroo Existing media streams are removed by creating a new

SDP with the port number for that stream set to zeroo 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


Offer-Answer – Examples Offer-Answer – Examples

v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 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 m=audio 49920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000

Offered SDP

Answered SDP


Reliability of Provisional Responses Reliability of Provisional Responses o An extension to the SIP providing reliable provisional

response messageso Uses the option tag 100rel to indicate supporto Uses the Provisional Response ACKnowledgement (PRACK)

method o Reliable provisional responses are retransmitted by the TU

exponentiallyo Retransmissions stops when a PRACK message is receivedo Reliability is ensured hop-by-hop through each stateful proxyo A single outstanding provisional response at a time, for

purposes of congestion controlo UAS send any non-100 provisional response reliably if the

initial request contained a Require header field with the option tag 100rel


Reliability of Provisional Responses Reliability of Provisional Responses

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

INVITE (oSDP)

180 Ringing (tSDP)

INVITE (oSDP)

180 Ringing (tSDP)

Backwards Speech Path (audible ringing)

SIP UA (A) SIP Proxy SIP UA (B)

100 Trying

PRACKPRACK

200 OK200 OK


o UAC to UASo Each provisional response is

given a sequence number, carried in the RSeq header, contains a single numeric value from 1 to 2**32 - 1

RSeq: 988789o Contain an RAck header field,

which indicates the sequence number of the provisional response that is being acknowledged, contains two numbers and a method tag

RAck : 776656 1 INVITEo Can optionally contain

session description

PRACK MethodPRACK Method

PRACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: [email protected]: 314159 PRACKRAck: 83 1 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 142


SIP

SDP

RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method RSeq = "RSeq" HCOLON response-num


UPDATE MethodsUPDATE Methodso Allows a client to update

parameters of a session (such as the set of media streams and their codecs)

o Target refresh request, it can update the remote target of a dialog

o No impact on the state of a dialog

o Can be sent before the initial INVITE has been completed

o Very useful for updating session parameters within early dialogs

UPDATE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: [email protected]: 314159 UPDATEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 142


SIP

SDP


UPDATE – Example Call FlowUPDATE – Example Call Flow

INVITE (Offer 1)

180 Ringing (Answer 1)

SIP UA (A) SIP UA (B)

PRACK

200 OK

UPDATE (Offer 2)

200 OK (Answer 2)

UPDATE (Offer 3)

200 OK (Answer 3)

200 OK

ACK

1

2

3

4

5

6

7

8

9

o User A sends an initial INVITE (1) which contains an offer

o User B generates a 180 response (2) with an answer to that offer

o User A generates a PRACK (3) to acknowledge the 180

o User B answered the PRACK with a 200 OK (4)

o User A generate an UPDATE request (5) with a new offer

o User B answered this offer in the 200 response to the UPDATE (6)

o User B generates an UPDATE request (7) with an offer

o User A answer is sent in the 200 response (8)

o Finally, User B answers the call, resulting in a 200 OK response to the INVITE (9)

o User B then sends an ACK (10)


SIP – Event Notification FrameworkSIP – Event Notification Frameworko 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


Event PackageEvent Packageo Defines a set of state information to be reported by a notifier

to a subscribero Define further syntax and semantics based on the framework

to convey such state informationo Define parameters for the Event header and their semantics

for such parameterso Define syntax and semantics for SUBSCRIBE method

bodieso Define semantics associated with the body of their NOTIFY

requests


Event PackageEvent Packageo Optionally, define a suggested range of times considered

reasonable for the duration of a subscriptiono Optionally, define MIME type is to be assumed for NOTIFY

bodieso Define processing of SUBSCRIBE and NOTIFY requesto 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 notifiero Define a throttle mechanism which allows subscribers to limit

the rate of notification


Event HeaderEvent Header

o Indicates which event or class of events been subscribedo Contain a token which indicates the type of state for which a subscription

is being requestedo May contain "id" parameter, which identifies the specific subscription

within a dialogo One event type is allowed per headero Multiple events per message is disallowedo Compared byte-by-byte to match NOTIFY messages with SUBSCRIBE

messageso The "id" parameter token (if present) is also compared byte-by-byteo "Event" header containing an "id" parameter is not equal to "Event"

header without an "id" parametero Compact form of the Event header field is oo Examples of valid Event header fields:

Event: foo; id=1234o: foo

Event = ( "Event" / "o" ) HCOLON event-package *( "." event-template ) *( SEMI "id" EQUAL token )


Subscription-State HeaderSubscription-State Header

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: activeSubscription-State: terminated;reason=timeout

Subscription-State = "Subscription-State" HCOLON substate-value *( SEMI ("reason" EQUAL event-reason-value) / ("expires" EQUAL delta-seconds) / ("retry-after" EQUAL delta-seconds) )


SUBSCRIBE MethodsSUBSCRIBE Methodso Used to request asynchronous

notification of an event or set of events at a later time

o UAC to UASo Used to request current state and state

updates from a remote node o Should contain an "Expires" headero Dialog creating method, may contain

"Accept" headero Must include exactly one "Event"

headero To keep subscriptions effective beyond

the duration communicated in the "Expires" header, subscribers need to refresh subscriptions on a periodic basis using a new request on the same dialog

o To terminate subscription, refresh, with the "Expires" header set to "0".

o Can optionally contain body, defined by the event packages

SUBSCRIBE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: [email protected]: 314159 SUBSCRIBEContact: <sip:[email protected]>Event: message-summaryExpires: 0Content-Length: 0


NOTIFY MethodsNOTIFY Methodso 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 the event

o UAC to UASo To inform subscribers of changes in

state to which the subscriber has a subscription

o Must include exactly one "Event" header

o Must contain "Subscription-State" header

o NOTIFY are matched to such SUBSCRIBE if they contain the same "Call-ID", a "To" header "tag" parameter which matches the "From" header "tag" parameter of the SUBSCRIBE, and the same "Event" header

o Contain body defined by the event packages

NOTIFY sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhdsMax-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>;tag=1928301774Call-ID: [email protected]: 314159 NOTIFYEvent: message-summarySubscription-State: activeContact: <sip:[email protected]>Content-Type: application/simple-message-summaryContent-Length: 99

Messages-Waiting: yesMessage-Account: sip:[email protected]: 4/8 (1/2)

SIP

MWT


SIP Event Notification – Sample Message FlowSIP Event Notification – Sample Message Flow

SUBSCRIBE (Event: Zxx, Expires:3600)

200 OK

UAC UAS

NOTIFY (Subscription-State: Active)

200 OK

2

3

1

4Zxx Event Occurred


200 OK5

6

Zxx Event Occurred


200 OK7

8

SUBSCRIBE (Event: Zxx, Expires:0)

200 OK

NOTIFY (Subscription-State: Terminated)

200 OK

10

11

9

12

Terminate Subscription


SIP & SECURITYSIP & SECURITY


o Security Concernso Security Frameworko Security – SIP Signallingo Transport Layer Security (TLS)o HTTP Digest Authenticationo Secured MIME (S/MIME)o Security – Real-Time Mediao Secure RTP (SRTP)o NAT And SIPo RTP Relay (TURN)o DIAMETER Base Protocolo AAA SIP Architecture – Components

ContentsContents


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

Security ConcernsSecurity Concerns


Security FrameworkSecurity 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)


Security – SIP SignalingSecurity – SIP Signaling Authentication Methods:

PSK Pre-Shared Keys

PKI Public Key Infrastructure

Authentication

Integrity

Confidentiality

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


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

Transport Layer Security (TLS)Transport Layer Security (TLS)


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)

TLS And SIPTLS And SIP


TLS And SIP – Sample Call FlowTLS And SIP – Sample Call FlowNew 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 NULL1 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 NULL1 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


TLS And SIP – Sample Call FlowTLS And SIP – Sample Call FlowIssuer

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 Identifier1 4 0.4307 (0.0000) S>CV3.1(4) Handshake ServerHelloDone1 5 0.4594 (0.0286) C>SV3.1(134) Handshake ClientKeyExchange1 6 0.5498 (0.0903) C>SV3.1(1) ChangeCipherSpec1 7 0.5498 (0.0000) C>SV3.1(48) Handshake1 8 0.5505 (0.0007) S>CV3.1(1) ChangeCipherSpec1 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


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

HTTP Digest AuthenticationHTTP Digest Authentication


Digest Authentication And SIPDigest Authentication And SIP

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 Max-Forwards: 70 Route: <sip:ss1.atlanta.example.com;lr> From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Length: 0

Initial INVITESIP/2.0 407 Proxy Authorization Required Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 From: Alice <sip:[email protected]>;tag=9fxced76sl To: Bob <sip:[email protected]>;tag=3flal12sfCall-ID: [email protected] CSeq: 1 INVITE Proxy-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0

Proxy Challenge

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9Max-Forwards: 70Route: <sip:ss1.atlanta.example.com;lr>From: Alice <sip:[email protected]>;tag=9fxced76slTo: Bob <sip:[email protected]>Call-ID: [email protected]: 2 INVITEContact: <sip:[email protected];transport=tcp>Proxy-Authorization: Digest username="alice", realm="atlanta.example.com",nonce="wf84f1ceczx41ae6cbe5aea9c8e88d359",opaque="",uri="sip:[email protected]", response="42ce3cef44b22f50c6a6071bc8"Content-Length: 0

Authenticated INVITE

1 2

3


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

Secured MIME (S/MIME)Secured MIME (S/MIME)


S/MIME And SIPS/MIME And SIP

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>;tag=daa21162Call-ID: [email protected]: 1 INVITEMax-Forwards: 70Contact: <sip:[email protected]:5060>Content-Type: multipart/signed;boundary=992d915fef419824;micalg=sha1;protocol=application/pkcs7-signatureContent-Length: 3088--992d915fef419824Content-Type: application/pkcs7-mime;smime-type=envelopeddata; name=smime.p7mContent-Disposition: attachment;handling=required;filename=smime.p7mContent-Transfer-Encoding: binary<envelopedData object encapsulating encrypted SDP attachment not shown>--992d915fef419824Content-Type: application/pkcs7-signature;name=smime.p7sContent-Disposition: attachment;handling=required;filename=smime.p7sContent-Transfer-Encoding: binary<signedData object containing signature not shown>--992d915fef419824--

Encrypted and Signed using S/MIME


Security – Real-Time MediaSecurity – Real-Time Media

Authentication Methods:

PSK Pre-Shared Keys

PKI Public Key Infrastructure

Authentication

Integrity

Confidentiality

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


o An extension to the RTP Audio/Video profile o Provides confidentiality, message authentication, and

replay protection to the RTP and RTCP traffico Encrypts individual media packets using a symmetric

session keyo Session key must be securely exchanged - Current

recommendation is to use S/MIME in the signaling

Security RTP (SRTP)Security RTP (SRTP)

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>;tag=daa21162Call-ID: [email protected]: 1 INVITEMax-Forwards: 70Contact: <sip:[email protected]:5060>Content-Type: application/sdpContent-Length: 239v=0c=IN IP4 160.85.170.139k=clear:910bc4defa71eb6190008762fca6ae2f1d959e87cdf3c0c5c5076ad38ee8m=audio 10000 RTP/AVP 0a=rtpmap:0 PCMU/8000


o Part of Private and Enterprise IP network security policyo Simplifies managemento Single point of control for policy enforcement and

administrationo No need for every SIP Endpoint in network to be

configured with security policieso Help to preserve public IP Addresseso Firewall/NAT logically coexist in single nodeo Intelligent enough to understand the importance of ports

in SIP calls

SIP Enabled FIREWALL/NATSIP Enabled FIREWALL/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 packetso Short-term solution to IP depletion issueso Transparent to Applicationo Works in Layer 3 (i.e. Network Layer)o Four types

Full Cone Restricted Cone Port Restricted Cone Symmetric

Network Address Translation (NAT)Network Address Translation (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 NAT’s public IP:port

is dependant on the destination IP address that the packet is sent to

Types of NATTypes of NAT


SIP NAT Traversal – Reference ModelSIP NAT Traversal – Reference Model

PrivatePublic Private

SIP Proxy

RTP/RTCP Media

Firewall/NATFirewall/NAT

Media Signaling


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

SIP Outbound NAT TraversalSIP Outbound NAT Traversal



INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.atlanta.com;received=202.123.211.25;rport=12345Max-Forwards: 70To: Bob <sip:[email protected]>From: Alice <sip:[email protected]>Call-ID: [email protected]: 314159 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 142


Media

Signalling

Actual IP Address and

port it received from

Internal IP Address and

port it sent from


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



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

SIP Inbound TraversalSIP Inbound 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

RTP TraversalRTP Traversal


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

RTP Traversal – SolutionsRTP Traversal – Solutions


RTP Traversal – RTP Relay (TURN)RTP Traversal – RTP Relay (TURN)

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

2 3 6 7

4

51

8

9

12

1012User

Agent

NAT NAT Proxy

RTP Relay

Voice Gateway


o Client will always need to send and receive RTP on the same port

o Increase overall voice latencyo Introduce another point of failureo 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

RTP Relay - ConsiderationsRTP Relay - Considerations


o Recommended method for traversal of NATo 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

RTP Traversal – Interactive Connectivity EstablishmentRTP Traversal – Interactive Connectivity Establishment


DIAMETER Base ProtocolDIAMETER 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


DIAMETER Based SIP ArchitectureDIAMETER Based SIP Architecture

SIP

DIAMETER

SIP Server

SIP Client

SIP Client

SIP

Diameter Server

SIP Server

SIP

DIAMETER

IP Network

DIAMETERDIAMETER

Diameter Subscriber Locator


SIP Server User AuthenticationSIP Server User Authentication

REGISTER

SIP Terminal

SIP Server 1

Diameter Server

SIP Server 2

1UAR

UAA3

401 Unauthorized

2

REGISTER4

MAR

MAA6

5

7401 Unauthorized

8REGISTER

9UAR

UAA11

200 OK

10

REGISTER12

MAR

MAA14

13

15200 OK

16

Includes challenge in the response which is map to

WWW-Authenticate

Successfully authenticates the user




SIP Server Requests AuthorizationSIP Server Requests Authorization

INVITE

SIP Terminal

SIP Server

Diameter Server

1MAR

MAA3

2

407 Proxy Authentication

Required 4

INVITE5

MAR

MAA7

200 OK

6

INVITE8

9200 OK

16


Includes challenge in the response which is map to

WWW-Authenticate

SIP Server


SIP & QoSSIP & QoS


o IP QoS Modelo SIP & QoSo SIP Preconditiono Common Open Policy Service (COPS)o COPS Based QoS SIP Architectureo QoS SIP Architecture – Componentso Q-SIP Call Flows

ContentsContents


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

IP QoS Model IP QoS Model


o SIP doesn’t 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 preconditionso 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

SIP & QoS SIP & QoS


SIP PreconditionSIP Preconditiono A set of constraints about the session which are

introduced in the offero Preconditions require that the participant reserve network

resources before continuing with the session o Preconditions are carried with SDP and treated as state

variableso The offer/answer model is usedo 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


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 Serviceo Strength tag: Indicates whether or not the callee can be

alerted, in case the network fails to meet the preconditions

SIP Precondition – SDP ExtensionsSIP Precondition – SDP Extensionscurrent-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

SIP Precondition – SDP ExtensionsSIP Precondition – SDP Extensionscurrent-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")


SIP Precondition – End-To-EndSIP Precondition – End-To-Endo SDP1: A includes end-to-end quality of service

preconditions in the initial offer. m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv

o SDP2: B uses RSVP, it can know when resources in its "send" direction are available, because it will receive RESV messages from the network. However, it does not know the status of the reservations in the other direction. B requests confirmation for resource reservations in its "recv" direction to the peer user agent A in its answer.

m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv

o After having sent the answer, B starts reserving network resources for the media stream. When A receives this answer (2), it starts performing resource reservation as well. Both UAs use RSVP, so A sends PATH messages towards B and B sends PATH messages towards A.

INVITE (SDP1)

183 Session Progress (SDP2)


PRACK

200 OK

UPDATE (SDP3)

200 OK (SDP4)

180 Ringing

200 OK

ACK

1

2

3

4

5

6

7

10

RESERVATION

RESERVATION

PRACK

200 OK

8

9

11

PATH

RESV

RSV-CONF

PATH

RESV

RSV-CONF

RSV

P se

tup

A to

B

RSV

P se

tup

B to

A


SIP Precondition – End-To-EndSIP Precondition – End-To-Endo As time passes, B receives RESV messages

confirming the reservation. However, B waits until resources in the other direction are reserved as well, since it did not receive any confirmation and the preconditions still have not been met.

o SDP3: When A receives RESV messages, it sends an updated offer (5) to B:

m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=curr:qos e2e send a=des:qos mandatory e2e sendrecv

o SDP4: B responds with an answer (6) which contains the current status of the resource reservation (i.e., sendrecv):

m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv

o At this point in time, session establishment resumes and B returns a 180 (Ringing) response (7).

INVITE (SDP1)

183 Session Progress (SDP2)


PRACK

200 OK

UPDATE (SDP3)

200 OK (SDP4)

180 Ringing

200 OK

ACK

1

2

3

4

5

6

7

10

RESERVATION

RESERVATION

PRACK

200 OK

8

9

11

PATH

RESV

RSV-CONF

PATH

RESV

RSV-CONF

RSV

P se

tup

A to

B

RSV

P se

tup

B to

A


SIP Precondition – SegmentedSIP Precondition – Segmentedo SDP1: A includes local and remote QoS

preconditions in the initial offer. Before sending the initial offer, A reserves resources in its access network. This is indicated in the local current status of the SDP below:

m=audio 20000 RTP/AVP 0 8 c=IN IP4 192.0.2.1 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv

o SDP2: B reserves resources in its access network and, since all the preconditions are met, returns an answer in a 180 (Ringing) response (3).

m=audio 30000 RTP/AVP 0 8 c=IN IP4 192.0.2.4 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv

INVITE (SDP1)

180 Ringing (SDP2)


PRACK

200 OK

200 OK

ACK

1

2

3

5

4

RESERVATION

RESERVATION

6


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

DiffServ Based SolutionDiffServ Based Solution


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

Common Open Policy Service (COPS) Common Open Policy Service (COPS)


COPS – Provisioning ModelCOPS – Provisioning Model

Edge Router(Policy Enforcement Point)

Bandwidth Broker( Policy Decision Point)

Events

Notifications

Configuration Commands

o Trigger events, notifications, and configuration commands are asynchronous

o More scalableo Not flexible - difficult to handle modification of

configurationso Not explicitly customized to handle dynamic DiffServ QoS


COPS – Outsourcing ModelCOPS – Outsourcing Model

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

Edge Router(Policy Enforcement Point)

Bandwidth Broker( Policy Decision Point)

Trigger Events (1)

Query (2)

Response (3)


COPS Based QoS SIP ArchitectureCOPS Based QoS SIP Architecture

Q-SIP

PDP PEP PDP PEP

PDP

COPS

COPS

QoS-Enabled Network

Access Edge Router Access Edge Router

COPS

Q-SIP Server Q-SIP Server

SIP Client

SIP Client

SIP SIP

Client Network Client Network

Bandwidth Broker


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

QoS SIP ArchitectureQoS SIP Architecture


Q-SIP Call Flow - UnidirectionalQ-SIP Call Flow - Unidirectional

INVITE

SIP Terminal

Q-SIP Server

Edge Router

Edge Router

SIP Terminal

Q-SIP Server

1

2INVITE

INVITE3

65


4

180 Ringing

200 OK INVITE7

COPS REQ8

COPS DEC9

200 OK INVITE10

COPS REQ11

COPS DEC12

200 OK INVITE13

ACK14

15ACK

ACK16


Q-SIP Call Flow - BidirectionalQ-SIP Call Flow - Bidirectional

INVITE

SIP Terminal

Q-SIP Server

Edge Router

Edge Router

SIP Terminal

Q-SIP Server

1

2INVITE

INVITE3

65


4

180 Ringing

200 OK INVITE7

200 OK INVITE8

COPS REQ9

COPS DEC10

200 OK INVITE11

ACK12

13ACK

ACK14


SIP & PSTNSIP & PSTN


o SIP For Telephony (SIP-T)o MIME Typeso SIP Profileso ISUP-SIP Mapping o TEL URIo P-Asserted-Identity o Privacyo Number Portabilityo Early Mediao INFO Methodo Overlap Signalling

ContentsContents


SIP For Telephony (SIP-T)SIP For Telephony (SIP-T)o A set of mechanisms for interfacing traditional telephone

signaling with SIPo Provide protocol translation and feature transparency

across points of PSTN-SIP interconnectiono 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


IM SubsystemMGCF

CSCFHSS

Application Server


OSA Gateway

SIP/SIP-T

SIP/SIP ISC

SIP/SIP ISC

PCF

WiFi/ WiMax

VDSL FTTH

CDMA/ GSM/UMTS

PacketCable Network

MTA

CMTS

MTA

CMS/GC EBP


PSTNSTP

SSPDLC

SCP

PBX

SIP/SIP-T

PSTN GW

SIP Network

SIP

DNS Location Server

User Agents

Application Servers


SIP-T Call (SIP Bridging)SIP-T Call (SIP Bridging)

IAM

ANM

ACM

REL

RLC

IAM

ANM

ACM

REL

RLC

INVITE (IAM, oSDP)

100 Trying

ACK

180 Ring. (ACM, tSDP)


200 OK (ANM)

BYE (REL)

200 OK

Two way Speech Path

Switch A Switch BMGC A MGC B

12

3

4

56

7

89

10

11

1213

1415

1617


SIP-T Call (PSTN to SIP UA)SIP-T Call (PSTN to SIP UA)

IAM

ANM

ACM

REL

RLC

INVITE (oSDP)

200 OK (tSDP)

180 Ringing

BYE

200 OK

INVITE (oSDP)

100 Trying

ACK

180 Ringing

200 OK (tSDP)

BYE

200 OK

Two way Speech Path

Switch A SIP UAMGC A SIP Proxy


ACK

12

3

4

56

7

89

101112

1314

1516

17 18


SIP-T Call (SIP UA to PSTN)SIP-T Call (SIP UA to PSTN)

INVITE (oSDP)

200 OK

180 Ringing (tSDP)

BYE

200 OK

IAM

ANM

ACM

REL

RLC

INVITE (oSDP)

100 Trying

ACK

180 Ringing (tSDP)


200 OK

BYE

200 OK

Two way Speech Path

SIP UA Switch ASIP Proxy MGC A

100 Trying

ACK

12

3

5

4

67

89

10

12

1314

15

11

1618

17


Multipurpose Internet Mail Extensions (MIME) TypesMultipurpose 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


MIME Types – ISUPMIME Types – ISUPo Media type defined :

Media type name: application Media subtype name: ISUP Required parameters: versionOptional 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


MIME Types – ISUPMIME Types – ISUP

Content-Type: application/ISUP; version=nxv3; base=etsi121

Base (etsi121)Optional Version (X-NetxProprietaryISUPv3)MIME Type (application/ISUP)SIP Header (Content-Type)

Base Protocol

itu-t88 ITU-T Q.761-4 (1988)

itu-t92 ITU-T Q.761-4 (1992)

ansi88 ANSI T1.113-1988

ansi00 ANSI T1.113-2000

etsi121 ETS 300 121

etsi356 ETS 300 356

ISUP “Base” Values

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP den3.level3.comFrom: sip:[email protected]: sip:[email protected]: [email protected]: 8348 INVITEContact: <sip:[email protected]>Content-Length: 436Content-Type: multipart/mixed; boundary=unique-boundary-1MIME-Version: 1.0

--unique-boundary-1Content-Type: application/SDP; charset=ISO-10646v=0o=jpeterson 2890844526 2890842807 IN IP4 126.16.64.4s=SDP seminarc=IN IP4 MG122.level3.comt= 2873397496 2873404696m=audio 9092 RTP/AVP 0 3 4--unique-boundary-1Content-Type: application/ISUP; version=nxv3;base=etsi121Content-Disposition: signal; handling=optional01 00 49 00 00 03 02 00 07 04 10 00 33 63 2143 00 00 03 06 0d 03 80 90 a2 07 03 10 03 6353 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00--unique-boundary-1--


Content-Type HeaderContent-Type Header

o Indicates the media type of the message-body sent to the recipient

o Must be present if the body is not emptyo 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:

Content-Type: application/sdpc: application/ISUP; version=nxv3; base=etsi121

Content-Type = ( "Content-Type" / "c" ) HCOLON media-type media-type = "text" / "image" / "audio" / "video" / "application" /

"message" / "multipart" SLASH m-subtype *(SEMI m-parameter)


Content-Disposition HeaderContent-Disposition HeaderContent-Disposition = "Content-Disposition" HCOLON disp-type *( SEMI disp-param ) disp-type = "render" / "session" / "icon" / "alert" / “signal” / disp-extension-tokendisp-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 interpretationo 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: sessionContent-Disposition: signal; handling=optional


SIP ProfilesSIP Profiles

SIP Profile B

SIP Terminating Network

SIP Profile A

SIP 3GPP Mobile Network

SIP Profile CPSTN/ISDN

PSTN/ISDN


SIP Profile - ASIP 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 networko Pre-conditions are being used on the SIP network


SIP Profile - BSIP 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 networko Pre-conditions are not used on the SIP network


SIP Profile - CSIP 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


SIP-ISUP MappingSIP-ISUP Mapping

ISUP SIP

IAM INVITE

SAM INVITE

ACM 18x

CPG 18x

CON 200 OK INVITE

ANM 200 OK INVITE

REL BYE

4xx, 5xx, 6xx

CANCEL

RLC BYE

4xx, 5xx, 6xx

CANCEL

ISUP SIP

SUS INFO (Profile C)

RES INFO (Profile C)

COT 200 OK INVITE

RSC BYE

500 Server Internal Error

GRS BYE


CGB BYE



IAM/INVITE MappingIAM/INVITE MappingINVITE IAM

Called Party Number (M)E.164 encoded userinfo of Request-URI (sip:URI with user=phone)

Address Signal

Calling Party Category (M)Profile A & B : “Oridinary Calling Subscriber”

Profile C : Generated from the CPC of encapsulated ISUP

Nature of Connection Indicators (M)

Profile A & B : Default values

Profile C : Generated from the NOC of encapsulated ISUP

Forward Call Indicators (M)Profile A : D = 1, F = 0, HG = 01, I = 0. All other bits are default values.

Profile B : Determined based on analysis of various parameters

Profile C : Generated from the FCI of encapsulated ISUP


IAM/INVITE MappingIAM/INVITE MappingINVITE 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

Profile C : Generated from the CGN of encapsulated ISUP

Privacy header Profile A & B : Address Presentation Restricted Indicator (APRI)

Profile C : Generated from the CGN of encapsulated ISUP


Tel-URITel-URI

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"

telephone-url = "tel" ":" global-phone-number / local-phone-number


Tel-URI - ExamplesTel-URI - Examples

tel:+358-555-1234567

Visual Separator (-)E.164 Number (3585551234567)Indicative of global number (+)URI Schema (tel)

Global Phone Number (+358-555-1234567)

tel:456-7890;phone-context=213

Context (Area Code = 213)Visual Separator (-)Local Number (4567890)URI Schema (tel)

Local Phone Number (+1-213-456-7890)


Number MappingNumber Mappingo 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 fieldTo: tel:+17208881000

o sip URL constitute the user-portion of a URI field To: sip:[email protected]

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:[email protected];user=phone


ISUP to TEL URI MappingISUP to TEL URI Mapping

ISUP SIP

Called Party/Calling Party NumberNPI : E.164

NOA : International

CDN:17208881000

Telephone number digits to be appended unmodified to a 'tel:+‘ string

tel:+17208881000

NPI : E.164

NOA : National

CDN:7208881000

Country code must be prefixed to the telephone number digits before they are committed to a tel URL

tel:+17208881000 (assuming CC = 1)

NPI : E.164

NOA : Subscriber

CDN:8881000

Both a country code and any other numbering components necessary for the numbering plan in question may need to be added in order for the number to be internationally significant

tel:+17208881000 (assuming CC = 1, NPA = 720)sip:[email protected];user=phone

Calling Party NumberPI : 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:[email protected]>


TEL URI to ISUP MappingTEL URI to ISUP Mapping

SIP ISUP

Called Party/Calling Party NumberURI is in international format, the country code is not local to the gateway, retain the country code and populate the digits field

tel:+17208881000

NPI : E.164

NOA : International

CDN:17208881000

URI is in international format, the country code is local to the gateway, strip the country code from the URI before populating the digits field

tel:+17208881000 (assuming CC = 1)

NPI : E.164

NOA : National

CDN:7208881000

URI is not in international format, the gateway may treat the telephone number within the URI as if it were appropriate to its national or network-specific dialing plan

sip:[email protected];user=phone

NPI : Unknown

NOA : Subscriber

CDN:8881000

Calling Party NumberPresentation indicator should be set to 'presentation allowed' and the screening indicator to 'network provided', unless some service provider policy or user profile specifically disallows presentation

PI : Presentation Allowed

SI : Network Provided


P-Asserted-ID HeaderP-Asserted-ID Headero 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


P-Asserted-ID HeaderP-Asserted-ID Header

o Must consist of exactly one name-addr or addr-speco 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:[email protected]>

PAssertedID = "P-Asserted-Identity" HCOLON name-addr / addr-spec


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


Privacy HeaderPrivacy Header

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

Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value) priv-value = "header" / "session" / "user" / "none" / "critical" / “id”


Privacy to CGN MappingPrivacy 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 SIPPI : Presentation Allowed No Privacy header

PI : Presentation Restricted Privacy: id (included on if P-Asserted-Id header is included)


Number Portability (NP)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


Number Portability (NP)Number Portability (NP)o The "tel" URL has been extended to carry the routing

number for the ported geographical numberso 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


Number Portability (NP) - ExampleNumber Portability (NP) - Exampleo 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


NP – ISUP/SIP MappingNP – ISUP/SIP MappingSIP ISUP

Forward Call Indicator (M)

npdi=yes M bit = 'number translated‘

Called Party Number

'rn=' field is present

rn=+12025440000Mapped to CDN

CDN:12025440000

Generic Digit Parameter

Main telephone number in the tel URI

tel:+1-202-533-1234;rn=+1-202-544-0000; npdiMapped to GAP

GAP:12025331234

SIP ISUPForward Call Indicator (M)

M bit = 'number translated‘ npdi appended to the tel URL

Called Party Number

CDN

CDN:12025440000Mapped to 'rn=' field

rn=+12025440000

Generic Digit Parameter

GAP

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

tel:+1-202-533-1234;rn=+1-202-544-0000; npdi


18x/ACM Mapping18x/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

Backward Call Indicators (M)183 Session Progress Profile A : ACM is not generated

Profile B : ACM is not generated

Profile C : Generated from the BCI of encapsulated ACM


18x/ACM Mapping18x/ACM Mapping

ISUP SIP

Backward Call IndicatorsCalled Party Status = “subscriber free” Profile A : 180 Ringing

Profile B : 180 Ringing

Profile C : 180 Ringing with encapsulated ACM

Backward Call Indicators (M)Called Party Status = “no indication” or any other value

Profile A : Not interworked

Profile B : Not interworked

Profile C : 183 Session Progress with encapsulated ACM


18x/CPG Mapping18x/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

Event Information (M)183 Session Progress Profile A : CPG is not generated

Profile B : CPG is not generated

Profile C : Generated from the EI of encapsulated CPG


18x/CPG Mapping18x/CPG Mapping

ISUP SIP

Event Information (M)Event Indicator = “alerting” Profile A : 180 Ringing

Profile B : 180 Ringing

Profile C : 180 Ringing with encapsulated CPG

Event Information (M)Called Party Status = “progress” or “in-band information available”

Profile A : Not interworked

Profile B : Not interworked

Profile C : 183 Session Progress with encapsulated CPG


200/ANM Mapping200/ANM Mapping

SIP ISUP200 OK INVITE Profile A : ANM

Profile B : ANM

Profile C : Generated ANM from the encapsulated ISUP

ISUP SIPANM Profile A : 200 OK INVITE

Profile B : 200 OK INVITE

Profile C : 200 OK INVITE with encapsulated ANM


Reason HeaderReason Header

o Provides the information on why a SIP request was issuedo Useful in creating services like Third-Party Call Control,

ISUP interworkingo Also intended to be used to encapsulate a final status

code in a provisional responseo 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"

Reason = "Reason" HCOLON reason-value *(COMMA reason-value) reason-value = "SIP" / "Q.850" *(SEMI protocol-cause / reason-text )


Reason Header Usage – ExampleReason Header Usage – Example

INVITE

BYE (SIP:486)

200 OK (SDPO)

200 OK

ACK

486 Busy Here

User A Controller User B

ACK (Hold SDP) INVITE

IAM

CANCEL (Q.8650:16)

200 OK

100 Trying

User A Gateway User B

REL (16)

INVITE

Third-Party Call Control ISUP Interworking


BYE/4xx/5xx/6xx/REL MappingBYE/4xx/5xx/6xx/REL MappingSIP 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”


CANCEL – Reason header present Profile A, B & C : Cause Value = protocol-cause, Location = “Network beyond interworking point”


BYE/4xx/5xx/6xx/REL MappingBYE/4xx/5xx/6xx/REL MappingSIP ISUP

Cause Indicator (M)4xx/5xx/6xx – Reason header not present Profile A & B: Cause Value = Status

Code Mapping, Location = “Network beyond interworking point”


Cause Indicator (M)4xx/5xx/6xx – Reason header present Profile A & B : Cause Value = protocol-

cause, Location = “Network beyond interworking point”


REL Cause Value 4xx/5xx/6xx SIP Messages127 Interworking 400 Bad Request

1 Unallocated Number 404 Not Found

20 Subscriber absent 480 Temporarily Unavailable

17 User busy 486 Busy Here


BYE/4xx/5xx/6xx/REL MappingBYE/4xx/5xx/6xx/REL Mapping

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


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

What is Media Clipping ?What is Media Clipping ?

INVITE

200 OK (SDPT)

INVITE

200 OK (SDPT)


100 Trying

ACK (SDPo) ACK (SDPo)

Media Flow from B to A

Media Clipping Occurs


Early MediaEarly Mediao 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


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


Early Media – Gateway ModelEarly Media – Gateway Model

INVITE (SDPo)

200 OK (SDPT)

INVITE (SDPo)

200 OK (SDPT)


100 Trying

ACK ACK

Early Media Session

INVITEINVITE

183 Session Progress (SDPT)


100 Trying

Early Media Session

183 Session Progress (SDPT)

PRACK (SDPo) PRACK (SDPo)


Early Media – AS Model Early Media – AS Model

INVITE (offer)INVITE (offer)

183 Session Progress (answer, early offer)


100 Trying

ACK ACK

Early Media Session

183 Session Progress (answer, early offer)

PRACK (early-answer)PRACK (early-answer)

200 OK200 OK

200 OK INVITE200 OK INVITE

Content-Type: application/sdp Content-Disposition: session v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0

Content-Type: multipart/mixed;boundary="boundary1"Content-Length: 401--boundary1Content-Type: application/sdpContent-Disposition: sessionv=0o=Bob 2890844725 2890844725 IN IP host.example.orgs=c=IN IP4 192.0.2.2t=0 0m=audio 30000 RTP/AVP 0--boundary1Content-Type: application/sdpContent-Disposition: early-sessionv=0o=Bob 2890844714 2890844714 IN IP4 host.example.orgs=c=IN IP4 192.0.2.2t=0 0m=audio 30002 RTP/AVP 0--boundary1--

Content-Type: application/sdpContent-Disposition: early-sessionv=0o=alice 2890844717 2890844717 IN IP4 host.example.coms=c=IN IP4 192.0.2.1t=0 0m=audio 20002 RTP/AVP 0


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


ISUP SUS/RESISUP SUS/RES

ISUP SIPSUS Profile A & B : Not interworked

Profile C : INFO with encapsulated SUS

RES Profile A & B : Not interworked

Profile C : INFO with encapsulated RES

SUSSUSINFO (SUS)

200 OK

Two way Speech Path


RESRESINFO (RES)

200 OK


DTMFDTMFo DTMF was designed to provide address signaling to CO

in PSTN at start of callo Created simple, universal user input mechanism for all

devices on the PSTN networko 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


DTMFDTMFo Original function of DTMF (address signaling) is not needed

in packet networko 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


Overlap SignallingOverlap Signallingo Consists of sending only some digits of the callee's number in the first

signaling messageo Further digits are sent in subsequent signaling messageso SIP uses en-bloc signaling - Request-URI of an INVITE always contains

the whole address of the calleeo 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


Overlap Signalling – Call FlowsOverlap Signalling – Call Flows

IAM

ANM

ACM

IAM

ANM

ACM

1 INVITE (IAM, oSDP)

3 ACK

3 180 Ring. (ACM, tSDP)


3 200 OK (ANM)

Two way Speech Path


SAM 12 INVITE (IAM, SAM 1, oSDP)

1 ACK

1 484 Address Incomplete

SAM 23 INVITE (IAM, SAM 1, SAM2,

oSDP)

2 ACK

2 484 Address Incomplete

SAM 1

SAM 2


SIP & PacketCableSIP & PacketCable


o Backgroundo Distributed Call Signalling Architectureo PacketCable Architectureo Call Management Servero Service Provider Requirementso SIP Proxy-To-Proxy Extensionso CMS to CMS Call Flowo CMS to MGC Call Flow

ContentsContents


IM SubsystemMGCF

CSCFHSS

Application Server


OSA Gateway

SIP/SIP-T

SIP/SIP ISC

SIP/SIP ISC

PCF

WiFi/ WiMax

VDSL FTTH

CDMA/ GSM/UMTS

PSTNSTP

SSPDLC

SCP

PBX

SIP/SIP-T

PSTN GW


PacketCable Network

MTA

CMTS

MTA

CMS/GC EBP

SIP Network

SIP

DNS Location Server

User Agents

Application Servers


BackgroundBackgroundo 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


MTA M

PSTNGW

Signaling Transport (IP)Media transport (IP)

Access ER

Announcement Server

Distributed Call Signaling FrameworkDistributed Call Signaling Framework

AccessER MTAM

DCS-Proxy+GC

PSTN

DCS-Proxy+GC

MTA Media Terminal Adaptor

M Cable Modem

ER Edge Router

GC Gate Controller

Call State

Connection State

Transaction State


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, don’t 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

DCS ArchitectureDCS Architecture


PacketCable ArchitecturePacketCable Architecture


Call Management Server (Call Management Server (CMS)CMS)o Architectural entity that performs services necessary to

enable endpoints to establish IP multimedia sessionso Act a SIP User Agent (UA)o Support session signaling, call routing, feature support and

service-specific admission controlo 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


Call Management Server (Call Management Server (CMS)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) endpointso 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 functionso Support operator services such as Busy Line Verification and

Emergency Interrupt


Call Agent DCS-Proxy

Gate Controller

DQoS

Call Signaling

Translation, Congestion Control, PSTN, DB access, Event recording, Routing

COPS

DCS/SIPNCS/TGCP

Call Management Server InterfaceCall Management Server Interface

QoS Signaling


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 serviceo Must be able to operate in large scale, cost-effectively

End-points keep state associated with their own calls, and not proxies

Service Provider RequirementsService Provider Requirements


SIP Proxy-To-Proxy ExtensionsSIP Proxy-To-Proxy Extensionso 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


P-DCS-TRACE-PARTY-IDP-DCS-TRACE-PARTY-ID

o To initiate a customer-originated-trace from an un-trusted UAC

o Un-trusted UAC includes in the INVITE Requesto 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 headero Must not appear in any request or response sent to an

un-trusted endpoint

P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr


P-DCS-OSPSP-DCS-OSPS

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”

P-DCS-OSPS = "P-DCS-OSPS" HCOLON "BLV" / "EI"


Busy Line Verify (BLV) Call FlowBusy Line Verify (BLV) Call Flow

NTFYPSTN GW MTATCMS/MGC DPT

1

CRCX2

ACK3

INVITE (BLV)

Busy Line Verification in Progress (one-way data transfer from MTA to Operator)

4 INVITE (BLV)5

183 Session Progress6183 Session Progress

7

PRACK8

200 OK9

UPDATE10

200 OK11

Allocate network

resources

200 OK INVITE12200 OK INVITE

13

ACK14

Commit to network

resources

P-DCS-OSPS : BLV (Indicator of Busy Line Verification

function)

MF

Sign

al


Emergency Interrupt (EI) Call FlowEmergency Interrupt (EI) Call FlowPSTN GW MTATCMS/MGC DPT

Busy Line Verification in Progress (one-way data transfer from MTA to Operator)

NTFY15

Inte

rrupt INVITE (EI)

16

P-DCS-OSPS : EI (Indicates a change to Emergency Interrupt)

ACK14

200 OK INVITE16

Emergency Interrupt in Progress (two-way data transfer)


P-DCS-BILLING-INFOP-DCS-BILLING-INFO

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

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


CMS-CMS Call FlowCMS-CMS Call Flow


CMS-MGC Call FlowCMS-MGC Call Flow


SIP & IMSSIP & IMS


o IP Multimedia Subsystemo Call Session Control Function (CSCF)o IMS Interfaceso 3GPP SIP Overviewo Differences to IETF SIPo 3GPP SIP requirementso IMS Service Architectureo IMS Service Control Interface (ISC)o Convergenceo TISPANo Differences to NGN IMSo SIP and Mobility

ContentsContents


PSTNSTP

SSPDLC

SCP

PBX

SIP/SIP-T

PSTN GW

PacketCable Network

MTA

CMTS

MTA

CMS/GC EBP

IM SubsystemMGCF

CSCFHSS

Application Server


OSA Gateway

SIP/SIP-T

SIP/SIP ISC

SIP/SIP ISC

PCF

WiFi/ WiMax

VDSL FTTH

CDMA/ GSM/UMTS


SIP Network

SIP

DNS Location Server

User Agents

Application Servers

266SIP Certification Training1.1 © Copyright 2006 Wipro Ltd 266

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

IP Multimedia Subsystem (IMS)IP Multimedia Subsystem (IMS)

Original (late ’90s/early ’00s) definition per 3GPP TS 23.228:

The IP Multimedia CN subsystem comprises all CN elements for provision of multimedia services. This includes the collection of signaling and bearer related network elements…

Original (late ’90s/early ’00s) definition per 3GPP TS 23.228:

The IP Multimedia CN subsystem comprises all CN elements for provision of multimedia services. This includes the collection of signaling and bearer related network elements…


User IdsUser profile

security roaming

Inter-WorkingCS/PSTN

QoS policycontrol

BasicCall

Control

Service logicAPIs

SIP

charging

IP Multimedia Subsystem (IMS)IP Multimedia Subsystem (IMS)


o Applications Layer End-user telephony service logic AIN call trigger points Non-telephony based services APIs for enterprise & legacy applications

o Session Control Layer End Point Registration Session setup QoS establishment

o Transport & Endpoint Layer Bearer Services, Media Conversion (PCM > IP),

Compression Special functions: announcements, touch tones

collection, voice recognition, speech synthesis

IMS Building BlocksIMS Building Blocks

Media Gateway

Media Server

CSCF, BGCF

MGCF & MRFC

HSS

OSA-GW

Telephony AS

Non-telephony AS


IMS

UTRAN

SGSN GGSNUE

PS Domain

IMS ArchitectureIMS Architecture

I-CSCF

Go Gi

I-CSCF

P-CSCF S-CSCFMw

HSS

Cx

Cx

CSCFs are the IMS entities responsible of the call control: there are 3 types of CSCFs depending on their role:P-CSCF (Proxy CSCF)S-CSCF (Serving CSCF)I-CSCF (Interrogating CSCF)

The PS domain provides the IP bearer to access to the IMS, i.e. a PDP context.

The HSS holds the IMS service profile of the subscribers.

Gi

Other IP/IMS network

Mm

Traffic Plane

Control Plane

S-CSCF interconnects to external IP networks and other IMS networks.If THIG is used by the operator to hide its internal configuration, the connections to external networks goes through an I-CSCF.


IMS

UTRAN

SGSN GGSNUE

PS Domain

IMS ArchitectureIMS Architecture

I-CSCF

Go Gi

I-CSCF

P-CSCF S-CSCFMw

HSS

Cx

Cx

Other IP/IMS network

Mm

Traffic Plane

Control Plane

SGWMGCF

BGCF

IMS-MGW

Legacy/PSTN

Mk

MiMg

Mj

MnGi

Those entities are responsible for interworking between IMS and CS domain/PSTN

MRF

Gi

Mr

The MRF is used for multiparty call control

PDFGo

Gq

In Release 6, the PDF can be separated from the P-CSCF. Those two entities are then connected through the Gq interface.


Wireline and Wireless SIP EndpointsGSM, UMTS, 802.11, Bluetooth, DSL, FTTP, …

SIP

TDMPBX

Legacy IPEndpoints & PBXsH.323 and MGCP

MGCFMGCFMGCFMGCF

Web PortalWeb PortalWeb PortalWeb Portal

ININAccessAccess

ININAccessAccess

Parlay Parlay App App

ServerServer

Parlay Parlay App App

ServerServer

SIP AppSIP AppServerServer

SIP AppSIP AppServerServer

OSA SCSOSA SCSOSA SCSOSA SCS

I-CSCFI-CSCFI-CSCFI-CSCF

SGSGSGSG

P-CSCFP-CSCFPDF

P-CSCFP-CSCFPDF

AnalogEndpoint

PSTNPSTNSS7SS7

IP IP SignallingSignallingConverterConverter

IP IP SignallingSignallingConverterConverter

MediaMediaGatewaGatewa

yy

MediaMediaGatewaGatewa

yy

Transport and End Point

Layer

Session ControlLayer

Application Layer

MediaMediaServerServerMediaMediaServerServer

MRFCMRFCMRFCMRFC

S-CSCFS-CSCFS-CSCFS-CSCF

CentralizedCentralizedDatabasesDatabases

HSS

CentralizedCentralizedDatabasesDatabases

HSS

Support SystemsSupport SystemsBilling Mediation, Fault Correlation,

Operations, Maintenance, …

Support SystemsSupport SystemsBilling Mediation, Fault Correlation,

Operations, Maintenance, …

BGCFBGCFBGCFBGCFSIP

SIP

SIP

SIP

SIP

COPS

Diamete

rH.248

H.248

3GPP/3GPP2 IMS Architecture3GPP/3GPP2 IMS Architecture


IMS StandardsIMS Standards

3GPP and 3GPP2 (3rd Generation Partnership Project/3rd Generation Partnership Project 2)

Have both defined the IP Multimedia Subsystem (IMS)

The harmonization effort has kept the definitions as similar as possible.

IETF (Internet Engineering Task Force)

Provide the definitions for SIP, SDP and other protocols underlying IMS

IMS is driving some of the work in IETF

OMA (Open Mobile Alliance) Defining services for IMS architecture, e.g. Instant Messaging, Push-to-Talk

ITU (International Telecommunication Union)

Provides protocol definitions used by IMS

H.248 for media control

Q.1912.SIP for SIP – ISUP interworking (in conjunction with IETF)

ETSI (European Telecommunications Standards Institute)

TISPAN - TISPAN is merger of TIPHON (VoIP) and SPAN (fixed networks)

Agreement on reuse of 3GPP/3GPP2 IMS in comprehensive NGN plans

ANSI (American National Standards Institute)

Provides protocol definitions used by IMS

T1.679 covers interworking between ANSI ISUP and SIP

ATIS (Alliance for Telecommunications Industry Solutions)

Addressing end-to-end solutions over wireline and wireless

Nearing agreement to use 3GPP/3GPP2 IMS


Advantages of IMSAdvantages of IMSo Layered architecture that separates transport, control and

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


Call Session Control Function (CSCF)Call Session Control Function (CSCF)o SIP server which authenticates users and routes user SIP

messageso Manages sessions for voice, video, file transfer,

messaging, shared whiteboard services, roaming, etco Coordinates with other network elements for session

control, feature/service control and resource allocationo Manage subscriber data in co-operation with HSSo Generate detailed billing recordso Ensure appropriate Security & QoS policy for each

sessiono Support value-added services through to Interface to

External App Serverso Can act as

Proxy CSCF (P-CSCF) Serving CSCF (S-CSCF) Interrogating CSCF (I-CSCF)


Proxy CSCF (P-CSCF)Proxy CSCF (P-CSCF)

o First contact point within the IMS for the subscribero 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 I‑CSCF by

determining the home domain name SIP messages received from the UE to the SIP server (e.g.

S‑CSCF) whose name the P‑CSCF 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 establishmento Perform SIP message compression/decompressiono Maintain security association between P-CSCF and UEo Interface to PCF to manage QoS and resources

authorizationo Generation of CDRs


Interrogating CSCF (I-CSCF)Interrogating CSCF (I-CSCF)o Gateway between P-CSCF and S-CSCFo Acts as a network entry point for SIP signalingo Assigning a S-CSCF to a user performing SIP registration o Route a SIP request received from another network towards

the S-CSCFo 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 utilisationo Generation of CDRs


Serving CSCF (S-CSCF)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 serviceso Hosts end users’ network services, either locally or via SIP

(ISC) interface to external service platformso Selecting access to the home network application server,

and providing access to that servero 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


GGSN

P-CSCFBG

GoCOPS-PR to GGSN for resource control

RfDIAMETEROffline Charging

PDF

P-CSCF interfaces

HSS

I-CSCF S-CSCF

BGCF

MGCF

IM- MGW

BG

ASOCS

CxDIAMETER

ISCSIP (3GPP profile)

MmSIP To external PDN

RfDIAMETEROffline Charging

MRFC

BGCF McH.248

MkSIP (3GPP profile)

MwSIP (3GPP profile)To I-CSCF or S-CSCF

GmCompressed SIP

(3GPP profile)

GqDIAMETER

Home NetworkVisited/Home Network

Mw

MrSIP(3GPP profile)

MiSIP (3GPP profile)

ShDIAMETER

MjSIP (3GPP profile)

HSS

I-CSCFS-CSCF

SLF

To P-CSCF Home Network

I-CSCF interfaces

Mw

Mw

CxDIAMETER

MmSIPTo external PDN

DxDIAMETER

RfDIAMETER Offline Charging

RoDIAMETEROnline Charging

RoDIAMETEROnline Charging

MRFP

MpH.248

All interfaces are IPv6IMS uses SIP, DIAMETER, H.248 and COPS-PR

ASDhDIAMETER

UtHTTP

S-CSCF interfaces

IMS InterfacesIMS Interfaces


o Users have to be identified uniquelyo 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

IMS IdentitiesIMS 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.

IMS IdentitiesIMS Identities


Relationship of the Private and Public User Identities Relationship of the Private and Public User Identities

IMS Subscription

Private User Identity

Public User Identity



IMS Subscription

Private IUser Identity

Public IUser Identity

Public IIUser Identity

Private IIUser Identity

Public IIIUser Identity


SIP RegistrationSIP Registration

LocationLocation

I-CSCFI-CSCF

Home

P-CSCFP-CSCFVisited

GGSNGGSNSGSNSGSN

Radio Access NetworkRadio Access Network

S-CSCFS-CSCF

HSS

ProfileProfile

REGISTER1

REGISTER2

Cx-Query3 Cx-Query Resp4

REGISTER5

Cx-Pull/Put Resp7Cx-Pull/Put6

200 OK8

200 OK9

200 OK10


IMS Origination to PSTN/PLMNIMS Origination to PSTN/PLMN

S-CSCFS-CSCF I-CSCFI-CSCF

HSSHSS

P-CSCFP-CSCF

Visited

I-CSCFI-CSCFMGCF/T-SGWMGCF/T-SGW

MGWMGW

HSSHSS

GGSNGGSNSGSNSGSN

Radio Access NetworkRadio Access Network

PSTN

Home

INVITE tel:14111

INVITE sip:info@visited

2

Cx-Query3Cx-Query Resp4

INVITE5

INVITE6

INVITE9

Cx-Query7 Cx-Query Resp8

IAM10

ANM11 200 OK12

200 OK13

200 OK15

200 OK14

200 OK16Media17


3GPP SIP Overview3GPP 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 3GPP´s 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.


o 3GPP CSCFs are not “pure” (as defined in the IETF SIP standard) SIP proxieso 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

Differences to IETF SIPDifferences to IETF SIP


3GPP SIP Requirements3GPP SIP Requirementso 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


3GPP SIP Requirements3GPP SIP Requirementso 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


3GPP SIP Requirements3GPP SIP Requirementso 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-CSCFo 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.


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)

Services on IMSServices on IMS


IMS Service ArchitectureIMS Service Architecture

S-CSCF

IM SSF

HSS

CAMEL Service

Environment

OSA/Parley Gateway

Service Logic

OSA Application

ServerISC (SIP+)

ISC (SIP+)

ISC (SIP+)

CAP

MAP

OSA API

Cx

DIAMETER

S-CSCF Serving -Call Session Control Function

IM SSF IP Multi-media Service Switching Function

HSS Home Subscriber Store

ISC IMS Service Control Interface

Native SIP Services

Legacy IN Services

3rd Party Services

SIP AS

Servlet/CPL/API

All 3 types of AS behave as SIP AS on ISC interface towards

S-CSCF


o Networks may contain more than one application servero Application Server (AS) may be specialized to certain

serviceso S-CSCF communicates with AS via the IP multimedia

service control (ISC) interfaceo ISC makes use of SIP - pure SIP like other IMS

interfaceso Application Server can be in the own network or in third

party networkso AS can either act as originating UA, terminating UA, SIP

proxy, SIP redirect server or B2BUAo Functionality of proxy depends on situation, parameters

and configuration as well as on application itselfo AS may or may not remain in signaling path

IMS Service ArchitectureIMS Service Architecture


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

IMS Application Server (AS)IMS Application Server (AS)


o SIP based interface between the S-CSCF and the service platforms

o Support subscription to event notifications between the AS and S‑CSCF

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 S‑CSCF perform any filtering (based on information received from the HSS) for ISC interaction

o Shall be able to convey charging information

IMS Service Control Interface (ISC)IMS Service Control Interface (ISC)


4

INVITE Match Initial Filter Criteria

S-CSCF

Filter Criteria X to AS1 SPT HeaderA priority 1

Filter criteria Y to AS2 SPT HeaderB priority 2

ISC Interface

Incoming SIP Leg Out-Going SIP Leg

Application

Server 1 Application

Server 2

INVITE

Header = A

1

SIP message forwarded by S-CSCF

6

2 3

SIP message now with header=B

SIP message possibly modified

5

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.

Filter Criteria Triggering ExampleFilter Criteria Triggering Example1. User initiates a SIP session by sending a

SIP INVITE with header=A to its S-CSCF2. S-CSCF evaluates the SPTs and finds a

match with the filter criteria X. S-CSCF forwards request to AS1.

3. AS1 performs any needed service logic and sends the SIP request back to the S-CSCF with a service related modification, i.e. change header=A to header=B.

4. S-CSCF evaluates the SPTs and finds a match with the filter criteria Y. S-CSCF forwards the request to AS2.

5. AS2 performs any needed service logic and sends SIP request back to the S-CSCF.

6. No more filter criteria, S-CSCF forwards this request to the next hop based on the route decision.

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.


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

Need For ConvergenceNeed For Convergence


Driving forces for Driving forces for ConvergenceConvergence

Service convergence

Control convergence

Network convergence

Terminal convergence

Fixed network towards convergence

Mobile network towards convergence

Convergence from two sidesConvergence from two sides


Past : Separate of Voice & Data Transport

Circuit SwitchAccess

Capability

Circuit SwitchTransport Capability

Packet SwitchTransport Capability

Present : Separate of V & D Access

xDSL / FTTx

Circuit SwitchAccess Capability



Packet SwitchAccess Capability

Near Future : Integration of V & D Transport

VoIP / VToA

Circuit SwitchAccess Capability




Future : Integration of V & D Access and Transport



Expected Future Transition TrendExpected Future Transition Trend


Current Transition TrendCurrent Transition Trend

LDAP

VOIP Session

LDAP

IM Session

LDAP

IM Session

SIP Terminal

SIP Terminal

SIP Terminal

AS ASSoftswitch

Integrated Vertical Structure

Adapter

HSS

LDAP LDAPLDAP

Common Session Control

SIP Terminals

AS ASSoftswitch

Intermediate Horizontal Structure

LDAP LDAPLDAP

Common Session Control

SIP Terminals

HSS

AS ASSoftswitch

IMS Horizontal Structure

1 2 3


o Separation of access & transport layers from service layer

o Session management across multiple real-time communication devices

o Interworking with legacy TDM networkso Blending of real-time and non-real-time communication

serviceso Consistency in sharing user profiles across serviceso Consistent authentication & billing mechanism o Consistent user interfaceo Open standards & APIs for new services

Converged ArchitectureConverged Architecture


How to operate ConvergenceHow to operate Convergence

BaseStation

Controller

GANC(UMA)

NetworkController

UMA-enabledDual Mode

Handset

WiFi

TunneledIMS stack

Native IPStack

SIPFixed/Wireless Telephone

IP Core Transport

IP Access Network

GSM/IMS Core Service

Architecture

Radio Access Network

VOIP SIP Server

RG


TISPAN – Basic ObjectivesTISPAN – Basic Objectiveso TISPAN NGN project launched at Dec 2003.o Simplification of IMS for use over fixed networkso 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 coreo Management and operational needs including charging and

accounting


TISPAN ArchitectureTISPAN Architecture

Resource and Admission Control Functionality

RACS

Based on3GPP IMS

IP ConnectivityAccess NetworkAnd related functionality

Network AttachmentFunctionality

NASS

Other Multimedia Components …

Streaming Services (RTSP based)

PSTN / ISDN Emulation(SIP-I based)

Applications

Core transport Network

3GPP IP-CAN

Access Transport Network

IP

3GPP Terminals

NGN Terminals

LegacyTerminals

CustomerNetworks

DataBase

Oth

er Netw

orks

“Gq”interface

“Go”interface

IP Multimedia Component (Core IMS)

(SIP based)

PS

TN

/ ISD

N

MBG

TGW

ICF

GW

GW

LegacyTerminals

NGN Terminals

LegacyTerminals


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 profileso Access network configuration, based on user profileso Location management

Network Access AttachmentNetwork Access AttachmentApplication Functions

RACF

Transport FunctionsCPE

NAAF

Functions in other dom

ains


Resource And Admission Control Resource And Admission Control

M-PDF

I-TRCF

I-PDF

CoreAccess

Resource Mediation

ANF ENF

Access Transport

A-TRCF

I-BGF

Core Transport

Resource And Admission Control Functions

A-BGFR-BGF

CPN

SCPF SCF

Service Control Functions

IBCF

Network Access Attachment Functions

C-TRCF

Other

NGNs

Service Stratum

Transport Stratum Gq’ Gq’

RqRq

Go’ Rc

Rq Rq

Rc ReReRc

Ub


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

Resource And Admission Control Resource And Admission Control


PSTN/ISDN EmulationPSTN/ISDN Emulation

o Provides PSTN/ISDN-like service capabilities using session control over IP interface and infrastructure

o Mimicking a PSTN/ISDN network from legacy user’s 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

Next Generation Network

Originating Legacy Terminal

Terminating Legacy Terminal

ADF ADF

ADF = Adaptive Function


PSTN/ISDN SimulationPSTN/ISDN Simulation

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

NGN

Originating Network

SIP Client

NGN = Next Generation Network

NGN NGNNGN NGN

Terminating Network

Originating Subscriber’s

Home Network

Terminating Subscriber’s

Home Network

Core Transit Network

SIP Client


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

Differences - NGN and 3GPP IMSDifferences - NGN and 3GPP IMS


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

NGN Mobility RequirementsNGN Mobility Requirements


NGN Mobility Requirements – ScenariosNGN Mobility Requirements – Scenarios

Access Network

Border Gateway

Node

Intermediate Node

Access Node

Access Node

Access Network

Border Gateway

Node

Intermediate Node

Access Node

Access Network

Border Gateway

Node

Intermediate Node

Access Node

Access Node

NGN Core Network Border Node

Border Node

NGN Core Network Border Node

Border Node

NNI

Intra-AN

Inter-AN

Inter-TE

Inter-CN


o Terminal can move between sub networkso 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

SIP And Terminal MobilitySIP And Terminal Mobility


SIP And Terminal MobilitySIP And Terminal Mobility

Home Network

Visited Network

Home Proxy

Visited Proxy

Cell 1

Cell 2

REG

ISTE

R

REGISTER#1

#2

INVI

TE #4

INVITE

#3

INVITE

#5

#6

Home Network

Visited Network

Home Proxy

Visited Proxy

Cell 1

Cell 2

REG

ISTE

R

#2

Re-IN

VITE

#4

Re-INVITE

#5

#6

REGISTER#1

Re-INVITE#3


o Person uses different Devices and possibly addresso REGISTER binds a person to a deviceo Proxy and redirect translate address to location and

deviceo Issues to consider:

Authentication Binding different addresses to single person

SIP And Personal MobilitySIP And Personal 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

SIP And Service MobilitySIP And Service Mobility


SIP & SIMPLESIP & SIMPLE


o Presence

o SIP Extensions for Presence

o Instant Messaging (IM)

o SIP Extensions for IM

ContentsContents


o Also known as Buddy Listso 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

PresencePresence


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

SIP Extension for PresenceSIP Extension for Presence

Subscriber (Watcher)

SUBSCRIBE

ProxyNOTIFY

Presence Agent + Proxy/Registrar = Presence Server

Presentity

REGISTER


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

SIP Extension for PresenceSIP Extension for Presence

Subscriber (Watcher)

SUBSCRIBE

ProxyNOTIFY

Presence Agent + Proxy/Registrar = Presence Server

Presentity

REGISTER


Presence – Basic OperationPresence – Basic Operationo Subscriber send SUBSCRIBEo Routed to PA using normal SIPo PA authorizes subscribero Acceptance contains presence stateo NOTIFY sent when state changeso Routed using SIP Record-Route

SUBSCRIBE sip:[email protected] SIP/2.0Event: presenceTo: sip:[email protected]: sip:[email protected]: sip:[email protected]: [email protected]: 1 SUBSCRIBEExpires: 3600Content-Length: 0

NOTIFY sip:[email protected]: sip:[email protected]: sip:[email protected]: [email protected]: 1 NOTIFYContent-Type: application/xpidf+xml

<?xml version="1.0"?><!DOCTYPE presence PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd"><presence> <presentity uri="sip:[email protected];method="SUBSCRIBE"> <atom id="779js0a98"> <address uri="sip:[email protected];method=INVITE"> <status status="closed"/> </address> </atom> </presentity></presence>


o Defined as the exchange of content between a set of participants in near real time

o Content is short text messageso 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

Instant Messaging (IM)Instant Messaging (IM)


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

SIP Extension for Instant MessagingSIP Extension for Instant Messaging


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

IM - Basic OperationIM - Basic Operation

MESSAGE sip:[email protected] SIP/2.0Via: SIP/2.0/TCP uac.example.com;branch=z9hG4bKhjhs8ass83Max-Forwards: 70To: <sip:[email protected]>From: <sip:[email protected]>;tag=1234Call-ID: d432fa84b4c76e66710CSeq: 1 MESSAGEContent-Type:text/plainContent-Length: 15

Hello World


o Unifies major communications services Voice/video IM Presence

o Increases call completion rate Drastically improves efficiency of IP communications

o Improves the user experienceo Dissociate concept of presence from a specific

application and apply it to virtually any applicationo Reduces Management Costs

Advantages of Using SIP/SIMPLEAdvantages of Using SIP/SIMPLE


SIP & ServicesSIP & Services


o SIP REFER Methodo SIP Refer-To Headero SIP Call Transfer – Blindo SIP Replaces Headero SIP Call Transfer – Attendedo SIP Message Summary/Waiting Indicationo Push To Talk Over Cellular (PoC)

ContentsContents


REFER MethodREFER Methodo Indicates that the recipient (identified

by the Request-URI) should contact a third party using the contact information provided in the request

o Contain exactly one Refer-To header field value

o Request may be placed outside the scope of a dialog created with an INVITE

o Implicitly establishes a subscription to the refer event

o Each NOTIFY must contain a body of type "message/sipfrag"

o The body of a NOTIFY must begin with a SIP Response Status-Line

o Can be used to enable many applications, including Call Transfer

REFER sip:[email protected] SIP/2.0Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223To: <sip:[email protected]>From: <sip:[email protected]>;tag=1234Call-ID: [email protected]: 93809823 REFERMax-Forwards: 70Refer-To: sip:[email protected]: sip:[email protected]: 0

NOTIFY sip:[email protected] SIP/2.0Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25To: <sip:[email protected]>;tag=1234From: <sip:[email protected]>;tag=5678Call-ID: [email protected]: 1993402 NOTIFYMax-Forwards: 70Event: referSubscription-State: activeContact: sip:[email protected]: message/sipfrag;version=2.0Content-Length: 20

SIP/2.0 100 Trying


Refer-To HeaderRefer-To HeaderRefer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param)

o Request header field, appears only in a REFER requesto Provides a URL to referenceo 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 ro Examples of valid Refer-To header fields:

Refer-To: sip:[email protected]: <sip:[email protected];method=SUBSCRIBE>


SIP Call Transfer - BlindSIP Call Transfer - Blind

INVITE

200 OK

OriginatorUser A

RecipientUser B

Final RecipientUser C

1

2

ACK3

Two way Speech Path

REFER: Refer-To: C4

202 Accepted 5INVITE

200 OK

6

7

ACK9

8

200 OK10

NOTIFY : 200 OK

Two way Speech Path BYE

11

200 OK12

Call Transfer Initiated using

REFERCall Transfer

Success using REFER


Replaces HeaderReplaces HeaderReplaces = "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: [email protected];to-tag=24796;from-tag=0Replaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321;early-only


SIP Call Transfer – Attended (1)SIP Call Transfer – Attended (1)Originator

User ARecipient

User BFinal Recipient

User CINVITE/200/ACKCall-

ID:1;FromTag=11;ToTag=22Two way Speech Path

INVITE (Hold)Call-

ID:1;FromTag=11;ToTag=22200 OK

ACKCall-

ID:1;FromTag=11;ToTag=22INVITE Call-ID:2;FromTag=33

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

ACK Call-ID:2;FromTag=33;ToTag=44

REFER: Refer-To: <Final Recipient?Replaces:Call-ID:2;FromTag=33 ;ToTag=44Call-ID:1;FromTag=11;ToTag=22

202 Accepted

Call Transfer Initiated using

REFER


SIP Call Transfer – Attended (2)SIP Call Transfer – Attended (2)Originator

User ARecipient

User BFinal Recipient

User CINVITE: Replaces:Call-ID:2;FromTag=33 ;ToTag=44Call-ID:3;FromTag=55


ACK Call-ID:3;FromTag=55;ToTag=66

NOTIFY : 200 OK Call-


BYE Call-


Two way Speech Path

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


Call Transfer Success using

REFER


SIP Message Summary And Message-Waiting IndicationSIP Message Summary And Message-Waiting Indication

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

PSTN

User A

User B

VoiceMail Server

SwitchSMDI

Traditional Voice Mail System


SIP Message Summary And Message-Waiting IndicationSIP Message Summary And Message-Waiting Indication

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

PSTN

User A

User B

VoiceMail Server

Switch IP Network SIPSIP

SIP

SIP Client

Switch can act as a SIP UA on behalf

of TDM clients

SIP-Based Voice Mail System


Message Summary/Waiting Indication PayloadMessage Summary/Waiting Indication Payload

o Defined new event-package "message-summary"o Defined a simple text-based NOTIFY bodyo 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


Message Summary/Waiting Indication PayloadMessage Summary/Waiting Indication Payload

SUBSCRIBE sip:[email protected] SIP/2.0 To: <sip:[email protected]> From: <sip:[email protected]>;tag=78923Call-Id: [email protected] CSeq: 4 SUBSCRIBE Max-Forwards: 70Contact: <sip:[email protected]> Event: message-summary Expires: 86400 Accept: application/simple-message-summary Content-Length: 0

MWI SUBSCRIBE

NOTIFY sip:[email protected] SIP/2.0 To: <sip:[email protected]>;tag=78923 From: <sip:[email protected]>;tag=4442 Call-Id: [email protected] CSeq: 20 NOTIFY Contact: <sip:[email protected]> Event: message-summary Subscription-State: active Content-Type: application/simple-message-summary Content-Length: 99

Messages-Waiting: yes Message-Account: sip:[email protected] Voice-Message: 2/8 (0/2)

MWI NOTIFY (ON)

NOTIFY sip:[email protected] SIP/2.0 To: <sip:[email protected]>;tag=78923 From: <sip:[email protected]>;tag=4442 Call-Id: [email protected] CSeq: 20 NOTIFY Contact: <sip:[email protected]> Event: message-summary Subscription-State: active Content-Type: application/simple-message-summary Content-Length: 20

Messages-Waiting: no

MWI NOTIFY (OFF)


SIP MWT – Sample Call FlowSIP MWT – Sample Call FlowOriginator

User ASubscriber

User BNotifier

Voice Mail Server

SUBSCRIBE : message-summary

200 OK

NOTIFY : MWT=NO

200 OK

User A calls User B (CFD) forwarded to Voice Mail Server. User A leaves a message for User B and disconnects the call

NOTIFY : MWT=YES

200 OK

User B retrieves the message from the Voice Mail Server

NOTIFY : MWT=NO

200 OK

User B subscribes for MWT Notification

User B is not available to receive the call from User A

User B receives MWT “YES” Notification

User B receives MWT “NO” Notification


Pre-paid on the SIP B2BUAPre-paid on the SIP B2BUA

Start Billing

PSTN

SIP Controller B2BUA Application

INVITE sip:9193921000 w/ SDP

200 OK w/ SDP of SIP-GW

INVITE si

p:9194

7210

00 w

/ SDP of S

IP Phone

200 O

K w/ S

DP SIP-GW

ACK

End Call

RADIUS /Billing Server

Pre-Paid Client


Push-To-Talk Over Cellular (PoC)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


PoC 1-to-Many Group SessionPoC 1-to-Many Group Session

Wireless NetworkMember A

Member B

Member C

Member D

Member E


Logical Architecture of PoCLogical Architecture of PoC


PoC Client FunctionalityPoC Client Functionalityo Allow session initiation, participation and releaseo Perform registration with the SIP/IP Coreo Authentication of the PoC User to the SIP/IP Coreo Generate and send Talk Bursts by recording and encoding

audioo 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 Alerto May provide group advertisemento Request privacy of User Identity


PoC Server FunctionalityPoC 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


PoC Server FunctionalityPoC Server Functionalityo 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


Ad-hoc Group Session InvitationAd-hoc Group Session Invitation

INVITE

PoCClient A

SIP/IPCore

PoC Server A(Participating & Controlling)

1

INVITE2 Invitations to invited

POC subscriber

ALERTING 3First ALERTING

ResponseALERTING 4

OK 7First accepted

invitationOK 8

Talk Burst Confirms 9

Media10


Pre-Arranged Group Session SetupPre-Arranged Group Session SetupPoC

Client ASIP/IPCore A

PoC Server A(Participating)

SIP/IPCore X

PoC Server X(Controlling)

POC Client A Home Network Controlling Network

INVITE1 INVITE2

INVITE 3

INVITE4INVITE 5

ALERTING6

Invitations to the group members

First ALERTING Response

7ALERTING

ALERTING8

ALERTING 9ALERTING 10

First accepted invitation

OK11

12OK

OK13

OK 14OK 15




PoCClient A

SIP/IPCore A

PoC Server A(Participating)

SIP/IPCore X

PoC Server X(Controlling)

POC Client A Home Network Controlling Network

INVITE1 INVITE2

INVITE 3

INVITE4INVITE 5

ALERTING6

Invitations to the group members

First ALERTING Response

7ALERTING

ALERTING8

ALERTING 9ALERTING 10

First accepted invitation

OK11

12OK

OK13

OK 14OK 15



Pre-Arranged Group Session SetupPre-Arranged Group Session Setup


SIP Application SIP Application FrameworkFramework


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

ContentsContents


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

JAIN SIPJAIN SIP


JAIN SIP – Object ArchitectureJAIN SIP – Object Architecture

Proprietary SIP Stack

SIP Stack

Proprietary SIP Stack

Network

SIP Provider

SIP Listener SIP FactorySIP FactorycreateListener() getInstance()

createProvider() crea

teSt

ack(

)

Event Registration


o Provide methods to format SIP messageso Provides ability for an application to send and

receive SIP messageso Parse incoming messages and enable application

access to fields via a standardized Java interfaceo 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

JAIN SIP - ResponsibilitiesJAIN SIP - Responsibilities


JAIN SIP – Messaging ArchitectureJAIN SIP – Messaging Architecture

NetworkStack

Listening Point

SipProvider

SipListener

SIP Messages SIP Events

Stack

Listening Point

SipProvider

SipListener

SIP Messages SIP Events

Application


JAIN SIP – 3JAIN SIP – 3rdrd Party Call Control Party Call ControlSipListener SipFactory SipProvider

Client Transaction Dialog A Dialog B

SIP Party A

SIP Party B

createReq(INVITE, -)

createClientTransaction(inviteA)new()

sendRequest() new()

INVITE(SipListener, A)

200OK(offerA)createReq(INVITE, offerA)

createClientTransaction(inviteB)new()

sendRequest() new()

INVITE(SipListener, B)ACK(offerA)

200OK(offerB)ACK(offerB)

createReq(re-INVITE)-setBody(offerB)

createClientTransaction(inviteC)sendRequest(clientTransC)

Re-INVITE(offerB)

200OK(offerB)ACK(offerB) RTP

null

confirmed

null

confirmed


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

SIP ServletSIP Servlet


o SIP Signaling Allows applications to perform functionality of user agent client (UAC),

user agent server (UAS), and proxyo 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 fashiono Carrier grade

Application data stored in container managed session objects may persist and/or replicate to achieve high availability

SIP Servlet - ResponsibilitiesSIP Servlet - Responsibilities


SIP Servlet - SIP Servlet - Call Schedule on Busy or No AnswerCall Schedule on Busy or No Answer

INVITE

Alice’s Web Browser

Bob’s SIP UA

Alice’s SIP UA

Converged Servlet Container

1 INVITE2100 Trying3 486 Busy

4302 Moved Temporarily5

ACK6 ACK

7HTTP GET8

200 OK9

HTTP POST10

200 OK13

SUBSCRIBE11

200 OK12

NOTIFY14

200 OK15INVITE 16200 OK

17ACK

18 INVITE19

200 OK20

ACK23

INVITE 21

200 OK22

ACK 23RTP


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. PDA’s 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

SIP LiteSIP Lite


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

SIP For J2MESIP For J2ME


End to End architectures using the SIP APIsEnd to End architectures using the SIP APIs

HSS

MGCF

MGW

I-CSCFS-CSCF

P-CSCF

Application Server

Application Server

Application Server

Home Network

Visited Network

JAIN SIP

SIP Lite

SIP Lite

JAIN SIP JAIN SIP

SIP Servlet

SIP Servlet

SIP Servlet

SIP Servlet

SIP Lite

SIP for J2ME

SIP for J2ME


Questions ?Questions ?

SIP Certification Rel.1

Documents

Transcript of SIP Certification Rel.1