0% found this document useful (0 votes)
26 views

Chap5 PartII

The document discusses the Session Description Protocol (SDP), which provides a format for describing multimedia sessions to enable the exchange of multimedia content between endpoints. It describes SDP syntax, fields, and usage with the Session Initiation Protocol (SIP) for multimedia session negotiation.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views

Chap5 PartII

The document discusses the Session Description Protocol (SDP), which provides a format for describing multimedia sessions to enable the exchange of multimedia content between endpoints. It describes SDP syntax, fields, and usage with the Session Initiation Protocol (SIP) for multimedia session negotiation.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 49

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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy