SIP For Multimedia PDF

James Polk 20050503
SIP for Voice, Video and Instant

Messaging
James Polk 20050503
Faisal Chaudhry
fchaudhr@cisco.com
Technical Leader
Cisco Advanced Services
Cisco Systems, Inc. All rights reserved. 1

Agenda
• SIP History & Basics

• Elements of SIP
• SIP Message details
• SIP Signaling
• Interworking with MGCP/H.323
© Cisco Systems, Inc. All rights reserved. 2

VoIP Signaling Overview
• Peer-to-Peer Signaling Protocols

H.323 Signaling Architecture
SIP Signaling Architecture
• Client/Server Signaling Protocols
MGCP Architecture
MEGACO/H.248 Architecture
Skinny (SCCP)
• Audio (Bearer) Path
Always Real Time Protocol (RTP)
VoIP Signaling Overview
• H.323 uses TCP or UDP

First to Market!
Complexity of Protocols: H.225, H.245
Intelligent endpoints
Gatekeeper routed call models
• MGCP uses UDP

Centralized Call Control
Decoupling of Call & Media Control
Event Triggered

Session Initiation Protocol
• The Session Initiation Protocol (SIP) is an

application layer control (signaling) protocol
for creating, modifying and terminating
multimedia sessions with one or more
participants
• SIP defined by IETF working group as RFC
2543, in March 1999, work continues within
SIP WG
Additional “feature” drafts have been written to
address features & issues which concern
SS7/ISUP handling, QoS, Alerting, DHCP, Firewalls
& NAT, … etc.
SIP @ the IETF – A lot going on
REFER
Session Timer RFC 2543 1999
Privacy
Message-Waiting SIPPING-WG
Diversion Bis-01
3PCC
Presence Bis-02
SIP-T Bis-03
Tel: URL
Bis-04 SIP-WG
TRIP
INFO Bis-05
T.38 Bis-06
Supported
Caller-Pref Bis-07
PRACK / COMET SIMPLE-WG
Bis-08
Etc..
Bis-09 2002
RFC 3261
SIP – What Is it?
SIP entities can communicate via:

– unicast
– multicast
– via a mesh of unicast relations or
– a combination of these
in IPv4 and/or IPv6 environments using:
– UDP
– TCP
– SCTP or
– TLS over TCP
on a per SIP hop basis.
SIP – What Is it? (Cont.)
SIP is a simple extensible protocol

• Methods - Define the transaction
• Headers - Describe the transaction
• Message Body - SDP, Text, XML, jpeg, etc...

SIP Basic - Architecture
• SIP utilizes an Internet architecture,
similar to the World Wide Web -
intelligent clients utilizing services within
the network
Uses URL style addresses and syntax
MIME definition for multimedia (SDP)
• Applications and SIP Services can be
distributed throughout the network, with
intelligence in the clients or in
applications our the network
Additional services like Presence, Mobility,
Find-Me/Follow-Me, etc.. are added into the
network via basic SIP functionality or
Application servers
SIP Basic - Architecture
I
N
Application
T
3pcc Services
E eMail CPL
CPL
LDAP Oracle XML
L
L
I SIP Servers
G (Proxy, Registrar
E & Redirect)
N
T SIP
SIP SIP
S PSTN
E SIP User
Agents (UA)
R
V
I
RTP
C (Media)
E
S Legacy PBX
5 Facets for Establishing and Terminating
Multimedia Communications Using SIP
• User location: Determination of the end system to be

used for communication
• User availability: Determination of the willingness of
the called party to engage in communications
• User capabilities: Determination of the media and
media parameters to be used
• Session setup: “Ringing", establishment of session
parameters at both calling and called party
• Session management: Including transfer and
termination of sessions, modifying session
parameters, and invoking services

Agenda

• Elements of SIP
• SIP Signaling

5 Components of SIP
• User Agent [Mandatory]

• SIP Gateway [optional]
• Registrar Server [optional]
• Proxy Server [optional]
• Redirect Server [optional]

SIP User Agents
UA 1 UA 2 UA 3 UA 4
LAN A LAN B
• Client—Server model
User Agent Client (UAC)—Initiates sessions
User Agent Server (UAS)—Responds to
session requests
• User Agent = UAC + UAS

