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

From: Emil Ivov <[email-masked]>
Date: Wed, 18 Jun 2014 00:57:31 +0300

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

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 27 Jun 2014 13:25:23 +0000

Emil,

this version improved quite a bit from the last one.
Some comments/questions inline.

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Emil Ivov
> Sent: Dienstag, 17. Juni 2014 23:58
> To: MMUSIC
> Subject: [MMUSIC] Fwd: New Version Notification for draft-ivov-mmusic-trickle-
> ice-sip-02.txt
> 
> Hey all,
> 
[TS] You should update the reference from RFC3388 to RFC5588.
The text doesn't mention the a=group attribute. 
I think it is OK to omit it, but some explicit text might be worthwhile.
E.g. some like: This specification reuses the a=mid: attribute from RFC5588, 
but does not define any grouping semantics. 
Consequently, using the a=group: attribute as specified in RFC5588 is not needed for Trickle-ICE.

> offer/answer negotiation).
[TS] So, the INFOs carry the complete information needed by the ICE agents.
> required for such cases).
[TS] In Fig 2 you show the ICE agents as being separated from the Offer/Answer Module. 
I think this makes sense, since ICE's purpose of establishing connectivity is independent from the other tasks of the Offer/Answer module. 
Section 4.1 states the following two conditions needed to be fulfilled to start trickling
   o  ICE support in the peer agent MUST be confirmed. --> BTW: Shouldn't that read Trickle-ICE?
   o  The SIP dialog at both sides MUST be at least in the early state.

The rest of section 4.1 additionally assumes that the answer is needed as well.
I think that you could start trickling even if the 183 did not contain an answer, provided that the 183 indicated support for Trickle-ICE on SIP level via Supported:trickle-ice  and Recv-Info:trickle-ice.  
The answer would just include a third indicator a=ice-options:trickle on SDP-level.
The INFOs would include all necessary information to start ICE and could also carry a=ice-options:trickle to verify trickle-ICE support also on SDP-level.
There might be some benefits for existing implementations if they could start trickling before they have sent an answer.

Regards
Thomas

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic