draft-ietf-mmusic-sdp-cs-11.txt   draft-ietf-mmusic-sdp-cs-12.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: November 15, 2012 Nokia Expires: April 11, 2013 Nokia
May 14, 2012 October 8, 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-11 draft-ietf-mmusic-sdp-cs-12
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 November 15, 2012. This Internet-Draft will expire on April 11, 2013.
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 19 skipping to change at page 3, line 19
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 7 4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . 13
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 . . . . . . . . . . . . 16 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . . 16
5.2.3.5. Extensions to correlation mechanisms . . . . . . . 17
5.3. Negotiating the correlation mechanisms . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . 17 Bearer Setup . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. Populating the cs-correlation attribute . . . . . . . 18 5.3.2. Populating the cs-correlation attribute . . . . . . . 18
5.3.3. Considerations on successful correlation . . . . . . . 18 5.3.3. Considerations on successful correlation . . . . . . . 19
5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19 5.4. Considerations for Usage of Existing SDP . . . . . . . . . 19
5.4.1. Originator of the Session . . . . . . . . . . . . . . 19 5.4.1. Originator of the Session . . . . . . . . . . . . . . 20
5.4.2. Contact information . . . . . . . . . . . . . . . . . 19 5.4.2. Contact information . . . . . . . . . . . . . . . . . 20
5.5. Considerations for Usage of Third Party Call Control 5.5. Considerations for Usage of Third Party Call Control
(3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 19 (3PCC) . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 20 5.6. Offer/Answer mode extensions . . . . . . . . . . . . . . . 21
5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 20 5.6.1. Generating the Initial Offer . . . . . . . . . . . . . 21
5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 22 5.6.2. Generating the Answer . . . . . . . . . . . . . . . . 23
5.6.3. Offerer processing the Answer . . . . . . . . . . . . 25 5.6.3. Offerer processing the Answer . . . . . . . . . . . . 25
5.6.4. Modifying the session . . . . . . . . . . . . . . . . 26 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 27
5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 28 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . . 29
6.2. Advanced SDP example: Circuit-Switched Audio and Video 6.2. Advanced SDP example: Circuit-Switched Audio and Video
Streams . . . . . . . . . . . . . . . . . . . . . . . . . 30 Streams . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8.1. Registration of new cs-correlation SDP attribute . . . . . 32 8.1. Registration of new cs-correlation SDP attribute . . . . . 33
8.2. Registration of a new "nettype" value . . . . . . . . . . 32 8.2. Registration of a new "nettype" value . . . . . . . . . . 34
8.3. Registration of new "addrtype" values . . . . . . . . . . 33 8.3. Registration of new "addrtype" values . . . . . . . . . . 34
8.4. Registration of a new "proto" value . . . . . . . . . . . 33 8.4. Registration of a new "proto" value . . . . . . . . . . . 34
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . . 33 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
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 6, line 26 skipping to change at page 6, line 26
There are additional use cases related to third party call control There are additional use cases related to third party call control
where the session setup time is improved when the circuit-switched where the session setup time is improved when the circuit-switched
bearer in the PSTN is described together with one or more codecs. bearer in the PSTN is described together with one or more codecs.
The rest of the document is structured as follows: Section 2 provides The rest of the document is structured as follows: Section 2 provides
the document conventions, Section 3 introduces the requirements, the document conventions, Section 3 introduces the requirements,
Section 4 presents an overview of the proposed solutions, and Section 4 presents an overview of the proposed solutions, and
Section 5 contains the protocol description. Section 6 provides an Section 5 contains the protocol description. Section 6 provides an
example of descriptions of circuit-switched audio or video streams in example of descriptions of circuit-switched audio or video streams in
SDP. Section 8 and Section 7 contain the IANA and Security SDP. Section 7 and Section 8 contain the Security and IANA
considerations, respectively. considerations, respectively.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 [RFC2119] and indicate requirement levels for compliant 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
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. A new network type ("PSTN") and a new protocol type ("PSTN")
able to describe a media stream over a circuit-switched bearer. are defined for the "c=" and "m=" lines to be able to describe a
These SDP extensions are described in Section 5.2. Since circuit- media stream over a circuit-switched bearer. These SDP extensions
switched bearers are connection-oriented media streams, the mechanism are described in Section 5.2. Since circuit-switched bearers are
re-uses the connection-oriented extensions defined in RFC 4145 connection-oriented media streams, the mechanism re-uses the
[RFC4145] to negotiate the active and passive sides of a connection connection-oriented extensions defined in RFC 4145 [RFC4145] to
setup. This is further described in Section 5.3.1. negotiate the active and passive sides of a connection setup. This
is further described in Section 5.3.1.
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 9, line 40 skipping to change at page 9, line 40
At the moment, the only network type defined is "IN", which indicates At the moment, the only network type defined is "IN", which indicates
Internet network type. The address types "IP4" and "IP6" indicate Internet network type. The address types "IP4" and "IP6" indicate
the type of IP addresses. the type of IP addresses.
This memo defines a new network type for describing a circuit- This memo defines a new network type for describing a circuit-
switched bearer network type in the PSTN. The mnemonic "PSTN" is switched bearer network type in the PSTN. The mnemonic "PSTN" is
used for this network type. used for this network type.
For the address type, we initially consider the possibility of For the address type, we initially consider the possibility of
describing E.164 telephone numbers. We define a new "E164" address describing E.164 telephone numbers. We define a new "E164" address
type. When used, the "E164" address type indicates that the type to be used within the context of a "PSTN" network type. The
connection address contains an international E.164 number represented "E164" address type indicates that the connection address contains an
according to the ITU-T E.164 [ITU.E164.1991] recommendation. E.164 number represented according to the ITU-T E.164 [ITU.E164.1991]
recommendation.
It is a common convention that an international E.164 number contains It is a common convention that an international E.164 number contains
a leading '+' sign. For consistency's sake, we also require the a leading '+' sign. For consistency's sake, we also require the
E.164 telephone is prepended with a '+', even if that is not E.164 telephone is prepended with a '+', even if that is not
necessary for routing of the call in the PSTN network. necessary for routing of the call in the PSTN network.
There are cases, though, when the endpoint is merely aware of a There are cases, though, when the endpoint is merely aware of a
circuit-switched bearer, without having further information about the circuit-switched bearer, without having further information about the
address type or the E.164 number allocated to it. In these cases a address type or the E.164 number allocated to it. In these cases a
dash "-" is used to indicate an unknown address type or connection dash "-" is used to indicate an unknown address type or connection
address. This makes the connection data line be according to the SDP address. This makes the connection data line be according to the SDP
syntax. syntax.
Note that <addrtype> and/or <connection-address> should not be Please note that this "E164" and "-" address type defined in this
omitted without being set to a "-" since this would violate basic memo are exclusively defined to be used in conjunction with the
syntax of SDP [RFC4566]. "PSTN" network type. Usages of "E164" or "-" address types in
conjunction with other network types may exist elsewhere.
This memo exclusively uses the international representation of E.164
numbers, i.e., those initiated with a '+' sign. The syntax (see
Section 5.7) refers to the representation of a 'global-number'
construction already specified in RFC 3966 [RFC3966]. This
representation requires the presence of the '+' sign. Additionally,
this representation allows for the presence of one or more 'visual-
separator' constructions. Implementations confirming to this
specification and using the "E164" address type together with the
"PSTN" network type MUST only use international E.164, i.e., those
starting with a '+' sign and SHOULD NOT use visual-separators.
Note that <addrtype> and/or <connection-address> MUST NOT be
omitted when unknown since this would violate basic syntax of SDP
[RFC4566]. In such cases, they MUST be set to a "-".
The following are examples of the extension to the connection data The following are examples of the extension to the connection data
line: line:
c=PSTN E164 +35891234567 c=PSTN E164 +35891234567
c=PSTN - - c=PSTN - -
When the <addrtype> is PSTN, the connection address is defined as When the <addrtype> is PSTN, the connection address is defined as
follows: follows:
skipping to change at page 12, line 44 skipping to change at page 13, line 13
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" attribute can include any of the "callerid", "uuie", or "dtmf"
subfields, 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, see Section 5.2.3.5 fore more details. There
MUST be at most one "cs-correlation" attribute per media description.
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 /
dfmt-mech / ext-mech dfmt-mech / ext-mech
caller-id-mech = "callerid" [":" caller-id-value] caller-id-mech = "callerid" [":" caller-id-value]
uuie-mech = "uuie" [":" uuie-value] uuie-mech = "uuie" [":" uuie-value]
skipping to change at page 14, line 49 skipping to change at page 15, line 16
Element (UUIE) identifier is composed of a first octet identifying Element (UUIE) identifier is composed of a first octet identifying
this as a User-User Information Element, a second octet containing this as a User-User Information Element, a second octet containing
the Length of the user-user contents, a third octet containing a the Length of the user-user contents, a third octet containing a
Protocol Discriminator, and a value of up to 32 or 128 octets Protocol Discriminator, and a value of up to 32 or 128 octets
(depending on network settings) containing the actual User (depending on network settings) containing the actual User
Information (see Figure 4-36 in ITU-T Q.931). The first two octets Information (see Figure 4-36 in ITU-T Q.931). The first two octets
of the UUIE MUST NOT be used for correlation, only the octets of the UUIE MUST NOT be used for correlation, only the octets
carrying the Protocol Discriminator and the User Information value carrying the Protocol Discriminator and the User Information value
are input to the creation of the value of the "uuie" subfield in the are input to the creation of the value of the "uuie" subfield in the
"cs-correlation" attribute. Therefore, the value of the "uuie" "cs-correlation" attribute. Therefore, the value of the "uuie"
subfield in the "cs-correlation" attribute MUST start with the the subfield in the "cs-correlation" attribute MUST start with the
value starting at the Protocol Discriminator octet, followed by the Protocol Discriminator octet, followed by the User Information
User Information octets. The value of the Protocol Discriminator octets. The value of the Protocol Discriminator octet is not
octet is not specified in this document; it is expected that specified in this document; it is expected that organizations using
organizations using this technology will allocate a suitable value this technology will allocate a suitable value for the Protocol
for the Protocol Discriminator. Discriminator.
Once the binary value of the "uuie" subfield in the "cs-correlation" Once the binary value of the "uuie" subfield in the "cs-correlation"
attribute is created, it MUST be encoded in hexadecimal before it is 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 inserted in SDP. Each octet of binary data to be represented in the
hexadecimal encoding MUST be mapped to two hexadecimal digits hexadecimal encoding MUST be mapped to two hexadecimal digits
(represented by ASCII characters 0-9, A-F and a-f), each representing (represented by ASCII characters 0-9 and A-F, each representing four
four bits within the octet. The four bits appearing first in the bits within the octet. The four bits appearing first in the binary
binary data MUST be mapped to the first hexadecimal digit and the data MUST be mapped to the first hexadecimal digit and the four
four subsequent bits in the binary data MUST be mapped to the second subsequent bits in the binary data MUST be mapped to the second
hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the
bit appearing first in the binary data shall be most significant. bit appearing first in the binary data SHALL be most significant.
Thus, the resulting hexadecimal encoded value needs to have an even Thus, the resulting hexadecimal encoded value needs to have an even
number of hexadecimal digits, and MUST be considered invalid if it number of hexadecimal digits, and MUST be considered invalid if it
has an odd number. has an odd number.
Note that the encoding of the "uuie" subfield of the "cs- Note that the encoding of the "uuie" subfield of the "cs-
correlation" attribute is largely inspired by the encoding of the correlation" attribute is largely inspired by the encoding of the
same value in the User-to-User header field in SIP, according to same value in the User-to-User header field in SIP, according to
the document A Mechanism for Transporting User to User Call the document A Mechanism for Transporting User to User Call
Control Information in SIP [I-D.ietf-cuss-sip-uui]. Control Information in SIP [I-D.ietf-cuss-sip-uui].
As an example, an endpoint willing to send a UUIE containing a As an example, an endpoint willing to send a UUIE containing a
protocol discriminator with the hexadecimal value of %x56 and an protocol discriminator with the hexadecimal value of %x56 and an
hexadecimal User Information value of %xa390f3d2b7310023 would hexadecimal User Information value of %xA390F3D2B7310023 would
include a "cs-correlation" attribute line as follows: include a "cs-correlation" attribute line as follows:
a=cs-correlation:uuie:56a390f3d2b7310023 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 an 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
mechanism works. On one side, policy restrictions might not make the mechanism works. On one side, policy restrictions might not make the
User-User information available end to end in the PSTN. On the other User-User information available end to end in the PSTN. On the other
hand, the generation of the User-User Information Element is hand, the generation of the User-User Information Element is
skipping to change at page 17, line 7 skipping to change at page 17, line 22
SHOULD treat the circuit-switched bearer as not correlated to the SHOULD treat the circuit-switched bearer as not correlated to the
ongoing session. ongoing session.
DTMF digits can only be sent once the circuit-switched bearer is DTMF digits can only be sent once the circuit-switched bearer is
set up. In order to suppress alerting for an incoming circuit- set up. In order to suppress alerting for an incoming circuit-
switched call, implementations may choose various mechanisms. For switched call, implementations may choose various mechanisms. For
example, alerting may be suppressed for a certain time period for example, alerting may be suppressed for a certain time period for
incoming call attempts that originate from the number that was incoming call attempts that originate from the number that was
observed during the offer/answer negotiation. observed during the offer/answer negotiation.
5.2.3.5. Extensions to correlation mechanisms
New values for the "cs-correlation" attribute may be specified. The
registration policy for new values is "Specification Required", see
Section 8. Any such specification MUST include a description of how
SDP Offer/Answer mechanism is used to negotiate the use of the new
values, taking into account how endpoints determine which side will
become active or passive (see Section 5.3 for more details).
If, during the Offer/Answer negotiation, either endpoint encounters
an unknown value in the "cs-correlation" attribute, it MUST consider
that mechanism as unsupported, and MUST NOT include that value in
subsequent Offer/Answer negotiation.
5.3. Negotiating the correlation mechanisms 5.3. Negotiating the correlation mechanisms
The three correlation mechanisms presented above (based on called The three correlation mechanisms presented above (based on called
party number, User-User Information Element and DTMF digit sending) party number, User-User Information Element and DTMF digit sending)
are non-exclusive, and can be used independently of each other. In are non-exclusive, and can be used independently of each other. In
order to know how to populate the "a=cs-correlation" attribute, the order to know how to populate the "cs-correlation" attribute, the
endpoints need to agree which endpoint will become the active party, endpoints need to agree which endpoint will become the active party,
i.e. the one that will set up the circuit-switched bearer. i.e. the one that will set up the circuit-switched bearer.
5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup 5.3.1. Determining the Direction of the Circuit-Switched Bearer Setup
In order to avoid a situation where both endpoints attempt to In order to avoid a situation where both endpoints attempt to
initiate a connection simultaneously, the direction in which the initiate a connection simultaneously, the direction in which the
circuit-switched bearer is set up should be negotiated during the circuit-switched bearer is set up MUST be negotiated during the
Offer/Answer exchange. Offer/Answer exchange.
The framework defined in RFC 4145 [RFC4145] allows the endpoints to The framework defined in RFC 4145 [RFC4145] allows the endpoints to
agree which endpoint acts as the active endpoint when initiating a agree which endpoint acts as the active endpoint when initiating a
TCP connection. While RFC 4145 [RFC4145] was originally designed for TCP connection. While RFC 4145 [RFC4145] was originally designed for
establishing TCP connections, it can be easily extrapolated to the establishing TCP connections, it can be easily extrapolated to the
connection establishment of circuit-switched bearers. This connection establishment of circuit-switched bearers. This
specification uses the concepts specified in RFC 4145 [RFC4145] for specification uses the concepts specified in RFC 4145 [RFC4145] for
agreeing on the direction of establishment of a circuit-switched agreeing on the direction of establishment of a circuit-switched
bearer. bearer.
skipping to change at page 17, line 50 skipping to change at page 18, line 30
The "connection" attribute indicates whether a new connection is The "connection" attribute indicates whether a new connection is
needed or an existing connection is reused. The attribute can take needed or an existing connection is reused. The attribute can take
the values "new" or "existing". Please refer to Section 5 of RFC the values "new" or "existing". Please refer to Section 5 of RFC
4145 [RFC4145] for a detailed description of this attribute. 4145 [RFC4145] for a detailed description of this attribute.
Implementations according to this specification MUST support the Implementations according to this specification MUST support the
"setup" and "connection" attributes specified in RFC 4145 [RFC4145], "setup" and "connection" attributes specified in RFC 4145 [RFC4145],
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 exchange. The passive party
the one receiving the circuit-switched bearer. Either party may is 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 subfields 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.
skipping to change at page 20, line 27 skipping to change at page 21, line 9
Note that this may result in the recipient of the initial Offer in Note that this may result in the recipient of the initial Offer in
rejecting the Offer if the recipient of the Offer is not aware of rejecting the Offer if the recipient of the Offer is not aware of
its own E.164 number, and thus concluding that it will not be its own E.164 number, and thus concluding that it will not be
possible to establish a circuit-switched bearer since neither possible to establish a circuit-switched bearer since neither
party is aware of their E.164 number. party is aware of their E.164 number.
5.6. Offer/Answer mode extensions 5.6. Offer/Answer mode extensions
In this section, we define extensions to the Offer/Answer model In this section, we define extensions to the Offer/Answer model
defined in The Offer/Answer Model in SDP [RFC3264] and extended in defined in The Offer/Answer Model in SDP [RFC3264] to allow for PSTN
the SDP Capability Negotiation [RFC5939] to allow for PSTN addresses addresses to be used with the Offer/Answer model.
to be used with the Offer/Answer model.
5.6.1. Generating the Initial Offer 5.6.1. Generating the Initial Offer
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
skipping to change at page 21, line 11 skipping to change at page 21, line 40
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 Offerer MUST
correlation" line contains an enumeration of the correlation NOT include more than one "cs-correlation" attribute per media
mechanisms supported by the Offerer, in the format of subfields. decription. The "a=cs-correlation" line contains an enumeration of
the correlation mechanisms supported by the Offerer, in the format of
subfields.
The current list of subfields 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" subfields and MUST MUST add the "callerid", "uuie", and/or "dtmf" subfields and MUST
specify values for those subfields. specify values for those subfields.
skipping to change at page 21, line 50 skipping to change at page 22, line 33
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:56a390f3d2b7310023 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.
By 'active' endpoint, we refer to an endpoint that will establish the By 'active' endpoint, we refer to an endpoint that will establish the
circuit-switched bearer; and by 'passive' endpoint, we refer to an circuit-switched bearer; and by 'passive' endpoint, we refer to an
endpoint that will receive a circuit-switched bearer. endpoint that will receive a circuit-switched bearer.
If an Offerer does not know its international E.164 number, it MUST If an Offerer does not know its international E.164 number, it MUST
set the 'a=setup' attribute to the value 'active'. If the Offerer set the 'a=setup' attribute to the value 'active'. If the Offerer
knows its international E.164 number, it MUST set the value to either knows its international E.164 number, it SHOULD set the value to
'actpass' or 'passive'. either 'actpass' or 'passive'.
Also 'holdconn' is a permissible value in the 'a=setup' attribute. Also 'holdconn' is a permissible value in the 'a=setup' attribute.
It indicates that the connection is not established for the time It indicates that the connection is not established for the time
being. being.
The Offerer uses the "a=connection" attribute to decide whether a new The Offerer uses the "a=connection" attribute to decide whether a new
circuit-switched bearer is to be established or not. For the initial circuit-switched bearer is to be established or not. For the initial
Offer, the Offerer MUST use value 'new'. Offer, the Offerer MUST use value 'new'.
5.6.2. Generating the Answer 5.6.2. Generating the Answer
skipping to change at page 23, line 21 skipping to change at page 24, line 4
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
number to zero on the Answer. If the Answerer is aware of its number to zero on the Answer. If the Answerer is aware of its
international E.164 number, it MUST include the "a=setup" attribute international E.164 number, it MUST include the "a=setup" attribute
in the Answer and set it to value "passive" or "holdconn". in the Answer and set it to value "passive" or "holdconn". The
Answerer MUST also include its E.164 number of the "c=" line.
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 passive party, the Answerer MUST verify that the Offerer's become the passive party, the Answerer MUST verify that the Offerer's
E.164 number is included in the "c=" line of the Offer. If the E.164 number is included in the "c=" line of the Offer. If the
number is included, the Answerer MUST include the "a=setup" attribute number is included, the Answerer MUST include the "a=setup" attribute
in the Answer and set it to value "active" or "holdconn". If the in the Answer and set it to value "active" or "holdconn". If the
number is not included, call establishment is not possible, and the number is not included, call establishment is not possible, and the
Answerer MUST reject the circuit-switched media by setting the port Answerer MUST reject the circuit-switched media by setting the port
number to zero in the Answer. number to zero in the Answer.
skipping to change at page 23, line 45 skipping to change at page 24, line 29
international E.164 number in the "c=" line, the Answerer SHOULD international E.164 number in the "c=" line, the Answerer SHOULD
become the active party. If the Offer does not include an E.164 become the active party. If the Offer does not include an E.164
number, and if the Answerer is aware of its international E.164 number, and if the Answerer is aware of its international E.164
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 and is willing to use.
NOT add any mechanisms which were not included in the offer. The Answerer MUST NOT add any mechanisms which were not included in
the offer. If there are more than one "cs-correlation" attributes
per media description in the Offer, the Answerer MUST discard all but
the first for any media description. Also, the Answerer MUST discard
all unknown "cs-correlation" attribute values.
If the Answerer becomes the active party, it MUST add any of the If the Answerer becomes the active party, it MUST add any of the
"callerid", "uuie" or "dtmf" subfield values. "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" subfields. 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" subfield, 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" subfield, 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" subfield, 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
skipping to change at page 25, line 5 skipping to change at page 25, line 38
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" subfield, 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" subfield. If the value of received UUI to the value of the "uuie" subfield. If the value of
the received UUI matches the value of the "uuie" subfield, 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.
If the Answerer becomes the active party, generates an SDP answer,
and then it finds out that the circuit-switched call cannot be
established, then such endpoint MUST create a new SDP offer where
circuit-switched stream is removed from the session (actually, by
setting the corresponding port in the m= line to zero) and send it to
its counter part. This is to synchronize both parties (and potential
intermediaries) on the state of the 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
skipping to change at page 25, line 36 skipping to change at page 26, line 28
Answer, Answer,
o if the SDP Answer contained a value for the "dtmf" subfield, 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 Note that it if deliver of the Answer is delayed for some reason,
the circuit-switched call may arrive at the Offerer before the
Answer has been processed. In this case, since the correlation
mechanisms are negotiated as part of the Offer/Answer exchange,
the Answerer cannot know whether the incoming call attempt is
correlated with the session being negotiated, the Offerer SHOULD
accept the call only after it has received and processed the
Answer.
o if the Answer contained a value for the "dtmf" subfield, 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" subfield. If the received DTMF digits to the value of the "dtmf" subfield. If the
received DTMF digits match the value of the "dtmf" subfield in the received DTMF digits match the value of the "dtmf" subfield in 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" subfield, 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
skipping to change at page 26, line 34 skipping to change at page 27, line 34
exchange where it MUST set the "a=connection" attribute to 'new'". exchange where it MUST set the "a=connection" attribute to 'new'".
If the media types are different (for example, a different codec will If the media types are different (for example, a different codec will
be used for the circuit-switched bearer), the media descriptions for be used for the circuit-switched bearer), the media descriptions for
terminating the existing bearer and the new bearer can be in the same terminating the existing bearer and the new bearer can be in the same
Offer. Offer.
5.7. Formal Syntax 5.7. Formal Syntax
The following is the formal Augmented Backus-Naur Form (ABNF) The following is the formal Augmented Backus-Naur Form (ABNF)
[RFC5234] syntax that supports the extensions defined in this [RFC5234] syntax that supports the extensions defined in this
specification. The syntax is built above the SDP [RFC4566] grammar. specification. The syntax is built above the SDP [RFC4566] and the
Implementations according to this specification MUST be compliant tel URI [RFC3966] grammars. Implementations according to this
with this syntax. specification MUST be compliant with this syntax.
Figure 2 shows the formal syntax of the extensions defined in this Figure 2 shows the formal syntax of the extensions defined in this
memo. memo.
; extension to the connection field originally specified ; extension to the connection field originally specified
; in RFC 4566 ; in RFC 4566
connection-field = [%x63 "=" nettype SP addrtype SP connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF] connection-address CRLF]
;nettype and addrtype are defined in RFC 4566 ;nettype and addrtype are defined in RFC 4566
connection-address /= e164-address / "-" connection-address /= global-number / "-"
e164-address = "+" 1*15DIGIT ; global-number specified in RFC 3966
; DIGIT is specified in RFC 5234
;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*130(HEXDIG / %x61-66) uuie-value = 1*65(HEXDIG HEXDIG)
;0-9, A-F, and a-f ;This represents up to 130 HEXDIG (65 octets)
;HEXDIG defined in RFC5234 ;HEXDIG defined in RFC5234
dtmf-mech = "dtmf" [":" dtmf-value] ;HEXDIG defined as 0-9, A-F
dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A ) dtmf-mech = "dtmf" [":" dtmf-value]
;0-9, A-D, '#' and '*' dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A )
ext-mech = ext-mech-name[":" ext-mech-value] ;0-9, A-D, '#' and '*'
ext-mech-name = token ext-mech = ext-mech-name[":" ext-mech-value]
ext-mech-value = token ext-mech-name = token
; token is specified in RFC4566 ext-mech-value = token
; token is specified in RFC4566
Figure 2: Syntax of the SDP extensions Figure 2: Syntax of the SDP extensions
6. Examples 6. Examples
In the examples below, where an SDP line is too long to be displayed In the examples below, where an SDP line is too long to be displayed
as a single line, a braking character "\" indicates continuation in as a single line, a breaking character "\" indicates continuation in
the following line. Note that this is character is included for the following line. Note that this character is included for display
displaying purposes. Implementation MUST write a single line without purposes only. Implementation MUST write a single line without
brakes. breaks.
6.1. Single PSTN audio stream 6.1. Single PSTN 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) |
|<---------------------------------| |<---------------------------------|
skipping to change at page 28, line 25 skipping to change at page 29, line 25
| PSTN call setup | | PSTN call setup |
|<---------------------------------| |<---------------------------------|
| | | |
|<==== media over PSTN bearer ====>| |<==== media over PSTN bearer ====>|
| | | |
Figure 3: Basic flow Figure 3: Basic flow
Figure 3 shows a basic example that describes a single audio media Figure 3 shows a basic example that describes a single audio media
stream over a circuit-switched bearer. Alice generates a SDP Offer stream over a circuit-switched bearer. Alice generates a SDP Offer
which is show in Figure 4. The Offer describes a PSTN circuit- which is shown in Figure 4. The Offer describes a PSTN circuit-
switched bearer in the "m=" and "c=" line where it also indicates its switched bearer in the "m=" and "c=" line where it also indicates its
international E.164 number format. Additionally, Alice expresses international E.164 number format. Additionally, Alice expresses
that she can initiate the circuit-switched bearer or be the recipient that she can initiate the circuit-switched bearer or be the recipient
of it in the "a=setup" attribute line. The SDP Offer also includes a of it in the "a=setup" attribute line. The SDP Offer also includes
correlation identifiers that this endpoint will be inserting the correlation identifiers that this endpoint will insert in the Calling
Calling Party Number and/or User-User Information Element of the PSTN Party Number and/or User-User Information Element of the PSTN call
call setup if eventually this endpoint initiates the PSTN call. setup if eventually this endpoint initiates the PSTN call.
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:56a390f3d2b7310023 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 29, line 16 skipping to change at page 30, 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:56a390f3d2b7310023 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-
switched technology is available for him. The called party number is switched technology is available for him. The called party number is
set to Alice's number, and calling party number is set to Bob's own set to Alice's number, and calling party number is set to Bob's own
number. Bob also sets the User-User Information Element value to the number. Bob also sets the User-User Information Element value to the
on contained in the SDP Answer. one contained in the SDP Answer.
When Alice receives the circuit-switched bearer establishment, she When Alice receives the circuit-switched bearer establishment, she
examines the UUIE and the calling party number, and by comparing examines the UUIE and the calling party number, and by comparing
those received during O/A exchange determines that the call is those received during O/A exchange determines that the call is
related to the SDP session. related to the SDP session.
It may also be that neither the UUIE nor the calling party number is It may also be that neither the UUIE nor the calling party number is
received by the called party, or the format of the calling party received by the called party, or the format of the calling party
number is changed by the PSTN. Implementations may still accept such number is changed by the PSTN. Implementations may still accept such
call establishment attempts as being related to the session that was call establishment attempts as being related to the session that was
skipping to change at page 32, line 6 skipping to change at page 33, line 6
calling line identification into account if possible, by restricting calling line identification into account if possible, by restricting
the inclusion of the phone number in SDP "c=" line if the caller has the inclusion of the phone number in SDP "c=" line if the caller has
chosen to use CLIR. If this is not possible, implementations may chosen to use CLIR. If this is not possible, implementations may
present a prompt informing the user that their phone number may be present a prompt informing the user that their phone number may be
transmitted to the other party. transmitted to the other party.
Similarly as with IP addresses, if there is a desire the protect the Similarly as with IP addresses, if there is a desire the protect the
SDP containing phone numbers carried in SIP, implementers are adviced SDP containing phone numbers carried in SIP, implementers are adviced
to follow the security mechanisms defined in [RFC3261]. to follow the security mechanisms defined in [RFC3261].
It is possible that an attacker creates a circuit-switched session
whereby the attacked endpoint should dial a circuit-switched number,
perhaps even a premium-rate telephone number. To mitigate the
consequences of this attack, endpoints MUST authenticate and trust
remote endpoints users who try to remain passive in the circuit-
switched connection establishment. It is RECOMMENDED that endpoints
have local policies precluding the active establishment of circuit
switched connections to certain numbers (e.g., international,
premium, long distance). Additionally, it is strongly RECOMMENDED
that the end user is asked for consent prior to the endpoint
initiating a circuit-switched connection which might incur in
charges.
8. IANA Considerations 8. IANA Considerations
This document instructs IANA to register a number of SDP tokens This document instructs IANA to register a number of SDP tokens
according to the following data. according to the following data.
8.1. Registration of new cs-correlation SDP attribute 8.1. Registration of new cs-correlation SDP attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Attribute name: cs-correlation Attribute name: cs-correlation
skipping to change at page 32, line 28 skipping to change at page 33, line 41
Type of attribute: media level only Type of attribute: media level only
This attribute is subject to the charset attribute This attribute is subject to the charset attribute
Description: This attribute provides the Correlation Identifier Description: This attribute provides the Correlation Identifier
used in PSTN signaling used in PSTN signaling
Specification: RFC XXXX Specification: RFC XXXX
The IANA is requested the create a subregistry for 'cs-correlation' The IANA is requested to create a subregistry for 'cs-correlation'
attribute under the Session Description Protocol (SDP) Parameters attribute under the Session Description Protocol (SDP) Parameters
registry. The initial values for the subregistry are presented in registry. The initial values for the subregistry are presented in
the following, and IANA is requested to add them into its database: the following, and IANA is requested to add them into its database:
Value of 'cs-correlation' attribute Reference Description Value of 'cs-correlation' attribute Reference Description
----------------------------------- --------- ----------- callerid ----------------------------------- --------- ----------- callerid
RFC XXXX Caller ID uuie RFC XXXX User-User Information Element dtmf RFC XXXX Caller ID uuie RFC XXXX User-User Information Element dtmf
RFC XXXX Dual-tone Multifrequency RFC XXXX Dual-tone Multifrequency
Note for the RFC Editor: 'RFC XXXX' above should be replaced by a Note for the RFC Editor: 'RFC XXXX' above should be replaced by a
reference to the RFC number of this draft. reference to the RFC number of this draft.
As per the terminology in [RFC2434], the registration policy for new As per the terminology in [RFC5226], the registration policy for new
values of 'cs-correlation' parameter is 'Specification Required'. values of 'cs-correlation' parameter is 'Specification Required'.
8.2. Registration of a new "nettype" value 8.2. Registration of a new "nettype" value
This memo provides instructions to IANA to register a new "nettype" This memo provides instructions to IANA to register a new "nettype"
in the Session Description Protocol Parameters registry [1]. The in the Session Description Protocol Parameters registry [1]. The
registration data, according to RFC 4566 [RFC4566] follows. registration data, according to RFC 4566 [RFC4566] follows.
Type SDP Name Reference Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
skipping to change at page 33, line 20 skipping to change at page 34, line 31
This memo provides instructions to IANA to register a new "addrtype" This memo provides instructions to IANA to register a new "addrtype"
in the Session Description Protocol Parameters registry [1]. The in the Session Description Protocol Parameters registry [1]. The
registration data, according to RFC 4566 [RFC4566] follows. registration data, according to RFC 4566 [RFC4566] follows.
Type SDP Name Reference Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
addrtype E164 [RFCxxxx] addrtype E164 [RFCxxxx]
- [RFCxxxx] - [RFCxxxx]
Note: RFC XXXX uses the "E164" and "-" addrtypes in conjunction with
the "PSTN" nettype. Please refer to the relevant RFC for a
description of that representation.
8.4. Registration of a new "proto" value 8.4. Registration of a new "proto" value
This memo provides instructions to IANA to register a new "proto" in This memo provides instructions to IANA to register a new "proto" in
the Session Description Protocol Parameters registry [1]. The the Session Description Protocol Parameters registry [1]. The
registration data, according to RFC 4566 [RFC4566] follows. registration data, according to RFC 4566 [RFC4566] follows.
Type SDP Name Reference Type SDP Name Reference
-------------- --------------------------- --------- -------------- --------------------------- ---------
proto PSTN [RFCxxxx] proto PSTN [RFCxxxx]
The related "fmt" namespace re-uses the conventions and payload type
number defined for RTP/AVP. In this document, the RTP audio and
video media types, when applied to PSTN circuit-switched bearers,
represent merely on audio or video codec.
9. Acknowledgments 9. Acknowledgments
The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas
Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan
Rosenberg, Ingemar Johansson, Christer Holmberg, and Alf Heidermark Rosenberg, Ingemar Johansson, Christer Holmberg, and Alf Heidermark
for providing their insight and comments on this document. for providing their insight and comments on this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 34, line 9 skipping to change at page 35, line 31
October 1998. October 1998.
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the
Session Description Protocol (SDP) for ATM Bearer Session Description Protocol (SDP) for ATM Bearer
Connections", RFC 3108, May 2001. Connections", RFC 3108, May 2001.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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)
Capability Negotiation", RFC 5939, September 2010.
10.2. Informative References 10.2. Informative References
[I-D.ietf-cuss-sip-uui] [I-D.ietf-cuss-sip-uui]
Johnston, A. and J. Rafferty, "A Mechanism for Johnston, A. and J. Rafferty, "A Mechanism for
Transporting User to User Call Control Information in Transporting User to User Call Control Information in
SIP", draft-ietf-cuss-sip-uui-06 (work in progress), SIP", draft-ietf-cuss-sip-uui-07 (work in progress),
May 2012. July 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.
 End of changes. 55 change blocks. 
125 lines changed or deleted 208 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/