draft-ietf-mmusic-dtls-sdp-31.txt   draft-ietf-mmusic-dtls-sdp-32.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: April 10, 2018 October 7, 2017 Expires: May 2, 2018 October 29, 2017
Session Description Protocol (SDP) Offer/Answer Considerations for Session Description Protocol (SDP) Offer/Answer Considerations for
Datagram Transport Layer Security (DTLS) and Transport Layer Security Datagram Transport Layer Security (DTLS) and Transport Layer Security
(TLS) (TLS)
draft-ietf-mmusic-dtls-sdp-31.txt draft-ietf-mmusic-dtls-sdp-32.txt
Abstract Abstract
This document defines the Session Description Protocol (SDP) offer/ This document defines the Session Description Protocol (SDP) offer/
answer procedures for negotiating and establishing a Datagram answer procedures for negotiating and establishing a Datagram
Transport Layer Security (DTLS) association. The document also Transport Layer Security (DTLS) association. The document also
defines the criteria for when a new DTLS association must be defines the criteria for when a new DTLS association must be
established. The document updates RFC 5763 and RFC 7345, by established. The document updates RFC 5763 and RFC 7345, by
replacing common SDP offer/answer procedures with a reference to this replacing common SDP offer/answer procedures with a reference to this
specification. specification.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 10, 2018. This Internet-Draft will expire on May 2, 2018.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 9, line 13 skipping to change at page 9, line 13
association. association.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Endpoints MUST support the hash functions as defined in [RFC8122]. Endpoints MUST support the hash functions as defined in [RFC8122].
The certificate received during the DTLS handshake [RFC6347] MUST The certificate received during the DTLS handshake [RFC6347] MUST
match a certificate fingerprint received in SDP 'fingerprint' match a certificate fingerprint received in SDP 'fingerprint'
attributes according to the procedures defined in [RFC8122]. If attributes according to the procedures defined in [RFC8122]. If
fingerprints do not match the hashed certificate, then an endpoint fingerprints do not match the hashed certificate, then an endpoint
MUST tear down the media session immediately (see [RFC8122]). Note MUST tear down the media session immediately (see [RFC8122]).
that it is permissible to wait until the other side's fingerprint(s)
has been received before establishing the connection; however, this
may have undesirable latency effects.
SDP offerers and answerers might reuse certificates across multiple SDP offerers and answerers might reuse certificates across multiple
DTLS associations, and provide identical fingerprint values for each DTLS associations, and provide identical fingerprint values for each
DTLS association. The combination of the SDP 'tls-id' attribute DTLS association. The combination of the SDP 'tls-id' attribute
values of the SDP offerer and answerer identifies each individual values of the SDP offerer and answerer identifies each individual
DTLS association. DTLS association.
NOTE: There are cases where the SDP 'tls-id' attribute value NOTE: There are cases where the SDP 'tls-id' attribute value
generated by the offerer will end up being used for multiple DTLS generated by the offerer will end up being used for multiple DTLS
associations. For that reason the combination of the attribute associations. For that reason the combination of the attribute
skipping to change at page 10, line 4 skipping to change at page 9, line 52
offer an SDP 'tls-id' attribute with a unique attribute value. offer an SDP 'tls-id' attribute with a unique attribute value.
As the offerer inserts the SDP 'setup' attribute with an 'actpass' As the offerer inserts the SDP 'setup' attribute with an 'actpass'
attribute value, the offerer MUST be prepared to receive a DTLS attribute value, the offerer MUST be prepared to receive a DTLS
ClientHello message [RFC6347] (if a new DTLS association is ClientHello message [RFC6347] (if a new DTLS association is
established by the answerer) from the answerer before the offerer established by the answerer) from the answerer before the offerer
receives the SDP answer. receives the SDP answer.
If the offerer receives a DTLS ClientHello message, and a DTLS If the offerer receives a DTLS ClientHello message, and a DTLS
association is established, before the offerer receives the SDP association is established, before the offerer receives the SDP
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Answer carrying the fingerprint associated with the DTLS association, Answer carrying the fingerprint associated with the DTLS association,
any data received on the DTLS association before the fingerprint MUST any data received on the DTLS association before the fingerprint MUST
be considered coming from an unverified source. The processing of be considered coming from an unverified source. The processing of
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
such data, and sending of data by the offerer to the unverified such data, and sending of data by the offerer to the unverified
source, is outside the scope of this document. source, is outside the scope of this document.
5.3. Generating the Answer 5.3. Generating the Answer
When an answerer sends an answer, the answerer MUST insert in the When an answerer sends an answer, the answerer MUST insert in the
answer an SDP 'setup' attribute according to the procedures in answer an SDP 'setup' attribute according to the procedures in
[RFC4145], and one or more SDP 'fingerprint' attributes according to [RFC4145], and one or more SDP 'fingerprint' attributes according to
the procedures in [RFC8122]. If the answerer determines, based on the procedures in [RFC8122]. If the answerer determines, based on
the criteria specified in Section 3.1, that a new DTLS association is the criteria specified in Section 3.1, that a new DTLS association is
skipping to change at page 11, line 4 skipping to change at page 10, line 51
If a new DTLS association is to be established, and if the answerer If a new DTLS association is to be established, and if the answerer
inserts an SDP 'setup' attribute with an 'active' attribute value in inserts an SDP 'setup' attribute with an 'active' attribute value in
the answer, the answerer MUST initiate a DTLS handshake [RFC6347]) by the answer, the answerer MUST initiate a DTLS handshake [RFC6347]) by
sending a DTLS ClientHello message towards the offerer. sending a DTLS ClientHello message towards the offerer.
Even though an offerer is required to insert an 'SDP' setup attribute Even though an offerer is required to insert an 'SDP' setup attribute
with an 'actpass' attribute value in initial offers (Section 5.2) and with an 'actpass' attribute value in initial offers (Section 5.2) and
subsequent offers (Section 5.5), the answerer MUST be able to receive subsequent offers (Section 5.5), the answerer MUST be able to receive
initial and subsequent offers with other attribute values, in order initial and subsequent offers with other attribute values, in order
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
to be backward compatible with older implementations that might to be backward compatible with older implementations that might
insert other attribute values in initial and subsequent offers. insert other attribute values in initial and subsequent offers.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
5.4. Offerer Processing of the SDP Answer 5.4. Offerer Processing of the SDP Answer
When an offerer receives an answer that establishes a new DTLS When an offerer receives an answer that establishes a new DTLS
association based on criteria defined in Section 3.1, and if the association based on criteria defined in Section 3.1, and if the
offerer becomes DTLS client (based on the value of the SDP 'setup' offerer becomes DTLS client (based on the value of the SDP 'setup'
attribute value [RFC4145]), the offerer MUST establish a DTLS attribute value [RFC4145]), the offerer MUST establish a DTLS
association. If the offerer becomes DTLS server, it MUST wait for association. If the offerer becomes DTLS server, it MUST wait for
the answerer to establish the DTLS association. the answerer to establish the DTLS association.
If the offerer indicated a desire to reuse an existing DTLS If the offerer indicated a desire to reuse an existing DTLS
skipping to change at page 14, line 36 skipping to change at page 14, line 36
SDP offer. Such an INVITE request is often referred to as an 'empty SDP offer. Such an INVITE request is often referred to as an 'empty
INVITE', or an 'offer-less INVITE'. The receiving endpoint will INVITE', or an 'offer-less INVITE'. The receiving endpoint will
include the SDP offer in a response to the request. When the include the SDP offer in a response to the request. When the
endpoint generates such SDP offer, if a previously established DTLS endpoint generates such SDP offer, if a previously established DTLS
association exists, the offerer MUST insert an SDP 'tls-id' association exists, the offerer MUST insert an SDP 'tls-id'
attribute, and one or more SDP 'fingerprint' attributes, with attribute, and one or more SDP 'fingerprint' attributes, with
previously assigned attribute values. If a previously established previously assigned attribute values. If a previously established
DTLS association did not exist, the offer MUST be generated based on DTLS association did not exist, the offer MUST be generated based on
the same rules as a new offer (see Section 5.2). Regardless of the the same rules as a new offer (see Section 5.2). Regardless of the
previous existence of a DTLS association, the SDP 'setup' attribute previous existence of a DTLS association, the SDP 'setup' attribute
MUST be included according to the rules defined in [RFC4145] and if MUST be included according to the rules defined in [RFC4145].
ICE is used, ICE restart MUST be initiated. This is needed in order Furthermore, if ICE is used, according to the third party call
to support third party call control, as described in control considerations described in [I-D.ietf-mmusic-ice-sip-sdp],
[I-D.ietf-mmusic-ice-sip-sdp]. ICE restart MUST be initiated.
9. RFC Updates 9. RFC Updates
9.1. General 9.1. General
This section updates specifications that use DTLS-protected media, in This section updates specifications that use DTLS-protected media, in
order to reflect the procedures defined in this specification. order to reflect the procedures defined in this specification.
9.2. Update to RFC 5763 9.2. Update to RFC 5763
skipping to change at page 16, line 34 skipping to change at page 16, line 34
the media traffic is handled in the media path through DTLS. The the media traffic is handled in the media path through DTLS. The
signaling path is only used to verify the peers' certificate signaling path is only used to verify the peers' certificate
fingerprints. fingerprints.
The offerer and answerer MUST follow the SDP offer/answer procedures The offerer and answerer MUST follow the SDP offer/answer procedures
defined in [RFCXXXX]. defined in [RFCXXXX].
9.2.3. Update to section 6.6 9.2.3. Update to section 6.6
The text in section 6.6 (Session Modification) is modified by The text in section 6.6 (Session Modification) is modified by
replacing replacing generic SDP offer/answer procedures for DTLS with replacing generic SDP offer/answer procedures for DTLS with a
a reference to this specification: reference to this specification:
NEW TEXT: NEW TEXT:
Once an answer is provided to the offerer, either endpoint MAY Once an answer is provided to the offerer, either endpoint MAY
request a session modification that MAY include an updated offer. request a session modification that MAY include an updated offer.
This session modification can be carried in either an INVITE or This session modification can be carried in either an INVITE or
UPDATE request. The peers can reuse an existing DTLS association, UPDATE request. The peers can reuse an existing DTLS association,
or establish a new one, following the procedures in [RFCXXXX]. or establish a new one, following the procedures in [RFCXXXX].
9.2.4. Update to section 6.7.1 9.2.4. Update to section 6.7.1
skipping to change at page 19, line 18 skipping to change at page 19, line 18
Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa,
Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing
comments and suggestions on the document. Ben Campbell performed an comments and suggestions on the document. Ben Campbell performed an
AD review. Paul Kyzivat performed a gen-art review. AD review. Paul Kyzivat performed a gen-art review.
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-31
o Changes based on IESG comments from Eric R
Changes from draft-ietf-mmusic-sdp-dtls-30 Changes from draft-ietf-mmusic-sdp-dtls-30
o Changes based on IESG comments from Mirja K o Changes based on IESG comments from Mirja K
Changes from draft-ietf-mmusic-sdp-dtls-29 Changes from draft-ietf-mmusic-sdp-dtls-29
o Removal of ufrag value change as a trigger for a new DTLS o Removal of ufrag value change as a trigger for a new DTLS
association association
Changes from draft-ietf-mmusic-sdp-dtls-28 Changes from draft-ietf-mmusic-sdp-dtls-28
skipping to change at page 19, line 52 skipping to change at page 20, line 5
o Reference fixes based on Gen-ART review by Paul Kyzivat. o Reference fixes based on Gen-ART review by Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-26 Changes from draft-ietf-mmusic-sdp-dtls-26
o Editorial fixes based on Gen-ART review by Paul Kyzivat. o Editorial fixes based on Gen-ART review by Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-25 Changes from draft-ietf-mmusic-sdp-dtls-25
o Minor editorial nits. o Minor editorial nits.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Changes from draft-ietf-mmusic-sdp-dtls-24 Changes from draft-ietf-mmusic-sdp-dtls-24
o Changes based on 2nd WGLC comments from Roman S and Martin T: o Changes based on 2nd WGLC comments from Roman S and Martin T:
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
o - RFC update structure shortened (old text removed). o - RFC update structure shortened (old text removed).
o - Guidance regarding receiving ClientHello before SDP answer o - Guidance regarding receiving ClientHello before SDP answer
added. added.
o - Additional SIP condierations regarding forking. o - Additional SIP considerations regarding forking.
o - SDP setup attribute value restriction in initial and subsequent o - SDP setup attribute value restriction in initial and subsequent
offers based on comment from Ekr. offers based on comment from Ekr.
Changes from draft-ietf-mmusic-sdp-dtls-23 Changes from draft-ietf-mmusic-sdp-dtls-23
o Editrial change to make it clear that the document does not modify o Editorial change to make it clear that the document does not
the procedures in RFC 8122. modify the procedures in RFC 8122.
Changes from draft-ietf-mmusic-sdp-dtls-22 Changes from draft-ietf-mmusic-sdp-dtls-22
o Support for TLS added. o Support for TLS added.
o Editorial changes based on sec-dir review by Rich Salz. o Editorial changes based on sec-dir review by Rich Salz.
o Editorial changes based on gen-art review by Paul Kyzivat. o Editorial changes based on gen-art review by Paul Kyzivat.
o Editorial changes based on ops-dir review by Carlos Pignataro. o Editorial changes based on ops-dir review by Carlos Pignataro.
skipping to change at page 20, line 51 skipping to change at page 21, line 5
o Change to length and randomness of tls-id attribute value. o Change to length and randomness of tls-id attribute value.
Changes from draft-ietf-mmusic-sdp-dtls-19 Changes from draft-ietf-mmusic-sdp-dtls-19
o Change based on comment from Roman. o Change based on comment from Roman.
Changes from draft-ietf-mmusic-sdp-dtls-18 Changes from draft-ietf-mmusic-sdp-dtls-18
o Changes based on comments from Flemming. o Changes based on comments from Flemming.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
o - Change in tls-id value definition. o - Change in tls-id value definition.
o - Editorial fixes. o - Editorial fixes.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Changes from draft-ietf-mmusic-sdp-dtls-17 Changes from draft-ietf-mmusic-sdp-dtls-17
o Reference fix. o Reference fix.
Changes from draft-ietf-mmusic-sdp-dtls-16 Changes from draft-ietf-mmusic-sdp-dtls-16
o Editorial changes based on 2nd WGLC comments from Christian Groves o Editorial changes based on 2nd WGLC comments from Christian Groves
and Nevenka Biondic. and Nevenka Biondic.
Changes from draft-ietf-mmusic-sdp-dtls-15 Changes from draft-ietf-mmusic-sdp-dtls-15
o tls-id attribute value made globally unique o tls-id attribute value made globally unique
Changes from draft-ietf-mmusic-sdp-dtls-14 Changes from draft-ietf-mmusic-sdp-dtls-14
o Changes based on comments from Flemming: o Changes based on comments from Flemming:
o - Additional dtls-is clarifiations o - Additional dtls-is clarifications
o - Editorial fixes o - Editorial fixes
Changes from draft-ietf-mmusic-sdp-dtls-13 Changes from draft-ietf-mmusic-sdp-dtls-13
o Text about the updated RFCs added to Abstract and Introduction o Text about the updated RFCs added to Abstract and Introduction
o Reference to RFC 5763 removed from section 6 (ICE Considerations) o Reference to RFC 5763 removed from section 6 (ICE Considerations)
o Reference to RFC 5763 removed from section 8 (SIP Considerations) o Reference to RFC 5763 removed from section 8 (SIP Considerations)
skipping to change at page 21, line 50 skipping to change at page 22, line 5
Changes from draft-ietf-mmusic-sdp-dtls-11 Changes from draft-ietf-mmusic-sdp-dtls-11
o Attribute name changed to tls-id o Attribute name changed to tls-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 tls-id instead of dtls-connection o Modified document to use tls-id instead of dtls-connection
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
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
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
o Offer/Answer section modified in order to allow sending of o Offer/Answer section modified in order to allow sending of
multiple SDP 'fingerprint' attributes. multiple SDP 'fingerprint' attributes.
o Terminology made consistent: 'DTLS connection' replaced with 'DTLS o Terminology made consistent: 'DTLS connection' replaced with 'DTLS
association'. association'.
o Editorial changes based on comments from Paul Kyzivat. o Editorial changes based on comments from Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-07 Changes from draft-ietf-mmusic-sdp-dtls-07
skipping to change at page 22, line 51 skipping to change at page 23, line 5
Changes from draft-ietf-mmusic-sdp-dtls-04 Changes from draft-ietf-mmusic-sdp-dtls-04
o Editorial nits fixed based on comments from Paul Kyzivat: o Editorial nits fixed based on comments from Paul Kyzivat:
Changes from draft-ietf-mmusic-sdp-dtls-03 Changes from draft-ietf-mmusic-sdp-dtls-03
o Changes based on comments from Paul Kyzivat: o Changes based on comments from Paul Kyzivat:
o - Modification of tls-id attribute section. o - Modification of tls-id attribute section.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
o - Removal of IANA considerations subsection. o - Removal of IANA considerations subsection.
o - Making note into normative text in o/a section. o - Making note into normative text in o/a section.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
o Changes based on comments from Martin Thompson: o Changes based on comments from Martin Thompson:
o - Abbreviations section removed. o - Abbreviations section removed.
o - Clarify that a new DTLS association requires a new o/a o - Clarify that a new DTLS association requires a new o/a
transaction. transaction.
Changes from draft-ietf-mmusic-sdp-dtls-02 Changes from draft-ietf-mmusic-sdp-dtls-02
o - Updated RFCs added to boilerplate. o - Updated RFCs added to boilerplate.
skipping to change at page 23, line 51 skipping to change at page 24, line 5
o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision
with another expired draft. with another expired draft.
o - Clarify that if ufrag in offer is unchanged, it must be o - Clarify that if ufrag in offer is unchanged, it must be
unchanged in associated answer. unchanged in associated answer.
o - SIP Considerations section added. o - SIP Considerations section added.
o - Section about multiple SDP fingerprint attributes added. o - Section about multiple SDP fingerprint attributes added.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Changes from draft-holmberg-mmusic-sdp-dtls-00 Changes from draft-holmberg-mmusic-sdp-dtls-00
o - Editorial changes and clarifications. o - Editorial changes and clarifications.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
14. References 14. References
14.1. Normative References 14.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 25, line 21 skipping to change at page 25, line 21
<https://www.rfc-editor.org/info/rfc8122>. <https://www.rfc-editor.org/info/rfc8122>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-10 (work in progress), May 2017. rfc5245bis-13 (work in progress), October 2017.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), December 2016. (work in progress), December 2016.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-38 (work in progress), April 2017. negotiation-39 (work in progress), August 2017.
14.2. Informative References 14.2. Informative References
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>. <https://www.rfc-editor.org/info/rfc4474>.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
skipping to change at page 26, line 29 skipping to change at page 26, line 29
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), February 2017. (work in progress), February 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, Petit-Huguenin, M., Keranen, A., and S. Nandakumar,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-13 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in
progress), June 2017. progress), October 2017.
[I-D.ietf-mmusic-sdp-uks] [I-D.ietf-mmusic-sdp-uks]
Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on
uses of Transport Layer Security with the Session uses of Transport Layer Security with the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-00 Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-00
(work in progress), August 2017. (work in progress), August 2017.
[ITU.T38.2010] [ITU.T38.2010]
International Telecommunications Union, "Procedures for International Telecommunications Union, "Procedures for
real-time Group 3 facsimile communication over IP real-time Group 3 facsimile communication over IP
 End of changes. 27 change blocks. 
37 lines changed or deleted 37 lines changed or added

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