SIP + SDP

Transcription

SIP + SDP

National Chung Cheng University
Session Initiation
Protocol & SDP
Chiang, Wei-Kuo (江為國)
Assistant Professor
Department of CSIE
Office : EA 311
Phone : 05-2720411~33126
Email : [email protected]
URL : http://www.cs.ccu.edu.tw/
http://www cs ccu edu tw/~wkchiang/
wkchiang/
Dept. Computer Science & Information Engineering
O tli
Outline

Introduction
z
z
SIP Network Entities
SIP Architecture

SIP M
Message Format
F
t

SIP Communication

SIP Extensions
Telecom Service Integration for ITS
2
SIP & SDP
I t d ti
Introduction

Why SIP ?
z
A powerful alternative to H.323
z
M
More
fl
flexible,
ibl
simpler
i l
z
Easier to implement advanced features
z
Better to support of intelligent user devices
z
Transport independence (UDP, TCP, or SCTP)
What is “bake-off”
bake-off or “SIPIT”
SIPIT ?
z
Various vendors come together and test their
products against each other to ensure that
¬they have implemented the specification correctly
¬compatibility with other implementations
3
SIP & SDP
SIP Overview
O
i
(1/2)
( / )

Developed in SIP Working Group in IETF
z
Proposed standard RFC 2543, February 1999
z New Version of SIP - RFC 3261
3261, June 2002
z Work began 1995
z Sep.
p 1999 split
p
from MMUSIC
¬ Multiparty Multimedia Session Control

SIP (Session Initiation Protocol)
z
Application-Layer Control Protocol
z
Text-based Encoding (ISO 10646 in UTF-8)
z
SIP is HTTP-like, “Request-Response”
¬establish, modify and terminate multimedia
sessions
4
SIP & SDP
SIP Overview
O
i
(2/2)
( / )

A signaling protocol
z

SIP + SDP
z

The setup, modification, and tear-down of
multimedia sessions
Describe
esc be t
the
e sess
session
o c
characteristics
a acte st cs
Separate signaling and media streams
SIP Signaling
IP Network
RTP Media Stream
SIP User
SIP User
5
SIP & SDP
SIP in
i IP Multimedia
M lti
di
Applications
R
S
V
P
SDP/SDPng
HTTP SMTP
TCP/SCTP
SIP
RTSP
TCP/UDP
SAP
RTP/
RTCP
UDP
IPv4/IPv6 with Mobility, DiffServ and Multicast
• Common Addressing, user@domain
(URI & URL)
• Text-based
Te t based and Encoding Format
• Same Request-Response Model,
and Response Codes
• MIME for Flexible Payload
• DNS for Address Mapping
Easy to
E
t Do
D Integrated
I t
t d Services
S i
by Combining more than One
Protocols
6
SIP & SDP
SIP Network
N t
kE
Entities
titi ((1/4)
/ )

User Agent (UA)
z
User Agent Client - Initiate SIP Request
z
U
User
A
Agent
t S
Server - Accepts
A
t or rejects
j t call
ll
Server
z
Registrar, Proxy, Redirect Server
Location
Server
Proxy
Servers
Registrar
REGISTER
INVITE
INVITE
Client
Server
User
Agent
Redirect
Server
INVITE
Client
Response
3XX
Server
INVITE
7
SIP & SDP
SIP Network
N t
kE
Entities
titi ((2/4)
/ )

Proxy server
z
Handle requests or forward requests to other
servers
z
Can be used for call forwarding, time-of-day
routing, or follow-me services
1.Request
[email protected]
[email protected]
4.Response
2.Request
[email protected]
SIP
Proxy
8
3.Response
[email protected]
SIP & SDP
SIP Network
N t
kE
Entities
titi ((3/4)
/ )

Proxy Server + Location Server
itri.org.tw
cs.ccu.edu.tw
[email protected]
BMW
(1) INVITE
[email protected]
(6) 200
OK
(7) ACK [email protected]
(3) hon
nda@AUD
DI
(2) h
honda
location server
se e
(4) INVITE
honda@AUDI
AUDI
(5) 200 OK
BENS (8) ACK honda@AUDI
Honda@AUDI
9
SIP & SDP
SIP Network
N t
kE
Entities
titi ((4/4)
/ )

Redirect servers
z
Map the destination address to zero or more new
addresses
1.Request
[email protected]
2.Moved temporarily
Contact: [email protected]
[email protected]
@
3.ACK
Redirect Server
4.Request
[email protected]
5 Response
5.Response
[email protected]
10
SIP & SDP
SIP A
Architecture
hit t
SIP Request
SIP Response
RTP Media Stream
Redirect Server
Location Server
Proxy Server
Proxy Server
Proxy Server
User Agent
g
Client ((Caller))
User Agent Server (Callee)
11
SIP & SDP
M h d &R
Methods
Response C
Codes
d

Methods (Commands)
z
z
z
z
z
z
z
z
z
z
z
Response Status
Informational
Success
R di
Redirection
i
Client-Error
Server-Error
Global-Failure
Global
Failure
Code
1xx
2xx
3
3xx
4xx
5xx
6xx
REGISTER
Location
Server
INVITE,ACK
BYE
CANCEL
0 REGISTER
0.REGISTER
2xx
OPTION
Registrar
0.REGISTER
INFO
2xx
Redirect
Proxy
Proxy
Server
Servers
Servers
REFER
SUBSCRIBE
3_2.INVITE
NOTIFY
3_3.INVITE
2.3xx
1.INVITE
4.2xx
PRACK
5.ACK
COMET
Client
3_1.INVITE
12
Server
SIP & SDP
SIP Extensions
E t
i
Method
Extension
Header
INFO
REFER
Refer-To
Referred-By
SUBSCRIBE Event
NOTIFY
Allow-Event
PRACK
RAck
Rcseq
COMET
Original
Description
RFC 2976
Carry control information of a session.
Draft-ietf-sip-cctransfer-05
provide Call Transfer capabilities
Draft-roach-sipAsynchronous request notification of
subscribe-notify-03 events. Notify SIP events which has
been requested by an earlier
SUBSCRIBE method.
draft-ietf-sip100rel-04.txt -
Achieve reliability and in order for
provisional responses.
draft-ietf-sipmanyfolksresource-02
The COMET method is used for
communicating successful completion
of preconditions between the user
agents.
UPDATE, MESSAGE, ...
13
SIP & SDP
O tli
Outline

Introduction

SIP Message Format
z
z
Message Header
Message Body
d (SDP)
(S )

SIP Communication

SIP Extensions
14
SIP & SDP
SIP M
Messaging
i
S
Syntax
t

T
Text-based
b
d
z
Similar to HTTP
z Disadvantage – more bandwidth consumption

SIP messages
z
message = start-line
start line
*message-header CRLF
[message-body]
z start-line = request-line | status-line

Request-line specifies the type of request

The response line indicates the success or
failure of a given request.
15
SIP & SDP
SIP Message
M
Format
F
t (1/2)
( / )
SIP Request Example
SIP Response Example
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP science.fiction.com
From: Fingal <sip:[email protected]>
To: Patric <sip:[email protected]>
SIP
Call-ID: [email protected]
Header
Cseq: 1 INVITE
Subject: lunch at La Empenada?
Content-Type: application/sdp (mime)
Content-Length: …
v=0
o=ffl 53655765 2353687637 IN IP4 123.4.5.6
s=Chorizo
c=IN IP4 science.fiction.com
m=audio 5004 RTP/AVP 0 3 5
a=rtpmap:0 PCMU/8000
16
SIP/2.0 200 OK
Vi SIP/2.0/UDP
Via:
SIP/2 0/UDP science.fiction.com
i
fi ti
From: Fingal <sip:[email protected]>
To: Patric <sip:[email protected]>
Cseq: 1 INVITE
Content-Type:
Content
Type: application/sdp
Content-Length: …
Payload:
SDP
(MIME type)
SIP & SDP
SIP Message
M
Format
F
t (2/2)
( / )

M
Message
headers
h d
z
Additional information of the request or
response
p
z E.g.,
¬The originator and recipient
¬Retry-after
f
header
h d
¬Subject header

Message body
z
Describe the type of session
z The most common structure for the message
g body
y
is SDP (Session Description Protocol).
z Could include an ISDN User Part message
z Examined only at the two ends
17
SIP & SDP
SIP Request
R
t St
Start-Line
t Li
(1/2)

M h d SP Request-URI
Method
R
URI SP SIP-version
SIP
i
CRLF