SIP Gateways
UA 1 UA 2
SIP
Gateways
Speech Only
Telephone
LAN A Network (PSTN)
• Translation between SIP protocol format to and

from non-SIP protocol format

SIP Proxy Server
Alice@atlanta.com Bob@biloxi.com
UA 1 UA 2
IP
UA 3
Network
UA 4
Client Server
Proxy
• Optional *logical* SIP component
• Handles routing of SIP signaling messages
• Can add/modify/remove Headers from SIP
messages
SIP Proxy Server
• Handles the routing of SIP messages, but does not

initiate any new SIP messages
• When a SIP Proxy is present, signaling can be routed
in a similar manner to H.323 Gatekeeper Routed
Signaling (GKRCS), where all signaling flows through
the Proxy
SIP proxies can insert a Record Route: header into an INVITE
message; when a record route header is inserted, all
signaling messages flow through the proxy; this is useful for
billing, or feature support
• SIP Proxy can use any database, Registrar Server or
DNS SRV query to determine the location of the next-
hop of the message

SIP Registrar Server
UA 1 UA 2
IP UA 3
Network
Registrar
UA 4
Server

• Handles registration from SIP UAs
• Also a mechanism for “Presence”
• Does not route SIP messages

SIP Registrar Server
• Can be on the separate box, or a process that

resides on a SIP Proxy or Redirect Server
• Registrar server is the device that handles SIP
REGISTER messages from non-Gateway SIP User
Agents
Registrar server stores the (Contact:) header from a User
Agent REGISTER messages for location services
Once a SIP User Agent is registered within a domain, the
domain Proxy Server is able to route session requests to
that user (agent) properly
• Details from REGISTER messages are used by the
Translation & Routing functionality of Proxy &
Redirect servers.

SIP Redirect Server
UA 1 UA 2
IP
UA 3
Network
Redirect
UA 4
Server

• Does not route SIP messages
• Returns a redirect to UAC for directed
routing to the given “new” destination

SIP Servers—Redirect Server
• The redirect server determines next destination

of the now moved UA and returns a 3xx redirect
message for where that new location is with the
translated addresses in the Contact: header
• The originating UA initiates a new session using
the information supplied from the redirect server

SIP components in “action”
SIP
Location Servers/
Registrar Redirect Database Services
“Where is this
name/phone#?”
3xx Redirection
“They moved,
REGISTER SIP Proxy
try this address”
“Here I am”
Proxied INVITE
“I’ll handle it for
INVITE
you”
“I want to talk
to another UA
SIP User
Agents SIP User
Agents
SIP-GW

Back-to-Back User Agent
• SIP Requests can be managed by intermediate
components such as proxy servers
• Proxy servers have limited ability to modify SIP
messages
Must obey strict rules regarding the modification of SIP
headers
Can’t touch SIP bodies, where the session’s media is
defined
• The dialog remains end-to-end
Dialog 1

Back-to-Back User Agent
• A commonly-adopted model, called a back-to-back user

agent (B2BUA), combines a UAC and a UAS so that a
request received by the UAS is reissued by the co-
resident UAC
• The B2BUA generates a completely independent
outgoing dialog, which affords it the ability to
synthesize SIP headers and bodies of its choosing
• B2BUAs are inherently more stateful than proxy servers
or redirect servers, and can more easily inter-work SIP
with other protocols
Dialog 1 Dialog 2

Agenda

• Elements of SIP
• SIP Signaling

Example IPv4 SIP Packet Format with UDP
Version IHL DSCP ECN Total Length

IPv4 Header is 20 Bytes Identification Flags Fragment Offset
and Binary Time to Live Protocol Header Checksum
Source Address
UDP Header is 8 Bytes Destination Address
and Binary Options Padding
(Layer 4 here could also Source Port Destination Port
be TCP or SCTP) Length Checksum
SIP Headers in US-ASCII

SIP Header is Text-based (variable in length per header/per message)
and variable in length
SIP message body is also SIP messages *sometimes* have a message body
- a SIP message header indicates the type of body
variable, but not always - could be text, data, audio, video or something else
present (depending on
the Message-type)

