draft-ietf-mmusic-sdp-cs-12.txt   draft-ietf-mmusic-sdp-cs-13.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: April 11, 2013 Nokia Expires: April 24, 2013 Nokia
October 8, 2012 October 21, 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-12 draft-ietf-mmusic-sdp-cs-13
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 April 11, 2013. This Internet-Draft will expire on April 24, 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 4, line 5 skipping to change at page 4, line 5
Streams . . . . . . . . . . . . . . . . . . . . . . . . . 31 Streams . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8.1. Registration of new cs-correlation SDP attribute . . . . . 33 8.1. Registration of new cs-correlation SDP attribute . . . . . 33
8.2. Registration of a new "nettype" value . . . . . . . . . . 34 8.2. Registration of a new "nettype" value . . . . . . . . . . 34
8.3. Registration of new "addrtype" values . . . . . . . . . . 34 8.3. Registration of new "addrtype" values . . . . . . . . . . 34
8.4. Registration of a new "proto" value . . . . . . . . . . . 34 8.4. Registration of a new "proto" value . . . . . . . . . . . 34
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 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
skipping to change at page 24, line 5 skipping to change at page 24, line 5
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". The in the Answer and set it to value "passive" or "holdconn". The
Answerer MUST also include its E.164 number of the "c=" line. Answerer MUST also include its E.164 number on 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 25, line 40 skipping to change at page 25, line 40
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, If the Answerer becomes the active party, generates an SDP answer,
and then it finds out that the circuit-switched call cannot be and then it finds out that the circuit-switched call cannot be
established, then such endpoint MUST create a new SDP offer where established, then the Answerer MUST create a new SDP offer where
circuit-switched stream is removed from the session (actually, by circuit-switched stream is removed from the session (actually, by
setting the corresponding port in the m= line to zero) and send it to 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 its counter part. This is to synchronize both parties (and potential
intermediaries) on the state of the session. 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
skipping to change at page 26, line 28 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, o Note that it if delivery of the Answer is delayed for some reason,
the circuit-switched call may arrive at the Offerer before the the circuit-switched call attempt may arrive at the Offerer before
Answer has been processed. In this case, since the correlation the Answer has been processed. In this case, since the
mechanisms are negotiated as part of the Offer/Answer exchange, correlation mechanisms are negotiated as part of the Offer/Answer
the Answerer cannot know whether the incoming call attempt is exchange, the Answerer cannot know whether or not the incoming
correlated with the session being negotiated, the Offerer SHOULD circuit-switched call attempt is correlated with the session being
accept the call only after it has received and processed the negotiated, the Offerer SHOULD answer the circuit-switched call
Answer. attempt 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
skipping to change at page 33, line 16 skipping to change at page 33, line 16
It is possible that an attacker creates a circuit-switched session It is possible that an attacker creates a circuit-switched session
whereby the attacked endpoint should dial a circuit-switched number, whereby the attacked endpoint should dial a circuit-switched number,
perhaps even a premium-rate telephone number. To mitigate the perhaps even a premium-rate telephone number. To mitigate the
consequences of this attack, endpoints MUST authenticate and trust consequences of this attack, endpoints MUST authenticate and trust
remote endpoints users who try to remain passive in the circuit- remote endpoints users who try to remain passive in the circuit-
switched connection establishment. It is RECOMMENDED that endpoints switched connection establishment. It is RECOMMENDED that endpoints
have local policies precluding the active establishment of circuit have local policies precluding the active establishment of circuit
switched connections to certain numbers (e.g., international, switched connections to certain numbers (e.g., international,
premium, long distance). Additionally, it is strongly RECOMMENDED premium, long distance). Additionally, it is strongly RECOMMENDED
that the end user is asked for consent prior to the endpoint that the end user is asked for consent prior to the endpoint
initiating a circuit-switched connection which might incur in initiating a circuit-switched connection.
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>
skipping to change at page 35, line 9 skipping to change at page 35, line 9
The related "fmt" namespace re-uses the conventions and payload type The related "fmt" namespace re-uses the conventions and payload type
number defined for RTP/AVP. In this document, the RTP audio and number defined for RTP/AVP. In this document, the RTP audio and
video media types, when applied to PSTN circuit-switched bearers, video media types, when applied to PSTN circuit-switched bearers,
represent merely on audio or video codec. 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, Alf Heidermark, Tom
for providing their insight and comments on this document. Taylor, Thomas Belling, Keith Drage, and Andrew Allen for providing
their insight and comments on this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
 End of changes. 9 change blocks. 
19 lines changed or deleted 19 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/