draft-ietf-mmusic-sdp-cs-04.txt   draft-ietf-mmusic-sdp-cs-05.txt 
MMUSIC WG M. Garcia-Martin MMUSIC WG M. Garcia-Martin
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track S. Veikkolainen Intended status: Standards Track S. Veikkolainen
Expires: February 23, 2011 Nokia Expires: April 11, 2011 Nokia
August 22, 2010 October 08, 2010
Session Description Protocol (SDP) Extension For Setting Up Audio and Session Description Protocol (SDP) Extension For Setting Up Audio and
Video Media Streams Over Circuit-Switched Bearers In The Public Video Media Streams Over Circuit-Switched Bearers In The Public
Switched Telephone Network (PSTN) Switched Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-04 draft-ietf-mmusic-sdp-cs-05
Abstract Abstract
This memo describes use cases, requirements, and protocol extensions This memo describes use cases, requirements, and protocol extensions
for using the Session Description Protocol (SDP) Offer/Answer model for using the Session Description Protocol (SDP) Offer/Answer model
for establishing audio and video media streams over circuit-switched for establishing audio and video media streams over circuit-switched
bearers in the Public Switched Telephone Network (PSTN). bearers in the Public Switched Telephone Network (PSTN).
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 23, 2011. This Internet-Draft will expire on April 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 31 skipping to change at page 3, line 31
5.2.3.3. User-User Information Element Correlation 5.2.3.3. User-User Information Element Correlation
Mechanism . . . . . . . . . . . . . . . . . . . . 12 Mechanism . . . . . . . . . . . . . . . . . . . . 12
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 13 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 13
5.2.3.5. Negotiating the used correlation mechanisms . . . 15 5.2.3.5. Negotiating the used correlation mechanisms . . . 15
5.3. Considerations for Usage of Existing SDP . . . . . . . . . 17 5.3. Considerations for Usage of Existing SDP . . . . . . . . . 17
5.3.1. Originator of the Session . . . . . . . . . . . . . . 17 5.3.1. Originator of the Session . . . . . . . . . . . . . . 17
5.3.2. Contact information . . . . . . . . . . . . . . . . . 17 5.3.2. Contact information . . . . . . . . . . . . . . . . . 17
5.3.3. Determining the Direction of the Circuit-Switched 5.3.3. Determining the Direction of the Circuit-Switched
Connection Setup . . . . . . . . . . . . . . . . . . . 17 Connection Setup . . . . . . . . . . . . . . . . . . . 17
5.4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 18
6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Basic SDP example: Single Circuit-Switched Audio Stream . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. Registration of new correlation SDP attribute . . . . . . 21 7.1. Registration of new correlation SDP attribute . . . . . . 21
7.2. Registration of a new "nettype" value . . . . . . . . . . 21 7.2. Registration of a new "nettype" value . . . . . . . . . . 21
7.3. Registration of new "addrtype" values . . . . . . . . . . 21 7.3. Registration of new "addrtype" values . . . . . . . . . . 21
7.4. Registration of a new "proto" value . . . . . . . . . . . 21 7.4. Registration of a new "proto" value . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
skipping to change at page 5, line 4 skipping to change at page 5, line 4
setting up a circuit-switched call offers also the possibility of setting up a circuit-switched call offers also the possibility of
negotiating in the same session other IP based media that is not negotiating in the same session other IP based media that is not
sensitive to jitter and delay, for example, text messaging or sensitive to jitter and delay, for example, text messaging or
presence information. presence information.
At a later point in time the mobile device might move to an area At a later point in time the mobile device might move to an area
where a high-bandwidth packet-switched bearer, for example a Wireless where a high-bandwidth packet-switched bearer, for example a Wireless
Local Area Network (WLAN) connection, is available. At this point Local Area Network (WLAN) connection, is available. At this point
the mobile device may perform a handover and move the audio or video the mobile device may perform a handover and move the audio or video
media streams over to the high-speed bearer. This implies a new media streams over to the high-speed bearer. This implies a new
exchange of SDP offer/answer that lead to a re-negotiation of the exchange of SDP Offer/Answer that lead to a re-negotiation of the
media streams. media streams.
Other use cases exists. For example, and endpoint might have at its Other use cases exist. For example, and endpoint might have at its
disposal circuit-switch and packet-switched connectivity, but the disposal circuit-switch and packet-switched connectivity, but the
audio or video codecs are not the same in both access networks. audio or video codecs are not the same in both access networks.
Consider that the circuit-switched audio or video stream supports Consider that the circuit-switched audio or video stream supports
narrow-bandwidth codecs, while the packet-switched access allows any narrow-bandwidth codecs, while the packet-switched access allows any
other audio or video codec implemented in the endpoint. In this other audio or video codec implemented in the endpoint. In this
case, it might be beneficial for the endpoint to describe different case, it might be beneficial for the endpoint to describe different
codecs for each access type and get an agreement on the bearer codecs for each access type and get an agreement on the bearer
together with the remote endpoint. together with the remote endpoint.
There are additional use cases related to third party call control There are additional use cases related to third party call control
skipping to change at page 6, line 19 skipping to change at page 6, line 19
REQ-4: The mechanism MUST be independent of the type of the circuit- REQ-4: The mechanism MUST be independent of the type of the circuit-
switched access (e.g., Integrated Services Digital Network switched access (e.g., Integrated Services Digital Network
(ISDN), Global System for Mobile Communication (GSM), etc.) (ISDN), Global System for Mobile Communication (GSM), etc.)
REQ-5: There MUST be a mechanism that helps an endpoint to correlate REQ-5: There MUST be a mechanism that helps an endpoint to correlate
an incoming circuit-switched bearer with the one negotiated an incoming circuit-switched bearer with the one negotiated
in SDP, as opposed to another incoming call that is not in SDP, as opposed to another incoming call that is not
related to that. related to that.
REQ-6: It must be possible for endpoints to advertise different list REQ-6: It MUST be possible for endpoints to advertise different list
of audio or video codecs in the circuit-switched audio or of audio or video codecs in the circuit-switched audio or
video stream from those used in a packet-switched audio or video stream from those used in a packet-switched audio or
video stream. video stream.
REQ-7: It must be possible for endpoints to not advertise the list REQ-7: It MUST be possible for endpoints to not advertise the list
of available codecs for circuit-switched audio or video of available codecs for circuit-switched audio or video
streams. streams.
4. Overview of Operation 4. Overview of Operation
The mechanism defined in this memo extends SDP and allows describing The mechanism defined in this memo extends SDP and allows describing
an audio or video media stream established over a circuit-switched an audio or video media stream established over a circuit-switched
bearer. New tokens are registered in the "c=" and "m=" lines to be bearer. New tokens are registered in the "c=" and "m=" lines to be
able to describe a media stream over a circuit-switched bearer. able to describe a media stream over a circuit-switched bearer.
These SDP extensions are described in Section 5.2. Since circuit- These SDP extensions are described in Section 5.2. Since circuit-
switched bearers are a sort of connection-oriented media streams, the switched bearers are connection-oriented media streams, the mechanism
mechanism re-uses the connection-oriented extensions defined in RFC re-uses the connection-oriented extensions defined in RFC 4145
4145 [RFC4145] to negotiate the active and passive sides of a [RFC4145] to negotiate the active and passive sides of a connection
connection setup. This is further described in Section 5.3.3. setup. This is further described in Section 5.3.3.
4.1. Example Call Flow 4.1. Example Call Flow
Consider the example presented in Figure 1. In this example, Alice Consider the example presented in Figure 1. In this example, Alice
is located in an environment where she has access to both IP and is located in an environment where she has access to both IP and
circuit-switched bearers for communicating with other endpoints. circuit-switched bearers for communicating with other endpoints.
Alice decides that the circuit-switched bearer offers a better Alice decides that the circuit-switched bearer offers a better
perceived quality of service for voice, and issues an SDP Offer perceived quality of service for voice, and issues an SDP Offer
containing the description of an audio media stream over circuit- containing the description of an audio media stream over circuit-
switched bearer. switched bearer.
skipping to change at page 7, line 29 skipping to change at page 7, line 29
Figure 1: Example Flow Figure 1: Example Flow
Bob receives the SDP offer and determines that he is located in an Bob receives the SDP offer and determines that he is located in an
environment where the IP based bearer is not suitable for real-time environment where the IP based bearer is not suitable for real-time
audio media. However he also has PSTN circuit-switched bearer audio media. However he also has PSTN circuit-switched bearer
available for audio. Bob generates an SDP answer containing a available for audio. Bob generates an SDP answer containing a
description of the audio media stream over a circuit-switched bearer. description of the audio media stream over a circuit-switched bearer.
During the offer-answer exchange Alice and Bob also agree the During the offer-answer exchange Alice and Bob also agree the
direction in which the circuit-switched connection should be direction in which the circuit-switched connection should be
established. The exchange also contains identifiers or references established. The exchange contains identifiers or references that
that can be used on the circuit-switched network for addressing the can be used on the circuit-switched network for addressing the other
other endpoint, as well as identifying that the incoming circuit- endpoint, as well as identifying that the incoming circuit-switched
switched bearer establishment is related to the ongoing session bearer establishment is related to the ongoing session between Alice
between Alice and Bob. and Bob.
Bob establishes a circuit-switched bearer towards Alice using Bob establishes a circuit-switched bearer towards Alice using
whatever mechanisms are defined for the network type in question. whatever mechanisms are defined for the network type in question.
When receiving the incoming circuit-switched connection attempt, When receiving the incoming circuit-switched connection attempt,
Alice is able to determine that the attempt is related to the session Alice is able to determine that the attempt is related to the session
she is just establishing with Bob. she is just establishing with Bob.
Alice accepts the circuit-switched connection; the circuit-switched Alice accepts the circuit-switched connection; the circuit-switched
bearer setup is completed. Bob and Alice can now use the circuit- bearer setup is completed. Bob and Alice can now use the circuit-
switched connection for two-way audio media. switched connection for two-way audio media.
skipping to change at page 11, line 28 skipping to change at page 11, line 28
a new SDP attribute called "cs-correlation". This "cs-correlation" a new SDP attribute called "cs-correlation". This "cs-correlation"
attribute can include any of the "callerid", "uuie", or "dtmf" attribute can include any of the "callerid", "uuie", or "dtmf"
parameters, which specify additional information required by the parameters, which specify additional information required by the
Caller-ID, User to User Information, or DTMF correlation mechanisms, Caller-ID, User to User Information, or DTMF correlation mechanisms,
respectively. The list of correlation mechanisms may be extended by respectively. The list of correlation mechanisms may be extended by
other specifications. other specifications.
The following sections provide more detailed information of these The following sections provide more detailed information of these
parameters. The "cs-correlation" attribute has the following format: parameters. The "cs-correlation" attribute has the following format:
"a=cs-correlation: "callerid:<callerid-value>" | a=cs-correlation: callerid:<callerid-value> |
"uuie:<uuie-value>" | iuie:<uuie-value> |
"dtmf:<dtmf-value>" dtmf:<dtmf-value> |
[extension-name:<extension-value>]
The values "callerid", "uuie" and "dtmf" refer to the correlation The values "callerid", "uuie" and "dtmf" refer to the correlation
mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and mechanisms defined in Section 5.2.3.2, Section 5.2.3.3, and
Section 5.2.3.4, respectively. The formal Augmented Backus-Naur Section 5.2.3.4, respectively. The formal Augmented Backus-Naur
Format (ABNF) syntax of the "cs-correlation" attribute is presented Format (ABNF) syntax of the "cs-correlation" attribute is presented
in Section 5.4. in Section 5.4.
5.2.3.2. Caller-ID Correlation Mechanism 5.2.3.2. Caller-ID Correlation Mechanism
The Caller-ID correlation mechanisms consists of an exchange of the The Caller-ID correlation mechanisms consists of an exchange of the
skipping to change at page 13, line 9 skipping to change at page 13, line 9
call setup signaling of the circuit-switched bearer. The User-User call setup signaling of the circuit-switched bearer. The User-User
Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and
3GPP TS 24.008 [3GPP.24.008], among others. The User-User 3GPP TS 24.008 [3GPP.24.008], among others. The User-User
Information Element has a maximum size of 35 or 131 octets, depending Information Element has a maximum size of 35 or 131 octets, depending
on the actual message of the PSTN protocol where it is included. on the actual message of the PSTN protocol where it is included.
The mechanism works as follows: An endpoint creates a User-User The mechanism works as follows: An endpoint creates a User-User
Information Element, according to the requirements of the call setup Information Element, according to the requirements of the call setup
signaling protocol. The same value is included in the SDP offer or signaling protocol. The same value is included in the SDP offer or
SDP answer, in a "cs-correlation:uuie" attribute. When the SDP SDP answer, in a "cs-correlation:uuie" attribute. When the SDP
offer/answer exchange is completed, each endpoint has become aware of Offer/Answer exchange is completed, each endpoint has become aware of
the value that will be used in the User-User Information Element of the value that will be used in the User-User Information Element of
the call setup message of the PSTN protocol. The endpoint that the call setup message of the PSTN protocol. The endpoint that
initiates the call setup attempt includes this value in the User-User initiates the call setup attempt includes this value in the User-User
Information Element. The recipient of the call setup attempt can Information Element. The recipient of the call setup attempt can
extract the User-User Information Element and correlate it with the extract the User-User Information Element and correlate it with the
value previously received in the SDP. If both values match, then the value previously received in the SDP. If both values match, then the
call setup attempt corresponds to that indicated in the SDP. call setup attempt corresponds to that indicated in the SDP.
Note that, for correlation purposes, the value of the User-User Note that, for correlation purposes, the value of the User-User
Information Element is considered as a opaque string and only used Information Element is considered as a opaque string and only used
skipping to change at page 14, line 5 skipping to change at page 14, line 5
not offer enough freedom for generating different values from one not offer enough freedom for generating different values from one
endpoint to another one, or from one call to another in the same endpoint to another one, or from one call to another in the same
endpoint. This might result in the same value of the User-User endpoint. This might result in the same value of the User-User
Information Element for all calls. Information Element for all calls.
5.2.3.4. DTMF Correlation Mechanism 5.2.3.4. DTMF Correlation Mechanism
We introduce a third mechanism for correlating the circuit-switched We introduce a third mechanism for correlating the circuit-switched
bearer with the session controlled with SDP. This is based on bearer with the session controlled with SDP. This is based on
agreeing on a sequence of digits that are negotiated in the SDP agreeing on a sequence of digits that are negotiated in the SDP
Offer/Answer exchange and sent as Dual Tone Multifrequency Offer/Answer exchange and sent as Dual Tone Multifrequency (DTMF)
(DTMF)tones over the circuit-switched bearer once this bearer is tones over the circuit-switched bearer once this bearer is
established. If the DTMF digit sequence received through the established. If the DTMF digit sequence received through the
circuit-switched bearer matches the digit string negotiated in the circuit-switched bearer matches the digit string negotiated in the
SDP, the circuit-switched bearer is correlated with the session SDP, the circuit-switched bearer is correlated with the session
described in the SDP. The mechanism is similar to many voice described in the SDP. The mechanism is similar to many voice
conferencing systems which require the user to enter a PIN code using conferencing systems which require the user to enter a PIN code using
DTMF tones in order to be accepted in a voice conference. DTMF tones in order to be accepted in a voice conference.
The mechanism works as follows: An endpoint selects a DTMF digit The mechanism works as follows: An endpoint selects a DTMF digit
sequence. The same sequence is included in the SDP offer or SDP sequence. The same sequence is included in the SDP offer or SDP
answer, in a "cs-correlation:dtmf" attribute. When the SDP offer/ answer, in a "cs-correlation:dtmf" attribute. When the SDP offer/
answer exchange is completed, each endpoint has become aware of the answer exchange is completed, each endpoint has become aware of the
DTMF sequence that will be sent right after the circuit-switched DTMF sequence that will be sent right after the circuit-switched
bearer is set up. The endpoint that initiates the call setup attempt bearer is set up. The endpoint that initiates the call setup attempt
sends the DTMF digits as per the procedures defined for the circuit- sends the DTMF digits according to the procedures defined for the
switched bearer technology used. The recipient (passive side of the circuit-switched bearer technology used. The recipient (passive side
bearer setup) of the call setup attempt collects the digits and of the bearer setup) of the call setup attempt collects the digits
correlates them with the value previously received in the SDP. If and compares them with the value previously received in the SDP. If
the digits match, then the call setup attempt corresponds to that the digits match, then the call setup attempt corresponds to that
indicated in the SDP. indicated in the SDP.
An endpoint that is feasible to become the active party for setting An endpoint that is feasible to become the active party for setting
up the PSTN call and is willing to send the DTMF digits after up the PSTN call and is willing to send the DTMF digits after
circuit-switched bearer cut-through SHOULD include a "dtmf" parameter circuit-switched bearer cut-through SHOULD include a "dtmf" parameter
in the "cs-correlation" attribute of the SDP offer or answer. The in the "cs-correlation" attribute of the SDP offer or answer. The
value of the "dtmf" parameter SHOULD contain up to 32 randomly value of the "dtmf" parameter SHOULD contain up to 32 randomly
selected DTMF digits (numbers 0-9, characters A-D, "#" and "*"). selected DTMF digits (numbers 0-9, characters A-D, "#" and "*").
skipping to change at page 16, line 16 skipping to change at page 16, line 16
a=cs-correlation:uuie dtmf a=cs-correlation:uuie dtmf
The answerer, when generating the answer, SHOULD select those The answerer, when generating the answer, SHOULD select those
correlation mechanisms it supports, and include an "a=cs-correlation" correlation mechanisms it supports, and include an "a=cs-correlation"
attribute line in the answer containing those mechanisms it supports. attribute line in the answer containing those mechanisms it supports.
The answerer MUST NOT add any mechanism which was not included in the The answerer MUST NOT add any mechanism which was not included in the
offer. offer.
If the answer does not contain an "a=cs-correlation" attribute line, If the answer does not contain an "a=cs-correlation" attribute line,
the offerer MUST interpret this as an indication that the anwerer the offerer MUST interpret this as an indication that the answerer
does not support any of the correlation mechanisms for this session. does not support any of the correlation mechanisms for this session.
If, in addition to supporting any of the correlation mechanisms, an If, in addition to supporting any of the correlation mechanisms, an
endpoint is willing to assume the role of the active party in endpoint is willing to assume the role of the active party in
establishing the circuit-switched bearer, it MUST add a parameter establishing the circuit-switched bearer, it MUST add a parameter
value to the supported mechanisms. For example, if the endpoint value to the supported mechanisms. For example, if the endpoint
supports and is willing to send the User-User Information element and supports and is willing to send the User-User Information element and
DTMF digits, it includes the following line to the SDP offer: DTMF digits, it includes the following line to the SDP offer:
a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3 a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3
skipping to change at page 17, line 7 skipping to change at page 17, line 7
session, even if the other correlation mechanisms fail. session, even if the other correlation mechanisms fail.
If, after negotiating one or more correlation mechanisms in the SDP If, after negotiating one or more correlation mechanisms in the SDP
offer/answer exchange, an endpoint receives a circuit-switched call offer/answer exchange, an endpoint receives a circuit-switched call
with no correlation information present, the endpoint has two with no correlation information present, the endpoint has two
choices: it can either treat the call as unrelated, or treat the call choices: it can either treat the call as unrelated, or treat the call
as related to the ongoing session in the IP domain. as related to the ongoing session in the IP domain.
An endpoint may for example specify a time window after SDP offer/ An endpoint may for example specify a time window after SDP offer/
answer exchange during which received calls are treated as correlated answer exchange during which received calls are treated as correlated
even if the signalling in the circuit-switched domain does not carry even if the signaling in the circuit-switched domain does not carry
any correlation information. In this case, there is a chance that any correlation information. In this case, there is a chance that
the call is erroneously treated as related to the ongoing session. the call is erroneously treated as related to the ongoing session.
An endpoint may also choose to always treat an incoming call as An endpoint may also choose to always treat an incoming call as
unrelated if the signalling in the circuit-switched domain does not unrelated if the signaling in the circuit-switched domain does not
carry any correlation information. In this case, there is a chance carry any correlation information. In this case, there is a chance
that the call is erroneously treated as unrelated. that the call is erroneously treated as unrelated.
Since, in these cases, no correlation information can be deduced from Since, in these cases, no correlation information can be deduced from
the signalling, it is up to the implementation to decide how to the signaling, it is up to the implementation to decide how to
behave. One option is also to let the user decide whether to accept behave. One option is also to let the user decide whether to accept
the call as related, or to treat the call as unrelated. the call as related, or to treat the call as unrelated.
5.3. Considerations for Usage of Existing SDP 5.3. Considerations for Usage of Existing SDP
5.3.1. Originator of the Session 5.3.1. Originator of the Session
According to SDP [RFC4566], the origin line in SDP has the following According to SDP [RFC4566], the origin line in SDP has the following
syntax: syntax:
skipping to change at page 19, line 32 skipping to change at page 19, line 32
cs-correlation-attr= "cs-correlation:" corr-mechanisms cs-correlation-attr= "cs-correlation:" corr-mechanisms
corr-mechanisms = corr-mech *(SP corr-mech) corr-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech / dtmf-mech / ext-mech corr-mech = caller-id-mech / uuie-mech / dtmf-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value] caller-id-mech = "callerid" [":" caller-id-value]
caller-id-value = ["+"] 1*DIGIT caller-id-value = ["+"] 1*DIGIT
uuie-mech = "uuie" [":" uuie-value] uuie-mech = "uuie" [":" uuie-value]
uuie-value = 1*32(ALPHA/DIGIT) uuie-value = 1*32(ALPHA/DIGIT)
dtmf-mech = "dtmf" [":" dtmf-value] dtmf-mech = "dtmf" [":" dtmf-value]
dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A ) dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A )
;0-9, A-D, '#' and '*' ;0-9, A-D, '#' and '*'
ext-mech = token ext-mech = ext-mech-name[":" ext-mech-value]
ext-mech-name = token
ext-mech-value = token
; token is specified in RFC4566 ; token is specified in RFC4566
Figure 2: Syntax of the SDP extensions Figure 2: Syntax of the SDP extensions
6. SDP Examples 6. Example
6.1. Basic SDP example: Single Circuit-Switched Audio Stream
Alice Bob Alice Bob
| | | |
| (1) SDP Offer (PSTN audio) | | (1) SDP Offer (PSTN audio) |
|--------------------------------->| |--------------------------------->|
| | | |
| (2) SDP Answer (PSTN audio) | | (2) SDP Answer (PSTN audio) |
|<---------------------------------| |<---------------------------------|
| | | |
| PSTN call setup | | PSTN call setup |
 End of changes. 20 change blocks. 
36 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/