Professional Documents
Culture Documents
What is Telephony?
It is the working and use of the telephone network
Contents
*VOIP Network Architecture
*SIP Concept
*SIP Protocol Specification
*SIP Messages
*Protocol Basics
*Message Bodies
*Headers
*Session Description Protocol (SDP)
*Offer-Answer Model
*SIP State Machine
*SIP Routing
*SIP Event Notification Framework
App
Server
App Layer
Parlay, JAIN
Media
SSP
STP
SS7
MG
SG
MG
RTP
MGCP,
Megaco
MGCP,
Megaco
Softswitch
SIGTRAN
SIP T,
BICC
Softswitch
PBX
PSTN Enterprise
Network
PSTN Carrier
Network
SIP, MGCP
Transport Layer
VoIP Enterprise
Network
IP Carrier Network
*Supporting Protocols
Responsible for the actual transmission of requests and responses over network
transports
Transaction User
Transaction Layer
Transport Layer
Syntax/Encoding
Transport Layer
Network Layer
Data Layer
Physical Layer
LOCATION SERVER
INVITE sip:pramodh@techm.com
Caller@sip.com From: sip:Caller@sip.com
To: sip:pramodh@techm.com
#1
Call-ID: 345678@sip.com
200 OK
#6 From: sip:Caller@sip.com
To: sip:pramodh@techm.com
Call-ID: 345678@sip.com
#7 ACK sip:pramodh@techm.com
#8 Media Streams
Callee
pramodh@192.219.223.160
#2
PROXY
#3
pramodh@techm.com
INVITE sip:pramodh@192.219.223.160
From: sip:Caller@sip.com
To: sip:pramodh@techm.com
#4
Call-ID: 345678@sip.com
200 OK
From: sip:Caller@sip.com
To: sip:pramodh@techm.com
Call-ID: 345678@sip.com
#5
Stateful Mode
Usage
Good for heavy-load scenario, i.e. Core
Network
Behavior
Proxies just receive messages, perform
routing logic, send messages out
No memory requirements
#2
pramodh@192.219.223.160
LOCATION SERVER
This registration example establishes presence
of user with address pramodh@techm.com and
binds this address to users current location
192.219.223.160
#3
SIP REGISTRAR
(domain register.techm.com)
SIP/2.0 200 OK
PSTN
PSTN
VoIP Network
1
INVITE (Call-ID#1)
INVITE (Call-ID#2)
1
Calling Party
100 Trying
SIP Signaling
& SDP Signaling
(UDP or TCP)
180 Ringing
200 OK
1
1
1
180 Ringing
200 OK
Called Party
Signaling
1
ACK
1
Media (UDP)
100 Trying
RTP Stream
ACK
Bearer Or
Media
SIP Messages
* Start-Line
* One or more Header fields
* An Empty Line indicating the end
of the header fields
* An optional Message Body
Message Body
2279)
* Request and Response messages
use the basic format of RFC 2822
* Message and header field syntax
is very much identical to
HTTP/1.1
Message Header
Request
*Method name
*Request-URI
*Protocol version
Request
Method
Request-URI
Protocol
Version
Sample Requests
OPTIONS
INVITE
INVITE sip:called@dmn.com SIP/2.0
From: sip:caller@clrdomain.com
To: sip:called@clddomain.com
CallID: 31415@clrdomain.com
CSeq: 1 INVITE
Via: SIP/2.0/UDP clrdomain.com;
branch=z9hG4bK776
Content-Type: application/sdp
Content-Length: 274
v=0
o=called 536 2337 IN IP4 h3.clddomain.com
s=session_name_1
c=IN IP4 192.213.229.147
t=0 0
m=audio 3456 RTP/AVP 0
Requests can
have headers
and SDP
SIP
SIP
SDP
SDP
INFO
INFO sip:called@dmn.com SIP/2.0
From: sip:caller@clrdomain.com
To: sip:called@clddomain.com
Contact: <sip:called@clddomain.com>
CallID: 31415@clrdomain.com
CSeq: 1 INFO
Content-Length: 0
SIP
SDP
Response
*Distinguished from requests by having a Status-Line as
their start-line
*A Status-Line consists of
* Protocol version
* Numeric Status-Code
* Associated textual phrase
*1yz Informational
* 100 Trying
* 180 Ringing
* 181 Call is Being Forwarded
* 182 Queued
*2yz Success
* 200 Ok
*3yz Redirection
Sample Responses
Success 200 OK
SIP/2.0 200 OK
From: sip:caller@clrdomain.com
To: sip:called@clddomain.com
CallID: 31415@clrdomain.com
CSeq: 1 OPTIONS
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Content-Type: application/sdp
Content-Length: 274
SIP
SIP
SDP
v=0
o=called 536 2337 IN IP4 h3.clddomain.com
s=session_name_1
c=IN IP4 192.213.229.147
t=0 0
m=audio 3456 RTP/AVP 0
Response can
have headers
and SDP
SDP
SIP
SDP
Form Long
From: sip:caller@clrdomain.com
To: sip:called@clddomain.com
CallID: 31415@clrdomain.com
CSeq: 1 OPTIONS
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Content-Type: application/sdp
Content-Length: 274
f: sip:caller@clrdomain.com
t: sip:called@clddomain.com
i: 31415@clrdomain.com
CSeq: 1 OPTIONS
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
c: application/sdp
l: 274
Application - pkcs7-signature
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
Location
Services
Proxy
Server
INVITE (SDPo)
2
Location Lookup
Lookup Result
100 Trying
180 Ringing
200 OK (SDPT)
10
4
5
7
SIP UA (B)
INVITE (SDPo)
180 Ringing
200 OK (SDPT)
6
8
ACK
Session In
Progress
Session
Initiation
BYE
200 OK
12
Session
Teardown
SIP Transaction
*Fundamental unit of message exchange
*Request Response cycle
*Consists of a single request and any responses to that
request, which include
SIP Transaction
Successful Call Scenario
UAC
1
First Transaction
INVITE (CSeq:1 INVITE)
UAS
First Transaction
INVITE (CSeq:1 INVITE)
UAS
Second Transaction
5
UAC
SIP Dialog
* When a UA sends a request, it contains a From tag only,
* 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 Dialog
Single Dialog Scenario
UAC
1
Dialog
First Transaction
INVITE (F-Tag: Xxx)
No Dialog Scenario
UAS
100 Trying
200 OK (F-Tag: Xxx, T-Tag: Yyy)
4
2
3
4
UAC
First Transaction
INVITE
UAS
100 Trying
ACK
SIP Session
*A session is the exchange of media between two or more
endpoints
*Most common form of a session uses the RTP protocol for
exchange of voice media
*Can also be used to exchange text, video, game
information and other types of media
*Sessions are described using the Session Description
Protocol (SDP) and generally consist of multiple RTP
streams between two endpoints
*SIP is used in the setup of sessions, but sessions can be
setup without SIP
*Exchange of SIP messages does not always result in a
session being set up
*There can be dialogs without SIP sessions
To
To = ( "To" / "t" ) HCOLON ([ display-name ] LAQUOT addr-spec RAQUOT / addr-spec ) *( SEMI tag-param )
Display
Tag
Addr
Name
Parameter
spec
From
Addr
spec
Tag
Parameter
Call-ID
Call-ID = ( "Call-ID" / "i" ) HCOLON word [ "@" word ]
CSeq
CSeq = "CSeq" HCOLON 1*DIGIT LWS Method
Max-Forwards
*Examples of valid Max-Forwards header fields:
Max-Forwards: 6
Via
Protocol/Version/
Transport
Host
Port
Branch
Parameter
Branch Parameter
* The exceptions to this rule are CANCEL and ACK for non-2xx
responses
* CANCEL request will have the same value of the branch
parameter as the request it cancels.
* ACK for a non-2xx response will also have the same branch ID
as the INVITE whose response it acknowledges
* The branch ID inserted by an element always begin with the
characters "z9hG4bK (magic cookie)
Via: SIP/2.0/UDP sip.techm.com;branch=z9hG4bK776asdhds
172.16.16.120
Proxy
UAC
Via:192.219.223.160
Via:192.219.223.160
172.16.16.160
Proxy
Via:172.16.16.120
Via:192.219.223.160
Via:172.16.16.120
Via:192.219.223.160
Request
Response
192.219.223.197
Via:172.16.16.160
Via:172.16.16.120
Via:192.219.223.160
Via:172.16.16.160
Via:172.16.16.120
Via:192.219.223.160
UAS
Contact
Display Name
Contact
Parameters
Address
Spec
REGISTER Method
* Create bindings in a location service
REGISTER Response
*Check if domain is its own
*Authorize user in From
*Add address bindings of To to
Contact list
*Modify expiration time, if too long
*Return, in response, list of all
current registrations
*Return, in response, expiration
time for all registrations and
respective priorities, if present
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;
branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Contact: <sip:bob@192.219.223.160>
Expires: 7200
Content-Length: 0
INVITE Method
*Used to signal the desire
to open a session
*Sent from UAC to UAS
*Mandatory header
fields :
* From
* To
* Call-ID
* CSeq
* Via
* Max-Forward
SIP
SDP
ACK Method
*
*
*
*
SIP
v=0
o=user1 536 2337 IN IP4 h3.clrdomain.com
s=session_name_1
c=IN IP4 h3.clrdomain.com
m=audio 3456 RTP/AVP 0 1
SDP
UAC
1
First Transaction
INVITE (SDPO)
100 Trying
200 OK (SDPT)
UAS
200 OK (SDPT)
First Transaction
INVITE
100 Trying
ACK
200 OK
UAC
ACK (SDPO)
UAS
2
3
OPTIONS Method
another UA or a proxy server
as to its capabilities
*Capabilities:
* Supported methods
* Content types
* Extensions
* Codecs
*Sent from UAC to UAS
*Target identified in RequestURI
*All UAs must support the
OPTIONS method
*Allows a UA to query
OPTIONS Method
*May be sent as part of an established dialog to query the
peer on capabilities
*Accept header field included to indicate the type of
message body the UAC wishes to receive in the response
*Typically, set to a format that is used to describe the
media capabilities of a UA
*Contact header field may be present in an OPTIONS
OPTIONS Response
Encoding, Accept-Language,
and Supported header fields
are recommended
*200 OK - if UAS is ready to
accept a call
*486 (Busy Here) if UAS is
busy, etc
*Allow header field should be
omitted, if generated by a
proxy
*Message body may be sent,
the type of which is
determined by the Accept
header field in the request
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;
branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Content-Length: 0
BYE Method
*
*
*
*
*
CANCEL Method
*
*
*
*
*
*
*
UAC
1
First Transaction
INVITE
100 Trying
200 OK
UAS
UAC
1
100 Trying
2
3
ACK
4
First Transaction
INVITE
180 Ringing
Second Transaction
CANCEL
200 OK
487 Request Terminated
ACK
UAS
2
3
SIP Addressing
*Uses Uniform Resource Indicator (URI) for addressing an
entity in the network
*Allows any URI type
* sip/sips URIs
* tel URIs
* http URLs for Redirect Service (for example)
* maito URLs
DNS-Server
Query
1.3.1.9.5.8.6.8.6.4.e164.arpa.?
Response
sip:ssarkar@techm.com
Call setup
Dial
+4686859131
SIP
sip:ssarkar@techm.com
Gateway
SIP Server
signaling path
*Contact: Appears in INVITE / OPTIONS / ACK / REGISTER
requests and in responses. It indicates direct response
address to which subsequent transactions are sent.
*Via: Identifies the location where the response is to be sent
*Record-Route: Inserted by proxies in a request to force
future requests in the dialog to be routed through the proxy
*Route: Used to force routing for a request through the
listed set of proxies
IP Network
UAS Location
Query
Session setup
Request from
the UAC
UAS1
Location
Server
Location Server
UAS2
4
6
Connect to UAS 2
OK to connect
SIP
Proxy
1
SIP Protocol
UAC
Non-SIP Protocol
(Eg. Database Query)
UAS3
SDP Anatomy
originator
Session ID and version timestamp
originating host
connection information (multicast address)
Conference Total, Max 64kb/s bandwidth
start time (NTP timestamp)
stop time (NTP timestamp)
SDP with the port number for that stream set to zero
*Media stream can be put "on hold", i.e., request that it
temporarily stops sending one or more unicast media
streams by
Offer-Answer Examples
Offered SDP
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
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
Answered SDP
SIP Proxy
INVITE (oSDP)
100 Trying
180 Ringing (tSDP)
SIP UA (B)
INVITE (oSDP)
180 Ringing (tSDP)
PRACK
200 OK
PRACK
200 OK
* 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
* UAC on receipt of reliable provisional response with an offer, generates
an answer in the PRACK
* UAS on receipt of a PRACK with an offer, generates the answer in the 2xx
to the PRACK
contains an offer
* User B generates a 180 response (2)
with an answer to that offer
* User A generates a PRACK (3) to
acknowledge the 180
* User B answered the PRACK with a 200
OK (4)
* User A generate an UPDATE request (5)
with a new offer
* User B answered this offer in the 200
response to the UPDATE (6)
* User B generates an UPDATE request
(7) with an offer
* User A answer is sent in the 200
response (8)
* Finally, User B answers the call,
resulting in a 200 OK response to the
INVITE (9)
* User B then sends an ACK (10)
SIP UA (B)
SIP UA (A)
1
INVITE (Offer 1)
180 Ringing (Answer 1)
PRACK
200 OK
UPDATE (Offer 2)
200 OK (Answer 2)
UPDATE (Offer 3)
200 OK (Answer 3)
200 OK
ACK
UAS
Terminate
Subscription
200 OK
NOTIFY (Subscription-State: Active)
200 OK
NOTIFY (Subscription-State: Active)
200 OK
SUBSCRIBE (Event: Zxx, Expires:0)
200 OK
10
200 OK
Zxx Event
Occurred
Zxx Event
Occurred
Test Setup
Zone1
Zone2
Zone 3
zone 4
zone 5
zone 6
zone 7
zone 8
VIP
10.19.125.227
10.19.125.133
10.19.125.137
10.19.125.247
10.19.124.12
10.19.125.167
10.19.121.216
10.19.121.170
CCM1
10.19.125.203
10.19.125.131
10.19.125.134
10.19.125.233
10.19.125.145
10.19.121.197
10.19.121.168
CCM2
10.19.125.204
10.19.125.132
10.19.125.135
10.19.125.238
10.19.125.148
10.19.121.200
10.19.121.169
MM
10.19.121.201
10.19.124.11
10.19.121.207
10.19.121.211
Not Available
MG
10.19.125.210(L
B1)
10.19.125.211
Turret Logon
logon_7019_Z5_sip.pcap
Turret Logoff
logoff_7019_Z5_sip.pcap
DT Call
* DT Call from T1 with 6001 6002
DT_6001to60002_Z5_sip.pcap
DT_6001to60002_Z1_sip.pcap
DT_6001to60002_Z6_sip.pcap
MRD Call
* MRD Call from T1 with 10005 20005
MRD_10005to20005_Z5_sip.pcap
MRD_10005to20005_Z1_sip.pcap
MRD_10005to20005_Z6_sip.pcap
ARD Call
* ARD Call from T1 with 10015 20015
ARD_10015to20015_Z5_sip.pcap
ARD_10015to20015_Z1_sip.pcap
ARD_10015to20015_Z6_sip.pcap
HOOT Call
* HOOT Call from T1 with 10025 20025
hoot_10025to20025_Z5_sip.pcap
hoot_10025to20025_Z1_sip.pcap
hoot_10025to20025_Z6_sip.pcap
*Q&A