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

["Stach, Thomas" <[e-mail]>]

Emil,

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


> -----Original Message-----
> From: mmusic [mailto:[e-mail]] 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,
> 
> 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.
[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.

> 
> 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).
[TS] So, the INFOs carry the complete information needed by the ICE agents.
> 
> 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).
> 
[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

> 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
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic