draft-ietf-mmusic-sdp-cs-10.txt   draft-ietf-mmusic-sdp-cs-11.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: September 7, 2012 Nokia Expires: November 15, 2012 Nokia
March 6, 2012 May 14, 2012
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 Switched Video Media Streams Over Circuit-Switched Bearers In The Public Switched
Telephone Network (PSTN) Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-10 draft-ietf-mmusic-sdp-cs-11
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 September 7, 2012. This Internet-Draft will expire on November 15, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 23 skipping to change at page 3, line 23
5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 9 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 9
5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 9 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 9 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 9
5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 10 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . . 10
5.2.3. Correlating the PSTN Circuit-Switched Bearer with 5.2.3. Correlating the PSTN Circuit-Switched Bearer with
SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12 SDP . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 12 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . . 12
5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 13
5.2.3.3. User-User Information Element Correlation 5.2.3.3. User-User Information Element Correlation
Mechanism . . . . . . . . . . . . . . . . . . . . 14 Mechanism . . . . . . . . . . . . . . . . . . . . 14
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 15 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16
5.3. Negotiating the correlation mechanisms . . . . . . . . . . 16 5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17
5.3.1. Determining the Direction of the Circuit-Switched 5.3.1. Determining the Direction of the Circuit-Switched
Bearer Setup . . . . . . . . . . . . . . . . . . . . . 16 Bearer Setup . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. Populating the cs-correlation attribute . . . . . . . 17 5.3.2. Populating the cs-correlation attribute . . . . . . . 18
5.3.3. Considerations on successful correlation . . . . . . . 17 5.3.3. Considerations on successful correlation . . . . . . . 18
5.4. Considerations for Usage of Existing SDP . . . . . . . . . 18 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19
5.4.1. Originator of the Session . . . . . . . . . . . . . . 18 5.4.1. Originator of the Session . . . . . . . . . . . . . . 19
5.4.2. Contact information . . . . . . . . . . . . . . . . . 19 5.4.2. Contact information . . . . . . . . . . . . . . . . . 19
5.5. Considerations for Usage of Third Party Call Control 5.5. Considerations for Usage of Third Party Call Control
(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 19 (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 19 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 20
5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 19 5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 20
5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 21 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 22
5.6.3. Offerer processing the Answer . . . . . . . . . . . . 24 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 25
5.6.4. Modifying the session . . . . . . . . . . . . . . . . 25 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 26
5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 25 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 27 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 28
6.2. Advanced SDP example: Circuit-Switched Audio and Video 6.2. Advanced SDP example: Circuit-Switched Audio and Video
Streams . . . . . . . . . . . . . . . . . . . . . . . . . 29 Streams . . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. Registration of new cs-correlation SDP attribute . . . . . 31 8.1. Registration of new cs-correlation SDP attribute . . . . . 32
8.2. Registration of a new "nettype" value . . . . . . . . . . 31 8.2. Registration of a new "nettype" value . . . . . . . . . . 32
8.3. Registration of new "addrtype" values . . . . . . . . . . 32 8.3. Registration of new "addrtype" values . . . . . . . . . . 33
8.4. Registration of a new "proto" value . . . . . . . . . . . 32 8.4. Registration of a new "proto" value . . . . . . . . . . . 33
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] is intended for The Session Description Protocol (SDP) [RFC4566] is intended for
describing multimedia sessions for the purposes of session describing multimedia sessions for the purposes of session
announcement, session invitation, and other forms of multimedia announcement, session invitation, and other forms of multimedia
session initiation. SDP is most commonly used for describing media session initiation. SDP is most commonly used for describing media
streams that are transported over the Real-Time Transport Protocol streams that are transported over the Real-Time Transport Protocol
(RTP) [RFC3550], using the profiles for audio and video media defined (RTP) [RFC3550], using the profiles for audio and video media defined
in RTP Profile for Audio and Video Conferences with Minimal Control in RTP Profile for Audio and Video Conferences with Minimal Control
skipping to change at page 10, line 37 skipping to change at page 10, line 37
o any syntactically valid value, which is to be ignored o any syntactically valid value, which is to be ignored
5.2.2. Media Descriptions 5.2.2. Media Descriptions
According to SDP [RFC4566], the media descriptions line in SDP has According to SDP [RFC4566], the media descriptions line in SDP has
the following syntax: the following syntax:
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
The <media> sub-field carries the media type. For establishing an The <media> subfield carries the media type. For establishing an
audio bearer, the existing "audio" media type is used. For audio bearer, the existing "audio" media type is used. For
establishing a video bearer, the existing "video" media type is used. establishing a video bearer, the existing "video" media type is used.
The <port> sub-field is the transport port to which the media stream The <port> subfield is the transport port to which the media stream
is sent. Circuit-switched access lacks the concept of a port number, is sent. Circuit-switched access lacks the concept of a port number,
and therefore the <port> sub-field does not carry any meaningful and therefore the <port> subfield does not carry any meaningful
value. In order to be compliant with SDP syntax, implementations value. In order to be compliant with SDP syntax, implementations
SHOULD set the <port> sub-field to the discard port value "9" and SHOULD set the <port> subfield to the discard port value "9" and MUST
MUST ignore it on reception. ignore it on reception.
According to RFC 3264 [RFC3264], a port number of zero in the offer According to RFC 3264 [RFC3264], a port number of zero in the offer
of a unicast stream indicates that the stream is offered but must not of a unicast stream indicates that the stream is offered but must not
be used. If a port number of zero is present in the answer of a be used. If a port number of zero is present in the answer of a
unicast stream, it indicates that the stream is rejected. These unicast stream, it indicates that the stream is rejected. These
rules are still valid when the media line in SDP represents a rules are still valid when the media line in SDP represents a
circuit-switched bearer. circuit-switched bearer.
The <proto> sub-field is the transport protocol. The circuit- The <proto> subfield is the transport protocol. The circuit-switched
switched bearer uses whatever transport protocol it has available. bearer uses whatever transport protocol it has available. This
This subfield SHOULD be set to the mnemonic "PSTN" to be subfield SHOULD be set to the mnemonic "PSTN" to be syntactically
syntactically correct with SDP [RFC4566] and to indicate the usage of correct with SDP [RFC4566] and to indicate the usage of circuit-
circuit-switched protocols in the PSTN. switched protocols in the PSTN.
The <fmt> sub-field is the media format description. In the The <fmt> subfield is the media format description. In the classical
classical usage of SDP to describe RTP-based media streams, when the usage of SDP to describe RTP-based media streams, when the <proto>
<proto> sub-field is set to "RTP/AVP" or "RTP/SAVP", the <fmt> sub- subfield is set to "RTP/AVP" or "RTP/SAVP", the <fmt> subfield
field contains the payload types as defined in the RTP audio profile contains the payload types as defined in the RTP audio profile
[RFC3551]. [RFC3551].
When "RTP/AVP" is used in the <proto> field, the <fmt> sub-field When "RTP/AVP" is used in the <proto> field, the <fmt> subfield
contains the RTP payload type numbers. We use the <fmt> sub-field to contains the RTP payload type numbers. We use the <fmt> subfield to
indicate the list of available codecs over the circuit-switched indicate the list of available codecs over the circuit-switched
bearer, by re-using the conventions and payload type numbers defined bearer, by re-using the conventions and payload type numbers defined
for RTP/AVP. The RTP audio and video media types, which, when for RTP/AVP. The RTP audio and video media types, which, when
applied to PSTN circuit-switched bearers, represent merely an audio applied to PSTN circuit-switched bearers, represent merely an audio
or video codec. or video codec.
In some cases, the endpoint is not able to determine the list of In some cases, the endpoint is not able to determine the list of
available codecs for circuit-switched media streams. In this case, available codecs for circuit-switched media streams. In this case,
in order to be syntactically compliant with SDP [RFC4566], the in order to be syntactically compliant with SDP [RFC4566], the
endpoint MUST include a single dash "-" in the <fmt> sub-field. endpoint MUST include a single dash "-" in the <fmt> subfield.
As per RFC 4566 [RFC4566], the media format descriptions are listed As per RFC 4566 [RFC4566], the media format descriptions are listed
in priority order. in priority order.
Examples of media descriptions for circuit-switched audio streams Examples of media descriptions for circuit-switched audio streams
are: are:
m=audio 9 PSTN 3 0 8 m=audio 9 PSTN 3 0 8
m=audio 9 PSTN - m=audio 9 PSTN -
skipping to change at page 12, line 40 skipping to change at page 12, line 40
The third mechanism is based on sending in SDP a string that The third mechanism is based on sending in SDP a string that
represents Dual Tone MultiFrequency (DTMF) digits that will be later represents Dual Tone MultiFrequency (DTMF) digits that will be later
sent right after the circuit-switched bearer is established. sent right after the circuit-switched bearer is established.
Implementations MAY use any of these mechanisms and MAY use two or Implementations MAY use any of these mechanisms and MAY use two or
more mechanisms simultaneously. more mechanisms simultaneously.
5.2.3.1. The "cs-correlation" attribute 5.2.3.1. The "cs-correlation" attribute
In order to provide support for the correlation mechanisms, we define In order to provide support for the correlation mechanisms, we define
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" sub- attribute can include any of the "callerid", "uuie", or "dtmf"
fields, which specify additional information required by the subfields, 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
subfields. The "cs-correlation" attribute has the following format: subfields. The "cs-correlation" attribute has the following format:
a=cs-correlation: <correlation-mechanisms> a=cs-correlation: <correlation-mechanisms>
correlation-mechanisms = corr-mech *(SP corr-mech) correlation-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech / corr-mech = caller-id-mech / uuie-mech /
skipping to change at page 13, line 34 skipping to change at page 13, line 34
followed by the availability of the Calling Party Number information followed by the availability of the Calling Party Number information
element in the call setup signaling of the circuit switched element in the call setup signaling of the circuit switched
connection. If both pieces of information match, the circuit- connection. If both pieces of information match, the circuit-
switched bearer is correlated to the session described in SDP. switched bearer is correlated to the session described in SDP.
Example of inclusion of an international E.164 number in the "cs- Example of inclusion of an international E.164 number in the "cs-
correlation" attribute is: correlation" attribute is:
a=cs-correlation:callerid:+35891234567 a=cs-correlation:callerid:+35891234567
The presence of the "callerid" sub-field indicates that the endpoint The presence of the "callerid" subfield indicates that the endpoint
supports use of the calling party number as a means of correlating a supports use of the calling party number as a means of correlating a
PSTN call with the session being negotiated. The "callerid" sub- PSTN call with the session being negotiated. The "callerid" subfield
field MAY be accompanied by the international E.164 number of the MAY be accompanied by the international E.164 number of the party
party inserting the parameter. inserting the parameter.
Note that there are no warranties that this correlation mechanism Note that there are no warranties that this correlation mechanism
works or is even available, due a number of problems: works or is even available, due a number of problems:
o The endpoint might not be aware of its own E.164 number, in which o The endpoint might not be aware of its own E.164 number, in which
case it cannot populate the SDP appropriately. case it cannot populate the SDP appropriately.
o The Calling Party Number information element in the circuit- o The Calling Party Number information element in the circuit-
switched signaling might not be available, e.g., due to policy switched signaling might not be available, e.g., due to policy
restrictions of the network operator or caller restriction due to restrictions of the network operator or caller restriction due to
skipping to change at page 14, line 21 skipping to change at page 14, line 21
the purpose of displaying the caller's name. the purpose of displaying the caller's name.
5.2.3.3. User-User Information Element Correlation Mechanism 5.2.3.3. User-User Information Element Correlation Mechanism
A second correlation mechanism is based on including in SDP a string A second correlation mechanism is based on including in SDP a string
that represents the User-User Information Element that is part of the that represents the User-User Information Element that is part of the
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 [TS.24.008], among others. The User-User Information 3GPP TS 24.008 [TS.24.008], among others. The User-User Information
Element has a maximum size of 35 or 131 octets, depending on the Element has a maximum size of 35 or 131 octets, depending on the
actual message of the PSTN protocol where it is included. actual message of the PSTN protocol where it is included and the
network settings.
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 the "uuie" subfield of the "cs-correlation" attribute.
Offer/Answer exchange is completed, each endpoint has become aware of When the SDP Offer/Answer exchange is completed, each endpoint has
the value that will be used in the User-User Information Element of become aware of the value that will be used in the User-User
the call setup message of the PSTN protocol. The endpoint that Information Element of the call setup message of the PSTN protocol.
initiates the call setup attempt includes this value in the User-User The endpoint that initiates the call setup attempt includes this
Information Element. The recipient of the call setup attempt can value in the User-User Information Element. The recipient of the
extract the User-User Information Element and correlate it with the call setup attempt can extract the User-User Information Element and
value previously received in the SDP. If both values match, then the correlate it with the value previously received in the SDP. If both
call setup attempt corresponds to that indicated in the SDP. values match, then the call setup attempt corresponds to that
indicated in the SDP.
The first three octets of the User-User Information Element specified According to ITU-T Q.931 [ITU.Q931.1998], the User-User Information
in ITU-T Q.931 [ITU.Q931.1998] are the UUIE identifier, lenght of the Element (UUIE) identifier is composed of a first octet identifying
user-user contents, and a protocol discriminator, followed by the this as a User-User Information Element, a second octet containing
actual User information. The first two octets of the UUIE MUST NOT the Length of the user-user contents, a third octet containing a
be used for correlation, only the octets carrying the Protocol Protocol Discriminator, and a value of up to 32 or 128 octets
Discriminator and the User information value are compared the value (depending on network settings) containing the actual User
of the "cs-correlation:uuie" attribute. The value of the Protocol Information (see Figure 4-36 in ITU-T Q.931). The first two octets
Discriminator octet is not specified in this document; it is expected of the UUIE MUST NOT be used for correlation, only the octets
that organizations using this technology will allocate a suitable carrying the Protocol Discriminator and the User Information value
value for the Protocol Discriminator. are input to the creation of the value of the "uuie" subfield in the
"cs-correlation" attribute. Therefore, the value of the "uuie"
subfield in the "cs-correlation" attribute MUST start with the the
value starting at the Protocol Discriminator octet, followed by the
User Information octets. The value of the Protocol Discriminator
octet is not specified in this document; it is expected that
organizations using this technology will allocate a suitable value
for the Protocol Discriminator.
Once the binary value of the "uuie" subfield in the "cs-correlation"
attribute is created, it MUST be encoded in hexadecimal before it is
inserted in SDP. Each octet of binary data to be represented in the
hexadecimal encoding MUST be mapped to two hexadecimal digits
(represented by ASCII characters 0-9, A-F and a-f), each representing
four bits within the octet. The four bits appearing first in the
binary data MUST be mapped to the first hexadecimal digit and the
four subsequent bits in the binary data MUST be mapped to the second
hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the
bit appearing first in the binary data shall be most significant.
Thus, the resulting hexadecimal encoded value needs to have an even
number of hexadecimal digits, and MUST be considered invalid if it
has an odd number.
Note that the encoding of the "uuie" subfield of the "cs-
correlation" attribute is largely inspired by the encoding of the
same value in the User-to-User header field in SIP, according to
the document A Mechanism for Transporting User to User Call
Control Information in SIP [I-D.ietf-cuss-sip-uui].
As an example, an endpoint willing to send a UUIE containing a
protocol discriminator with the hexadecimal value of %x56 and an
hexadecimal User Information value of %xa390f3d2b7310023 would
include a "cs-correlation" attribute line as follows:
a=cs-correlation:uuie:56a390f3d2b7310023
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
for correlation purposes. Typically call signaling protocols impose for correlation purposes. Typically call signaling protocols impose
requirements on the creation of User-User Information Element for requirements on the creation of User-User Information Element for
end-user protocol exchange. The details regarding the generation of end-user protocol exchange. The details regarding the generation of
the User-User Information Element are outside the scope of this the User-User Information Element are outside the scope of this
specification. specification.
Please note that there are no warranties that this correlation Please note that there are no warranties that this correlation
skipping to change at page 15, line 33 skipping to change at page 16, line 21
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 "dtmf" subfield of the "cs-correlation" attribute. When
Answer exchange is completed, each endpoint has become aware of the the SDP Offer/Answer exchange is completed, each endpoint has become
DTMF sequence that will be sent right after the circuit-switched aware of the DTMF sequence that will be sent right after the circuit-
bearer is set up. The endpoint that initiates the call setup attempt switched bearer is set up. The endpoint that initiates the call
sends the DTMF digits according to the procedures defined for the setup attempt sends the DTMF digits according to the procedures
circuit-switched bearer technology used. The recipient (passive side defined for the circuit-switched bearer technology used. The
of the bearer setup) of the call setup attempt collects the digits recipient (passive side of the bearer setup) of the call setup
and compares them with the value previously received in the SDP. If attempt collects the digits and compares them with the value
the digits match, then the call setup attempt corresponds to that previously received in the SDP. If the digits match, then the call
indicated in the SDP. setup attempt corresponds to that indicated in the SDP.
Implementations are advised to select a number of DTMF digits that Implementations are advised to select a number of DTMF digits that
provide enough assurance that the call is related, but on the provide enough assurance that the call is related, but on the
other hand do not prolong the bearer setup time unnecessarily. other hand do not prolong the bearer setup time unnecessarily.
As an example, an endpoint willing to send DTMF tone sequence "14D*3" As an example, an endpoint willing to send DTMF tone sequence "14D*3"
would include a "cs-correlation" attribute line as follows: would include a "cs-correlation" attribute line as follows:
a=cs-correlation:dtmf:14D*3 a=cs-correlation:dtmf:14D*3
skipping to change at page 17, line 23 skipping to change at page 18, line 9
but applied to circuit-switched bearers in the PSTN. but applied to circuit-switched bearers in the PSTN.
We define the active party as the one that initiates the circuit- We define the active party as the one that initiates the circuit-
switched bearer after the Offer/Answer process. The passive party is switched bearer after the Offer/Answer process. The passive party is
the one receiving the circuit-switched bearer. Either party may the one receiving the circuit-switched bearer. Either party may
indicate its desire to become the active or passive party during the indicate its desire to become the active or passive party during the
Offer/Answer exchange using the procedures described in Section 5.6. Offer/Answer exchange using the procedures described in Section 5.6.
5.3.2. Populating the cs-correlation attribute 5.3.2. Populating the cs-correlation attribute
By defining values for the sub-fields in the "a=cs-correlation" By defining values for the subfields in the "a=cs-correlation"
attribute, the endpoint indicates that it is willing to become the attribute, the endpoint indicates that it is willing to become the
active party, and that it can use those values in the Calling party active party, and that it can use those values in the Calling party
number, User-User Information Element, or as DTMF tones during the number, User-User Information Element, or as DTMF tones during the
circuit-switched bearer setup. circuit-switched bearer setup.
Thus, the following rules apply: Thus, the following rules apply:
An endpoint that can only become the active party in the circuit- An endpoint that can only become the active party in the circuit-
switched bearer setup MUST include all correlation mechanisms it switched bearer setup MUST include all correlation mechanisms it
supports in the "a=cs-correlation" attribute, and MUST also supports in the "a=cs-correlation" attribute, and MUST also
specify values for the sub-fields. specify values for the subfields.
An endpoint that can only become the passive party in the circuit- An endpoint that can only become the passive party in the circuit-
switched bearer setup MUST include all correlation mechanisms it switched bearer setup MUST include all correlation mechanisms it
supports in the "a=cs-correlation" attribute, but MUST NOT specify supports in the "a=cs-correlation" attribute, but MUST NOT specify
values for the sub-fields. values for the subfields.
An endpoint that is willing to become either the active or passive An endpoint that is willing to become either the active or passive
party (by including the "a=setup:actpass" attribute in the Offer), party (by including the "a=setup:actpass" attribute in the Offer),
MUST include all correlation mechanisms it supports in the "a=cs- MUST include all correlation mechanisms it supports in the "a=cs-
correlation" attribute, and MUST also specify values for the sub- correlation" attribute, and MUST also specify values for the
fields. subfields.
5.3.3. Considerations on successful correlation 5.3.3. Considerations on successful correlation
Note that, as stated above, it cannot be guaranteed that any given Note that, as stated above, it cannot be guaranteed that any given
correlation mechanism will succeed even if the usage of those was correlation mechanism will succeed even if the usage of those was
agreed beforehand. This is due to the fact that the correlation agreed beforehand. This is due to the fact that the correlation
mechanisms require support from the circuit-switched bearer mechanisms require support from the circuit-switched bearer
technology used. technology used.
Therefore, even a single positive indication using any of these Therefore, even a single positive indication using any of these
skipping to change at page 20, line 8 skipping to change at page 20, line 43
The Offerer, wishing to use PSTN audio or video stream, MUST populate The Offerer, wishing to use PSTN audio or video stream, MUST populate
the "c=" and "m=" lines as follows. the "c=" and "m=" lines as follows.
The endpoint MUST set the <nettype> in the "c=" line to "PSTN", and The endpoint MUST set the <nettype> in the "c=" line to "PSTN", and
the <addrtype> to "E164". Furthermore, the endpoint SHOULD set the the <addrtype> to "E164". Furthermore, the endpoint SHOULD set the
<connection-address> field to its own international E.164 number <connection-address> field to its own international E.164 number
(with a leading "+"). If the endpoint is not aware of its own E.164 (with a leading "+"). If the endpoint is not aware of its own E.164
number, it MUST set the <connection-address> to "-". number, it MUST set the <connection-address> to "-".
In the "m=" line, the endpoint MUST set the <media> subfield to In the "m=" line, the endpoint MUST set the <media> subfield to
"audio" or "video", depending on the media type, and the <proto> sub- "audio" or "video", depending on the media type, and the <proto>
field to "PSTN". The <port> sub-field SHOULD be set to "9" (the subfield to "PSTN". The <port> subfield SHOULD be set to "9" (the
discard port). discard port).
The <fmt> sub-field carries the payload type number(s) the endpoint The <fmt> subfield carries the payload type number(s) the endpoint is
is wishing to use. Payload type numbers in this case refer to the wishing to use. Payload type numbers in this case refer to the
codecs that the endpoint wishes to use. For example, if the endpoint codecs that the endpoint wishes to use. For example, if the endpoint
wishes to use the GSM codec, it would add payload type number 3 in wishes to use the GSM codec, it would add payload type number 3 in
the list of codecs. the list of codecs.
For dynamic payload types, the endpoint MUST define the set of valid For dynamic payload types, the endpoint MUST define the set of valid
encoding names and related parameters using the "a=rtpmap" attribute encoding names and related parameters using the "a=rtpmap" attribute
line. See Section 6 of SDP [RFC4566] for details. line. See Section 6 of SDP [RFC4566] for details.
When generating the Offer, if the Offerer supports any of the When generating the Offer, if the Offerer supports any of the
correlation mechanisms defined in this memo, it MUST include an correlation mechanisms defined in this memo, it MUST include an
attribute line "a=cs-correlation" in the SDP offer. The "a=cs- attribute line "a=cs-correlation" in the SDP offer. The "a=cs-
correlation" line contains an enumeration of the correlation correlation" line contains an enumeration of the correlation
mechanisms supported by the Offerer, in the format of sub-fields. mechanisms supported by the Offerer, in the format of subfields.
The current list of sub-fields include "callerid", "uuie" and "dtmf" The current list of subfields include "callerid", "uuie" and "dtmf"
and they refer to the correlation mechanisms defined in and they refer to the correlation mechanisms defined in
Section 5.2.3.2, Section 5.2.3.3, and Section 5.2.3.4, respectively. Section 5.2.3.2, Section 5.2.3.3, and Section 5.2.3.4, respectively.
If the Offerer supports any of the correlation mechanisms defined in If the Offerer supports any of the correlation mechanisms defined in
this memo, and is willing to become the active party, the Offerer this memo, and is willing to become the active party, the Offerer
MUST add the "callerid", "uuie", and/or "dtmf" sub-fields and MUST MUST add the "callerid", "uuie", and/or "dtmf" subfields and MUST
specify values for those sub-fields. specify values for those subfields.
o the international E.164 number as the value in the "callerid" sub- o the international E.164 number as the value in the "callerid"
field, subfield,
o the contents of the User-User information element as the value of o the contents of the User-User information element as the value of
the "uuie" sub-field, and/or the "uuie" subfield, and/or
o the DTMF tone string as the value of the "dtmf" sub-field o the DTMF tone string as the value of the "dtmf" subfield
If the Offerer is only able to become the passive party in the If the Offerer is only able to become the passive party in the
circuit-switched bearer setup, it MUST add the "callerid", "uuie" circuit-switched bearer setup, it MUST add the "callerid", "uuie"
and/or "dtmf" sub-fields, but MUST NOT specify values for those sub- and/or "dtmf" subfields, but MUST NOT specify values for those
fields. subfields.
For example, if the Offerer is willing to use the User-User For example, if the Offerer is willing to use the User-User
Information element and DTMF digit sending mechanisms, but can only Information element and DTMF digit sending mechanisms, but can only
become the passive party, it includes the following lines to the SDP: become the passive party, it includes the following lines to the SDP:
a=cs-correlation:uuie dtmf a=cs-correlation:uuie dtmf
a=setup:passive a=setup:passive
If, on the other hand, the Offerer is willing to use the User-User If, on the other hand, the Offerer is willing to use the User-User
Information element and the DTMF correlation mechanisms, and is able Information element and the DTMF correlation mechanisms, and is able
to become the active or passive side, it includes to following lines to become the active or passive side, it includes to following lines
to the SDP: to the SDP:
a=cs-correlation:uuie:2890W284hAT452612908awudfjang908 dtmf:14D*3 a=cs-correlation:uuie:56a390f3d2b7310023 dtmf:14D*3
a=setup:actpass a=setup:actpass
The negotiation of the value of the 'setup' attribute takes place as The negotiation of the value of the 'setup' attribute takes place as
defined in Section 4.1 of TCP-Based Media Transport in the SDP defined in Section 4.1 of TCP-Based Media Transport in the SDP
[RFC4145]. [RFC4145].
The Offerer states which role or roles it is willing to perform; and The Offerer states which role or roles it is willing to perform; and
the Answerer, taking the Offerer's willingness into consideration, the Answerer, taking the Offerer's willingness into consideration,
chooses which roles both endpoints will actually perform during the chooses which roles both endpoints will actually perform during the
circuit-switched bearer setup. circuit-switched bearer setup.
skipping to change at page 22, line 21 skipping to change at page 23, line 8
payload type. Most often, a "-" is expected to be used instead of payload type. Most often, a "-" is expected to be used instead of
the payload type when the endpoint is not aware of or not willing to the payload type when the endpoint is not aware of or not willing to
define the codecs which will eventually be used on the circuit- define the codecs which will eventually be used on the circuit-
switched bearer. The circuit-switched signaling protocols have their switched bearer. The circuit-switched signaling protocols have their
own means of negotiating or indicating the codecs, therefore an own means of negotiating or indicating the codecs, therefore an
Answerer SHOULD accept such Offers, and SHOULD set the payload type Answerer SHOULD accept such Offers, and SHOULD set the payload type
to "-" also in the Answer. to "-" also in the Answer.
If the Answerer explicitly wants to specify a codec for the circuit- If the Answerer explicitly wants to specify a codec for the circuit-
switched media, it MAY set the respective payload numbers in the switched media, it MAY set the respective payload numbers in the
<fmt> sub-field in the answer. This behavior, however, is NOT <fmt> subfield in the answer. This behavior, however, is NOT
RECOMMENDED. RECOMMENDED.
When receiving the Offer, the Answerer MUST determine whether it When receiving the Offer, the Answerer MUST determine whether it
becomes the active or passive party. becomes the active or passive party.
If the SDP in the Offer indicates that the Offerer is only able to If the SDP in the Offer indicates that the Offerer is only able to
become the active party, the Answerer needs to determine whether it become the active party, the Answerer needs to determine whether it
is able to become the passive party. If this is not possible e.g. is able to become the passive party. If this is not possible e.g.
due to the Answerer not knowing its international E.164 number, the due to the Answerer not knowing its international E.164 number, the
Answerer MUST reject the circuit-switched media by setting the port Answerer MUST reject the circuit-switched media by setting the port
skipping to change at page 23, line 13 skipping to change at page 23, line 48
number, it MUST become the passive party. If the Offer does not number, it MUST become the passive party. If the Offer does not
include an E.164 number in the "c=" line and the Answerer is not include an E.164 number in the "c=" line and the Answerer is not
aware of its E.164 number, it MUST reject the circuit-switched media aware of its E.164 number, it MUST reject the circuit-switched media
by setting the port number to zero in the Answer. by setting the port number to zero in the Answer.
The Answerer MUST select those correlation mechanisms from the Offer The Answerer MUST select those correlation mechanisms from the Offer
it supports, and include an "a=cs-correlation" attribute line in the it supports, and include an "a=cs-correlation" attribute line in the
Answer containing those mechanisms it supports. The Answerer MUST Answer containing those mechanisms it supports. The Answerer MUST
NOT add any mechanisms which were not included in the offer. NOT add any mechanisms which were not included in the offer.
If the Answerer becomes the active party, it MUST add parameter If the Answerer becomes the active party, it MUST add any of the
values to the "callerid", "uuie" or "dtmf" sub-fields. "callerid", "uuie" or "dtmf" subfield values.
If the Answerer becomes the passive party, it MUST NOT add values to If the Answerer becomes the passive party, it MUST NOT add values to
the "callerid", "uuie" and/or "dtmf" sub-fields. the "callerid", "uuie" and/or "dtmf" subfields.
After generating and sending the Answer, if the Answerer became the After generating and sending the Answer, if the Answerer became the
active party, it active party, it
o MUST extract the E.164 number from the "c=" line of the Offer and o MUST extract the E.164 number from the "c=" line of the Offer and
MUST establish a circuit-switched bearer to that address. MUST establish a circuit-switched bearer to that address.
o if the SDP Answer contained a value for the "callerid" sub-field, o if the SDP Answer contained a value for the "callerid" subfield,
must set the Calling Party Number Information Element to that must set the Calling Party Number Information Element to that
number, number,
o if the SDP Answer contained a value for the "uuie" sub-field, MUST o if the SDP Answer contained a value for the "uuie" subfield, MUST
send the User-User Information element according to the rules send the User-User Information element according to the rules
defined for the circuit-switched technology used, and set the defined for the circuit-switched technology used, and set the
value of the Information Element to that received in the SDP value of the Information Element to that received in the SDP
Offer, Offer,
o if the SDP Answer contained a value for the "dtmf" sub-field, MUST o if the SDP Answer contained a value for the "dtmf" subfield, MUST
send those DTMF digits according to the circuit-switched send those DTMF digits according to the circuit-switched
technology used. technology used.
If, on the other hand, the Answerer became the passive party, it If, on the other hand, the Answerer became the passive party, it
o MUST be prepared to receive a circuit-switched bearer, o MUST be prepared to receive a circuit-switched bearer,
o if the Offer contained a value for the "callerid" sub-field, MUST o if the Offer contained a value for the "callerid" subfield, MUST
compare that value to the Calling Party Number Information Element compare that value to the Calling Party Number Information Element
of the circuit-switched bearer, of the circuit-switched bearer,
o if the Offer contained a value for the "dtmf" sub-field, MUST be o if the Offer contained a value for the "dtmf" subfield, MUST be
prepared to receive and collect DTMF digits once the circuit- prepared to receive and collect DTMF digits once the circuit-
switched bearer is set up. The Answerer MUST compare the received switched bearer is set up. The Answerer MUST compare the received
DTMF digits to the value of the "dtmf" sub-field. If the received DTMF digits to the value of the "dtmf" subfield. If the received
DTMF digits match the value of the "dtmf" sub-field in the "cs- DTMF digits match the value of the "dtmf" subfield in the "cs-
correlation" attribute, the call SHOULD be treated as correlated correlation" attribute, the call SHOULD be treated as correlated
to the ongoing session. to the ongoing session.
o if the Offer contained a value for the "uuie" sub-field, MUST be o if the Offer contained a value for the "uuie" subfield, MUST be
prepared to receive a User-User Information element once the prepared to receive a User-User Information element once the
circuit-switched bearer is set up. The Answerer MUST compare the circuit-switched bearer is set up. The Answerer MUST compare the
received UUI to the value of the "uuie" sub-field. If the value received UUI to the value of the "uuie" subfield. If the value of
of the received UUI matches the value of the "uuie" sub-field, the the received UUI matches the value of the "uuie" subfield, the
call SHOULD be treated as correlated to the ongoing session. call SHOULD be treated as correlated to the ongoing session.
5.6.3. Offerer processing the Answer 5.6.3. Offerer processing the Answer
When receiving the Answer, if the SDP does not contain "a=cs- When receiving the Answer, if the SDP does not contain "a=cs-
correlation" attribute line, the Offerer should take that as an correlation" attribute line, the Offerer should take that as an
indication that the other party does not support or is not willing to indication that the other party does not support or is not willing to
use the procedures defined in the document for this session, and MUST use the procedures defined in the document for this session, and MUST
revert to normal processing of SDP. revert to normal processing of SDP.
When receiving the Answer, the Offerer MUST first determine whether When receiving the Answer, the Offerer MUST first determine whether
it becomes the active or passive party, as described in Section it becomes the active or passive party, as described in Section
Section 5.3.1. Section 5.3.1.
If the Offerer becomes the active party, it If the Offerer becomes the active party, it
o MUST extract the E.164 number from the "c=" line and MUST o MUST extract the E.164 number from the "c=" line and MUST
establish a circuit-switched bearer to that address. establish a circuit-switched bearer to that address.
o if the SDP Answer contained a value for the "uuie" sub-field, MUST o if the SDP Answer contained a value for the "uuie" subfield, MUST
send the User-User Information element according to the rules send the User-User Information element according to the rules
defined for the circuit-switched technology used, and set the defined for the circuit-switched technology used, and set the
value of the Information Element to that received in the SDP value of the Information Element to that received in the SDP
Answer, Answer,
o if the SDP Answer contained a value for the "dtmf" sub-field, MUST o if the SDP Answer contained a value for the "dtmf" subfield, MUST
send those DTMF digits according to the circuit-switched send those DTMF digits according to the circuit-switched
technology used. technology used.
If the Offerer becomes the passive party, it If the Offerer becomes the passive party, it
o MUST be prepared to receive a circuit-switched bearer, o MUST be prepared to receive a circuit-switched bearer,
o if the Answer contained a value for the "dtmf" sub-field, MUST be o if the Answer contained a value for the "dtmf" subfield, MUST be
prepared to receive and collect DTMF digits once the circuit- prepared to receive and collect DTMF digits once the circuit-
switched bearer is set up. The Offerer SHOULD compare the switched bearer is set up. The Offerer SHOULD compare the
received DTMF digits to the value of the "dtmf" sub-field. If the received DTMF digits to the value of the "dtmf" subfield. If the
received DTMF digits match the value of the "dtmf" sub-field in received DTMF digits match the value of the "dtmf" subfield in the
the "cs-correlation" attribute, the call SHOULD be treated as "cs-correlation" attribute, the call SHOULD be treated as
correlated to the ongoing session. correlated to the ongoing session.
o if the Answer contained a value for the "uuie" sub-field, MUST be o if the Answer contained a value for the "uuie" subfield, MUST be
prepared to receive a User-User Information element once the prepared to receive a User-User Information element once the
circuit-switched bearer is set up. The Offerer SHOULD compare the circuit-switched bearer is set up. The Offerer SHOULD compare the
received UUI to the value of the "uuie" sub-field. If the value received UUI to the value of the "uuie" subfield. If the value of
of the received UUI matches the value of the "uuie" sub-field, the the received UUI matches the value of the "uuie" subfield, the
call SHOULD be treated as correlated to the ongoing session. call SHOULD be treated as correlated to the ongoing session.
5.6.4. Modifying the session 5.6.4. Modifying the session
If, at a later time, one of the parties wishes to modify the session, If, at a later time, one of the parties wishes to modify the session,
e.g., by adding new media stream, or by changing properties used on e.g., by adding new media stream, or by changing properties used on
an existing stream, it may do so via the mechanisms defined for An an existing stream, it may do so via the mechanisms defined for An
Offer/Answer Model with SDP [RFC3264]. Offer/Answer Model with SDP [RFC3264].
If there is an existing circuit-switched bearer between the If there is an existing circuit-switched bearer between the
skipping to change at page 26, line 26 skipping to change at page 27, line 26
;subrules for correlation attribute ;subrules for correlation attribute
attribute /= cs-correlation-attr attribute /= cs-correlation-attr
; attribute defined in RFC 4566 ; attribute defined in RFC 4566
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 / corr-mech = caller-id-mech / uuie-mech /
dtmf-mech / ext-mech dtmf-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value] caller-id-mech = "callerid" [":" caller-id-value]
caller-id-value = "+" 1*15DIGIT caller-id-value = "+" 1*15DIGIT
uuie-mech = "uuie" [":" uuie-value] uuie-mech = "uuie" [":" uuie-value]
uuie-value = 1*32(ALPHA/DIGIT) uuie-value = 1*130(HEXDIG / %x61-66)
;0-9, A-F, and a-f
;HEXDIG defined in RFC5234
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 = ext-mech-name[":" ext-mech-value] ext-mech = ext-mech-name[":" ext-mech-value]
ext-mech-name = token ext-mech-name = token
ext-mech-value = 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
skipping to change at page 27, line 43 skipping to change at page 28, line 43
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5
s= s=
t=0 0 t=0 0
m=audio 9 PSTN - m=audio 9 PSTN -
c=PSTN E164 +35891234567 c=PSTN E164 +35891234567
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=cs-correlation:callerid:+15551234 \ a=cs-correlation:callerid:+15551234 \
uuie:2890W284hAT452612908awudfjang908 uuie:56a390f3d2b7310023
Figure 4: SDP offer (1) Figure 4: SDP offer (1)
Bob generates a SDP Answer (Figure 5), describing a PSTN audio media Bob generates a SDP Answer (Figure 5), describing a PSTN audio media
on port 9 without information on the media sub-type on the "m=" line. on port 9 without information on the media sub-type on the "m=" line.
The "c=" line contains Bob's international E.164 number. In the The "c=" line contains Bob's international E.164 number. In the
"a=setup" line Bob indicates that he is willing to become the active "a=setup" line Bob indicates that he is willing to become the active
endpoint when establishing the PSTN call, and he also includes the endpoint when establishing the PSTN call, and he also includes the
"a=cs-correlation" attribute line containing the values he is going "a=cs-correlation" attribute line containing the values he is going
to include in the Calling Party Number and User-User IE of the PSTN to include in the Calling Party Number and User-User IE of the PSTN
skipping to change at page 28, line 16 skipping to change at page 29, line 16
v=0 v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7 o=- 2890973824 2890987289 IN IP4 192.0.2.7
s= s=
t=0 0 t=0 0
m=audio 9 PSTN - m=audio 9 PSTN -
c=PSTN E164 +35897654321 c=PSTN E164 +35897654321
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cs-correlation:callerid:+15554321 \ a=cs-correlation:callerid:+15554321 \
uuie:2127W49uThi455916adjfhtow9619361 uuie:56a390f3d2b7310023
Figure 5: SDP Answer with circuit-switched media Figure 5: SDP Answer with circuit-switched media
When Alice receives the Answer, she examines that Bob is willing to When Alice receives the Answer, she examines that Bob is willing to
become the active endpoint when setting up the PSTN call. Alice become the active endpoint when setting up the PSTN call. Alice
temporarily stores Bob's E.164 number and the User-User IE value of temporarily stores Bob's E.164 number and the User-User IE value of
the "cs-correlation" attribute, and waits for a circuit-switched the "cs-correlation" attribute, and waits for a circuit-switched
bearer establishment. bearer establishment.
Bob initiates a circuit-switched bearer using whatever circuit- Bob initiates a circuit-switched bearer using whatever circuit-
skipping to change at page 29, line 47 skipping to change at page 30, line 47
Figure 7: SDP offer with circuit-switched audio and video (1) Figure 7: SDP offer with circuit-switched audio and video (1)
Upon receiving the SDP offer descibed in Figure 7, Bob rejects the Upon receiving the SDP offer descibed in Figure 7, Bob rejects the
video stream as his device does not currently support video, but video stream as his device does not currently support video, but
accepts the circuit-switched audio stream. As Alice indicated that accepts the circuit-switched audio stream. As Alice indicated that
she is able to become either the active, or passive party, Bob gets she is able to become either the active, or passive party, Bob gets
to select which role he would like to take. Since the Offer to select which role he would like to take. Since the Offer
contained the international E.164 number of Alice, Bob decides that contained the international E.164 number of Alice, Bob decides that
he becomes the active party in setting up the circuit-switched he becomes the active party in setting up the circuit-switched
bearer. Bob includes a new value in the cs-correlation:dtmf sub- bearer. Bob includes a new value in the "dtmf" subfield of the "cs-
field, which he is going send as DTMF tones once the bearer setup is correlation" attribute, which he is going send as DTMF tones once the
complete. The Answer is described in Figure 8 bearer setup is complete. The Answer is described in Figure 8
v=0 v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7 o=- 2890973824 2890987289 IN IP4 192.0.2.7
s= s=
t=0 0 t=0 0
a=setup:active a=setup:active
a=connection:new a=connection:new
a=cs-correlation:dtmf:332211 a=cs-correlation:dtmf:332211
c=PSTN E164 +35897654321 c=PSTN E164 +35897654321
m=audio 9 PSTN - m=audio 9 PSTN -
m=video 0 PSTN 34 m=video 0 PSTN 34
skipping to change at page 33, line 24 skipping to change at page 34, line 24
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
Capability Negotiation", RFC 5939, September 2010. Capability Negotiation", RFC 5939, September 2010.
10.2. Informative References 10.2. Informative References
[I-D.ietf-cuss-sip-uui]
Johnston, A. and J. Rafferty, "A Mechanism for
Transporting User to User Call Control Information in
SIP", draft-ietf-cuss-sip-uui-06 (work in progress),
May 2012.
[ITU.E164.1991] [ITU.E164.1991]
International Telecommunications Union, "The International International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU- Public Telecommunication Numbering Plan", ITU-
T Recommendation E.164, 1991. T Recommendation E.164, 1991.
[ITU.Q931.1998] [ITU.Q931.1998]
"Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN
User - Network Interface Layer 3 Specification for Basic User - Network Interface Layer 3 Specification for Basic
Call Control", ISO Standard 9594-1, May 1998. Call Control", ISO Standard 9594-1, May 1998.
skipping to change at page 34, line 31 skipping to change at page 35, line 38
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Ericsson Ericsson
Calle Via de los Poblados 13 Calle Via de los Poblados 13
Madrid, ES 28033 Madrid, ES 28033
Spain Spain
Email: miguel.a.garcia@ericsson.com Email: miguel.a.garcia@ericsson.com
Simo Veikkolainen Simo Veikkolainen
Nokia Nokia
P.O. Box 407 P.O. Box 226
NOKIA GROUP, FI 00045 NOKIA GROUP, FI 00045
Finland Finland
Phone: +358 50 486 4463 Phone: +358 50 486 4463
Email: simo.veikkolainen@nokia.com Email: simo.veikkolainen@nokia.com
 End of changes. 59 change blocks. 
135 lines changed or deleted 178 lines changed or added

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