Methods
z
REGISTER
¬Log in and register the address with a SIP server
¬“all
all SIP servers
servers” – multicast address (224.0.1.175)
¬Can register with multiple servers
¬Can have several registrations with one server
z INVITE, ACK
¬Initiate a session
¬Information of the calling and called parties
¬The type of media
¬～IAM (initial address message) of ISUP
¬ACK only when receiving the final response
18
SIP & SDP
SIP Request
R
t St
Start-Line
t Li
(2/2)
z
BYE
¬Terminate a session
¬Can
Can be issued by either the calling or called party
z CANCEL
¬Terminate a pending request
¬E.g., an INVITE did not receive a final response
z OPTIONS
¬Query a server as to its capabilities
(A particular type of media

Request URI
Request-URI
z

The address of the destination
SIP-Version: SIP/2.0
/
19
SIP & SDP
SIP Add
Addressing
i
& Naming
N
i

The entities addressed by SIP are users at
hosts (SIP URLs: Uniform Resource Locators)
z
A
Augmented
t d Backus-Naur
B k
N
F
Form
d
described
ib d
z
email-like identifier of the form user@host
¬user: user name or telephones number
¬host: domain name or a numeric network address

Examples of SIP URLs
z
z
z
z
z
user@host
sip:[email protected]
sip:beagleboy@176 7 6 1
20
SIP & SDP
SIP Response
R
Status-Line
St t
Li

SIP Version
V
i
SP Status
S
C
Code
d SP Reason-Phrase CRLF

Status code (A three-digit number)
z
z
z
z
z
z
z
1XX
2XX
3XX
3
4XX
5XX
6XX
All
Informational
Success (only code 200 is defined)
Redirection
ed ect o
Request Failure
Server Failure
Global Failure
responses, except for 1XX, are considered final
¬ Should be ACKed

Reason-Phrase
z
A textual description
p
of the outcome
z Could be presented to the user
21
SIP & SDP
SIP S
Server properties
ti
Property
Acts as a SIP
client
Returns 1xx status
Returns 2xx status
Returns 3xx status
Returns 4xx status
Returns 5xx status
Returns 6xx status
Inserts Via header
Accepts
p ACK
User agent registrar
server
No
No
Redirect
server
No
Proxy
server
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
No
No
22
SIP & SDP
D fi iti
Definition
off Terms
T
(1/2)
( / )

C ll
Call
z
Some communication between peers.
z Identified by a globally unique Call-ID
Call ID

Dialog (call leg)
z
Peer to peer SIP relationship between two UAs.
Peer-to-peer
z Combination with Call-ID, To and From

SIP Transaction
z
The first SIP request message to a final
response.
z 1 INVITE request + a non
non-2xx
2xx response + ACK
z 1 INVITE request + a 2xx response
z 1 Non-INVITE request
q
+ 1 final response
p
23
SIP & SDP
D fi iti
Definition
off Terms
T
(2/2)
( / )

Provisional response
z
Indicate call progress
z
St t
Status
code
d = 1
1xx
Final response
z
A response terminates a SIP transaction.
z
Status code = 2xx,3xx,4xx,5xx,6xx
Session
z
SDP specification: “ A multimedia session is a
set of multimedia senders and receivers and the
data streams flowing from senders to
receivers.”
24
SIP & SDP
M
Message
H
Headers
d

Provide further information about the message

Example of headers

z
To: The called party
z
From: The calling party
z
Call-ID Header: uniquely identifies a specific
invitation to a session
Four main categories
z
General headers
z
Request headers
z
Response headers
z
Entity headers
25
SIP & SDP
G
General
lH
Headers
d
((1/6)
/6)

Used in both requests and responses

Call-ID Header
z
uniquely identifies a specific invitation to a
session
z
Call ID = (“Call
Call-ID
(“Call-ID”
ID” | “i”) “:” local
local-id“@”host
id“@”host
¬local-id = 1 *uric
¬“host”
host SHOULD be a fully qualified domain name or
a globally routable IP address.
z Call-IDs are case-sensitive
z
All REGISTER requests issued by a single client
SHOULD use the same Call-ID, at least within
the same boot cycle.
y
26
SIP & SDP
G
General
lH
Headers
d
((2/6)
/6)

T Header
To
H d
z
z
z
z
z
To = (“To” | “t”) “:” (name-addr | addr-spec) *
( ;
(“;”addr-params)
p
)
¬To: The Operator
<sip:[email protected]>;tag=28722
¬To: sip:[email protected]
sip:+12124441212@server phone2net com
Requests and responses MUST contain To field.
UAS or redirect server copies the To field to
response.
Add “tag” by UAS, registrars and redirect
servers.
Add a “tag” if request contained more than one
Via.
¬Since handled by at least one proxy server.
server
27
SIP & SDP
G
General
lH
Headers
d
((3/6)
/6)

Contact Header
z
Provides a URL for use in future communication
regarding a particular session
z
Examples 1: In a SIP INVITE, the Contact header
might be different from the From header.
¬An third-party administrator initiates a multiparty
session.
z Example 2: Used in response
response, it is useful for
directing further requests directly to the
called user.
z
Example 3: It is used to indicate a more
appropriate address if an INVITE issued to a
given URI failed to reach the user.
g
28
SIP & SDP
G
General
lH
Headers
d
((4/6)
/6)
z
Appear in INVITE, OPTIONS, ACK, and REGISTER
z
Provide a URL for further communications.
z
INVITE and ACK request
¬location the request is originating
z INVITE 2xx response
p
¬reachable most directly for future SIP requests
z INVITE 1xx response
¬same as 2xx response
z REGISTER request
¬which locations the user is reachable
z REGISTER 2xx responses
¬return all locations
29
SIP & SDP
G
General
lH
Headers
d
((5/6)
/6)

Via Header
z
Prevent request looping.
z
E
Ensure
replies
li
take
t k the
th same path.
th
z
Requests:
¬Original request MUST insert Via field(host name,
name
network address, port number).
¬Subsequent proxy: add its own Via field before
¬Proxy send a request to a multicast address
(add the “maddr” and “ttl”
¬Proxy server receive
i
a request containing
i i
it’s
i ’
address.
(Response
Response with a 482(loop detected)
30
SIP & SDP
G
General
lH
Headers
d
(6/6)
z
Receiver-tagged
i
t
d Via
i h
header
d
¬ Via: SIP/2.0/UDP erlang.bell-telephone.com:5060
¬ Via: SIP/2.0/UDP 10.0.0.1:5060;
received=199.172.136.3
z
Response
¬First
First Via header indicate the proxy or client
processing the response ?
(Yes: remove this Via field
(N discard
(No:
di
d the
th message
¬No second Via header
p
is destined ffor this client
(Yes: this response
(No: processing depends on “maddr” or
“receiver-tag”
z UAS or redirect server copies the Via into
response.
31
SIP & SDP
R
Request/Response
t/R
H
Header
d

Request Headers
z
Apply only to SIP requests
z
Additi
Addition
i
info.
f
about
b t th
the request
t or th
the client
li t
¬Subject:
¬Priority: urgency of the request
(emergency, urgent, normal, or non-urgent

Response Headers
z
Further info about the response that cannot be
included in the status line
¬Unsupported
¬Retry-After
32
SIP & SDP
E tit H
Entity
Headers
d

Indicate the type and format of information
included in the message body

Content-Length: the length of message body

Content-Type: the media type of message body
z
E.g., application/sdp

Content-Encoding:
g for message
g compression
p

Content Disposition: how a message part
should be interpreted
p
z
session, icon (image), alert (audio), render
(text) …
33
SIP & SDP
SIP Request Example
SIP Request Message
Call-ID:[email protected]
Content-Type:application/sdp
Content
Type:application/sdp
CSeq: 1 INVITE
From: sip:[email protected];tag=c8f31453efad
Description
Method type, request URI and SIP version
Globally unique ID for this call
The body type, an SDP message
Command Sequence number and type
User originating the request
To:sip:[email protected]
Vi SIP/2
Via:
SIP/2.0/UDP
0/UDP 140
140.96.200.1:8080
96 200 1 8080
Max-Forwards:80
Content-Type:application/sdp
Content-Length:133
g
User being invited into the call
IP Address
Add
and
d portt off previous
i
h
hop
Maximun Routing hubs
Content Type : using SDP
Conthent length
g
Blank line separates header from body
SDP Version
Owner/creator and session identifier
The name of the session
Phone number of caller
Connection information
Time the session is active
Media name and transport address
v=0
o=smayer 280932498 0 IN IP4 140.96.200.1
s=Incoming phone call from acer
p=+886 3 5914494
c=IN IP4 140.96.102.100
t=31289123980198230912
m=audio 492837 RTP/AVP 0
34
SIP & SDP
S
Session
i
Description
D
i ti
Protocoll

The Most Common Message Body
z
Be session information describing the media to
be exchanged between the parties
z
SDP, RFC 2327 (initial publication)
SIP uses SDP in an answer/offer mode.
mode
z
An agreement between the two parties as to the
types of media they are willing to share
z
RFC 3264 (An Offer/Answer Model with SDP)
¬To describe how SDP and SIP should be used
t
together
th
35
SIP & SDP
U
Usage
off SDP with
ith SIP

SIP and SDP make a wonderful partnership for
the transmission of session information.

SIP provides the messaging mechanism for the
establishment of multimedia sessions.

SDP provides a structured language for
describing the sessions.
z
The entity headers identifies the message body.
36
SIP & SDP
Th Structure
The
St
t
off SDP

T
Text-based
b
dP
Protocoll

The Structure of SDP
Session Description
z
Session Level Info
¬Name of the session
¬Originator
Originator of the session
¬Time that the session is
to be active
z Media Level Info
¬Media type
¬Port number
¬Transport protocol
¬Media format
37
Session Levell Information
f
Protocol Version
Originator and Session ID
Session Name
Session Time
Media Description 1
Media Name
Medi
N me and
nd Transport
T n po t
Connection Information
Media Description 2
Media Name and Transport
Connection Information
SIP & SDP
SDP Syntax
S t

A number of lines of text

In each line
z
field=value
z
field is exactly one character
¬case-significant

Session-level fields

Media-level fields
z
Begin with media description field (m=)
38
SIP & SDP
M d t
Mandatory
Fi
Fields
ld

v=(protocol version)
o=(session origin or creator)
s=(session name), a text string
z

t=(time of the session), start time & stop time
z

For multicast conference
For pre-arranged multicast conference
m=(media)
z
Media type
z
The
h transport port
z
The transport protocol
z
The media format
format, an RTP payload format
39
SIP & SDP
O ti
Optional
l Fields
Fi ld ((1/3)
/ )

Some optional fields can be applied at both
session and media levels.
z

The value applied at the media level overrides
that at the session level
i=(session
(
information))
z
A text description
z At both session and media levels
z It would be somewhat superfluous
superfluous, since SIP
already supports the Subject header.

u=(URI
(
of description)
p
)
z
Where further session information can be
obtained
z Only at session level
40
SIP & SDP
O ti
Optional
l Fields
Fi ld ((2/3)
/ )

e=(e-mail
(
il address)
dd
)
z
Who is responsible for the session
z Only at the session level

p=(phone number)
z

Only at the session level
c=(connection information)
z
Network type,
yp , address type
yp & connection address
z At session or media level

b=(bandwidth
(
information))
z
In kilobits per second
41
SIP & SDP
O ti
Optional
l Fields
Fi ld ((3/3)
/ )

r=(repeat times)
z
For regularly scheduled session a session is to
be repeated
p
z How often and how many times

z=(timezone adjustments)
z
z

For regularly scheduled session
Standard time and daylight savings time
k=(encryption key)
z
An encryption key or a mechanism to obtain it
for the purposes of encrypting and decrypting
the media

a=(attributes)
z
Describe additional attributes
42
SIP & SDP
O d i
Ordering
off Fields
Fi ld

Session Level
z
z
z
z
z
z
z
z
z
z
z
z
z
z

Protocol version (v)
Origin
g
(
(o)
)
Session name (s)
Session information (i)
URI (u)
E-mail address (e)
Phone number (p)
Connection info (c)
Bandwidth info (b)
Time description (t)
R
Repeat
t i
info
f (
(r)
)
Time zone adjustments (z)
Encryption key (k)
Attributes (a)
43
Media level
z
Media description (m)
z Media info (i)
z Connection info (c)
¬ Optional if specified at
the
h session
i
level
l
l
z Bandwidth info (b)
z Encryption
yp
key
y (
(k)
)
z Attributes (a)
SIP & SDP
S bfi ld (1/3)
Subfields
( / )

Field = <subfield1> <subfield2> <subfield3>
Origin
z
z
z
z
z
z
Username, the originator’s login id or “-”
session ID - A unique ID
¬Make use of NTP timestamp
version, a number for this particular session
network type
yp - A text string
g
¬IN refers to Internet
address type
¬IP4, IP6
address, a fully-qualified domain name or the
IP address
44
SIP & SDP
S bfi ld (2/3)
Subfields
( / )

Connection Data
z
The network and address at which media data
will be received
z
Network type, Address type, Connection address
Media Information
z
Media type - Audio, video, data, or control
z
Port
z
Format
¬List the types of media format to be supported
¬According to the RTP audio/video profile
z m= audio 45678 RTP/AVP 15 3 0
¬G.728, GSM, G.711
45
SIP & SDP
S bfi ld (3/3)
Subfields
( / )

Att ib t
Attributes
z
To enable additional information to be included
z Property attribute
¬ a=sendonly
¬ a=recvonly
z value attribute
¬ a=orient:landscape used in a shared whiteboard session
z rtpmap attribute
¬ The
Th use off dynamic
d
i payload
l d type
t
¬ a=rtpmap:<payload type> <encoding name>/<clock rate>
[/<encoding parameters>].
¬ m=video
id
54678 RTP/AVP 98
¬ a=rtpmap 98 L16/16000/2
(16-bit linear encoded stereo (2 channels) audio
sampled at 16kHz
46
SIP & SDP
SDP iin SIP Messages
M

INVITE with multiple media streams
z

Unsupported should also be returned with a port
number of zero
An alternative
z
INVITE
a=rtpmap
p
p 2 G726-32/8000
a=rtpmap 4 G723/8000
a=rtpmap 15 G728/8000
z
CONNECT
p
p 15 G728/8000
/
a=rtpmap
47
SIP & SDP
SDP iin SIP Flow
Fl
(1/2)
( / )
Daniel<sip:[email protected]>
a
b
Boss<sip:[email protected]>
From: Daniel<sip:[email protected]>; tag = abcd1234
To: Boss<sip:[email protected]>
q 1 INVITE
CSeq:
Content-Length: 213
Content-Type: application/sdp
Content-Disposition: session
v=0
o=collins 123456 001 IN IP4 station1.work.com
s=
c=IN IP4 station1.work.com
t=0 0
a=rtpmap 2 G726-32/8000
/
a=rtpmap 15 G728/8000
SIP/2.0 200 OK
…
48
SIP & SDP
SDP iin SIP Flow
Fl
(2/2)
( / )
Daniel<sip:Collins@station1 work com>
b
c
d
Boss<sip:Manager@station2 work com>
SIP/2.0 200 OK
To: Boss<sip:[email protected]>; tag = xyz789
CSeq: 1 INVITE
Content-Length: 163
v=0
s=
c=IN IP4 station2
station2.work.com
work com
t=0 0
m=audio 0 RTP/AVP 2
m=audio 0 RTP/AVP 4
a=rtpmap 15 G728/8000
ACK sip:[email protected] SIP/2.0
To: Boss<sip:[email protected]>; tag = xyz789
CSeq: 1 ACK
Content-Length: 0
Conversation
49
SIP & SDP
SIP&SDP Off
Offer/Answer
/A
Model
M d l

Re-INVITE is issued when the server replies
with more than one codec.
z
With the same dialog identifier (To and From
headers, including tag values), Call-ID and
Request-URI
z The session version is increased by 1 in o=
line of message body.

A mismatch
z
488 or 606 - Not Acceptable
z A Warning header with warning code 304 (media
t
type
not
t available)
il bl ) or 305 (i
(incompatible
tibl media
di
type)
z Then the caller issues a new INVITE request.
50
SIP & SDP
Off /A
Offer/Answer
Flow
Fl
((1/2)
/ )
a
b
CSeq: 1 INVITE
Content-Length: 183
v=0
s=
t=0 0
a=rtpmap 2 G726-32/8000
a=rtpmap 15 G728/8000
a=inactive
SIP/2.0 200 OK
CSeq: 1 INVITE
Content-Length: 157
v=0
s=
t=0 0
m=audio 6666 RTP/AVP 4 15
a=rtpmap
t
4 G723/8000
a=rtpmap 15 G728/8000
a=inactive
51
SIP & SDP
Off /A
Offer/Answer
Flow
Fl
((2/2)
/ )
c
d
To: Boss<sip:[email protected]>;
Boss<sip:Manager@station2 work com>; tag = xyz789
CSeq: 1 ACK
Content-Length: 0
CSeq 2 INVITE
CSeq:
Content-Length: 126
v=0
s=
tt=0
00
a=rtpmap 15 G728/8000
52
SIP & SDP
O tli
Outline

Introduction

SIP Message Format

SIP Communication
z
z

SIP Message Flows
SIP Entities Behavior
SIP Extensions
53
SIP & SDP
E
Examples
l off R
Registration
i t ti

Registration
z
z
z
z
z
z
z
Via:
[email protected]
Registrar
From: and To:
Call-ID:
¬ host-specific
Contact: (for future SIP
a
message transmission)
REGISTER sip:registrar.work.com
p g
SIP/2.0
/
Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123
¬*
Max-Forwards: 70
From: sip:[email protected]; tag = 123456
Content-Length:
To: sip:[email protected]
¬ Zero, no msg body
CSeq: 1 REGISTER
p
Contact: sip:[email protected]
CSeq:
Expires: 7200
Content-Length: 0
¬ A response to any
b
request must use the
SIP/2.0 200 OK
same value of CSeq
q as
From: sip:[email protected]; tag = 123456
i
lli
k
used in the request.
CSeq: 1 REGISTER
Expires:
Expires: 3600
Content-Length: 0
¬ TTL
¬ 0,
0 unreg
54
SIP & SDP
Cli t N
Client
New R
Registration
i t ti
(1/2)
SIP Server
[email protected]
Register F1
401 Unauthorized F2
John
register.com
user.com
REGISTER sip:register.com SIP/2.0
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP user.com:5060
From: John <sip:client@ register.com>
To: John <sip:client@ register.com>
register com>
CSeq: 1 REGISTER
CSeq: 1 REGISTER
Contact: John <sip:[email protected]>
WWW-Authenticate:
WWW
Authenticate: Digest realm
realm="MCI
MCI WorldCom SIP
SIP",
Contact: <sip:+886-3-1234567@user
<sip:[email protected];user=phone>
com;user=phone>
domain="wcom.com",
Contact: tel:+886-3-1234567
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
Content-Length: 0
stale=FALSE,
algorithm=MD5
Content-Length: 0
F1
F2
55
SIP & SDP
Cli t N
Client
New R
Registration
i t ti
(2/2)
[email protected]
li t@
John
Register F1
SIP Server
401 Unauthorized F2
REGISTER F3
200 OK F4
user.com
register com
register.com
REGISTER sip:register.com
sip:register com SIP/2
SIP/2.0
0
From: John <sip:client@ register.com >
SIP/2.0 200 OK
To: John <sip:client@ register.com >
Call ID: 123456789@user
Call-ID:
[email protected]
com
CSeq: 2 REGISTER
Contact: <sip:[email protected];user=phone>
CSeq: 2 REGISTER
Contact: tel:+886-3-1234567
Contact:WorldCom
John <sip:[email protected]>
Authorization:Digest username=“John", realm="MCI
SIP",
Contact:
<sip:[email protected];user=phone>
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
Contact: tel:+886-3-1234567
uri="sip:ss2.wcom.com",
Content-Length:0
Co
te t e gt 0
response="dfe56131d1958046689cd83306477ecc"
response=
dfe56131d1958046689cd83306477ecc
Content-Length: 0
F3
F4
56
SIP & SDP
U d t d Registration
Updated
R i t ti
((1/2)
/ )
[email protected]
SIP Server
Register F1 (2hours)
200 OK
REGISTER F2 ((clear all))
200 OK
saturn bell tel com
saturn.bell-tel.com
bell-tel.com
REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:[email protected]
CSeq:
q 1 REGISTER
Contact: <sip:[email protected]:3890;transport=udp>
Expires: 7200
F1
Via: SIP/2.0/UDP saturn.bell-tel.com
CSeq: 2 REGISTER
Contact: *
Expires: 0
57
F2
SIP & SDP
U d t d Registration
Updated
R i t ti
((2/2)
/ )
SIP S
Server
[email protected]
Register F1 (2hours)
200 OK
REGISTER F2 (clear all)
200 OK
Updated REGISTER F3 (register again,moved)
200 OK
saturn.bell-tel.com
saturn.bell
tel.com
[email protected]
bell-tel.com
t
[email protected]
t
@
l
pluto.bell-tel.com
Via: SIP/2
SIP/2.0/UDP
0/UDP saturn.bell-tel.com
saturn bell tel com
CSeq: 3 REGISTER
F3
58
Via: SIP/2.0/UDP pluto.bell-tel.com
p
@
CSeq: 1 REGISTER
p
@
p
F4
SIP & SDP
UA behavior
b h i ((1/3)
/ )

Caller issues initial INVITE Request
z
Request-URI: address of the callee
z
T
To:
address
dd
of
f th
the callee
ll
z
From: address of caller
z
contact: UAC MAY optionally add
Callee Issues Response
z
Callee can accept,
accept redirect or reject
z
Copy To, From, Call-ID, CSeq and Via from
request
z
If more than one “Via” header in request
add the tag to the “To” field.
59
SIP & SDP
UA behavior
b h i ((2/3)
/ )

C ll receives
Caller
i
Response
R
to initial
i i i l request
z
ACK(acknowledge) or BYE(terminate)
z To and From field: copy all from 200 response
z Request-URI: copy Contact header from 200
response
if no contact header: copy from To header

Caller or Callee generate subsequence
z
To: set the remote address
z From: set the local address
z Contact: MAY be different than the previous
command
z Request-URI: set Contact header received
previously
60
SIP & SDP
UA behavior
b h i ((3/3)
/ )

Receiving subsequent requests
z
Call-ID is new, the request is for a new call.
z
C ll ID exist:
Call-ID
i t
¬To, From, Call-ID and CSeq exactly match
q
retransmission Request
¬CSeq didn’t match
new transaction for an exiting call leg
61
SIP & SDP
I it ti
Invitation

A two-party call
z
z
z
z
z
Subject:
¬ optional
Content-Type:
¬ application/sdp
A dialog ID
¬ To
T id
identify
tif a peer-to-peer
t
relationship between two
user agents
¬ Tag in From
¬ Tag in To
¬ Call-ID
CSeq:
¬ # unchanged in the same
transaction
ACK: no response for it
62
SIP & SDP
T
Termination
i ti
off a Call
C ll

Cseq:
z
# Has changed
Daniel<sip:Collins@work com>
B
< i M
@ t ti 2
k
>
a
BYE sip:[email protected] SIP/2.0
Max-Forwards: 70
From: Daniel<sip:[email protected]>; tag=44551
T B
To:
Boss<sip:[email protected]>;
< i M
@ t ti 2
k
> tag=11222
t
11222
CSeq: 2 BYE
Content-Length: 0
b
SIP/2.0
SIP/2
0 200 OK
To: Boss<sip:[email protected]>; tag=11222
CSeq: 2 BYE
Content-Length:
g
0
63
SIP & SDP
CS Header
CSeq
H d (1/2)

A general-header
l h d fi
field
ld to each
h request.

CSeq = “CSeq” “:” 1*DIGIT SP Method
z

Consecutive requests: same Call-ID, diff.
Header..
Header
z

1*DIGIT : 32-bit unsigned integer
Monotonically increasing and contiguous
sequence number
Retransmissions of the same request carry the
same sequence number, but an INVITE with a
diff
different
t message body
b d or diff
differentt header
h d
fields (a “re-invitation”) acquires a new, higher
q
number.
sequence
64
SIP & SDP
CS Header
CSeq
H d (2/2)

A server MUST echo
h the
h CSeq
CS
value
l
from
f
request.
z
If server missing the CSeq header field, then
server fills it in appropriately.

ACK and CANCEL contain the same CSeq value
as the INVITE request.

BYE request with higher CSeq value.

User agent server
z
Remember the highest CSeq with the same Call-ID.
z Discard a lower CSeq value.

Parallel search: same CSeq value
65
SIP & SDP
UA to
t UA C
Call
ll Fl
Flow ((1/3)
/ )
Idle@tomorrow com
[email protected]
[email protected]
INVITE F1
Mary
100 Trying F2
John
180 Ringing F3
today.com
tomorrow.com
Via: SIP/2.0/UDP today.com:5060
From: John <sip:[email protected]>
To: Mary <sip:[email protected]>
CSeq: 1 INVITE
Content-Length: 147
SIP/2 0 100 T
SIP/2.0
Trying
i
CSeq: 1 INVITE
Content-Length: 0
F1
SIP/2.0 180 Ringing
CSeq: 1 INVITE
Content-Length:
g
0
v=0
0
o=John 2890844526 2890844526 IN IP4 today.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
66
F2
F3
SIP & SDP
UA to
t UA C
Call
ll Fl
Flow ((2/3)
/ )
INVITE F1
[email protected]
[email protected]
100 Trying F2
180 Ringing F3
Mary
200 OK F4
John
ACK F5
today.com
RTP Media
tomorrow.com
<sip:Idle@tomorrow com>
CSeq: 1 ACK
Content-Length: 0
F5
SIP/2.0 200 OK
CSeq: 1 INVITE
Contact: Mary <sip:[email protected]>
Content-Length: 147
F4
v=0
o=Mary 2890844527 2890844527 IN IP4 tomorrow.com
s=Session SDP
c=IN IP4 110.111.112.113
t=0 0
m=audio
di 3456 RTP/AVP 0
67
SIP & SDP
UA to
t UA C
Call
ll Fl
Flow ((3/3)
/ )
INVITE F1
[email protected]
[email protected]
100 Trying F2
180 Ringing F3
Mary
y
200 OK F4
John
ACK F5
today.com
RTP Media
tomorrow.com
BYE F6
200 OK F7
SIP/2.0 200 OK
Via: SIP/2.0/UDP tomorrow.com:5060
From: Mary <sip:[email protected]>
To: John <sip:[email protected]>
pj @
y
CSeq: 1 BYE
Content-Length: 0
F7
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP tomorrow.com:5060
From: Mary <sip:[email protected]>
To: John <sip:[email protected]>
CSeq: 1 BYE
Content-Length: 0
68
F6
SIP & SDP
OPTIONS Method
M th d

Determine the capabilities of a potential called
party

Accept Header
z

Allow Header
z

Indicate the type of information that the
sender hopes to receive
I di t th
Indicate
the SIP methods
th d th
that
t B
Boss can h
handle
dl
Supported Header
z
Indicate
di
the
h SIP extensions
i
that
h
can b
be
supported
69
SIP & SDP
OPTION Flow
Fl
D
i l i C lli @ t ti 1
k
a
B
i M
@ t ti 2
k
OPTIONS sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP Station1.work.com; branch=z9hG4bK7890123
From: Daniel<sip:[email protected]>; tag=lmnop123
To: Boss<sip:Manager@station2
work com>
Contact: Daniel<sip:[email protected]>
CSeq: 1 OPTIONS
Accept: application/sdp
Content-Length: 0
b SIP/2.0 200 OK
Via: SIP/2.0/UDP Station1.work.com; branch=z9hG4bK7890123
From: Daniel<sip:[email protected]>; tag=lmnop123
To: Boss<sip:[email protected]>; tag=xyz5678
Call-ID:
Call
ID: [email protected]
CSeq: 1 OPTIONS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Content-Length: 146
v=0
0
o=manager 45678 001 IN IP4 station2.work.com
s=
t=0 0
m=audio 0 RTP/AVP
/
4 15
a=rtpmap 15 G728/8000
70
SIP & SDP
Th Supported
The
S
t dH
Header
d

The Require Header
z
In request
¬A
A client
li t iindicates
di t that
th t a server mustt supportt
certain extension.
z In response
p
¬421, extension required

The Supported header
z
RFC 2543 – Require: header (client -> server)
¬420 (bad extension) – server -> client
z Can be included in both requests and responses
71
SIP & SDP
R
Require
i Header
H d

Client uses it to tell Server about options.

If Server not understand the option, MUST
return 420(Bad Extension) and list those
options in the Unsupported header.

Example:
CÎS
INVITE sip:[email protected]
sip:watson@bell-telephone com SIP/2
SIP/2.0
0
Require: com.example.billing
Payment: sheep_skins, conch_shells
SÎC
SIP/2.0 420 Bad Extension
U
Unsupported:
t d com.example.billing
l billi
72
SIP & SDP
R di
Redirect
tS
Servers

An alternative
address
z
302, M
302
Moved
d
temporarily
z
Contact header
Another INVITE
z
Same Call-ID,
,
z
Same To
z
CSeq ++
p
a
b
c
d
Redirect ServerBoss<sip:[email protected]>
Boss<sip:Manager@pc1 home net>
M
Max-Forwards:
F
d 70
CSeq: 1 INVITE
Subject: Vacation
Content-Length: xxx
(
(message
b
body)
d )
SIP/2.0 302 Moved Temporarily
Via:SIP/2.0/UDP station1.work.com;branch=z9hG4bK123
To: Boss<sip:[email protected]>; tag=11222
CSeq: 1 INVITE
sip:Manager@pc1 home net
Max-Forwards: 70
CSeq: 1 ACK
Max-Forwards: 70
CSeq:
q 2 INVITE
Subject: Vacation
Content-Length: xxx
(message body)
73
SIP & SDP
P
Proxy
S
Servers

Numerous proxies
N
i can reside
id in
i a chain
h i
between caller & callee.

Th llastt proxy may change
The
h g the
th R
Request-URI.
t URI

Via:
z
Record
R
d th
the path
th t
taken
k
b
by a request
t
z Loop detected, 482 (status code)
z For a response
p
¬The 1st Via: header, Checked, and Removed
z Branch: used to distinguish between multiple
responses to the same request
¬Forking Proxy: Issue a single request to multiple
destinations
74
SIP & SDP
P
Proxy
C
Call
ll Fl
Flow ((1/2)
/ )
75
SIP & SDP
P
Proxy
C
Call
ll Fl
Flow ((2/2)
/ )
sip:Server.work.com
e
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890
Record-coute: <sip:server.work.com;lr>
F
From:
B
Boss<sip:[email protected]>;
< i M
@h
t> ttag=ab12
b12
To: Daniel<sip:[email protected]>; tag=xyz45
CSeq: 1 INVITE
f
g
ACK sip:[email protected]
i
lli
i
k
SIP/2.0
/
Max-Forwards: 70
Route: <sip:server.work.com;lr>
From: Boss<sip:[email protected]>; tag=ab12
@p
CSeq: 1 ACK
Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz2
Via: SIP/2
SIP/2.0/UDP
0/UDP pc1
pc1.home.net;
home net; branch=z9hG4bK7891
Max-Forwards: 69
From: Boss<sip:[email protected]>; tag=ab12
CSeq: 1 ACK
76
SIP & SDP
L
Loop
detect
d t t
UA1
Request message
Proxy1
482 Loop detect
Proxy4
loop detect
Proxy2
Proxy3
77
SIP & SDP
S i l
Spiral
ua2@proxy1;transport=tcp
@
Æ ua2@prxoy2;transport=tcp
@
ua2@proxy1 Æ ua2@prxoy2
Proxy1
y
UA2
ua2@proxy4;transport=tcp Æ
ua2@useragent2;transport=tcp
Request message
UA1
Proxy2
Proxy4
ua2@proxy4 Æ
ua2@prxoy1;transport=tcp
spiral
ua2@proxy2;transport=tcp Æ
ua2@prxoy3;transport=tcp
Proxy3
ua2@proxy3;transport=tcp Æ ua2@prxoy4;transport=tcp
78
SIP & SDP
2 Kinds
Ki d off Proxy
P
Servers
S

A logic role for SIP environment

Stateless Proxy

z
Act as a simple forwarding element.
z
Forward each request downstream to a single
element base on the request
request.
z
Forward every response upstream.
Stateful Proxy
z
It is a SIP transaction processing engine.
z
May fork a request and route it to multiple
destinations.
79
SIP & SDP
St t f l P
Stateful
Proxy B
Behavior
h i

F all
For
ll new request
A.Validate the request
¬ Reasonable
easo ab e sy
syntax
ta
¬ Max-Forwards
¬ Loop detection
¬ Proxy-Require
Proxy Require
¬ Proxy-Authorization
B.Make a routing decision
C.Forward the request to
each chosen destination
D.Request Processing
1. Make a copy of the
received request
2. Update the Request-URI
3. Add a Via header
80
4. Update the Max-Forwards,
Route headers
5. Optionally add Recordroute or additional
headers
6 Send
6.
S d new request
E.Process all responses
1. Find the appropriate
pp p
response context
2. Remove the topmost Via
3 Add the response to the
3.
response context
4. Check to see if this
response should
h ld b
be
forward
SIP & SDP
P
Proxy
St
State
t

C
Can
be
b either
i h stateless
l
or stateful
f l

Record-Route:
z
z
z
z
z
z
Two consecutive requests may not pass through
the same proxy
¬Use Contact:
A Proxy might require that it remains in the
signaling path
¬In particular,
particular for a stateful proxy
Insert its address into the Record-Route
The response includes the Record-Route
The info in the Record-Route is used in
subsequent requests related to the same call.
The Route = the Record-Route
Record Route in reverse order
81
SIP & SDP
R t H
Route
Header
d

Determine the request route.

Each host removes the first entry
z
Entry: Use it as Request-URI.
z
Proxy the request to the host.
82
SIP & SDP
R
Record-Route
dR t H
Header
d

Each proxy server adds its SIP-URI to the
beginning of the list.

UAS copies the Record-Route header field
unchanged into the response.

UAC copies the Record-Route header into a
Route header field of subsequent requests
within
ithi the
th same call
ll leg,
l g reversing
i g the
th order.
d

If the request featured a Contact header,
appended
d d to
t the
th R
Route
t H
Header
d li
list.
t
83
SIP & SDP
F ki
Forking
Proxy
P

“fork” requests

A user is registered at several locations
z

;branch=xxx
In order to handle such forking,
g ap
proxy
y must
be stateful.
84
SIP & SDP
F ki
Forking
Proxy
P
Flow
Fl
((1/2)
/ )
85
SIP & SDP
F ki
Forking
Proxy
P
Flow
Fl
((2/2)
/ )
86
SIP & SDP
R t
Retransmit
it R
Requestt
get request
not found
Compare
p
Call-ID
New Request
found
not match
Compare To
(tag values)
match
t h
Compare From
(tag values)
not match
match
more
Compare
CSeq
q
less or equal
Retransmitting Request
87
SIP & SDP
R
Response
B
Behavior
h i

Before final response
z
one or more provisional responses
z
no final
fi l within
ithi 200 ms: sent
t provisional
i i
l
response

100 response SHOULD NOT be forwarded

32 seconds - maximum retransmission duration
z
After received
Aft
i d th
the fi
first
t d
definitive
fi iti
non-200
200
response, in order to handle retransmissions of
the response.
88
SIP & SDP
SIP using
i
TCP

A TCP connection
ti
servers one or more transactions.
t
ti
z (1 request + *provisional response + 1*final
response)

Client keep the connection open until first final
response.
z No keep connection: server treat as a CANCEL
CANCEL.

Server should not close connection until sent final
response.
z Server MAY close connection.
z Normally, it is client’s duty to close
connection.

TCP Must NOT retransmit requests, but uses the same
algorithm as for UDP.
89
SIP & SDP
Reliability
(BYE, CANCEL, OPTIONS, REGISTER Requests)

TCP: using TCP do not need retransmission.

UDP:
z
default: T1=500ms, T2=4 seconds
retransmitting 4*T1 interval
Starting
g at a T1 interval
retransmitting T2 interval
(when n*T1 > T2)
T1
2*T1
T2
4*T1
T2
…….
90
SIP & SDP
T
Transaction
ti
R
Relationships
l ti
hi
Request
Request
Request
Response
Response
Response
UAC
Client Tx
Outbound
Proxy
Inbound
Proxy
UAS
Server Tx
91
SIP & SDP
State Transition for INVITE
M h d (RFC
Method
(RFC2543))
Initial
n
T1 * 2
INVITE
Initial
INVITE
Calling
failure
>=300
1xx
-
status
ACK
Call
Proceeding
INVITE
1xx
7 INVITE sent
CANCEL/BYE
1xx
1
-
status
ACK
Proceeding
Status change
1xx
Callee picks up
2xx
Min(T1*2n,T2)
status
INVITE
status
Success
INVITE
2xx
ACK
-
Completed
status
ACK
INVITE
1xx
CANCEL/BYE
487
Fail re
Failure
event
request sent
ACK
92
C
Completed
l t d
SIP & SDP
State Transition for
BYE,CANCEL/OPTIONS/REGISTER
,
/
/
Methods (client) (RFC2543)
Initial
n
Min(T1 * 2 , T2)or n * T2
REQUEST
REQUEST
event
request sent
Calling
1xx
status
-
n * T2
Request
1xx
-
Call
Proceeding
Status
-
11 REQUEST sent
Completed
status
t t
93
SIP & SDP
State Transition For
BYE,CANCEL/OPTIONS/REGISTER
,
/
/
methods (server) (RFC2543)
Initial
request
1xx
failure
>=300
request
status
request
1xx
Proceeding
Event
Message sent
Status
St
t change
h
1xx
success
2xx
terminated
487
Failure
Success
request
2xx
10 * T2
Confirmed
32s
-
32s
-
32s
-
Completed
94
SIP & SDP
INVITE Client
Cli t T
Transaction
ti
Timer A fires
Reset A,
INVITE sent
INVITE from
f
TU
INVITE sent
Calling
1xx
1xx to TU
1xx
1xx to TU
300 ~ 699
ACK sentt
resp. to TU
P
Proceeding
di
300 – 699
ACK SENT,
resp. To
T TU
300 – 699
ACK SENT
Timer B fires
or Transport Err.
Inform TU
Completed
2xx
2xx to TU
2xx
2xx to TU
Transport Err.
I f
Inform
TU
Timer D fires
-
Terminated
95
SIP & SDP
INVITE Server
S
T
Transaction
ti
INVITE
pass INV to TU
send 100 if TU won’t in 200ms
INVITE
send response
Timer G fires
send response
101 ~ 199 from TU
send response
Proceeding
2xx from TU
300 ~ 699 from TU
send response
Completed
INVITE
send response
Transport
p Err.
Inform TU
p
send response
Timer H fires
or Transport Err.
Err
Inform TU
ACK
-
Confirmed
Timer I fires
-
Transportt Err.
T
E
Inform TU
Terminated
96
SIP & SDP
O tli
Outline

Introduction

SIP Message Format

SIP Communication

SIP Extensions
97
SIP & SDP
SIP Extensions
E t
i
Method
Extension
Header
INFO
REFER
Refer-To
Referred-By
Original
Description
RFC 2976
Carry control information of a session
Draft-ietf-sip-cctransfer-05
provide Call Transfer capabilities
SUBSCRIBE Event
Allow-Event
NOTIFY
Draft roach sip
Draft-roach-sipAsynchronous request notification of
subscribe-notify-03 events. Notify SIP events which has
been requested by an earlier
SUBSCRIBE method.
PRACK
draft-ietf-sip100rel-04.txt -
Achieve reliability and in order for
provisional responses.
draft-ietf-sipmanyfolksresource-02
The COMET method is used for
communicating successful completion
of preconditions between the user
agents.
RAck
Rcseq
COMET
UPDATE, MESSAGE, ...
98
SIP & SDP
SIP INFO Method
M th d

Specified in RFC 2976
z
For transferring information during an ongoing
session
¬DTMF digits, account-balance information, mid-call
signaling information (from PSTN)
¬Application-layer information could be transferred
in the middle of a call.

A powerful, flexible tool to support new services
z
The transfer of DTMF digits
z
Th t
The
transfer
f
of
f account
t b
balance
l
i
information
f
ti
¬Pre-paid service
z The transfer of mid-call
mid call signaling information
99
SIP & SDP
SIP Event
E
tN
Notification
tifi ti

Several SIP-based
applications have
Subscriber
been devised based on
the concept of a user
a SUBSCRIBE
being
g informed of
b
some event.
z

E.g., Instant messaging
RFC 3265 has
addressed the issue of
event notification.
c
Notifier
200 OK
NOTIFY
Current state
information
NOTIFY
Updated state
information
d 200 OK
e
f
200 OK
z
SUBSCRIBE and NOTIFY
z The Event header
100
SIP & SDP
SIP Presence
P
(1/3)
( / )

A asks to be told when B registers
Registrar,
Presence Server,
101
SIP & SDP
SIP Presence
P
(2/3)
( / )

NOTIFY A that B has <Not Signed In>
Registrar,
Presence Server,
102
SIP & SDP
SIP Presence
P
(3/3)
( / )

NOTIFY A that B has <Signed In>
Registrar,
Presence Server,
103
SIP & SDP
SIP MESSAGE Method
M th d

The IETF working group – SIP for Instant
Messaging and Presence Leveraging Extensions
(SIMPLE)

A new SIP method – MESSAGE
z
This request
Thi
t carries
i
th
the actual
t l message i
in a
message body.
z
A MESSAGE request
q
does not establish a SIP
dialog.
104
SIP & SDP
I t tM
Instant
Messaging
i
((1/2)
/ )
a
b
sip:Server.work.com
MESSAGE sip:[email protected]
i C lli @
k
SIP/2.0
SIP/2 0
Max-Forwards: 70
From: Boss<sip:[email protected]>
To: Daniel<sip:[email protected]>
@p
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 19
Content-Disposition: render
Hello How are you?
Hello.
MESSAGE sip:[email protected] SIP/2.0
Max-Forwards: 69
p
g @
CSeq: 1 MESSAGE
Content-Length: 19
Content Disposition: render
Content-Disposition:
Hello. How are you?
c
d
SIP/2.0 200 OK
CSeq: 1 MESSAGE
Content-Length:
Content
Length: 0
SIP/2.0 200 OK
Vi SIP/2
Via:
SIP/2.0/UDP
0/UDP pc1.home.net;
1h
t b
branch=z9hG4bK7890
h 9hG4bK7890
CSeq: 1 MESSAGE
Content-Length:
g
0
105
SIP & SDP
I t tM
Instant
Messaging
i
((2/2)
/ )
e
f
sip:Server.work.com
MESSAGE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKabcd
Max-Forwards: 69
p
@
From: Daniel<sip:[email protected]>
CSeq: 1101 MESSAGE
Content-Length: 22
Content Disposition: render
I’m fine. How are you?
g
h SIP/2.0 200 OK
Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKabcd
Vi SIP/2
Via:
SIP/2.0/UDP
0/UDP station1.work.com;
t ti 1
k
b
branch=z9hG4bK123
h 9hG4bK123
CSeq: 1101 MESSAGE
Content-Length:
g
0
MESSAGE sip:[email protected]
i M
@h
t SIP/2
SIP/2.0
0
Max-Forwards: 70
@
CSeq: 1101 MESSAGE
Content-Length: 22
Content-Disposition: render
II’m
m fine.
fine How are you?
SIP/2.0 200 OK
CSeq: 1101 MESSAGE
Content-Length:
Content
Length: 0
106
SIP & SDP
U
Usage
off SIP for
f F
Features
t

C ll
Call-transfer
f application
li i (with
( i h REFER method)
h d)

Personal mobility through the use of registration

One number service through forking proxy

Call-completion services by using Retry-After: header

To carry MIME content as well as an SDP description

SIP address is a URL
z

Existing
g supplementary
pp
y services in traditional PSTN
z

Click-to-call applications
Call waiting/ forwarding/ screening , multi-party calling
Proxy
y invokes various types
yp of advanced feature logic.
g
Policy server (call-routing, QoS)
Telecom Service
Integration for ITS
107
z Authentication
server
U th
i
f
IN SCP
z
SIP & SDP
INAP
SIP REFER Method
M th d

To enable the sender of the request to instruct
the receiver to contact a third party
z
With the contact details for the third party included
within the REFER request
z For Call Transfer applications

The Refer-to: and Refer-by: Headers

The dialog between Mary and Joe remains
established.
z
Joe could return to the dialog after consultation
with Susan.
108
SIP & SDP
C ll T
Call
Transfer
f ((1/2)
/ )
i M
@ t ti 1
k
a
i J @ t ti 2
k
i S
@ t ti 3
k
REFER sip:[email protected] SIP/2.0
Max-Forwards: 70
From: Mary<sip:[email protected]>; tag=123456
To: Joe<sip:[email protected]>; tag=67890
Contact: Mary<[email protected]>
Mary<Mary@station1 work com>
Refer-To: Sussan<sip:[email protected]>
CSeq: 123 REFER
Content-Length: 0
b
SIP/2.0 Accepted
c
Contact: Joe<[email protected]>
CS
CSeq:
123 REFER
Content-Length: 0
Invite sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1
Max-Forwards: 70
From: Joe<sip:[email protected]>; tag=abcxyz
To: Susan<sip:[email protected]>
CSeq: 567 INVITE
Content-Length: xx
Content
Disposition: session
{message body}
109
SIP & SDP
C ll T
Call
Transfer
f ((2/2)
/ )
sip:Mary@station1 work com
sip:Joe@station2 work com
e
f
g NOTIFY sip:[email protected] SIP/2.0
Max-Forwards: 70
From: Mary<sip:[email protected]>; tag
tag=123456
123456
CSeq: 124 NOTIFY
Content-Type: message/sipfrag;version=2.0
Content-Length: 15
h
sip:Susan@station3 work com
SIP/2.0 200 OK
To: Susan<sip:[email protected]>;
p
; tag=123xyz
g
y
CSeq: 567 INVITE
Content-Length: xx
{message body}
Max-Forwards: 70
To: Susan<sip:[email protected]>;
p
@
; tag=123xyz
g
y
CSeq: 567 ACK
Content-Length: 0
SIP/2.0 200 OK
Call-ID:
Call
ID: [email protected]
CSeq: 124 NOTIFY
Content-Length: 0
110
SIP & SDP
M lti
Multi-registration
i t ti
Example
E
l

“One number” service
111
SIP & SDP
U i
Using
R
Retry-After
t Aft H
Header
d
112
SIP & SDP
C ll F
Call
Forwarding
di

On busy

486, busy here

With the same To, User 3
can recognize that this
call is a forwarded call,
originally sent to User 2.

Contact: header in 200
response

Call-forwarding-on-noanswer
z
Timeout
z CANCEL method
113
SIP & SDP
C
Consultation
lt ti
H
Hold
ld

A SIP UPDATE

User A asks User B a
question, and User B
need to check with
User C for the correct
answer.

User B could
U
ld use the
th
REFER method to
transfer the call to
User C.
114
SIP & SDP
PSTN Interworking
I t
ki

PSTN Interworking
z
A SIP URL to a
telephone number
z A network gateway

PSTN – SIP – PSTN
z
MIME media types
z For ISUP

SIP for Telephony (SIP-T)
(SIP T)

The whole issue of
interworking
g with SS7 is
fundamental to the
success of VoIP in the
real world.
world
115
SIP & SDP
SIP Related
R l t d St
Standards
d d
RFC 2543 - SIP, March 1999
RFC3261- SIP Protocol, June 2002
RFC 2616 – HTTP/1.1, June 1999
RFC 3372 – (SIP-T),
(SIP-T) Sep 2002
RFC 2617 – HTTP Authentication, June 1999
RFC 3361 – DHCP-for-IPv4, Aug 2002
RFC 2327 – SDP, April 1998
RFC 3351 – User Requirements for the
Session Initiation Protocol (SIP) in
Support of Deaf, Hard of Hearing and
Speech-impaired Individuals , June 2002
RFC 2976 – SIP INFO Method, Oct. 2000
RFC 2396 – SIP URL, Aug. 1998
RFC 3262 – Reliability of Provisional Responses in SIP , June 2002
RFC 3263 – SIP: Locating SIP Servers , June 2002
RFC 3311 – UPDATE Method, Oct 2002
RFC 3264 – An Offer/Answer Model with SDP, June 2002
RFC 3265 – SIP-Specific Event Notification, June 2002
RFC 3312 – Integration of Resource
Management and SIP, Oct 2002
Related Internet drafts (Call Flow, Supplementary service …)
116
SIP & SDP
N
New
RFCs
RFC P
Published
bli h d

RFC 3319 - DHCPv6 for SIP
z

RFC 3603 - Proxy-to-proxy
P
t
extensions
t
i
for
f
PacketCable
RFC 3485/3486 - SIP and SDP compression
z

automatic outbound proxy configuration
compress SIP headers and body via dynamic
dictionary
y
RFC 3665/3666 - Call flows
z
explain
p
behavior by
y example
p
z
useful for testing common cases
z
not a spec replacement
117
SIP & SDP
Any
yQ
Question?
Mobile All-IP Networking Laboratory
Department of Computer Science & Information Engineering