draft-ietf-mmusic-ice-sip-sdp-23.txt   draft-ietf-mmusic-ice-sip-sdp-24.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5245 (if approved) S. Nandakumar Obsoletes: 5245 (if approved) S. Nandakumar
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: April 12, 2019 A. Keranen Expires: May 13, 2019 A. Keranen
Ericsson Ericsson
October 9, 2018 November 9, 2018
Session Description Protocol (SDP) Offer/Answer procedures for Session Description Protocol (SDP) Offer/Answer procedures for
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-sip-sdp-23 draft-ietf-mmusic-ice-sip-sdp-24
Abstract Abstract
This document describes Session Description Protocol (SDP) Offer/ This document describes Session Description Protocol (SDP) Offer/
Answer procedures for carrying out Interactive Connectivity Answer procedures for carrying out Interactive Connectivity
Establishment (ICE) between the agents. Establishment (ICE) between the agents.
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 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 12, 2019. This Internet-Draft will expire on May 13, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 7 skipping to change at page 3, line 7
4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 18 4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 18
4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 19 4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 19
4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 20 4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 20
5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 21
6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 21 6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 21
6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 21 6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 21
6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 23 6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 23
6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 23 6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 23
6.3. Interactions with Forking . . . . . . . . . . . . . . . . 23 6.3. Interactions with Forking . . . . . . . . . . . . . . . . 23
6.4. Interactions with Preconditions . . . . . . . . . . . . . 24 6.4. Interactions with Preconditions . . . . . . . . . . . . . 23
6.5. Interactions with Third Party Call Control . . . . . . . 24 6.5. Interactions with Third Party Call Control . . . . . . . 24
7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 25 7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 25 8.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 25
8.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 25 8.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 25
8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 25 8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 25
8.2.2. Interactions with Application Layer Gateways and SIP 26 8.2.2. Interactions with Application Layer Gateways and SIP 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 27 9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 27
9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 27 9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 27
9.1.2. remote-candidates Attribute . . . . . . . . . . . . . 28 9.1.2. remote-candidates Attribute . . . . . . . . . . . . . 27
9.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 28 9.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 28
9.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 29 9.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 28
9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 29 9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 29
9.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 30 9.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 29
9.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 30 9.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 30
9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 31 9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 30
9.2. Interactive Connectivity Establishment (ICE) Options 9.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 31 Registry . . . . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 33
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35
Appendix B. The remote-candidates Attribute . . . . . . . . . . 37 Appendix B. The remote-candidates Attribute . . . . . . . . . . 36
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 37 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 37
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 38 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 38
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 39 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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
[RFC3264]. The ICE specification [RFC8445] describes procedures that [RFC3264]. The ICE specification [RFC8445] describes procedures that
skipping to change at page 21, line 50 skipping to change at page 21, line 50
enters the destination address for the user and ringback begins as a enters the destination address for the user and ringback begins as a
consequence of having successfully started alerting the called user consequence of having successfully started alerting the called user
agent. agent.
Two cases can be considered -- one where the offer is present in the Two cases can be considered -- one where the offer is present in the
initial INVITE and one where it is in a response. initial INVITE and one where it is in a response.
6.1.1. Offer in INVITE 6.1.1. Offer in INVITE
To reduce post-dial delays, it is RECOMMENDED that the caller begin To reduce post-dial delays, it is RECOMMENDED that the caller begin
gathering candidates prior to actually sending its initial INVITE. gathering candidates prior to actually sending its initial INVITE, so
that the candidates can be provided in the INVITE. This can be
This can be started upon user interface cues that a call is pending, started upon user interface cues that a call is pending, such as
such as activity on a keypad or the phone going off-hook. activity on a keypad or the phone going off-hook.
On the receipt of the offer, the answerer SHOULD generate an answer On the receipt of the offer, the answerer SHOULD generate an answer
in a provisional response once it has completed candidate gathering. in a provisional response as soon as it has completed gathering the
ICE requires that a provisional response with an SDP be transmitted candidates. ICE requires that a provisional response with an SDP be
reliably. This can be done through the existing Provisional Response transmitted reliably. This can be done through the existing
Acknowledgment (PRACK) mechanism [RFC3262] or through an ICE specific Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or
optimization, wherein, the agent retransmits the provisional response through an ICE specific optimization, wherein, the agent retransmits
with the exponential backoff timers described in [RFC3262]. Such the provisional response with the exponential backoff timers
retransmissions MUST cease on receipt of a STUN Binding request for described in [RFC3262]. Such retransmissions MUST cease on receipt
one of the data streams signaled in that SDP or on transmission of of a STUN Binding request with transport address matching candidate
the answer in a 2xx response. If no Binding request is received address for one of the data streams signaled in that SDP or on
prior to the last retransmit, the agent does not consider the session transmission of the answer in a 2xx response. If no Binding request
terminated. For the ICE lite peers, the agent MUST cease is received prior to the last retransmit, the agent does not consider
retransmitting the 18x after sending it four times (ICE will actually the session terminated. For the ICE lite peers , the agent MUST
work even if the peer never receives the 18x; however, experience has cease retransmitting the 18x after sending it four times since there
shown that sending it is important for middleboxes and firewall will be no Binding request sent and the number four is arbitrarily
traversal). chosen to limit the number of 18x retransmits ('poor man's version of
[RFC3262]' basically). (ICE will actually work even if the peer
It should be noted that the ICE specific optimization is very never receives the 18x; however, experience has shown that sending it
specific to provisional response carrying answers that start ICE is important for middleboxes and firewall traversal).
processing and it is not a general technique for 1xx reliability.
Also such an optimization SHOULD NOT be used if both agents support
PRACK.
Despite the fact that the provisional response will be delivered
reliably, the rules for when an agent can send an updated offer or
answer do not change from those specified in [RFC3262].
Specifically, if the INVITE contained an offer, the same answer
appears in all of the 1xx and in the 2xx response to the INVITE.
Only after that 2xx has been sent can an updated offer/answer
exchange occur.
Alternatively, an agent MAY delay sending an answer until the 200 OK;
however, this results in a poor user experience and is NOT
RECOMMENDED.
Once the answer has been sent, the agent SHOULD begin its Once the answer has been sent, the agent SHOULD begin its
connectivity checks. Once candidate pairs for each component of a connectivity checks. Once candidate pairs for each component of a
data stream enter the valid list, the answerer can begin sending data stream enter the valid list, the answerer can begin sending
media on that data stream. media on that data stream.
However, prior to this point, any media that needs to be sent towards However, prior to this point, any media that needs to be sent towards
the caller (such as SIP early media [RFC3960]) MUST NOT be the caller (such as SIP early media [RFC3960]) MUST NOT be
transmitted. For this reason, implementations SHOULD delay alerting transmitted. For this reason, implementations SHOULD delay alerting
the called party until candidates for each component of each data the called party until candidates for each component of each data
 End of changes. 15 change blocks. 
51 lines changed or deleted 36 lines changed or added

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