draft-ietf-mmusic-dtls-sdp-12.txt   draft-ietf-mmusic-dtls-sdp-13.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 5763,7345 (if approved) R. Shpount Updates: 5763,7345 (if approved) R. Shpount
Intended status: Standards Track TurboBridge Intended status: Standards Track TurboBridge
Expires: November 22, 2016 May 21, 2016 Expires: November 26, 2016 May 25, 2016
Using the SDP Offer/Answer Mechanism for DTLS Using the SDP Offer/Answer Mechanism for DTLS
draft-ietf-mmusic-dtls-sdp-12.txt draft-ietf-mmusic-dtls-sdp-13.txt
Abstract Abstract
This draft defines the SDP offer/answer procedures for negotiating This draft defines the SDP offer/answer procedures for negotiating
and establishing a DTLS association. The draft also defines the and establishing a DTLS association. The draft also defines the
criteria for when a new DTLS association must be established. criteria for when a new DTLS association must be established.
This draft defines a new SDP media-level attribute, 'dtls-id'. This draft defines a new SDP media-level attribute, 'dtls-id'.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 22, 2016. This Internet-Draft will expire on November 26, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 5, line 48 skipping to change at page 5, line 48
NOTE: The procedures in this section are generalizations of NOTE: The procedures in this section are generalizations of
procedures first specified in SRTP-DTLS [RFC5763], with the addition procedures first specified in SRTP-DTLS [RFC5763], with the addition
of usage of the SDP 'dtls-id' attribute. That document is herein of usage of the SDP 'dtls-id' attribute. That document is herein
revised to make use of these new procedures. revised to make use of these new procedures.
The procedures in this section apply to an SDP media description The procedures in this section apply to an SDP media description
("m=" line) associated a DTLS-protected media/data. ("m=" line) associated a DTLS-protected media/data.
When an offerer needs to establish a new DTLS association, and if an When an offerer needs to establish a new DTLS association, and if an
unreliable transport (e.g. UDP) is used, the offerer MUST allocate a unordered transport (e.g. UDP) is used, the offerer MUST allocate a
new transport for the offer in such a way that the offerer can new transport for the offer in such a way that the offerer can
disambiguate any packets associated with the new DTLS association disambiguate any packets associated with the new DTLS association
from any packets associated with any other DTLS association. This from any packets associated with any other DTLS association. This
typically means using a local address and or port, or a set of ICE typically means using a local address and or port, or a set of ICE
candidates (see Section 6), which were not recently used for any candidates (see Section 6), which were not recently used for any
other DTLS association. other DTLS association.
When an answerer needs to establish a new DTLS association, if When an answerer needs to establish a new DTLS association, if an
unreliable transport is used, and if the offerer did not allocate a unordered transport is used, and if the offerer did not allocate a
new transport, the answerer MUST allocate a new transport for the new transport, the answerer MUST allocate a new transport for the
offer in answer a way that it can disambiguate any packets associated offer in answer a way that it can disambiguate any packets associated
with new DTLS association from any packets associated with any other with new DTLS association from any packets associated with any other
DTLS association. This typically means using a local address and or DTLS association. This typically means using a local address and or
port, or a set of ICE candidates (see Section 6), which were not port, or a set of ICE candidates (see Section 6), which were not
recently used for any other DTLS association. recently used for any other DTLS association.
In order to negotiate a DTLS association, the following SDP In order to negotiate a DTLS association, the following SDP
attributes are used: attributes are used:
skipping to change at page 9, line 37 skipping to change at page 9, line 37
6. ICE Considerations 6. ICE Considerations
When ICE is used, the ICE connectivity checks are performed before When ICE is used, the ICE connectivity checks are performed before
the DTLS handshake begins. Note that if aggressive nomination mode the DTLS handshake begins. Note that if aggressive nomination mode
is used, multiple candidate pairs may be marked valid before ICE is used, multiple candidate pairs may be marked valid before ICE
finally converges on a single candidate pair. finally converges on a single candidate pair.
NOTE: Aggressive nomination has been deprecated from ICE, but must NOTE: Aggressive nomination has been deprecated from ICE, but must
still be supported for backwards compatibility reasons. still be supported for backwards compatibility reasons.
When new DTLS association is established over an unreliable When new DTLS association is established over an unordered transport,
transport, in order to disambiguate any packets associated with newly in order to disambiguate any packets associated with newly
established DTLS association, at least one of the endpoints MUST established DTLS association, at least one of the endpoints MUST
allocate a completely new set of ICE candidates which were not allocate a completely new set of ICE candidates which were not
recently used for any other DTLS association. This means that recently used for any other DTLS association. This means that
answerer cannot initiate a new DTLS association unless the offerer answerer cannot initiate a new DTLS association unless the offerer
initiated ICE restart [RFC5245]. If the answerer wants to initiate a initiated ICE restart [RFC5245]. If the answerer wants to initiate a
new DTLS association, it needs to initiate an ICE restart on its own. new DTLS association, it needs to initiate an ICE restart on its own.
However, an ICE restart does not by default require a new DTLS However, an ICE restart does not by default require a new DTLS
association to be established. association to be established.
NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets
skipping to change at page 19, line 47 skipping to change at page 19, line 47
12. Acknowledgements 12. Acknowledgements
Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa,
Charles Eckel and Gonzalo Salgueiro for providing comments and Charles Eckel and Gonzalo Salgueiro for providing comments and
suggestions on the draft. suggestions on the draft.
13. Change Log 13. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-dtls-12
o "unreliable" changed to "unordered"
Changes from draft-ietf-mmusic-sdp-dtls-11 Changes from draft-ietf-mmusic-sdp-dtls-11
o Attribute name changed to dtls-id o Attribute name changed to dtls-id
o Additional text based on comments from Roman Shpount. o Additional text based on comments from Roman Shpount.
Changes from draft-ietf-mmusic-sdp-dtls-10 Changes from draft-ietf-mmusic-sdp-dtls-10
o Modified document to use dtls-id instead of dtls-connection o Modified document to use dtls-id instead of dtls-connection
o Changes are based on comments from Eric Rescorla, Justin Uberti, o Changes are based on comments from Eric Rescorla, Justin Uberti,
and Paul Kyzivat. and Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-08 Changes from draft-ietf-mmusic-sdp-dtls-08
 End of changes. 8 change blocks. 
8 lines changed or deleted 12 lines changed or added

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