[MMUSIC] Fwd: New Version Notification for draft-ivov-mmusic-trickle-ice-sip-02.txt

[Emil Ivov <[e-mail]>]

Hey all,

We have just updated the trickle ICE for SIP specification [0] and 
thought we'd send a quick summary of its most important characteristics.

1. Using INFO messages. Candidates are trickled with INFO messages and a 
trickle specific Info Package. This eliminates risk of glare during 
trickling and it allows both sides to do it in parallel with no concern 
for potential collisions.

2. Candidates are sent incrementally. In addition to the newly 
discovered candidates, every INFO message contains all local candidates 
an agent has previously sent. This allows misordered/lost INFOs to not 
be a problem.

3. INFO requests carry a (currently underspecified) sdpfrag 
content-type. Help is very welcome!

4. sdpfrag bodies start with session level attributes and are then 
followed by media level sections that are identified and delimited by 
"a=mid" lines. These media level sections exactly refer to the ones in 
the corresponding offer or answer.

5. INFO requests must always carry the a=ice-ufrag and a=ice-pwd 
attributes (as either session or media-level attributes) so that the 
requests can be matched to a specific ICE generation (i.e., or an 
offer/answer negotiation).

6. Trickle ICE for SIP does NOT require support for PRACK (although it 
can use it if available). In cases where PRACK is not supported an 
offerer must send a trickle INFO as soon as it gets a provisional 
response. Such an INFO message can contain new candidates or just be 
entirely the same as the previous one. (This is a change from the 
previous non-incremental version where an "end-of-candidates" was 
required for such cases).

7. SIP User Agents may be configured to force use of full trickle where 
maintainers expect all endpoints to support it. This would likely be the 
case for WebRTC environments.

8. Support for trickle ICE may also be dynamically discover with RFC 
3840 but *only if* GRUU is also supported (otherwise there is no way to 
guarantee that the endpoint responding to caps query will be the same as 
the one that will get a subsequent INVITE

9. For those with an aversion to the above discovery hacks, trickle ICE 
for SIP can also be used in half trickle mode where the offerer starts 
with a regular ICE offer and, if the answerer can trickle, it just does.

Comments and questions are welcome!


Trickle ICE for SIP:
[0] html: http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02
[1] diff: 
http://www.ietf.org/rfcdiff?url2=draft-ivov-mmusic-trickle-ice-sip-02


-------- Original Message --------
Subject: New Version Notification for 
draft-ivov-mmusic-trickle-ice-sip-02.txt
Date: Tue, 17 Jun 2014 14:51:19 -0700

A new version of I-D, draft-ivov-mmusic-trickle-ice-sip-02.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Name:		draft-ivov-mmusic-trickle-ice-sip
Revision:	02
Title:		A Session Initiation Protocol (SIP) usage for Trickle ICE
Document date:	2014-06-17
Group:		Individual Submission
Pages:		21
URL: 
http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-sip-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice-sip/
Htmlized: 
http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-02
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-ivov-mmusic-trickle-ice-sip-02

Abstract:
    The Interactive Connectivity Establishment (ICE) protocol describes a
    Network Address Translator (NAT) traversal mechanism for UDP-based
    multimedia sessions established with the offer/answer model.  The ICE
    extension for Incremental Provisioning of Candidates (Trickle ICE)
    defines a mechanism that allows ICE agents to shorten session
    establishment delays by making the candidate gathering and
    connectivity checking phases of ICE non-blocking and by executing
    them in parallel.

    This document defines usage semantics for Trickle ICE with the
    Session Initiation Protocol (SIP).

 



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat