The Session Description Protocol
The Most Common Message Body
Be session information describing the media to be
exchanged between the parties
SDP, RFC 2327 (initial publication)
SIP uses SDP in an answer/offer mode.
An agreement between the two parties as to the
types of media they are willing to share
RFC 3264 (An Offer/Answer Model with SDP)
To describe how SDP and SIP should be used together
Internet Telephony 1
The Structure of SDP
SDP simply provides a format for describing
session information to potential session
participants.
Text-based Protocol
The Structure of SDP
Session Level Info
Name of the session
Originator of the session
Time that the session is to be active
Media Level Info
Media type
Port number
Transport protocol
Media format
Internet Telephony 2
SDP Syntax
A number of lines of text
In each line
field=value
field is exactly one character (case-significant)
Session-level fields
Media-level fields
Begin with media description field (m=)
Internet Telephony 3
Mandatory Fields
v=(protocol version)
o=(session origin or creator)
s=(session name), a text string
For multicast conference
t=(time of the session), the start time and stop time
For pre-arranged multicast conference
m=(media)
Media type
The transport port
The transport protocol
The media format, an RTP payload format
Internet Telephony 4
Optional Fields [1/3]
Some optional fields can be applied at both
session and media levels.
The value applied at the media level overrides that at the
session level
i=(session information)
A text description
At both session and media levels
It would be somewhat superfluous, since SIP already
supports the Subject header.
u=(URI of description)
Where further session information can be obtained
Only at session level
Internet Telephony 5
Optional Fields [2/3]
e=(e-mail address)
Who is responsible for the session
Only at the session level
p=(phone number)
Only at the session level
c=(connection information)
Network type, address type and connection address
At session or media level
b=(bandwidth information)
In kilobits per second
At session or media level
Internet Telephony 6
Optional Fields [3/3]
r=(repeat times)
For regularly scheduled session a session is to be repeated
How often and how many times
z=(timezone adjustments)
For regularly scheduled session
Standard time and daylight savings time
k=(encryption key)
An encryption key or a mechanism to obtain it for the
purposes of encrypting and decrypting the media
At session or media level
a=(attributes)
Describe additional attributes
Internet Telephony 7
Ordering of Fields
Session Level Media level
Protocol version (v) Media description (m)
Origin (o) Media info (i)
Session name (s) Connection info (c)
Session information (i) Optional if specified at the
session level
URI (u)
Bandwidth info (b)
E-mail address (e)
Encryption key (k)
Phone number (p)
Attributes (a)
Connection info (c)
Bandwidth info (b)
Time description (t)
Repeat info (r)
Time zone adjustments (z)
Encryption key (k)
Attributes (a)
Internet Telephony 8
Subfields [1/3]
Field = <value of subfield1> <value of subfield2>
<value of subfield3>.
Origin
Username, the originator’s login id or “-”
session ID
A unique ID
Make use of NTP timestamp
version, a version number for this particular session
network type
A text string
IN refers to Internet
address type
IP4, IP6
address, a fully-qualified domain name or the IP address
Internet Telephony 9
Subfields [2/3]
Connection Data
The network and address at which media data will be
received
Network type
Address type
Connection address
Media Information
Media type
Audio, video, data, or control
Port
Format
List the various types of media format that can be supported
According to the RTP audio/video profile
m= audio 45678 RTP/AVP 15 3 0
G.728, GSM, G.711
Internet Telephony 10
Subfields [3/3]
Attributes
To enable additional information to be included
Property attribute
a=sendonly
a=recvonly
value attribute
a=orient:landscape used in a shared whiteboard session
rtpmap attribute
The use of dynamic payload type
a=rtpmap:<payload type> <encoding name>/<clock rate>
[/<encoding parameters>].
m=video 54678 RTP/AVP 98
a=rtpmap 98 L16/16000/2
16-bit linear encoded stereo (2 channels) audio sampled
at 16kHz
Internet Telephony 11
Usage of SDP with 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.
The entity headers identifies the message body.
Internet Telephony 12
SIP Inclusion in SIP Messages
Fig 5-15
G.728 is selected
INVITE with multiple media streams
Unsupported should also be returned with a port number of
zero
An alternative
INVITE
m=audio 4444 RTP/AVP 2 4 15
a=rtpmap 2 G726-32/8000
a=rtpmap 4 G723/8000
a=rtpmap 15 G728/8000
CONNECT
m=audio 6666 RTP/AVP 15
a=rtpmap 15 G728/8000
Internet Telephony 13
SIP and SDP Offer/Answer Model
Re-INVITE is issued when the server replies with more
than one codec.
With the same dialog identifier (To and From headers, including
tag values), Call-ID and Request-URI
The session version is increased by 1 in o= line of message body.
A mismatch
488 or 606
Not Acceptable
A Warning header with warning code 304 (media type not
available) or 305 (incompatible media type)
Then the caller issues a new INVITE request.
Internet Telephony 16
OPTIONS Method
Determine the capabilities of a potential called
party
Accept Header
Indicate the type of information that the sender hopes to
receive
Allow Header
Indicate the SIP methods that Boss can handle
Supported Header
Indicate the SIP extensions that can be supported
Internet Telephony 19
SIP Extensions and Enhancements
RFC 2543, March 1999
SIP has attracted enormous interest.
Traditional telecommunications companies, cable
TV providers and ISP
A large number of extensions to SIP have
been proposed.
SIP will be enhanced considerably before it
becomes an Internet standard.
Internet Telephony 21
183 Session Progress
It has been included within the revised SIP
spec.
To open one-way audio path from called end to
calling end
From the called party to calling party
Enable in-band call progress information to be transmitted
Tones or announcements
Interworking with SS7 network
ACM (Address Complete Message)
For SIP-PSTN-SIP connections
Internet Telephony 22
The Supported Header
The Require Header
In request
A client indicates that a server must support certain
extension.
In response
421, extension required
The Supported header
RFC 2543 – Require: header (client -> server)
420 (bad extension) – server -> client
Can be included in both requests and responses
Internet Telephony 23
SIP INFO Method
Be specified in RFC 2976
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
Internet Telephony 24
SIP Event Notification
Several SIP-based
applications have been
devised based on the concept
of a user being informed of
some event.
E.g., Instant messaging
RFC 3265 has addressed the
issue of event notification.
SUBSCRIBE and NOTIFY
The Event header
Internet Telephony 25
SIP for Instant Messaging
The IETF working group – SIP for Instant
Messaging and Presence Leveraging Extensions
(SIMPLE)
A new SIP method – MESSAGE
This request carries the actual message in a
message body.
A MESSAGE request does not establish a SIP dialog.
Internet Telephony 26
SIP REFER Method
To enable the sender of the request to instruct the
receiver to contact a third party
With the contact details for the third party included within the REFER
request
For Call Transfer applications
The Refer-to: and Refer-by: Headers
The dialog between Mary and Joe remains established.
Joe could return to the dialog after consultation with Susan.
Internet Telephony 29
Reliability of Provisional Responses
Provisional Responses
100 (trying), 180 (ringing), 183 (session in progress)
Are not answered with an ACK
If the messages is sent over UDP
Unreliable
Lost provisional response may cause problems when
interoperating with other network
180, 183 → Q931 alerting or ISUP ACM
To drive a state machine
E.g., a call to an unassigned number
ACM to create a one-way path to relay an announcement such as
“The number you have called has been changed”
If the provisional response is lost, the called might left in the dark
and not understand why the call did not connect.
Internet Telephony 32
RFC 3262
Reliability of Provisional
Responses in SIP
Supported: 100rel
RSeq Header
Response Seq
+1, when retxm
RAck Header
Response ACK
In PRACK
RSeq+CSeq
PRACK
Prov. Resp. ACK
Should not
Apply to 100
Default timer value = 0.5 s
The SIP UPDATE Method
To enable the modification of session
information before a final response to an
INVITE is received
E.g., to change the codec
One important usage is when reserving
network resources as part of a SIP session
establishment
Internet Telephony 35
Integration of SIP Signaling and Resource
Management [1/2]
Ensuring that sufficient resources are available to handle a
media stream is a very important.
To provide a high-quality service for a carrier-grade network
The signaling might take a different path from the media.
The successful transfer of signaling messages does not
imply to a successful transfer of media.
Assume resource-reservation mechanisms are available
(Chapter 8)
On a per-session basis
End-to-end network resources are reserved as part of session
establishment.
On an aggregate basis
A certain amount of network resources are reserved in advance
for a certain type of usage.
Policing functions at the edge of the network
Internet Telephony 36
Integration of SIP Signaling and Resource
Management [2/2]
Reserving network
resources in advance of
altering the called user
A new draft –
“Integration of Resource
Management and SIP”
By using the provisional
responses and UPDATE
method
By involving extensions to
SDP
Example of e2e Resource Reservation [1/2]
SDP for initial INVITE
v=0
o=userA 45678 001 IN IP4 stationA.network.com
s=
c=IN IP4 stationA.nework.com
t=0 0
m=audio 4444 RTP/AVP 0
a=curr: qos e2e none
a=des: qos mandatory e2e sendrecv
SDP for 183 response
v=0
o=userB 12345 001 IN IP4 stationB.network.com
s=
c=IN IP4 stationB.nework.com
t=0 0
m=audio 6666 RTP/AVP 0
a=curr: qos e2e none
a=des: qos mandatory e2e sendrecv
a=conf: qos e2e recv
Internet Telephony 38
Example of e2e Resource Reservation [2/2]
SDP for UPDATE
v=0
o=userA 45678 001 IN IP4 stationA.network.com
s=
c=IN IP4 stationA.nework.com
t=0 0
m=audio 4444 RTP/AVP 0
a=curr: qos e2e send
a=des: qos mandatory e2e sendrecv
SDP for 200 response
v=0
o=userB 12345 001 IN IP4 stationB.network.com
s=
c=IN IP4 stationB.nework.com
t=0 0
m=audio 6666 RTP/AVP 0
a=curr: qos e2e sendrecv
a=des: qos mandatory e2e sendrecv
Internet Telephony 39
Example of Aggregate-
based Reservation
Each participant deals with
network access permission at
its own end.
Usage of SIP for Features/Services
Call-transfer application (with REFER method)
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
Click-to-call applications
The existing supplementary services in traditional
telephony
Call waiting, call forwarding, multi-party calling, call screening
Proxy invokes various types of advanced feature logic.
Policy server (call-routing, QoS)
Authentication server
Use the services of an IN SCP over INAP
Internet Telephony 41
Call Forwarding
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-no-
answer
Timeout
CANCEL method
Consultation Hold
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 use the
REFER method to
transfer the call to User
C.
PSTN Interworking
PSTN Interworking
A SIP URL to a telephone
number
A network gateway
PSTN – SIP – PSTN
MIME media types
For ISUP
SIP for Telephony (SIP-T)
The whole issue of
interworking with SS7 is
fundamental to the success of
VoIP in the real world.
Interworking with H.323
SIP-H.323 interworking gateway
Internet Telephony 45
Summary
The future for signaling in VoIP networks
Simple, yet flexible
Easier to implement
Fit well with the media gateway control protocols
SIP is the protocol of choice for the evolution
of third-generation wireless networks.
SIP-based mobile devices will become available
SIP-based network elements will be introduced
within mobile networks.
Internet Telephony 49