SIP – Sample INVITE
INVITE sip:23198@172.17.207.91:5060 SIP/2.0
Via: SIP/2.0/UDP 10.80.17.134:5060
Via: SIP/2.0/UDP 172.18.192.232:5060;branch=1FV1xhfvxGJOK9rWcKdAKOA
To: <sip:23198@172.18.192.232>;tag=abc
From: <sip:15691@10.80.17.134>;tag=a73kszlfl
Call-ID: c2943000-50405d-6af10a-382e3031@10.80.17.134
SIP CSeq: 100 INVITE
Header
Contact: sip:15691@10.80.17.134:5060
Expires: 180
Content-Type: application/sdp
Content-Length: 219
User-Agent: Cisco IP Phone/ Rev. 1/ SIP enabled
Accept: application/sdp
Record-Route: <sip:23198@172.18.192.232:5060;maddr=172.18.192.232>
v=0
o=CiscoSystemsSIP-IPPhone-UserAgent 17045 11864 IN IP4 10.80.17.134
s=SIP Call
c=IN IP4 10.80.17.134
body t=0 0
m=audio 29118 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
SIP Addressing
• Fully-Qualified Domain Names
sip:jdoe.cisco.com
• SMTP-style Domain Names [RFC 2368]
sip:jdoe@cisco.com
• E.164 style addresses [RFC 2806]
sip:14085551234@gateway.com; user=phone
user=phone means this is a gateway
• Mixed addresses
sip:14085551234@10.1.1.1; user=phone
sip:jdoe@10.1.1.1
• Secure SIP Messaging (indicates TLS is used) [RFC 4346]
sips:jdoe@cisco.com
called a “SIPS-URI” or just “SIPS”
SIP—Headers Explained
INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Length: 142
- Message body goes down here

- Content-Length Header indicates one is present
Method = Command Request URI SIP Protocol Version

Max-Forwards: 70
CSeq: 314159 INVITE
Content-Length: 142

Mandatory header in all SIP Requests
List of all SIP devices to be included in the path
‘branch’ is for identifying forking
Max-Forwards: 70
CSeq: 314159 INVITE
Content-Length: 142

Mandatory header in all SIP Requests except INFO
Maximum Number of SIP Server hops permissible in signal path

Max-Forwards: 70
CSeq: 314159 INVITE
Content-Length: 142

INVITE sip:bob@biloxi.com
Destination SIP/2.0
for the SIP Message (but isn’t used for routing message)
Max-Forwards: 70
CSeq: 314159 INVITE
Content-Length: 142


The Originator of the SIP Message Pseudo Random String (used for id)
Max-Forwards: 70
CSeq: 314159 INVITE
Content-Length: 142


Max-Forwards: 70 Call Identifier
Globally Unique
CSeq: 314159 INVITE
Content-Length: 142
James Polk 20050503


Max-Forwards: 70
Incremental
To: Sequence number of Method used from this UA
Bob <sip:bob@biloxi.com>
CSeq: 314159 INVITE
Content-Length: 142


Max-Forwards: 70
Direct route to Originator with Fully Qualified Domain Name or IP address
CSeq: 314159 INVITE
Content-Length: 142


Max-Forwards: 70
Description
CSeq: 314159 of the message body (if and when there is one)
INVITE
James Polk 20050503

Content-Length: 142

Expected header in all SIP Requests

Max-Forwards: 70
CSeq: 314159 INVITE
Content Length in Octets of Message Body
Content-Length: 142

RFC 2327, 3264
Session Description Protocol (SDP)
• A session description “Lines” below are in order

protocol for multimedia
connections • v = protocol version
• Presents a set of parameters • o = owner/creator and
for a multimedia session session identifier
Similar to H.245 in • s = session name
functionality • c = connection information –
• Developed by IETF not required if included
in all media
MMUSIC WG
• k = encryption keys
• Simple/Flexible
Text-based • t = time the session is active
Extensible • m = media description and
transport address
• SIP Offer/Answer Model is
• a = (zero or more) media
RFC 3264 attributes lines

RFC 2327, 3264
SIP Message Body for Multimedia
• An SDP message body for voice only

v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.com
c=IN IP4 10.1.3.33
- Audio t=0 0
- UDP port # 49172 m=audio 49172 RTP/AVP 0
- Codecs supported: G.711 a=rtpmap:0 PCMU/8000
• An SDP message body for voice and video

v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.com
- Audio c=IN IP4 10.1.3.33
- UDP port # 49172 t=0 0
- Codecs supported: G.711 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
James Polk 20050503
- Video m=video 51172 RTP/AVP 31 34

- UDP port # 51172 a=rtpmap:31 H.261/90000
- Codecs supported: H.261, H.263 a=rtpmap:34 H.263/90000
Agenda

• Elements of SIP
• SIP Signaling

RFC 3264
SIP Is a Request/Response Protocol

Requestor Responder
Starts with an “offer”
(the Client) (the Server)
The Request

SIP Methods (Which Are Requests) from
RFC 3261
• INVITE—A user or service is being invited to
participate in a multimedia session
• ACK—Confirms that a client has received a final
response to an INVITE request
• BYE—Terminates an existing session; can be
sent by any user agent (in a multiparty session)
• CANCEL—Cancels pending requests; does not
terminate sessions that have been accepted
• OPTIONS—Queries the capabilities of servers
• REGISTER—Registers the user agent with the
registrar server of a domain

Additional SIP Request Methods
• INFO (RFC 2976)

• PRACK (RFC 3262)
• SUBSCRIBE and NOTIFY (RFC 3265)
• UPDATE (RFC 3311)
• MESSAGE (RFC 3428)
• REFER (RFC 3515)
• PUBLISH (RFC 3903)

RFC 3264
SIP is a Request/Response Protocol

Requestor Responder
(the Client) (the Server)
The Request
Progressing Message (optional)
Progressing Message (optional)
James Polk 20050503
*then*
Acceptance Message
*or*
ONLY
one of Redirection Message
these is
*or*
sent
Rejection Message
Expects an “answer”
RFC 3261
SIP Responses (Which Are Replies)

Description Examples
100 Trying
Informational – Request received, continuing to 180 Ringing
1xx
process request. 181 Call is Being Forwarded
183 Session Progressing
Success – Action was successfully received, 200 OK
2xx
understood and accepted. 202 Acceptable
300 Multiple Choices
Redirection – Another SIP Element needs to be
3xx 301 Moved Permanently
contacted in order to complete the request.
302 Moved Temporarily
401 Unauthorized
406 Not Acceptable
Client Error – Request contains bad syntax or 407 Proxy Authentication Required
4xx
cannot be fulfilled at this server. 486 Busy Here
487 Request Terminated
488 Not Acceptable Here
Server Error – Server failed to fulfill an 502 Bad Gateway
5xx
apparently valid request. 503 Service Unavailable
600 Busy Everywhere
6xx Global Failure – Request is invalid at any server.
603 Decline

SIP Endpoint-to-Endpoint
Signaling Without a Server
UA 1 (Alice) UA 2 (Bob)
Assumes User Agents
Know Each Other’s IP Address
INVITE (contains
“offer”)
180 Ringing Signaling

Signaling
Plane 200 OK (contains “answer”)
(UDP, TCP,
SCTP, or
ACK TLS over TCP)
RTP
Bearer RTCP
Plane
Media (UDP)
RTP
RTCP
3 Mandatory Packets for Establishment Handshake INVITE - 200 OK - ACK

SIP Call Flow with Proxy Server
UA 1 (Alice) UA 2 (Bob)
Assumes User Agents don’t
Know Each Other’s IP Address
SIP Proxy
INVITE
INVITE
100 Trying
180 Ringing
180 Ringing
200 OK
200 OK
ACK
RTP

Stateless, Stateful and “Really” Stateful Proxy
Transaction Stateless
The proxy server forwards all messages and responses without
maintaining any state
Transaction Stateful
A Proxy Server that receives a SIP Request retains state of that
transaction until that Server receives a Final Response (meaning a
2XX, 3XX, 4XX, 5XX or 6XX Response). Transaction Stateful has no
knowledge of a session Update Request (UPDATE), a Transfer
Request (REFER) or of a Termination Request (BYE)
Dialog Stateful
When Record Route Header is utilized by a Proxy while processing
a SIP Request to ensure all remaining messages traverse that
Proxy; this applies to each proxy that is in the signaling path
between UAs

