draft-ietf-mmusic-sdp-cs-20.txt   draft-ietf-mmusic-sdp-cs-21.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: December 08, 2013 Nokia Expires: December 28, 2013 Nokia
June 06, 2013 June 26, 2013
Session Description Protocol (SDP) Extension For Setting Audio and Video Session Description Protocol (SDP) Extension For Setting Audio and Video
Media Streams Over Circuit-Switched Bearers In The Public Switched Media Streams Over Circuit-Switched Bearers In The Public Switched
Telephone Network (PSTN) Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-20 draft-ietf-mmusic-sdp-cs-21
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 December 08, 2013. This Internet-Draft will expire on December 28, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 18 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5 4.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 7 5.1. Level of Compliance . . . . . . . . . . . . . . . . . . . 7
5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 7 5.2. Extensions to SDP . . . . . . . . . . . . . . . . . . . . 7
5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 7 5.2.1. Connection Data . . . . . . . . . . . . . . . . . . . 7
5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . 8 5.2.2. Media Descriptions . . . . . . . . . . . . . . . . . 9
5.2.3. Correlating the PSTN Circuit-Switched Bearer with SDP 10 5.2.3. Correlating the PSTN Circuit-Switched Bearer with SDP 10
5.2.3.1. The "cs-correlation" attribute . . . . . . . . . 11 5.2.3.1. The "cs-correlation" attribute . . . . . . . . . 11
5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 11 5.2.3.2. Caller-ID Correlation Mechanism . . . . . . . . . 11
5.2.3.3. User-User Information Element Correlation 5.2.3.3. User-User Information Element Correlation
Mechanism . . . . . . . . . . . . . . . . . . . . 12 Mechanism . . . . . . . . . . . . . . . . . . . . 12
5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . 14 5.2.3.4. DTMF Correlation Mechanism . . . . . . . . . . . 14
5.2.3.5. Extensions to correlation mechanisms . . . . . . 15 5.2.3.5. Extensions to correlation mechanisms . . . . . . 15
5.3. Negotiating the correlation mechanisms . . . . . . . . . 15 5.3. Negotiating the correlation mechanisms . . . . . . . . . 15
5.3.1. Determining the Direction of the Circuit-Switched 5.3.1. Determining the Direction of the Circuit-Switched
Bearer Setup . . . . . . . . . . . . . . . . . . . . 15 Bearer Setup . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 2, line 50 skipping to change at page 2, line 50
5.6.4. Modifying the session . . . . . . . . . . . . . . . . 26 5.6.4. Modifying the session . . . . . . . . . . . . . . . . 26
5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26 5.7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 27 6.1. Single PSTN audio stream . . . . . . . . . . . . . . . . 27
6.2. Advanced SDP example: Circuit-Switched Audio and 6.2. Advanced SDP example: Circuit-Switched Audio and
Video Streams . . . . . . . . . . . . . . . . . . . . . . 29 Video Streams . . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. Registration of new cs-correlation SDP attribute . . . . 32 8.1. Registration of new cs-correlation SDP attribute . . . . 32
8.2. Registration of a new "nettype" value . . . . . . . . . . 33 8.2. Registration of a new "nettype" value . . . . . . . . . . 33
8.3. Registration of new "addrtype" values . . . . . . . . . . 33 8.3. Registration of new "addrtype" value . . . . . . . . . . 33
8.4. Registration of a new "proto" value . . . . . . . . . . . 33 8.4. Registration of a new "proto" value . . . . . . . . . . . 33
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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
[RFC3551]. [RFC3551].
However, SDP can be used to describe other transport protocols than However, SDP can be used to describe other media transport protocols
RTP. Previous work includes SDP conventions for describing ATM than RTP. Previous work includes SDP conventions for describing ATM
bearer connections [RFC3108] and the Message Session Relay Protocol bearer connections [RFC3108] and the Message Session Relay Protocol
[RFC4975]. [RFC4975].
SDP is commonly carried in Session Initiation Protocol (SIP) SDP is commonly carried in Session Initiation Protocol (SIP)
[RFC3261] messages in order to agree on a common media description [RFC3261] messages in order to agree on a common media description
among the endpoints. An Offer/Answer Model with Session Description among the endpoints. An Offer/Answer Model with Session Description
Protocol (SDP) [RFC3264] defines a framework by which two endpoints Protocol (SDP) [RFC3264] defines a framework by which two endpoints
can exchange SDP media descriptions and come to an agreement as to can exchange SDP media descriptions and come to an agreement as to
which media streams should be used, along with the media related which media streams should be used, along with the media related
parameters. parameters.
skipping to change at page 3, line 48 skipping to change at page 3, line 48
scenario is illustrated with two mobile devices capable of both scenario is illustrated with two mobile devices capable of both
circuit-switched and packet-switched communication over a low- circuit-switched and packet-switched communication over a low-
bandwidth radio bearer. The radio bearer may not be suitable for bandwidth radio bearer. The radio bearer may not be suitable for
carrying real-time audio or video media, and using a circuit-switched carrying real-time audio or video media, and using a circuit-switched
bearer would offer a better perceived quality of service. So, bearer would offer a better perceived quality of service. So,
according to this scenario, SDP and its higher layer session control according to this scenario, SDP and its higher layer session control
protocol (e.g., the Session Initiation Protocol (SIP) [RFC3261]) are protocol (e.g., the Session Initiation Protocol (SIP) [RFC3261]) are
used over regular IP connectivity, while the audio or video is used over regular IP connectivity, while the audio or video is
received through the classical circuit-switched bearer. received through the classical circuit-switched bearer.
This document addresses only the use of circuit-switched bearers in
the PSTN, not a generic circuit-switched network. The mechanisms
presented below require a call signaling protocol of the PSTN to be
used (such as ITU-T Q.931 [ITU.Q931.1998] or 3GPP TS 24.008
[TS.24.008]).
Setting up a signaling relationship in the IP domain instead of just Setting up a signaling relationship in the IP domain instead of just
setting up a circuit-switched call offers also the possibility of setting up a circuit-switched call offers also the possibility of
negotiating in the same session other IP based media that is not negotiating in the same session other IP based media that is not
sensitive to jitter and delay, for example, text messaging or sensitive to jitter and delay, for example, text messaging or
presence information. presence information.
At a later point in time the mobile device might move to an area At a later point in time the mobile device might move to an area
where a high-bandwidth packet-switched bearer, for example a Wireless where a high-bandwidth packet-switched bearer, for example a Wireless
Local Area Network (WLAN) connection, is available. At this point Local Area Network (WLAN) connection, is available. At this point
the mobile device may perform a handover and move the audio or video the mobile device may perform a handover and move the audio or video
skipping to change at page 6, line 21 skipping to change at page 6, line 24
| | | |
| PSTN call setup | | PSTN call setup |
|<-----------------------------------| |<-----------------------------------|
| | | |
| | | |
|<===== media over PSTN bearer =====>| |<===== media over PSTN bearer =====>|
| | | |
Figure 1: Example Flow Figure 1: Example Flow
Endpoitn B receives the SDP offer and determines that it is located Endpoint B receives the SDP offer and determines that it is located
in an environment where the IP based bearer is not suitable for real- in an environment where the IP based bearer is not suitable for real-
time audio media. However, Endpoint B also has PSTN circuit-switched time audio media. However, Endpoint B also has PSTN circuit-switched
bearer available for audio. Endpoint B generates an SDP answer bearer available for audio. Endpoint B generates an SDP answer
containing a description of the audio media stream over a circuit- containing a description of the audio media stream over a circuit-
switched bearer. switched bearer.
During the offer-answer exchange Endpoints A and B also agree the During the offer-answer exchange Endpoints A and B also agree the
direction in which the circuit-switched bearer should be established. direction in which the circuit-switched bearer should be established.
In this example, Endpoint B becomes the active party, in other words, In this example, Endpoint B becomes the active party, in other words,
it establishes the circuit-switched call to the other endpoint. The it establishes the circuit-switched call to the other endpoint. The
skipping to change at page 7, line 52 skipping to change at page 8, line 9
E.164 number represented according to the ITU-T E.164 [ITU.E164.1991] E.164 number represented according to the ITU-T E.164 [ITU.E164.1991]
recommendation. 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 E.164 number allocated to it. In these cases a dash ("-") is used to
dash ("-") is used to indicate an unknown address type or connection indicate an unknown connection address. This makes the connection
address. This makes the connection data line be according to the SDP data line be according to the SDP syntax.
syntax.
Please note that these "E164" and "-" address types defined in this Please note that the "E164" address type defined in this memo is
memo are exclusively defined to be used in conjunction with the exclusively defined to be used in conjunction with the "PSTN" network
"PSTN" network type in accordance with [RFC4566]. Usage of "E164" or type in accordance with [RFC4566]. Usage of "E164" address type in
"-" address types in conjunction with other network types may be conjunction with other network types may be defined elsewhere.
defined elsewhere.
This memo exclusively uses the international representation of E.164 This memo exclusively uses the international representation of E.164
numbers, i.e., those including a country code and, as described above numbers, i.e., those including a country code and, as described above
prepended with a '+' sign. Implementations conforming to this prepended with a '+' sign. Implementations conforming to this
specification and using the "E164" address type together with the specification and using the "E164" address type together with the
"PSTN" network type MUST use the 'global-number-digits' construction "PSTN" network type MUST use the 'global-number-digits' construction
specified in RFC 3966 [RFC3966] for representing international E.164 specified in RFC 3966 [RFC3966] for representing international E.164
numbers. This representation requires the presence of the '+' sign, numbers. This representation requires the presence of the '+' sign,
and additionally allows for the presence of one or more 'visual- and additionally allows for the presence of one or more 'visual-
separator' constructions for easier human readability (see separator' constructions for easier human readability (see
Section 5.7). Section 5.7).
Note that <addrtype> and/or <connection-address> MUST NOT be omitted Note that <connection-address> MUST NOT be omitted when unknown since
when unknown since this would violate basic syntax of SDP [RFC4566]. this would violate basic syntax of SDP [RFC4566]. In such cases, it
In such cases, they MUST be set to a "-". 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 +441134960123 c=PSTN E164 +441134960123
c=PSTN - - c=PSTN E164 -
When the <addrtype> is E164, the connection address is defined as When the <addrtype> is E164, the connection address is defined as
follows: follows:
o an international E.164 number o an international E.164 number (prepended with a '+' sign)
When the <addrtype> is "-", the connection address is defined as
follows:
o the value "-", signifying that the address is unknown o the value "-", signifying that the address is unknown
o any value resulting from the production rule of connection-address o any other value resulting from the production rule of connection-
in RFC4566 [RFC4566], but in all cases any value encountered will address in RFC4566 [RFC4566], but in all cases any value
be ignored. encountered will be ignored.
5.2.2. Media Descriptions 5.2.2. Media Descriptions
According to SDP [RFC4566], the media description line in SDP has the According to SDP [RFC4566], the media description line in SDP has the
following syntax: following syntax:
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
The <media> subfield 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> subfield is the transport port to which the media stream The <port> subfield is the transport port to which the media stream
skipping to change at page 19, line 49 skipping to change at page 19, line 49
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> "audio" or "video", depending on the media type, and the <proto>
subfield to "PSTN". The <port> subfield SHOULD be set to "9" (the subfield to "PSTN". The <port> subfield SHOULD be set to "9" (the
discard port). discard port). The values "audio" or "video" in the <media> subfield
MUST NOT be set by the endpoint unless it has knowledge that these
bearer types are available on the circuit-switched network.
The <fmt> subfield carries the payload type number(s) the endpoint is The <fmt> subfield carries the payload type number(s) the endpoint 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 on the PSTN media stream. For codecs that the endpoint wishes to use on the PSTN media stream. For
example, if the endpoint wishes to use the GSM codec, it would add example, if the endpoint wishes to use the GSM codec, it would add
payload type number 3 in the list of codecs. The list of payload payload type number 3 in the list of codecs. The list of payload
types MUST only contain those codecs the endpoint is able to use on types MUST only contain those codecs the endpoint is able to use on
the PSTN bearer. In case the endpoint is not aware of the codecs the PSTN bearer. In case the endpoint is not aware of the codecs
available for the circuit-switched media streams, it MUST include a available for the circuit-switched media streams, it MUST include a
dash ("-") in the <fmt> subfield. dash ("-") in the <fmt> subfield.
skipping to change at page 21, line 47 skipping to change at page 21, line 51
time being. time 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
If the Offer contained a circuit-switched audio or video stream, the If the Offer contained a circuit-switched audio or video stream, the
Answerer first determines whether it is able to accept and use such Answerer first determines whether it is able to accept and use such
streams. If the Answerer does not support or is not willing to use streams on the circuit-switched network. If the Answerer does not
circuit-switched media for the session, it MUST construct an Answer support or is not willing to use circuit-switched media for the
where the port number for such media stream(s) is set to zero, session, it MUST construct an Answer where the port number for such
according to Section 6 of [RFC3264]. If the Answerer is willing to media stream(s) is set to zero, according to Section 6 of [RFC3264].
use circuit-switched media for the session, it MUST ignore the If the Answerer is willing to use circuit-switched media for the
received port number (unless the port number is set to zero). session, it MUST ignore the received port number (unless the port
number is set to zero).
If the Offer included a "-" as the payload type number, it indicates If the Offer included a "-" as the payload type number, it indicates
that the Offerer is not willing or able to define any specific that the Offerer is not willing or able to define any specific
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.
skipping to change at page 33, line 15 skipping to change at page 33, line 15
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
---- ------------------ --------- ---- ------------------ ---------
nettype PSTN [RFCxxxx] nettype PSTN [RFCxxxx]
8.3. Registration of new "addrtype" values 8.3. Registration of new "addrtype" value
This memo provides instructions to IANA to register two new This memo provides instructions to IANA to register a new "addrtype"
"addrtype" in the Session Description Protocol Parameters registry in the Session Description Protocol Parameters registry [2]. The
[2]. 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]
addrtype - [RFCxxxx]
Note: RFC XXXX defines the "E164" and "-" addrtypes in the context of Note: RFC XXXX defines the "E164" addrtype in the context of the
the "PSTN" nettype only. Please refer to the relevant RFC for a "PSTN" nettype only. Please refer to the relevant RFC for a
description of that representation. 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 [3]. The the Session Description Protocol Parameters registry [3]. 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
-------------- --------------------------- --------- -------------- --------------------------- ---------
 End of changes. 21 change blocks. 
43 lines changed or deleted 47 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/