draft-ietf-mmusic-ice-sip-sdp-13.txt   draft-ietf-mmusic-ice-sip-sdp-14.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5245 (if approved) A. Keranen Obsoletes: 5245 (if approved) A. Keranen
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: December 30, 2017 S. Nandakumar Expires: April 5, 2018 S. Nandakumar
Cisco Systems Cisco Systems
June 28, 2017 October 2, 2017
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-13 draft-ietf-mmusic-ice-sip-sdp-14
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 December 30, 2017. This Internet-Draft will expire on April 5, 2018.
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
(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 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ICE Candidate Exchange and Offer/Answer Mapping . . . . . . . 4 3. ICE Candidate Exchange and Offer/Answer Mapping . . . . . . . 4
4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4
4.1. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 4 4.1. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 4
4.1.1. Sending the Initial Offer . . . . . . . . . . . . . . 4 4.1.1. Sending the Initial Offer . . . . . . . . . . . . . . 4
4.1.2. Receiving the Initial Offer . . . . . . . . . . . . . 7 4.1.2. Receiving the Initial Offer . . . . . . . . . . . . . 7
4.1.3. Receipt of the Initial Answer . . . . . . . . . . . . 8 4.1.3. Receipt of the Initial Answer . . . . . . . . . . . . 8
4.1.4. Performing Connectivity Checks . . . . . . . . . . . 9 4.1.4. Performing Connectivity Checks . . . . . . . . . . . 9
4.1.5. Concluding ICE . . . . . . . . . . . . . . . . . . . 9 4.1.5. Concluding ICE . . . . . . . . . . . . . . . . . . . 9
4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 9 4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10
4.2.1. Generating the Offer . . . . . . . . . . . . . . . . 10 4.2.1. Generating the Offer . . . . . . . . . . . . . . . . 10
4.2.2. Receiving the Offer and Generating an Answer . . . . 12 4.2.2. Receiving the Offer and Generating an Answer . . . . 13
4.2.3. Receiving the Answer for a Subsequent Offer . . . . . 16 4.2.3. Receiving the Answer for a Subsequent Offer . . . . . 16
4.2.4. Updating the Check and Valid Lists . . . . . . . . . 17 4.2.4. Updating the Check and Valid Lists . . . . . . . . . 17
5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 18 5.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 18
5.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 21 5.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 21
5.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 21 5.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 21
5.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 22 5.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 22
5.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 22 5.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 22
5.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 23 5.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 23
6. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 4, line 45 skipping to change at page 4, line 45
The offerer shall follow the procedures defined in section 4 of The offerer shall follow the procedures defined in section 4 of
[ICE-BIS] to gather, prioritize and eliminate the redundant [ICE-BIS] to gather, prioritize and eliminate the redundant
candidates. It then chooses the default candidates and encodes them candidates. It then chooses the default candidates and encodes them
in the SDP to be sent to its peer, the answerer. in the SDP to be sent to its peer, the answerer.
4.1.1.1. Choosing Default Candidates 4.1.1.1. Choosing Default Candidates
A candidate is said to be default if it would be the target of media A candidate is said to be default if it would be the target of media
from a non-ICE peer; that target is called the DEFAULT DESTINATION. from a non-ICE peer; that target is called the DEFAULT DESTINATION.
If the default candidates are not selected by the ICE algorithm when
communicating with an ICE-aware peer, an updated offer/answer will be
required after ICE processing completes in order to "fix up" the SDP
so that the default destination for media matches the candidates
selected by ICE. If ICE happens to select the default candidates, no
updated offer/answer is required.
An agent MUST choose a set of candidates, one for each component of An agent MUST choose a set of candidates, one for each component of
each in-use media stream, to be default. A media stream is in-use if each in-use media stream, to be default. A media stream is in-use if
it does not have a port of zero (which is used in RFC 3264 to reject it does not have a port of zero (which is used in RFC 3264 to reject
a media stream). Consequently, a media stream is in-use even if it a media stream). Consequently, a media stream is in-use even if it
is marked as a=inactive [RFC4566] or has a bandwidth value of zero. is marked as a=inactive [RFC4566] or has a bandwidth value of zero.
An agent may choose any type of the candidate as the default, if the An agent may choose any type of the candidate as the default, if the
chosen candidates increases the likelihood of success with the peer chosen candidates increases the likelihood of success with the peer
that is being contacted if ICE is not being used. that is being contacted if ICE is not being used. It is recommended
that, when multiple candidates are used, UDP based candidates SHOULD
be included wherever possible and default candidate SHOULD be chosen
from one of those UDP candidates. The proto value MUST match the
transport protocol associated with the default candidate. If UDP
transport is used for the default candidate, the 'proto' value MUST
include UDP and the 'proto' value MUST be TCP when the transport is
TCP for the default candidate.
It is RECOMMENDED that default candidates be chosen based on the Since it is RECOMMENDED that default candidates be chosen based on
likelihood of those candidates to work with the peer that is being the likelihood of those candidates to work with the peer that is
contacted if ICE is not being used. Many factors may influence such being contacted if ICE is not being used. Many factors may influence
a decision in a given agent. In scenarios where the agent is fully such a decision in a given agent. In scenarios where the agent is
aware of its peer's location and can reach the peer directly, fully aware of its peer's location and can reach the peer directly,
choosing the host candidates as the default may well be sufficient. choosing the host candidates as the default may well be sufficient.
If the network configuration under which the agents operates is If the network configuration under which the agents operates is
static and known beforehand, either the host or the server reflexives static and known beforehand, either the host or the server reflexives
candidates can serve as the default candidates (depending on if a candidates can serve as the default candidates (depending on if a
given agent is behind NAT and their reachability). If the agent is given agent is behind NAT and their reachability). If the agent is
completely unaware of the peer's location or no assumptions can be completely unaware of the peer's location or no assumptions can be
made of network characteristics and the connectivity, the relayed made of network characteristics and the connectivity, the relayed
candidates might be the only option as the default candidate. Having candidates might be the only option as the default candidate. Having
the decision of choosing the default candidate as a configurable the decision of choosing the default candidate as a configurable
option in the implementations might provide agents the flexibility to option in the implementations might provide agents the flexibility to
skipping to change at page 9, line 46 skipping to change at page 9, line 46
4.1.5. Concluding ICE 4.1.5. Concluding ICE
Once the state of each check list is Completed, If an agent is Once the state of each check list is Completed, If an agent is
controlling, it examines the highest-priority nominated candidate controlling, it examines the highest-priority nominated candidate
pair for each component of each media stream. If any of those pair for each component of each media stream. If any of those
candidate pairs differ from the default candidate pairs in the most candidate pairs differ from the default candidate pairs in the most
recent offer/answer exchange, the controlling agent MUST generate an recent offer/answer exchange, the controlling agent MUST generate an
updated offer as described in Section 4.2. updated offer as described in Section 4.2.
However, If the support for 'ice2' ICE Option is in use, the highest-
priority nominated candidate is noted and sent in the subsequent
offer/answer exchange as the default candidate and no updated offer
is needed to fix the default candidate.
4.2. Subsequent Offer/Answer Exchanges 4.2. Subsequent Offer/Answer Exchanges
Either agent MAY generate a subsequent offer at any time allowed by Either agent MAY generate a subsequent offer at any time allowed by
[RFC3264]. The rules in Section 4.1.5 will cause the controlling [RFC3264]. This section defines rules for construction of subsequent
agent to send an updated offer at the conclusion of ICE processing
when ICE has selected different candidate pairs from the default
pairs. This section defines rules for construction of subsequent
offers and answers. offers and answers.
Should a subsequent offer fail, ICE processing continues as if the Should a subsequent offer fail, ICE processing continues as if the
subsequent offer had never been made. subsequent offer had never been made.
4.2.1. Generating the Offer 4.2.1. Generating the Offer
4.2.1.1. Procedures for All Implementations 4.2.1.1. Procedures for All Implementations
4.2.1.1.1. ICE Restarts 4.2.1.1.1. ICE Restarts
skipping to change at page 11, line 40 skipping to change at page 11, line 47
4.2.1.2.2. Existing Media Streams with ICE Completed 4.2.1.2.2. Existing Media Streams with ICE Completed
If an agent generates an updated offer including a media stream that If an agent generates an updated offer including a media stream that
was previously established, and for which ICE checks are in the was previously established, and for which ICE checks are in the
Completed state, the agent follows the procedures defined here. Completed state, the agent follows the procedures defined here.
The default destination for media (i.e., the values of the IP The default destination for media (i.e., the values of the IP
addresses and ports in the "m=" and "c=" lines used for that media addresses and ports in the "m=" and "c=" lines used for that media
stream) MUST be the local candidate from the highest-priority stream) MUST be the local candidate from the highest-priority
nominated pair in the valid list for each component. This "fixes" nominated pair in the valid list for each component.
the default destination for media to equal the destination ICE has
selected for media.
The agent MUST include candidate attributes for candidates matching The agent MUST include candidate attributes for candidates matching
the default destination for each component of the media stream, and the default destination for each component of the media stream, and
MUST NOT include any other candidates. MUST NOT include any other candidates.
In addition, if the agent is controlling, it MUST include the In addition, if the agent is controlling, it MUST include the
a=remote-candidates attribute for each media stream whose check list a=remote-candidates attribute for each media stream whose check list
is in the Completed state. The attribute contains the remote is in the Completed state. The attribute contains the remote
candidates from the highest-priority nominated pair in the valid list candidates from the highest-priority nominated pair in the valid list
for each component of that media stream. It is needed to avoid a for each component of that media stream. It is needed to avoid a
 End of changes. 12 change blocks. 
26 lines changed or deleted 26 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/