draft-ietf-mmusic-trickle-ice-sip-09.txt   draft-ietf-mmusic-trickle-ice-sip-10.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: April 13, 2018 Unaffiliated Expires: April 18, 2018 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
October 10, 2017 October 15, 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-09 draft-ietf-mmusic-trickle-ice-sip-10
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 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2018. This Internet-Draft will expire on April 18, 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 35 skipping to change at page 2, line 35
3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5
3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6
4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7
4.1. Initial Offer/Answer exchange . . . . . . . . . . . . . . 8 4.1. Initial Offer/Answer exchange . . . . . . . . . . . . . . 8
4.1.1. Sending the initial Offer . . . . . . . . . . . . . . 8 4.1.1. Sending the initial Offer . . . . . . . . . . . . . . 8
4.1.2. Receiving the initial Offer . . . . . . . . . . . . . 9 4.1.2. Receiving the initial Offer . . . . . . . . . . . . . 9
4.1.3. Sending the initial Answer . . . . . . . . . . . . . 9 4.1.3. Sending the initial Answer . . . . . . . . . . . . . 9
4.1.4. Receiving the initial Answer . . . . . . . . . . . . 9 4.1.4. Receiving the initial Answer . . . . . . . . . . . . 9
4.2. Establishing the dialog . . . . . . . . . . . . . . . . . 9 4.2. Establishing the dialog . . . . . . . . . . . . . . . . . 9
4.2.1. Asserting dialog state through reliable Offer/Answer 4.2.1. Asserting dialog state through reliable Offer/Answer
delivery . . . . . . . . . . . . . . . . . . . . . . 9 delivery . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Asserting dialog state through unreliable 4.2.2. Asserting dialog state through unreliable
Offer/Answer delivery . . . . . . . . . . . . . . . . 10 Offer/Answer delivery . . . . . . . . . . . . . . . . 10
4.2.3. Initiating Trickle ICE without an SDP Answer . . . . 12 4.2.3. Initiating Trickle ICE without an SDP Answer . . . . 12
4.2.4. Considerations for 3PCC . . . . . . . . . . . . . . . 14 4.2.4. Considerations for 3PCC . . . . . . . . . . . . . . . 14
4.3. Delivering candidates in INFO messages . . . . . . . . . 15 4.3. Delivering candidates in INFO messages . . . . . . . . . 15
5. Initial discovery of Trickle ICE support . . . . . . . . . . 19 5. Initial discovery of Trickle ICE support . . . . . . . . . . 19
5.1. Provisioning support for Trickle ICE . . . . . . . . . . 20 5.1. Provisioning support for Trickle ICE . . . . . . . . . . 20
5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 20 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 20
5.3. Trickle ICE discovery through other protocols . . . . . . 21 5.3. Trickle ICE discovery through other protocols . . . . . . 21
5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 21 5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 21
6. Considerations for RTP and RTCP multiplexing . . . . . . . . 23 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 23
7. Considerations for Media Multiplexing . . . . . . . . . . . . 24 7. Considerations for Media Multiplexing . . . . . . . . . . . . 25
8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 27 8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 27
8.1. Defintion . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Defintion . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. Offer/Answer procedures . . . . . . . . . . . . . . . . . 27 8.2. Offer/Answer procedures . . . . . . . . . . . . . . . . . 27
9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 28 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 28
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 28 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 28
9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 30 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 30
10.2. Overall Description . . . . . . . . . . . . . . . . . . 31 10.2. Overall Description . . . . . . . . . . . . . . . . . . 31
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 31 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 9, line 5 skipping to change at page 9, line 5
If the Offerer wants to send its initial Offer before knowing any If the Offerer wants to send its initial Offer before knowing any
candidate of one or more media descriptions, it MUST include the candidate of one or more media descriptions, it MUST include the
following default values in the corresponding "m=" line. following default values in the corresponding "m=" line.
o The media field is set to 'audio'. o The media field is set to 'audio'.
o The port value is set to '9'. o The port value is set to '9'.
o The proto value is set to 'RTP/AVP'. o The proto value is set to 'RTP/AVP'.
In this case, the Offerer obviously cannot know the RTCP transport
address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086].
This avoids potential ICE mismatch (see
[I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address.
If the Offerer wants to use RTCP multiplexing [RFC5761] and/or
exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still
MUST include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in
the initial Offer.
In any case, the Offerer MUST include the attribute a=ice- In any case, the Offerer MUST include the attribute a=ice-
options:trickle in accordance to [I-D.ietf-ice-trickle]. options:trickle in accordance to [I-D.ietf-ice-trickle].
4.1.2. Receiving the initial Offer 4.1.2. Receiving the initial Offer
If the initial Offer included candidates, the Answerer MUST treat If the initial Offer included candidates, the Answerer MUST treat
these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp]. these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp].
If the initial Offer included the attribute a=ice-options:trickle, If the initial Offer included the attribute a=ice-options:trickle,
the Answerer MUST be prepared for receiving trickled candidates later the Answerer MUST be prepared for receiving trickled candidates later
skipping to change at page 11, line 28 skipping to change at page 11, line 28
| +----------------------+ | +----------------------+
| | | |
Figure 4: A SIP UA that sent an Answer in an unreliable provisional Figure 4: A SIP UA that sent an Answer in an unreliable provisional
response does not know if it was received and if the dialog at the response does not know if it was received and if the dialog at the
side of the Offerer has entered the early state side of the Offerer has entered the early state
In order to clear this ambiguity as soon as possible, the Answerer In order to clear this ambiguity as soon as possible, the Answerer
needs to retransmit the provisional response with the exponential needs to retransmit the provisional response with the exponential
back-off timers described in [RFC3262]. These retransmissions MUST back-off timers described in [RFC3262]. These retransmissions MUST
cease on receipt of an INFO request or on transmission of the answer cease on receipt of an 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 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN section 8.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.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for
version 14 of said I-D. Please cross-check since it could have have version 14 of said I-D. Please cross-check since it could have have
changed in the meantime.] changed in the meantime.]
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
skipping to change at page 12, line 47 skipping to change at page 12, line 47
The possibility to convey arbitrary candidates in INFO message bodies The possibility to convey arbitrary candidates in INFO message bodies
allows ICE Agents to initiate trickling without actually sending an allows ICE Agents to initiate trickling without actually sending an
Answer. Trickle ICE Agents MAY therefore respond to an INVITE Answer. Trickle ICE Agents MAY therefore respond to an INVITE
request with provisional responses without an SDP Answer. Such request with provisional responses without an SDP Answer. Such
provisional responses serve for establishing an early dialog. provisional responses serve for establishing an early dialog.
Agents that choose to establish the dialog in this way, MUST Agents that choose to establish the dialog in this way, MUST
retransmit these responses with the exponential back-off timers retransmit these responses with the exponential back-off timers
described in [RFC3262]. These retransmissions MUST cease on receipt described in [RFC3262]. These retransmissions MUST cease on receipt
of an INFO request or on transmission of the answer in a 2xx of an INFO request or on transmission of the Answer in a 2xx
response. This is again similar to the procedure described in response. This is again similar to the procedure described in
section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer
is not yet provided. is not yet provided.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for
version 14 of said I-D. Please cross-check since it could have have version 14 of said I-D. Please cross-check since it could have have
changed in the meantime.] changed in the meantime.]
Note: The +SRFLX in Figure 6 indicates that additionally newly Note: The +SRFLX in Figure 6 indicates that additionally newly
learned server-reflexive candidates are included. learned server-reflexive candidates are included.
skipping to change at page 14, line 49 skipping to change at page 14, line 49
Trickle Agents that send an Offer in a 200 OK and receive an Answer Trickle Agents that send an Offer in a 200 OK and receive an Answer
in an ACK can still create a dialog and confirm support for Trickle in an ACK can still create a dialog and confirm support for Trickle
ICE by sending an unreliable provisional response similar to ICE by sending an unreliable provisional response similar to
Section 4.2.3. According to [RFC3261], this unreliable response MUST Section 4.2.3. According to [RFC3261], this unreliable response MUST
NOT contain an Offer. NOT contain an Offer.
The Trickle Agent (at the UAS) retransmits the provisional response The Trickle Agent (at the UAS) retransmits the provisional response
with the exponential back-off timers described in [RFC3262]. with the exponential back-off timers described in [RFC3262].
Retransmits MUST cease on receipt of an INFO request or on Retransmits MUST cease on receipt of an INFO request or on
transmission of the answer in a 2xx response. The peer Trickle Agent transmission of the Answer in a 2xx response. The peer Trickle Agent
(at the UAC) MUST send a Trickle ICE INFO request as soon as they (at the UAC) MUST send a Trickle ICE INFO request as soon as they
receive an unreliable provisional response (see Figure 8). receive an unreliable provisional response (see Figure 8).
Alice Bob Alice Bob
| | | |
| INVITE | | INVITE |
|------------------------>| |------------------------>|
| 183 (-) | | 183 (-) |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
skipping to change at page 15, line 40 skipping to change at page 15, line 40
Figure 8: A SIP UAC in a 3PCC scenario can also freely start Figure 8: A SIP UAC in a 3PCC scenario can also freely start
trickling as soon as it receives an unreliable provisional response. trickling as soon as it receives an unreliable provisional response.
4.3. Delivering candidates in INFO messages 4.3. Delivering candidates in INFO messages
Whenever new ICE candidates become available for sending, agents Whenever new ICE candidates become available for sending, agents
would encode them in "a=candidate" lines as described by would encode them in "a=candidate" lines as described by
[I-D.ietf-mmusic-ice-sip-sdp]. For example: [I-D.ietf-mmusic-ice-sip-sdp]. For example:
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
raddr 10.0.1.1 rport 8998 raddr 2001:db8:a0b:12f0::1 rport 8998
The use of SIP INFO requests happens within the context of the Info The use of SIP INFO requests happens within the context of the Info
Package as defined Section 10. The Media Type [RFC6838] for their Package as defined Section 10. The Media Type [RFC6838] for their
payload MUST be set to 'application/trickle-ice-sdpfrag' as defined payload MUST be set to 'application/trickle-ice-sdpfrag' as defined
in Section 9. 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
skipping to change at page 23, line 16 skipping to change at page 23, line 16
use the Full Trickle mode of operation. use the Full Trickle mode of operation.
6. Considerations for RTP and RTCP multiplexing 6. Considerations for RTP and RTCP multiplexing
The following consideration describe options for Trickle-ICE in order The following consideration describe options for Trickle-ICE in order
to give some guidance to implementors on how trickling can be to give some guidance to implementors on how trickling can be
optimized with respect to providing RTCP candidates. optimized with respect to providing RTCP candidates.
Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux"
attribute for RTP/RTCP multiplexing [RFC5761] is already considered attribute for RTP/RTCP multiplexing [RFC5761] is already considered
in section 4.2. of [I-D.ietf-mmusic-ice-sip-sdp], respectively, as in section 5.6.1. of [I-D.ietf-mmusic-rfc5245bis] and as well in
well in [RFC5761] itself. These considerations are still valid for [RFC5761] itself. These considerations are still valid for Trickle
Trickle ICE, however, trickling provides more flexibility for the ICE, however, trickling provides more flexibility for the sequence of
sequence of candidate exchange in case of RTCP multiplexing. candidate exchange in case of RTCP multiplexing.
[RFC EDITOR NOTE: The section 5.6.1 in above sentence is correct for
version 05 of said I-D. Please cross-check since it could have have
changed in the meantime.]
If the Offerer supports RTP/RTCP multiplexing exclusively as If the Offerer supports RTP/RTCP multiplexing exclusively as
specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that
document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" document apply for the handling of the "a=rtcp-mux-only", "a=rtcp"
and the "a=rtcp-mux" attributes. and the "a=rtcp-mux" attributes.
While a Half Trickle Offerer would have to send an offer compliant to While a Half Trickle Offerer would have to send an offer compliant to
[I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for
all components, this flexibility allows a Full Trickle Offerer to all components, this flexibility allows a Full Trickle Offerer to
initially send only RTP candidates (component 1) if it assumes that send only RTP candidates (component 1) in the initial Offer if it
RTCP multiplexing is supported by the Answerer. A Full Trickle assumes that RTCP multiplexing is supported by the Answerer. A Full
Offerer would need to start gathering and trickling RTCP candidates Trickle Offerer would need to start gathering and trickling RTCP
(component 2) only after having received an indication in the answer candidates (component 2) only after having received an indication in
that the Answerer unexpectedly does not support RTCP multiplexing. the Answer that the Answerer unexpectedly does not support RTCP
multiplexing.
A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in
the application/trickle-ice-sdpfrag body if it supports and uses RTP the application/trickle-ice-sdpfrag body if it supports and uses RTP
and RTCP multiplexing. The Trickle Answerer MUST follow the guidance and RTCP multiplexing. The Trickle Answerer MUST follow the guidance
on the usage of the "a=rtcp" attribute as given in on the usage of the "a=rtcp" attribute as given in
[I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this
Offerer in an INFO request prior to the Answer indicates that the attribute at the Offerer in an INFO request prior to the Answer
Answerer supports and uses RTP and RTCP multiplexing. The Offerer indicates that the Answerer supports and uses RTP and RTCP
can use this information e.g. for stopping gathering of RTCP multiplexing. The Offerer can use this information e.g. for stopping
candidates and/or for freeing corresponding resources. gathering of RTCP candidates and/or for freeing corresponding
resources.
This behavior is illustrated by the following example offer that This behavior is illustrated by the following example offer that
indicates support for RTP and RTCP multiplexing. indicates support for RTP and RTCP multiplexing.
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8 a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0 m=audio 10000 RTP/AVP 0
a=mid:1 a=mid:1
a=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
Once the dialog is established as described in section Section 4.2 Once the dialog is established as described in section Section 4.2
the Answerer sends the following INFO request. the Answerer sends the following 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=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
This INFO request indicates that the Answerer supports and uses RTP This INFO request indicates that the Answerer supports and uses RTP
and RTCP multiplexing as well. It allows the Offerer to omit and RTCP multiplexing as well. It allows the Offerer to omit
gathering of RTCP candidates or releasing already gathered RTCP gathering of RTCP candidates or releasing already gathered RTCP
candidates. If the INFO request did not contain the a=rtcp-mux candidates. If the INFO request did not contain the a=rtcp-mux
attribute, the Offerer would have to gather RTCP candidates unless it attribute, the Offerer would have to gather RTCP candidates unless it
wants to wait until receipt of an Answer that eventually confirms wants to wait until receipt of an Answer that eventually confirms
support or non-support for RTP and RTCP multiplexing. support or non-support for RTP and RTCP multiplexing.
7. Considerations for Media Multiplexing 7. Considerations for Media Multiplexing
skipping to change at page 25, line 17 skipping to change at page 25, line 26
still valid for Trickle ICE, however, trickling provides more still valid for Trickle ICE, however, trickling provides more
flexibility for the sequence of candidate exchange, especially in flexibility for the sequence of candidate exchange, especially in
Full Trickle mode. Full Trickle mode.
Except for bundle-only "m=" lines, a Half Trickle Offerer would have Except for bundle-only "m=" lines, a Half Trickle Offerer would have
to send an offer with candidates for all bundled "m=" lines. The to send an offer with candidates for all bundled "m=" lines. The
additional flexibility, however, allows a Full Trickle Offerer to additional flexibility, however, allows a Full Trickle Offerer to
initially send only candidates for the "m=" line with the suggested initially send only candidates for the "m=" line with the suggested
Offerer BUNDLE address. Offerer BUNDLE address.
Latest on receipt of the answer, the Offerer will detect if BUNDLE is Latest on receipt of the Answer, the Offerer will detect if BUNDLE is
supported by the Answerer and if the suggested Offerer BUNDLE address supported by the Answerer and if the suggested Offerer BUNDLE address
was selected. In this case, the Offerer does not need to trickle was selected. In this case, the Offerer does not need to trickle
further candidates for the remaining "m=" lines in a bundle. further candidates for the remaining "m=" lines in a bundle.
However, if BUNDLE is not supported, the Full Trickle Offerer needs However, if BUNDLE is not supported, the Full Trickle Offerer needs
to gather and trickle candidates for the remaining "m=" lines as to gather and trickle candidates for the remaining "m=" lines as
necessary. If the Answerer selects an Offerer BUNDLE address necessary. If the Answerer selects an Offerer BUNDLE address
different from the suggested Offerer BUNDLE address, the Full Trickle different from the suggested Offerer BUNDLE address, the Full Trickle
Offerer needs to gather and trickle candidates for the "m=" line that Offerer needs to gather and trickle candidates for the "m=" line that
carries the selected Offerer BUNDLE address. carries the selected Offerer BUNDLE address.
skipping to change at page 26, line 6 skipping to change at page 26, line 6
Receipt of this attribute at the Offerer in an INFO request prior to Receipt of this attribute at the Offerer in an INFO request prior to
the Answer indicates that the Answerer supports and uses bundling. the Answer indicates that the Answerer supports and uses bundling.
The Offerer can use this information e.g. for stopping the gathering The Offerer can use this information e.g. for stopping the gathering
of candidates for the remaining "m=" lines in a bundle and/or for of candidates for the remaining "m=" lines in a bundle and/or for
freeing corresponding resources. freeing corresponding resources.
This behaviour is illustrated by the following example offer that This behaviour is illustrated by the following example offer that
indicates support for Media Multiplexing. indicates support for Media Multiplexing.
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP6 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8 a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0 m=audio 10000 RTP/AVP 0
a=mid:foo a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 m=video 10002 RTP/AVP 31
a=mid:bar a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
Once the dialog is established as described in section Section 4.2 Once the dialog is established as described in section Section 4.2
the Answerer sends the following INFO request. the Answerer sends the following 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=group:BUNDLE foo bar a=group:BUNDLE foo bar
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:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
m=audio 9 RTP/AVP 0 m=audio 9 RTP/AVP 0
a=mid:bar a=mid:bar
This INFO request indicates that the Answerer supports and uses Media This INFO request indicates that the Answerer supports and uses Media
Multiplexing as well. Note, that the second "m=" line shows the Multiplexing as well. Note, that the second "m=" line shows the
default values as specified in section Section 4.3, e.g. media set default values as specified in section Section 4.3, e.g. media set
'audio' although 'video' was offered. The receiving ICE Agents MUST 'audio' although 'video' was offered. The receiving ICE Agents MUST
ignore these default values in the pseudo "m=" lines. ignore these default values in the pseudo "m=" lines.
The INFO request also indicates that the Answerer accepted the The INFO request also indicates that the Answerer accepted the
suggested Offerer Bundle Address. This allows the Offerer to omit suggested Offerer Bundle Address. This allows the Offerer to omit
gathering of RTP and RTCP candidates for the other "m=" lines or gathering of RTP and RTCP candidates for the other "m=" lines or
skipping to change at page 35, line 46 skipping to change at page 35, line 46
12. Security Considerations 12. Security Considerations
The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp],
[RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies
how the above specifications are used together for trickling how the above specifications are used together for trickling
candidates and does not create addtitional security risks. candidates and does not create addtitional security risks.
13. Acknowledgements 13. Acknowledgements
The authors would like to thank Flemming Andreasen, Ayush Jain, Paul The authors would like to thank Flemming Andreasen, Ayush Jain, Paul
Kyzivat, Jonathan Lennox, Simon Perreault and Martin Thomson for Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin
reviewing and/or making various suggestions for improvements and Thomson for reviewing and/or making various suggestions for
optimizations. improvements and optimizations.
14. Change Log 14. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]. [RFC EDITOR NOTE: Please remove this section when publishing].
Changes from draft-ietf-mmusic-trickle-ice-sip-01 Changes from draft-ietf-mmusic-trickle-ice-sip-01
o Editorial Clean up o Editorial Clean up
o IANA Consideration added o IANA Consideration added
skipping to change at page 38, line 24 skipping to change at page 38, line 24
o using IPv6 addresses in examples o using IPv6 addresses in examples
Changes from draft-ietf-mmusic-trickle-ice-sip-08 Changes from draft-ietf-mmusic-trickle-ice-sip-08
o editorial fixes/clarification based on Flemmings review o editorial fixes/clarification based on Flemmings review
o Description of Trickle specifics in O/A procedures for initial O/A o Description of Trickle specifics in O/A procedures for initial O/A
exchange and specification of ICE mismatch exception exchange and specification of ICE mismatch exception
Changes from draft-ietf-mmusic-trickle-ice-sip-09
o editorial fixes/correction of references
o adding missing Ref to RFC3605 in section 6, 5th para
o replaced remaining IPv4 adresses with IPv6
o Added text for handling a=rtcp in case of default RTP address
0.0.0.0:9 based on comment from Roman Shpount.
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-14 (work in progress), Protocol", draft-ietf-ice-trickle-14 (work in progress),
September 2017. September 2017.
 End of changes. 24 change blocks. 
69 lines changed or deleted 96 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/