RFC 3261
Dialog Stateful SIP Message Flow

Alice SIP Proxy Bob
Invite
Invite (w/ RR header)
180 Ringing
180 Ringing
200 OK (w/ RR header)
ACK (w/ Route header)

ACK
Session Established
BYE (w/ Route header)

BYE
200 OK
200 OK

RFC 3261
SIP Call Flow w/ 2 Proxies and Record Route
Alice Atlanta.com Proxy Biloxi.com Proxy Bob
Invite
100 Trying
100 Trying
180 Ringing 180 Ringing

180 Ringing
200 OK (w/ RR header) 200 OK (w/ RR header)
ACK (w/ Route header)
ACK (w/ Route Header)
ACK
Session Established
BYE (w/ Route header)
BYE (w/ Route Header)
BYE
200 OK 200 OK
200 OK
SIP Redirect Server
Biloxi.com
Redirect Bob’s
i . com ) Server Work Phone
@bilox ily”
o b r ar
nvi te ( B Te m po
I ved
“ M o
302 ACK
Alice Bob’s
Soft Phone
Bob’s
Cell Phone

SIP Redirect Server
Biloxi.com
Redirect Bob’s
i . com ) Server Work Phone
@bilox ily”
o b r ar
nvi te ( B Te m po
I ved
“ M o
302 ACK
Alice INVITE (from Contact header of 3XX reply) Bob’s
Soft Phone
180 Ringing
200 OK
ACK
RTP Session Established
Bob’s
Cell Phone

SIP Redirecting at the User Agent Server
Redirect
Server
Bob’s
Work Phone
b il o xi.com) lar.com
( Bo b @ lo xi ce l lu
Invite a c t : bob@bi
n t
m p or a rily”, Co
ved Te ACK
Alice 302 “Mo
Bob’s
Soft Phone
Bob’s
Cell Phone

SIP Redirecting at the User Agent Server
Redirect
Server
Bob’s
Work Phone
b ilox i.com) l lul ar.com
B ob @ xic e
Invite ( ct : bob@bilo
r ar i ly” , Conta
oved Tempo ACK
Alice 302 “M Bob’s
Soft Phone
Invite
(sip:B
ob@b
iloxice
200 O llular.c
James Polk 20050503

K om)
RTP S ACK Bob’s
e ssion Cell Phone
E stablis
hed
James Polk 20050503

RFC 3261
Call Forking (Sequentially)

When Alice calls Bob, does she care which device Bob answers with?
In SIP, she’s calling “Bob”. Forking allows her to find “Bob”.
v i te
James Polk 20050503

In
C EL erm Bob’s
N . T Office
Atlanta.com Biloxi.com CA Req
7 Phone
Alice 48
Invite Invite Invite
CANCEL
487 Req. Term
Mobile Laptop
In Bob’s
vit
e
- Biloxi.com Proxy Server “Forks” Alice’s INVITE to

known UAs Registered by Bob (perhaps after 3 rings
James Polk 20050503
each) in a sequential pattern Bob’s

- A Forking Proxy (Biloxi.com) Proxy is “Transaction Stateful” Cellphone
- “branch” values are different per forked INVITE
Call Forking (Concurrently)
vi te
In
Bob’s
Office
Atlanta.com Biloxi.com Phone
Alice
James Polk 20050503

Mobile Laptop
In Bob’s
vit
e
- Biloxi.com Proxy Server “Forks” Alice’s INVITE to

known UAs Registered by Bob concurrently
James Polk 20050503
- A Forking Proxy (Biloxi.com) Proxy is “Transaction Stateful” Bob’s

Cellphone

Call Forking Flow
v i te ng
In i
R ing Bob’s
0 L Office
Atlanta.com Biloxi.com 18 NCE
CA Phone
Alice
James Polk 20050503

180 Ringing 180 Ringing
200 OK 200 OK CANCEL
Mobile Laptop
18 Inv
Bob’s
0 it
Ses ACK 20 Rin e
sion 0 O gin
Esta K g
blis
hed
-Biloxi.com Proxy Server is “Transaction
Stateful” in order to properly generate Cancels
James Polk 20050503
Bob’s
-If the Proxy is also “Dialog Stateful”, Cellphone
it will receive BYE Request from Alice or Bob
RFC 3265&3680
SIP Methods: SUBSCRIBE & NOTIFY

IM App Server SIP Registrar
SUBSCRIBE - used to
SUBSCRIBE (Event: Reg) request asynchronous
notification of an event or
set of events at a later
time
• method used to request current
state and state updates from a
SUBSCRIBE sip:alice@atlanta.com SIP/2.0
remote node
Via: SIP/2.0/TCP app_IM.atlanta.com
;branch=z9hG4bKnashds7 • Expires header SHOULD be
From: sip:app_IM.atlanta.com ;tag=123aa9 present in Request
To: sip:alice@atlanta.com • Requests MUST have exactly
Call-ID: 9987@app_IM.atlanta.com one Event Header value
CSeq: 9887 SUBSCRIBE
Contact: sip:app_IM.atlanta.com
Event: reg
Max-Forwards: 70
Expires: 21600
Accept: application/reginfo+xml

SUBSCRIBE - used to
SUBSCRIBE (Event: Reg) request asynchronous
200 OK notification of an event or
set of events at a later
time
• Expires header MUST be
present in Response
SIP/2.0 200 OK
Via: SIP/2.0/TCP app_IM.atlanta.com • 200-class responses indicate
;branch=z9hG4bKnashds7 ;received=10.1.3.2 that the subscription has been
From: sip:app_IM.atlanta.com ;tag=123aa9 accepted, and that a NOTIFY
To: sip:alice@atlanta.com ;tag=xyzygg will be sent immediately
Call-ID: 9987@app_IM.atlanta.com
CSeq: 9987 SUBSCRIBE
Contact: sip:server19.atlanta.com
Expires: 3600

NOTIFY - used to notify a
SIP node that an event
SUBSCRIBE (Event: Reg) which has been
200 OK requested by an earlier
NOTIFY (status: init) SUBSCRIBE method has
occurred
• NOTIFY is sent to inform
NOTIFY sip:app_IM.atlanta.com SIP/2.0
Via: SIP/2.0/TCP server1.atlanta.com subscribers of changes in state
;branch=z9hG4bKnasaii to which the subscriber has a
From: sip:alice@atlanta.com ;tag=xyzygg subscription
To: sip:app_IM.atlanta.com ;tag=123aa9 • Event Header MUST match
CSeq: 1288 NOTIFY
Contact: sip:server19.atlanta.com <?xml version="1.0"?>
Event: reg <reginfo xmlns=
Max-Forwards: 70 "urn:ietf:params:xml:ns:reginfo"
Content-Type: application/reginfo+xml version="0" state="full">
Content-Length: 223 <registration aor="sip:alice@atlanta.com"
id="a7" state="init" />
</reginfo>
NOTIFY - used to notify a
SIP node that an event
SUBSCRIBE (Event: Reg) which has been
200 OK requested by an earlier
NOTIFY (status: init) SUBSCRIBE method has
200 OK
occurred
• sending a NOTIFY message to
SIP/2.0 200 OK
Via: SIP/2.0/TCP server19.atlanta.com an unsuspecting node is
;branch=z9hG4bKnasaii ;received=10.1.3.1 invalid behavior, MUST receive
From: sip:app_IM.atlanta.com ;tag=123aa9 a 481 "Subscription does not
To: sip:alice@atlanta.com ;tag=xyzygg exist" response
CSeq: 1288 NOTIFY
Contact: sip:server1.atlanta.com
Content-Length: 0

RFC 3428
SIP Methods: MESSAGE

Alice Bob
MESSAGE
MESSAGE - the transfer of
messages between users
in near real-time
• Content (the payload) in
MIME body parts
MESSAGE sip:bob@biloxi.com SIP/2.0 • MESSAGE does not initiate
Via: SIP/2.0/TCP pc33.atlanta.com
;branch=z9hG4bK776asegma dialogs
Max-Forwards: 70 • There is no explicit
From: Alice <sip:alice@atlanta.com>;tag=1928301774 association between
Call-ID: a84b4c76e66710@pc33.atlanta.com messages
CSeq: 22756 MESSAGE
Content-Type: text/plain • The body size MUST NOT
Content-Length: 37 exceed 1300 bytes
Isn’t this a great presentation ?

SIP Methods: MESSAGE
Alice Bob
MESSAGE - the transfer of

MESSAGE
messages between users
200 OK
in near real-time
• 200 OK response does not
necessarily mean the user
SIP/2.0 200 OK has read the message
Via: SIP/2.0/TCP pc33.atlanta.com
;branch=z9hG4bKnashds7 ;received=10.1.3.33
To: sip: sip:bob@biloxi.com>;tag=1928301774
• A 4xx or 5xx response
From: alice@atlanta.com indicates that the
Call-ID: a84b4c76e66710@pc33.atlanta.com message was not
CSeq: 22756 MESSAGE
Content-Length: 0
delivered successfully
• A 6xx response means it
was delivered
successfully, but refused

RFC 3680
SIP Methods: Logging onto Service

Alice SIP Registrar IM App Server
SUBSCRIBE (Event: Reg)

200 OK
NOTIFY (status: init)
200 OK
REGISTER
200 OK
NOTIFY (status: active)*
200 OK*
* Messages shown on next slide

SIP Methods: Logging onto Service (Cont.)
NOTIFY sip:app_IM.example.com SIP/2.0
Via: SIP/2.0/TCP server19.example.com
;branch=z9hG4bKnasaij
From: sip:alice@atlanta.com ;tag=xyzygg
To: sip:app_IM.atlanta.com ;tag=123aa9
CSeq: 1289 NOTIFY
Contact: sip:server19.atlanta.com SIP/2.0 200 OK
Event: reg Via: SIP/2.0/TCP server19.atlanta.com
Max-Forwards: 70 ;branch=z9hG4bKnasaii ;received=10.1.3.1
Content-Type: application/reginfo+xml From: sip:app_IM.atlanta.com ;tag=123aa9
Content-Length: ... To: sip:alice@atlanta.com ;tag=xyzygg
<?xml version="1.0"?> CSeq: 1289 NOTIFY
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo" Contact: sip:server1.atlanta.com
version="1" state="partial"> Content-Length: 0
<registration aor="sip:alice@atlanta.com"
id="a7" state="active">
<contact id="76" state="active" event="registered"
duration-registered="0">
<uri>sip:alice@pc33.atlanta.com</uri>
</contact>
</registration>
</reginfo>

RFC 3680
SIP Methods: Logging onto Service

Alice SIP Registrar IM App Server
SUBSCRIBE (Event: Reg)

200 OK
NOTIFY (status: init)
200 OK
REGISTER
200 OK
NOTIFY (status: active)
200 OK
MESSAGE
Welcome to the Atlanta Instant Messaging service!

Agenda

• Elements of SIP
• SIP Signaling

Peer-to-Peer to/from Client/Server
Interworking
Domain Proxy
Server
Alice
INVITE /200 OK
SIP Only
INVITE /200 OK Domain
RT AC
P K
St
re
am
User
Agents
Alice Calls Audrey

Anna
Audrey
Interworking
Call Agent
MGCP Only
YF
Domain
OK
NT
0
20
Carol Bob
Carol Calls Bob

Interworking
Call Agent
MGCP Only
CX
CRC
Domain
OK
CR
200
X
0
20
OK
RTP
Stream
Carol Bob
Carol Calls Bob

Interworking
Domain Proxy
Server
Alice Call Agent
INVITE INVITE
?
User
Agents
Carol Bob
But…Can Alice Call Bob?

Anna
Audrey
Interworking
Domain Proxy
Server
Alice Call Agent
? CRCX
NTFY
User
Agents
Carol Bob
And…Can Bob Call Alice?

Anna
Audrey
Interworking
Domain Proxy Domain Proxy

Server Server
Alice Call Agent
INVITE
?
User
Agents
Carol Bob
Here?
Anna
Audrey
Interworking
Domain Proxy Domain Proxy

Server Server
Alice Proxy Server/ Call Agent
Embedded Server
INV/
INVITE /200 OK 200 OK INV/200 OK
ACK
CRCX/
RTP
Strea
200 OK
m
User
Agents
Carol Bob
Putting SIP on the CA

Anna Server Allows for the
Audrey Necessary Interoperability
James Polk 20050503
James Polk 20050503
In Conclusion…
Cisco Systems, Inc. All rights reserved. 77

In Conclusion…
• SIP is a session set-up protocol, providing
primitives to invoke services
• SIP is Layer 2, 3 & 4 independent
• SIP utilizes many existing IETF protocols and
syntax
• Signals Instant Messaging, and transports another
protocol (SDP) to establish Voice & Video
• Servers can have varying degrees of “awareness”
– Amount of control based on configuration of the server
• The integration of call control and web services
creates applications that reduce cost and increase
productivity
SIP References
• http://www.cisco.com—Search for SIP, Cisco proxy server and

CallManager 5.0
• http://www.cs.columbia.edu/~hgs/sip/—SIP homepage
• http://www.ietf.org/html.charters/sip-charter.html/—IETF SIP WG
• http://www.ietf.org/html.charters/sipping-charter.html/—
IETF SIPPING WG
• http://search.ietf.org/rfc.html—IETF RFC search page
• http://search.ietf.org/search/brokers/internet-drafts/query.html—
Internet draft search page
• http://www.sipcenter.com/—The SIP center
• http://www.ietf.org/html.charters/ecrit-charter.html/—IETF ECRIT
WG for emergency calling


SIP For Multimedia PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SIP For Multimedia PDF

Uploaded by

Copyright:

Available Formats

James Polk 20050503

SIP for Voice, Video and Instant

Cisco Systems, Inc. All rights reserved. 1

• SIP History & Basics

© Cisco Systems, Inc. All rights reserved. 2

• Peer-to-Peer Signaling Protocols

• H.323 uses TCP or UDP

• MGCP uses UDP

© Cisco Systems, Inc. All rights reserved. 4

• The Session Initiation Protocol (SIP) is an

SIP entities can communicate via:

SIP is a simple extensible protocol

© Cisco Systems, Inc. All rights reserved. 8

• User location: Determination of the end system to be

© Cisco Systems, Inc. All rights reserved. 11

• SIP History & Basics

© Cisco Systems, Inc. All rights reserved. 12

• User Agent [Mandatory]

© Cisco Systems, Inc. All rights reserved. 13

• User Agent = UAC + UAS

© Cisco Systems, Inc. All rights reserved. 14

• Translation between SIP protocol format to and

© Cisco Systems, Inc. All rights reserved. 15

• Handles the routing of SIP messages, but does not

© Cisco Systems, Inc. All rights reserved. 17

• Optional *logical* SIP component

© Cisco Systems, Inc. All rights reserved. 18

• Can be on the separate box, or a process that

© Cisco Systems, Inc. All rights reserved. 19

• Optional *logical* SIP component

© Cisco Systems, Inc. All rights reserved. 20

• The redirect server determines next destination

© Cisco Systems, Inc. All rights reserved. 21

© Cisco Systems, Inc. All rights reserved. 22

• The dialog remains end-to-end

© Cisco Systems, Inc. All rights reserved. 23

• A commonly-adopted model, called a back-to-back user

© Cisco Systems, Inc. All rights reserved. 24

• SIP History & Basics

© Cisco Systems, Inc. All rights reserved. 25

Version IHL DSCP ECN Total Length

SIP Headers in US-ASCII

© Cisco Systems, Inc. All rights reserved. 26

INVITE sip:bob@biloxi.com SIP/2.0

- Message body goes down here

INVITE sip:bob@biloxi.com SIP/2.0

- Message body goes down here

- Message body goes down here

Maximum Number of SIP Server hops permissible in signal path

- Message body goes down here

- Message body goes down here

INVITE sip:bob@biloxi.com SIP/2.0

- Message body goes down here

INVITE sip:bob@biloxi.com SIP/2.0

James Polk 20050503

INVITE sip:bob@biloxi.com SIP/2.0

- Message body goes down here

INVITE sip:bob@biloxi.com SIP/2.0

- Message body goes down here

INVITE sip:bob@biloxi.com SIP/2.0

James Polk 20050503

- Message body goes down here

INVITE sip:bob@biloxi.com SIP/2.0

• Optional logical SIP component

• Optional logical SIP component