draft-ietf-mmusic-ice-sip-sdp-04.txt   draft-ietf-mmusic-ice-sip-sdp-05.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Intended status: Standards Track A. Keranen Intended status: Standards Track A. Keranen
Expires: April 30, 2015 Ericsson Expires: September 10, 2015 Ericsson
October 27, 2014 March 9, 2015
Using Interactive Connectivity Establishment (ICE) with Using Interactive Connectivity Establishment (ICE) with
Session Description Protocol (SDP) offer/answer and Session Initiation Session Description Protocol (SDP) offer/answer and Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-mmusic-ice-sip-sdp-04 draft-ietf-mmusic-ice-sip-sdp-05
Abstract Abstract
This document describes how Interactive Connectivity Establishment This document describes how Interactive Connectivity Establishment
(ICE) is used with Session Description Protocol (SDP) offer/answer (ICE) is used with Session Description Protocol (SDP) offer/answer
and Session Initiation Protocol (SIP). and Session Initiation Protocol (SIP).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
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 April 30, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 6 skipping to change at page 3, line 6
8.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 13 8.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 13
9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 13 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 13
9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 13 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 13
9.1.1. Procedures for All Implementations . . . . . . . . . 13 9.1.1. Procedures for All Implementations . . . . . . . . . 13
9.1.2. Procedures for Full Implementations . . . . . . . . . 14 9.1.2. Procedures for Full Implementations . . . . . . . . . 14
9.1.3. Procedures for Lite Implementations . . . . . . . . . 16 9.1.3. Procedures for Lite Implementations . . . . . . . . . 16
9.2. Receiving the Offer and Generating an Answer . . . . . . 17 9.2. Receiving the Offer and Generating an Answer . . . . . . 17
9.2.1. Procedures for All Implementations . . . . . . . . . 17 9.2.1. Procedures for All Implementations . . . . . . . . . 17
9.2.2. Procedures for Full Implementations . . . . . . . . . 18 9.2.2. Procedures for Full Implementations . . . . . . . . . 18
9.2.3. Procedures for Lite Implementations . . . . . . . . . 19 9.2.3. Procedures for Lite Implementations . . . . . . . . . 19
9.3. Updating the Check and Valid Lists . . . . . . . . . . . 20 9.3. Receiving the Answer for a Subsequent Offer . . . . . . . 20
9.3.1. Procedures for Full Implementations . . . . . . . . . 20 9.3.1. Procedures for All Implementations . . . . . . . . . 20
9.3.2. Procedures for Lite Implementations . . . . . . . . . 21 9.4. Updating the Check and Valid Lists . . . . . . . . . . . 21
10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.4.1. Procedures for Full Implementations . . . . . . . . . 21
11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 22 9.4.2. Procedures for Lite Implementations . . . . . . . . . 22
11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 22 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1.1. Procedures for All Implementations . . . . . . . . . 22 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 23
11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 22 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 23
12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 23 11.1.1. Procedures for All Implementations . . . . . . . . . 23
12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 23 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 23
12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . 23 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 24
12.1.2. Offer in Response . . . . . . . . . . . . . . . . . 24 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 24
12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 25 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . 24
12.3. Interactions with Forking . . . . . . . . . . . . . . . 25 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . 26
12.4. Interactions with Preconditions . . . . . . . . . . . . 25 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 26
12.5. Interactions with Third Party Call Control . . . . . . . 26 12.3. Interactions with Forking . . . . . . . . . . . . . . . 26
13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 26 12.4. Interactions with Preconditions . . . . . . . . . . . . 27
14. Setting Ta and RTO for RTP Media Streams . . . . . . . . . . 26 12.5. Interactions with Third Party Call Control . . . . . . . 27
15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 27
15.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . 28 14. Setting Ta and RTO for RTP Media Streams . . . . . . . . . . 28
15.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . 29 15. Security Considerations . . . . . . . . . . . . . . . . . . . 30
15.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . 29 15.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . 30
15.2.2. Interactions with Application Layer Gateways and SIP 29 15.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . 30
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 15.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . 30
16.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 30 15.2.2. Interactions with Application Layer Gateways and SIP 30
16.1.1. candidate Attribute . . . . . . . . . . . . . . . . 30 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
16.1.2. remote-candidates Attribute . . . . . . . . . . . . 31 16.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 32
16.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 31 16.1.1. candidate Attribute . . . . . . . . . . . . . . . . 32
16.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 32 16.1.2. remote-candidates Attribute . . . . . . . . . . . . 32
16.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 32 16.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 33
16.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 33 16.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 33
16.1.7. ice-pacing Attribute . . . . . . . . . . . . . . . . 33 16.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 33
16.1.8. ice-options Attribute . . . . . . . . . . . . . . . 33 16.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 34
16.1.7. ice-pacing Attribute . . . . . . . . . . . . . . . . 34
16.1.8. ice-options Attribute . . . . . . . . . . . . . . . 35
16.2. Interactive Connectivity Establishment (ICE) Options 16.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 34 Registry . . . . . . . . . . . . . . . . . . . . . . . . 35
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
18.1. Normative References . . . . . . . . . . . . . . . . . . 35 18.1. Normative References . . . . . . . . . . . . . . . . . . 36
18.2. Informative References . . . . . . . . . . . . . . . . . 36 18.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 38
Appendix B. The remote-candidates Attribute . . . . . . . . . . 39 Appendix B. The remote-candidates Attribute . . . . . . . . . . 40
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 39 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 41
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 40 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document describes how Interactive Connectivity Establishment This document describes how Interactive Connectivity Establishment
(ICE) is used with Session Description Protocol (SDP) offer/answer (ICE) is used with Session Description Protocol (SDP) offer/answer
and Session Initiation Protocol (SIP). The ICE specification and Session Initiation Protocol (SIP). The ICE specification
[ICE-BIS] describes procedures that are common to all usages of ICE [ICE-BIS] describes procedures that are common to all usages of ICE
and this document gives the additional details needed to use ICE with and this document gives the additional details needed to use ICE with
SIP and SDP offer/answer. SIP and SDP offer/answer.
skipping to change at page 20, line 23 skipping to change at page 20, line 23
this section) MUST change its role to controlled. Consequently, if this section) MUST change its role to controlled. Consequently, if
the agent was going to send an updated offer since, based on the the agent was going to send an updated offer since, based on the
rules in section 8.2 of [ICE-BIS], it was controlling, it no longer rules in section 8.2 of [ICE-BIS], it was controlling, it no longer
needs to. needs to.
Besides the potential role change, change in the Valid list, and Besides the potential role change, change in the Valid list, and
state changes, the construction of the answer is performed state changes, the construction of the answer is performed
identically to the construction of an offer as described in identically to the construction of an offer as described in
Section 9.1.3. Section 9.1.3.
9.3. Updating the Check and Valid Lists 9.3. Receiving the Answer for a Subsequent Offer
9.3.1. Procedures for Full Implementations Some deployments of ICE include e.g. SDP-Modifying Signaling-only
Back-to-Back User Agents (B2BUAs) [RFC7092] that modify the SDP body
during the subsequent offer/answer exchange. With the B2BUA being
ICE-unaware a subsequent answer might be manipulated and might not
include ICE candidates although the initial answer did.
An example of a situation where such an "unexpected" answer might be
experienced appears when such a B2BUA introduces a media server
during call hold using 3rd party call-control procedures. Omitting
further details how this is done this could result in an answer being
received at the holding UA that was constructed by the B2BUA. With
the B2BUA being ICE-unaware that answer would not include ICE
candidates.
Receiving an answer without ICE attributes in this situation might be
unexpected, but would not necessarily impair the user experience.
In addition to procedures for the expected answer, the following
sections advice on how to recover from the unexpected situation.
9.3.1. Procedures for All Implementations
When receiving an answer within an existing session for a subsequent
offer as specified in Section 9.1.2.2, an agent MUST verify ICE
support as specified in Section 5.1.
9.3.1.1. ICE Restarts 9.3.1.1. ICE Restarts
If ICE support is indicated in the SDP answer, the agent MUST perform
ICE restart procedures as specified in Section 9.4.
If ICE support is no longer indicated in the SDP answer, the agent
MUST fall-back to RFC 3264 procedures and SHOULD NOT drop the dialog
just because of missing ICE support. If the agent sends a new offer
later on it SHOULD perform an ICE restart as specified in
Section 9.1.1.1.
9.3.1.2. Existing Media Streams with ICE Running
If ICE support is indicated in the SDP answer, the agent MUST
continue ICE procedures as specified in Section 9.4.1.4.
If ICE support is no longer indicated in the SDP answer, the agent
MUST abort the ongoing ICE processing and fall-back to RFC 3264
procedures. The agent SHOULD NOT drop the dialog just because of
missing ICE support. If the agent sends a new offer later on, it
SHOULD perform an ICE restart as specified in Section 9.1.1.1.
9.3.1.3. Existing Media Streams with ICE Completed
If ICE support is indicated in the SDP answer and if the answer
conforms to Section 9.2.2.3, the agent MUST remain in the ICE
Completed state.
If ICE support is no longer indicated in the SDP answer, the agent
MUST fall-back to RFC 3264 procedures and SHOULD NOT drop the dialog
just because of this unexpected answer. Once the agent sends a new
offer later on it MUST perform an ICE restart.
9.4. Updating the Check and Valid Lists
9.4.1. Procedures for Full Implementations
9.4.1.1. ICE Restarts
The agent MUST remember the highest-priority nominated pairs in the The agent MUST remember the highest-priority nominated pairs in the
Valid list for each component of the media stream, called the Valid list for each component of the media stream, called the
previous selected pairs, prior to the restart. The agent will previous selected pairs, prior to the restart. The agent will
continue to send media using these pairs, as described in continue to send media using these pairs, as described in
Section 11.1. Once these destinations are noted, the agent MUST Section 11.1. Once these destinations are noted, the agent MUST
flush the valid and check lists, and then recompute the check list flush the valid and check lists, and then recompute the check list
and its states as described in section 6.3 of [ICE-BIS]. and its states as described in section 6.3 of [ICE-BIS].
9.3.1.2. New Media Stream 9.4.1.2. New Media Stream
If the offer/answer exchange added a new media stream, the agent MUST If the offer/answer exchange added a new media stream, the agent MUST
create a new check list for it (and an empty Valid list to start of create a new check list for it (and an empty Valid list to start of
course), as described in section 6.3 of [ICE-BIS]. course), as described in section 6.3 of [ICE-BIS].
9.3.1.3. Removed Media Stream 9.4.1.3. Removed Media Stream
If the offer/answer exchange removed a media stream, or an answer If the offer/answer exchange removed a media stream, or an answer
rejected an offered media stream, an agent MUST flush the Valid list rejected an offered media stream, an agent MUST flush the Valid list
for that media stream. It MUST terminate any STUN transactions in for that media stream. It MUST terminate any STUN transactions in
progress for that media stream. An agent MUST remove the check list progress for that media stream. An agent MUST remove the check list
for that media stream and cancel any pending ordinary checks for it. for that media stream and cancel any pending ordinary checks for it.
9.3.1.4. ICE Continuing for Existing Media Stream 9.4.1.4. ICE Continuing for Existing Media Stream
The valid list is not affected by an updated offer/answer exchange The valid list is not affected by an updated offer/answer exchange
unless ICE is restarting. unless ICE is restarting.
If an agent is in the Running state for that media stream, the check If an agent is in the Running state for that media stream, the check
list is updated (the check list is irrelevant if the state is list is updated (the check list is irrelevant if the state is
completed). To do that, the agent recomputes the check list using completed). To do that, the agent recomputes the check list using
the procedures described in section 6.3 of [ICE-BIS]. If a pair on the procedures described in section 6.3 of [ICE-BIS]. If a pair on
the new check list was also on the previous check list, and its state the new check list was also on the previous check list, and its state
was Waiting, In-Progress, Succeeded, or Failed, its state is copied was Waiting, In-Progress, Succeeded, or Failed, its state is copied
skipping to change at page 21, line 34 skipping to change at page 22, line 48
Next, the agent goes through each check list, starting with the Next, the agent goes through each check list, starting with the
highest-priority pair. If a pair has a state of Succeeded, and it highest-priority pair. If a pair has a state of Succeeded, and it
has a component ID of 1, then all Frozen pairs in the same check list has a component ID of 1, then all Frozen pairs in the same check list
with the same foundation whose component IDs are not 1 have their with the same foundation whose component IDs are not 1 have their
state set to Waiting. If, for a particular check list, there are state set to Waiting. If, for a particular check list, there are
pairs for each component of that media stream in the Succeeded state, pairs for each component of that media stream in the Succeeded state,
the agent moves the state of all Frozen pairs for the first component the agent moves the state of all Frozen pairs for the first component
of all other media streams (and thus in different check lists) with of all other media streams (and thus in different check lists) with
the same foundation to Waiting. the same foundation to Waiting.
9.3.2. Procedures for Lite Implementations 9.4.2. Procedures for Lite Implementations
If ICE is restarting for a media stream, the agent MUST start a new If ICE is restarting for a media stream, the agent MUST start a new
Valid list for that media stream. It MUST remember the pairs in the Valid list for that media stream. It MUST remember the pairs in the
previous Valid list for each component of the media stream, called previous Valid list for each component of the media stream, called
the previous selected pairs, and continue to send media there as the previous selected pairs, and continue to send media there as
described in Section 11.1. The state of ICE processing for each described in Section 11.1. The state of ICE processing for each
media stream MUST change to Running, and the state of ICE processing media stream MUST change to Running, and the state of ICE processing
MUST change to Running. MUST change to Running.
10. Keepalives 10. Keepalives
skipping to change at page 35, line 15 skipping to change at page 36, line 26
related extensions related extensions
17. Acknowledgments 17. Acknowledgments
A large part of the text in this document was taken from RFC 5245, A large part of the text in this document was taken from RFC 5245,
authored by Jonathan Rosenberg. authored by Jonathan Rosenberg.
Some of the text in this document was taken from RFC 6336, authored Some of the text in this document was taken from RFC 6336, authored
by Magnus Westerlund and Colin Perkins. by Magnus Westerlund and Colin Perkins.
Thanks to Thomas Stach for the text in Section 9.3
18. References 18. References
18.1. Normative References 18.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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
skipping to change at page 36, line 40 skipping to change at page 38, line 5
October 2008. October 2008.
[RFC5768] Rosenberg, J., "Indicating Support for Interactive [RFC5768] Rosenberg, J., "Indicating Support for Interactive
Connectivity Establishment (ICE) in the Session Initiation Connectivity Establishment (ICE) in the Session Initiation
Protocol (SIP)", RFC 5768, April 2010. Protocol (SIP)", RFC 5768, April 2010.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, August 2012. for RTP over UDP", RFC 6679, August 2012.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", RFC
7092, December 2013.
[ICE-BIS] Keranen, A. and J. Rosenberg, "Interactive Connectivity [ICE-BIS] Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer Protocols", Translator (NAT) Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-rfc5245bis-02 (work in progress), July draft-ietf-mmusic-rfc5245bis-04 (work in progress), March
2014. 2015.
18.2. Informative References 18.2. Informative References
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004. BCP 85, RFC 3725, April 2004.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
Tone Generation in the Session Initiation Protocol (SIP)", Tone Generation in the Session Initiation Protocol (SIP)",
 End of changes. 16 change blocks. 
56 lines changed or deleted 125 lines changed or added

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