draft-ietf-mmusic-trickle-ice-sip-07.txt   draft-ietf-mmusic-trickle-ice-sip-08.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Standards Track T. Stach Intended status: Standards Track T. Stach
Expires: September 4, 2017 Unaffiliated Expires: January 22, 2018 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
March 3, 2017 July 21, 2017
A Session Initiation Protocol (SIP) usage for Trickle ICE A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-07 draft-ietf-mmusic-trickle-ice-sip-08
Abstract Abstract
The Interactive Connectivity Establishment (ICE) protocol describes a The Interactive Connectivity Establishment (ICE) protocol describes a
Network Address Translator (NAT) traversal mechanism for UDP-based Network Address Translator (NAT) traversal mechanism for UDP-based
multimedia sessions established with the Offer/Answer model. The ICE multimedia sessions established with the Offer/Answer model. The ICE
extension for Incremental Provisioning of Candidates (Trickle ICE) extension for Incremental Provisioning of Candidates (Trickle ICE)
defines a mechanism that allows ICE agents to shorten session defines a mechanism that allows ICE agents to shorten session
establishment delays by making the candidate gathering and establishment delays by making the candidate gathering and
connectivity checking phases of ICE non-blocking and by executing connectivity checking phases of ICE non-blocking and by executing
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 September 4, 2017. This Internet-Draft will expire on January 22, 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 36 skipping to change at page 2, line 36
3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6
4. Incremental Signaling of ICE candidates . . . . . . . . . . . 8 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 8
4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 8 4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 8
4.1.1. Asserting dialog state through reliable Offer/Answer 4.1.1. Asserting dialog state through reliable Offer/Answer
delivery . . . . . . . . . . . . . . . . . . . . . . 8 delivery . . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Asserting dialog state through unreliable 4.1.2. Asserting dialog state through unreliable
Offer/Answer delivery . . . . . . . . . . . . . . . . 9 Offer/Answer delivery . . . . . . . . . . . . . . . . 9
4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 11 4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 11
4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 12 4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 12
4.2. Delivering candidates in INFO messages . . . . . . . . . 14 4.2. Delivering candidates in INFO messages . . . . . . . . . 14
5. Initial discovery of Trickle ICE support . . . . . . . . . . 17 5. Initial discovery of Trickle ICE support . . . . . . . . . . 18
5.1. Provisioning support for Trickle ICE . . . . . . . . . . 17 5.1. Provisioning support for Trickle ICE . . . . . . . . . . 19
5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 18 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 19
5.3. Trickle ICE discovery through other protocols . . . . . . 19 5.3. Trickle ICE discovery through other protocols . . . . . . 20
5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 19 5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 20
6. Considerations for RTP and RTCP multiplexing . . . . . . . . 21 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 23
7. Considerations for Media Multiplexing . . . . . . . . . . . . 22 7. Considerations for Media Multiplexing . . . . . . . . . . . . 24
8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 25 8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 27
9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 25 8.1. Defintion . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 25 8.2. Offer/Answer procedures . . . . . . . . . . . . . . . . . 27
9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 28
10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 28
10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 27 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. Overall Description . . . . . . . . . . . . . . . . . . 28 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 30
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 28 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 30
10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 28 10.2. Overall Description . . . . . . . . . . . . . . . . . . 31
10.5. Info Package Parameters . . . . . . . . . . . . . . . . 28 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 31
10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 28 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 31
10.7. Info Message Body Parts . . . . . . . . . . . . . . . . 29 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 31
10.8. Info Package Usage Restrictions . . . . . . . . . . . . 29 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 31
10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 29 10.7. Info Message Body Parts . . . . . . . . . . . . . . . . 32
10.10. Info Package Security Considerations . . . . . . . . . . 29 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 32
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 32
11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 29 10.10. Info Package Security Considerations . . . . . . . . . . 32
11.2. application/trickle-ice-sdpfrag MIME Type . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 32 11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 32
11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 32 11.2. application/trickle-ice-sdpfrag MIME Type . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 35
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 35
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
15.1. Normative References . . . . . . . . . . . . . . . . . . 35 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 36
15.2. Informative References . . . . . . . . . . . . . . . . . 37 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 15.1. Normative References . . . . . . . . . . . . . . . . . . 38
15.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
The Interactive Connectivity Establishment protocol The Interactive Connectivity Establishment protocol
[I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal [I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal
that consists of three main phases: a phase where an agent gathers a that consists of three main phases: a phase where an agent gathers a
set of candidate transport addresses (source IP address, port and set of candidate transport addresses (source IP address, port and
transport protocol), a second phase where these candidates are sent transport protocol), a second phase where these candidates are sent
to a remote agent and this gathering procedure is repeated and, to a remote agent and this gathering procedure is repeated and,
finally, a third phase where connectivity between all candidates in finally, a third phase where connectivity between all candidates in
skipping to change at page 10, line 38 skipping to change at page 10, line 38
cease on receipt of a INFO request or on transmission of the answer cease on receipt of a INFO request or on transmission of the answer
in a 2xx response. This is similar to the procedure described in in a 2xx response. This is similar to the procedure described in
section 13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN section 13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN
binding Request is replaced by the INFO request. binding Request is replaced by the INFO request.
The Offerer MUST send a Trickle ICE INFO request as soon as it The Offerer MUST send a Trickle ICE INFO request as soon as it
receives an SDP Answer in an unreliable provisional response. This receives an SDP Answer in an unreliable provisional response. This
INFO message MUST repeat the candidates that were already provided in INFO message MUST repeat the candidates that were already provided in
the Offer (as would be the case when Half Trickle is performed or the Offer (as would be the case when Half Trickle is performed or
when new candidates have not been learned since then) and/or they MAY when new candidates have not been learned since then) and/or they MAY
also deliver new candidates (if available). An end-of-candidates also deliver new candidates (if available). The Offerer MAY include
indication MAY be included in case candidate discovery has ended in an end-of-candidates attribute in case candidate discovery has ended
the mean time. in the mean time.
As soon as an Answerer has received such an INFO request, the As soon as an Answerer has received such an INFO request, the
Answerer has an indication that a dialog is established at both ends Answerer has an indication that a dialog is established at both ends
and MAY begin trickling (Figure 5). and MAY begin trickling (Figure 5).
Note: The +SRFLX in Figure 5 indicates that additionally newly Note: The +SRFLX in Figure 5 indicates that additionally newly
learned server-reflexive candidates are included. learned server-reflexive candidates are included.
Alice Bob Alice Bob
| | | |
skipping to change at page 15, line 8 skipping to change at page 15, line 8
be set to 'application/trickle-ice-sdpfrag' as defined in Section 9. be set to 'application/trickle-ice-sdpfrag' as defined in Section 9.
Since neither the "a=candidate" nor the "a=end-of-candidates" Since neither the "a=candidate" nor the "a=end-of-candidates"
attributes contain information that would allow correlating them to a attributes contain information that would allow correlating them to a
specific "m=" line, this is handled through the use of pseudo "m=" specific "m=" line, this is handled through the use of pseudo "m="
lines and identification tags in "a=mid:" attributes as defined in lines and identification tags in "a=mid:" attributes as defined in
[RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as
defined in [RFC4566], but provide no semantics other than indicating defined in [RFC4566], but provide no semantics other than indicating
to which "m=" line a candidate belongs. Consequently, the receiving to which "m=" line a candidate belongs. Consequently, the receiving
agent MUST ignore the remaining content of the pseudo m-line. This agent MUST ignore any remaining content of the pseudo m-line, which
guarantees that the 'application/trickle-ice-sdpfrag' bodies do not is not defined in this document. This guarantees that the
interfere with the Offer/Answer procedures as specified in [RFC3264]. 'application/trickle-ice-sdpfrag' bodies do not interfere with the
Offer/Answer procedures as specified in [RFC3264].
When sending the INFO request, the agent MAY, if already known to the When sending the INFO request, the agent MAY, if already known to the
agent, include the same content into the pseudo m-line as for the agent, include the same content into the pseudo m-line as for the
corresponding Offer or Answer. However, since Trickle-ICE might be corresponding Offer or Answer. However, since Trickle-ICE might be
decoupled from the Offer/Answer negotiation this content might be decoupled from the Offer/Answer negotiation this content might be
unknown to the agent. In this case, the agent MUST include the unknown to the agent. In this case, the agent MUST include the
following default values. following default values.
o The media is set to 'audio'. o The media is set to 'audio'.
skipping to change at page 16, line 17 skipping to change at page 16, line 20
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the
same level as the ones in the Offer/Answer exchange. In other words, same level as the ones in the Offer/Answer exchange. In other words,
if they were present as session-level attributes, they will also if they were present as session-level attributes, they will also
appear at the beginning of all INFO message payloads, i.e. preceding appear at the beginning of all INFO message payloads, i.e. preceding
all "a=mid:" attributes. If they were originally exchanged as media all "a=mid:" attributes. If they were originally exchanged as media
level attributes, potentially overriding session-level values, then level attributes, potentially overriding session-level values, then
they will also be included in INFO message payloads, following the they will also be included in INFO message payloads, following the
corresponding "a=mid:" attribute. corresponding "a=mid:" attribute.
Note that [I-D.ietf-ice-trickle] requires that when candidates are
trickled, each candidate MUST be delivered to the receiving Trickle
ICE implementation not more than once and in the same order as it was
conveyed. If the signaling protocol provides any candidate
retransmissions, they need to be hidden from the ICE implementation.
This requirement is fulfilled as follows.
Since the agent is not fully aware of the state of the ICE Since the agent is not fully aware of the state of the ICE
Negotiation Session at its peer it MUST include all currently known Negotiation Session at its peer it MUST include all currently known
and used local candidates in every INFO request. I.e. all candidates and used local candidates in every INFO request. I.e. the agent MUST
that were previously sent under the same combination of "a=ice-pwd:" repeat in the INFO request body all candidates that were previously
and "a=ice-ufrag:" need to be repeated. Although repeating all sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in
candidates creates some overhead, it also allows easier handling of the same order as they were gathered. In other words, the sequence
problems that could arise from unreliable transports, like e.g. loss of a previously sent list of candidates MUST NOT change in subsequent
of messages and reordering, which can be detected through the CSeq: INFO requests and newly gathered candidates MUST be added at the end
header field in the INFO request. of that list. Although repeating all candidates creates some
overhead, it also allows easier handling of problems that could arise
from unreliable transports, like e.g. loss of messages and
reordering, which can be detected through the CSeq: header field in
the INFO request.
When receiving INFO requests carrying any candidates, agents will When receiving INFO requests carrying any candidates, agents will
therefore first identify and discard the attribute lines containing therefore first identify and discard the attribute lines containing
candidates they have already received in previous INFO requests or in candidates they have already received in previous INFO requests or in
the Offer/Answer exchange preceding them. Two candidates are the Offer/Answer exchange preceding them. Two candidates are
considered to be equal if their IP address port, transport and considered to be equal if their IP address port, transport and
component ID are the same. After identifying and discarding known component ID are the same. After identifying and discarding known
candidates, the ICE agents will then process the remaining, actually candidates, the agents MUST forward the actually new candidates to
new candidates according to the rules described in the ICE agents in the same order as they were received in the INFO
[I-D.ietf-ice-trickle]. request body. The ICE agents will then process the new candidates
according to the rules described in [I-D.ietf-ice-trickle].
Receiving an "a=end-of-candidates" attribute in a INFO request body -
with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the
current ICE generation - is an indication of the peer agent that it
will not send any further candidates. When included at session
level, i.e. before any pseudo "m=" line, this indication applies to
the whole session; when included at media level the indication
applies only to the corresponding pseudo "m=" line. Handling of such
end-of-candidate indications is defined in [I-D.ietf-ice-trickle].
Note: At the time of writing this specification there were ongoing Note: At the time of writing this specification there were ongoing
discussions if a functionality for removing already exchanged discussions if a functionality for removing already exchanged
candidates would be useful. Such a functionality is out of the scope candidates would be useful. Such a functionality is out of the scope
of this specification and most likely needs to be signaled by means of this specification and most likely needs to be signaled by means
of a yet to be defined ICE extension, although it could in principle of a yet to be defined ICE extension, although it could in principle
be achieved quite easily, e.g. without anticipating any solution by be achieved quite easily, e.g. without anticipating any solution by
simply omitting a previously sent candidate from a subsequent INFO simply omitting a previously sent candidate from a subsequent INFO
message. However, if an implementation according to this message. However, if an implementation according to this
specification receives such an INFO message with a missing candidate specification receives such an INFO message with a missing candidate
it MAY treat that as an exceptional case. Implementing appropriate it MAY treat that as an exceptional case. Implementing appropriate
recovery procedures at the receiving side is RECOMMENDED for this recovery procedures at the receiving side is RECOMMENDED for this
situation. Ignoring that a candidate was missing might be a sensible situation. Ignoring that a candidate was missing might be a sensible
strategy. strategy.
The following example shows the content of one sample candidate The following example shows the content of one sample candidate
delivering INFO request: delivering INFO request:
INFO sip:alice@example.com SIP/2.0 INFO sip:alice@example.com SIP/2.0
... ...
Info-Package: trickle-ice Info-Package: trickle-ice
Content-type: application/sdp Content-type: application/sdp
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: ... Content-length: ...
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0 m=audio 9 RTP/AVP 0
a=mid:1 a=mid:1
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host
a=candidate:2 1 UDP 1658497328 203.0.113.3 5000 typ srflx a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host
raddr 10.0.1.1 rport 8998 a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
a=end-of-candidates raddr 2001:db8:a0b:12f0::1 rport 8998
m=audio 9 RTP/AVP 0 a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx
a=mid:2 raddr 2001:db8:a0b:12f0::1 rport 8998
a=candidate:2 1 UDP 1658497328 203.0.113.3 5002 typ srflx a=end-of-candidates
raddr 10.0.1.1 rport 9000 m=audio 9 RTP/AVP 0
a=end-of-candidates a=mid:2
a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host
a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host
a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 9998
a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 9998
a=end-of-candidates
5. Initial discovery of Trickle ICE support 5. Initial discovery of Trickle ICE support
SIP User Agents (UAs) that support and intend to use trickle ICE are SIP User Agents (UAs) that support and intend to use trickle ICE are
REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers
and Answers using the following attribute: "a=ice-options:trickle". and Answers using the following attribute: "a=ice-options:trickle".
This makes discovery fairly straightforward for Answerers or for This makes discovery fairly straightforward for Answerers or for
cases where Offers need to be generated within existing dialogs cases where Offers need to be generated within existing dialogs
(i.e., when sending re-INVITE requests). In both scenarios prior SDP (i.e., when sending re-INVITE requests). In both scenarios prior SDP
would have provided the necessary information. would have provided the necessary information.
skipping to change at page 25, line 21 skipping to change at page 27, line 21
to wait until receipt of an Answer that eventually confirms support to wait until receipt of an Answer that eventually confirms support
or non-support for Media Multiplexing. or non-support for Media Multiplexing.
Independent of using Full Trickle or Half Trickle mode, the rules Independent of using Full Trickle or Half Trickle mode, the rules
from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and
Answerer, when putting attributes in the application/trickle-ice- Answerer, when putting attributes in the application/trickle-ice-
sdpfrag body. sdpfrag body.
8. SDP 'end-of-candidate' Attribute 8. SDP 'end-of-candidate' Attribute
8.1. Defintion
This section defines a new SDP media-level and session-level This section defines a new SDP media-level and session-level
attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a
property attribute [RFC4566], and hence has no value. By including property attribute [RFC4566], and hence has no value. By including
this attribute in an Offer or Answer the sending agent indicates that this attribute in an Offer or Answer the sending agent indicates that
it will not trickle further candidates. The detailed SDP Offer/ it will not trickle further candidates. When included at session
Answer procedures for the 'end-of-candidate' attribute are specified level this indication applies to the whole session, when included at
in [I-D.ietf-ice-trickle]. media level the indication applies only to the corresponding media
desciption.
Name: end-of-candidate Name: end-of-candidate
Value: N/A Value: N/A
Usage Level: media and session-level Usage Level: media and session-level
Charset Dependent: no Charset Dependent: no
Mux Category: IDENTICAL Mux Category: IDENTICAL
Example: a=end-of-candidate Example: a=end-of-candidate
8.2. Offer/Answer procedures
The Offerer or Answerer MAY include an "a=end-of-candidates"
attribute in case candidate discovery has ended and no further
candidates are to be trickled. The Offerer or Answerer MUST provide
the "a=end-of-candidates" attribute together with the "a=ice-ufrag"
and "a=ice-pwd" attributes of the current ICE generation as required
by [I-D.ietf-ice-trickle]. When included at session level this
indication applies to the whole session; when included at media level
the indication applies only to the corresponding media description.
Receipt of an "a=end-of-candidates attribute at an Offerer or Anwerer
- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the
current ICE generation - indicates that gathering of candidates has
ended at the peer, either for the session or only for the
corresponding media description as specified above. The receiving
agent forwards an end-of-candidates indication to the ICE Agent,
which in turn acts as specified in [I-D.ietf-ice-trickle].
9. Content Type 'application/trickle-ice-sdpfrag' 9. Content Type 'application/trickle-ice-sdpfrag'
9.1. Overall Description 9.1. Overall Description
A application/trickle-ice-sdpfrag body is used by the Trickle-ICE A application/trickle-ice-sdpfrag body is used by the Trickle-ICE
Info Package. It uses a subset of the possible SDP lines as defined Info Package. It uses a subset of the possible SDP lines as defined
by the grammar defined in [RFC4566]. A valid body uses only media by the grammar defined in [RFC4566]. A valid body uses only media
descriptions and certain attributes that are needed and/or useful for descriptions and certain attributes that are needed and/or useful for
trickling candidates. The content adheres to the following grammar. trickling candidates. The content adheres to the following grammar.
skipping to change at page 26, line 16 skipping to change at page 29, line 10
The grammar of an 'application/trickle-ice-sdpfrag' body is based the The grammar of an 'application/trickle-ice-sdpfrag' body is based the
following ABNF [RFC5234]. It specifies the subset of existing SDP following ABNF [RFC5234]. It specifies the subset of existing SDP
attributes, that are needed or useful for trickling candidates. attributes, that are needed or useful for trickling candidates.
; Syntax ; Syntax
trickle-ice-sdpfrag = session-level-fields trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions pseudo-media-descriptions
session-level-fields = [bundle-group-attribute CRLF] session-level-fields = [bundle-group-attribute CRLF]
[ice-lite-attribute CRLF] [ice-lite-attribute CRLF]
ice-pwd-attribute CRLF ice-pwd-attribute CRLF
ice-ufrag-attribute CRLF ice-ufrag-attribute CRLF
[ice-options-attribute CRLF] [ice-options-attribute CRLF]
[ice-pacing-attribute CRLF] [ice-pacing-attribute CRLF]
[end-of-candidates-attribute CRLF] [end-of-candidates-attribute CRLF]
extension-attribute-fields extension-attribute-fields
; for future extensions ; for future extensions
ice-lite-attribute = %s"a=" ice-lite ice-lite-attribute = %s"a" "=" ice-lite
ice-pwd-attribute = %s"a=" ice-pwd-att ice-pwd-attribute = %s"a" "=" ice-pwd-att
ice-ufrag-attribute = %s"a=" ice-ufrag-att ice-ufrag-attribute = %s"a" "=" ice-ufrag-att
ice-pacing-attribute = %s"a=" ice-pacing-att ice-pacing-attribute = %s"a" "=" ice-pacing-att
ice-options-attribute = %s"a=" ice-options ice-options-attribute = %s"a" "=" ice-options
bundle-group-attribute = "a=group:" bundle-semantics bundle-group-attribute = %s"a" "=" "group:" bundle-semantics
*(SP identification-tag) *(SP identification-tag)
bundle-semantics = "BUNDLE" bundle-semantics = "BUNDLE"
end-of-candidates-attribute = %s"a=" end-of-candidates end-of-candidates-attribute = %s"a" "=" end-of-candidates
end-of-candidates = "end-of-candidates"
extension-attribute-fields = attribute-fields extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields trickle-ice-attribute-fields
[extension-attribute-fields] ) [extension-attribute-fields] )
; for future extensions ; for future extensions
trickle-ice-attribute-fields = mid-attribute CRLF trickle-ice-attribute-fields = %s"a" "=" mid-attribute CRLF
["a=rtcp-mux" CRLF] [%s"a" "=" "rtcp-mux" CRLF]
["a=rtcp-mux-only" CRLF] [%s"a" "=" "rtcp-mux-only" CRLF]
*(candidate-attributes CRLF) *(candidate-attributes CRLF)
[ice-pwd-attribute CRLF] [ice-pwd-attribute CRLF]
[ice-ufrag-attribute CRLF] [ice-ufrag-attribute CRLF]
[remote-candidate-attribute CRLF] [remote-candidate-attribute CRLF]
[end-of-candidates-attribute CRLF] [end-of-candidates-attribute CRLF]
remote-candidate-attribute = %s"a=" remote-candidate-att remote-candidate-attribute = %s"a" "=" remote-candidate-att
candidate-attributes = %s"a=" candidate-attribute candidate-attributes = %s"a" "=" candidate-attribute
end-of-candidates = %s"end-of-candidates"
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
pacing-att, ice-options, candidate-attribute remote-candidate-att pacing-att, ice-options, candidate-attribute remote-candidate-att
from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute
; from [RFC5888], media-field, attribute-fields from [RFC4566]. The ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The
indicator for case-sensitivity %s is defined in [RFC7405]. "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux"
attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in
[I-D.ietf-mmusic-mux-exclusive]. The indicator for case-sensitivity
%s is defined in [RFC7405].
An Agent MUST ignore any received unknown extension-attribute-fields. An Agent MUST ignore any received unknown extension-attribute-fields.
10. Info Package 10. Info Package
10.1. Rationale - Why INFO? 10.1. Rationale - Why INFO?
The decision to use SIP INFO requests as a candidate transport method The decision to use SIP INFO requests as a candidate transport method
is based primarily on their lightweight nature. Once a dialog has is based primarily on their lightweight nature. Once a dialog has
been established, INFO messages can be exchanged both ways with no been established, INFO messages can be exchanged both ways with no
skipping to change at page 29, line 35 skipping to change at page 32, line 31
about loss of packets in such a case might consider aggregating ICE about loss of packets in such a case might consider aggregating ICE
candidates and sending INFOS only at some configurable intervals. candidates and sending INFOS only at some configurable intervals.
10.10. Info Package Security Considerations 10.10. Info Package Security Considerations
See Section 12 See Section 12
11. IANA Considerations 11. IANA Considerations
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document. Please replace "I-D.ietf-ice-trickle" with the RFC number document. ]
of that document.]
11.1. SDP 'end-of-candidate' Attribute 11.1. SDP 'end-of-candidate' Attribute
This section defines a new SDP media-level and session-level This section defines a new SDP media-level and session-level
attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a
property attribute [RFC4566] , and hence has no value. property attribute [RFC4566] , and hence has no value.
Name: end-of-candidate Name: end-of-candidate
Value: N/A Value: N/A
Usage Level: media and session Usage Level: media and session
Charset Dependent: no Charset Dependent: no
Purpose: The sender indicates that it will not trickle Purpose: The sender indicates that it will not trickle
further candidates. further candidates.
O/A Procedures: "I-D.ietf-ice-trickle" defines the detailed O/A Procedures: RFCXXX defines the detailed
SDP Offer/Answer procedures for SDP Offer/Answer procedures for
the 'end-of-candidate' attribute. the 'end-of-candidate' attribute.
Mux Category: IDENTICAL Mux Category: IDENTICAL
Reference: RFCXXXX Reference: RFCXXXX
Example: Example:
a=end-of-candidate a=end-of-candidate
skipping to change at page 35, line 4 skipping to change at page 38, line 4
Changes from draft-ietf-mmusic-trickle-ice-sip-06 Changes from draft-ietf-mmusic-trickle-ice-sip-06
o editorial fixes o editorial fixes
o additional text on the content of the INFO messages. o additional text on the content of the INFO messages.
o recommendation on what to do if a previously sent candidate is o recommendation on what to do if a previously sent candidate is
unexpectedly missing in a subsequent INFO unexpectedly missing in a subsequent INFO
o terminology alignment with draft-ietf-ice-trickle-07 o terminology alignment with draft-ietf-ice-trickle-07
Changes from draft-ietf-mmusic-trickle-ice-sip-07
o editorial fixes
o clarification on ordering of candidates for alignment with draft-
ietf-ice-trickle-12
o O/A procedures for end-of-candidates attribute described here
after corresponding procedures have been removed from draft-ietf-
ice-trickle-11
o using IPv6 addresses in examples
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-07 (work in progress), Protocol", draft-ietf-ice-trickle-13 (work in progress),
February 2017. July 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using Petit-Huguenin, M., Keranen, A., and S. Nandakumar,
Interactive Connectivity Establishment (ICE) with Session "Session Description Protocol (SDP) Offer/Answer
Description Protocol (SDP) offer/answer and Session procedures for Interactive Connectivity Establishment
Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- (ICE)", draft-ietf-mmusic-ice-sip-sdp-13 (work in
sdp-11 (work in progress), January 2017. progress), June 2017.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-11 (work in progress), February 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-rfc5245bis] [I-D.ietf-mmusic-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal", draft-ietf-mmusic- Translator (NAT) Traversal", draft-ietf-mmusic-
rfc5245bis-05 (work in progress), September 2015. rfc5245bis-05 (work in progress), September 2015.
[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-36 (work in progress), October 2016. negotiation-38 (work in progress), April 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.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 28 change blocks. 
105 lines changed or deleted 172 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/