Re: [MMUSIC] Trickle ICE

Hey Christer,

Thanks for your comments!

Replies inline.

On 10.10.12, 20:18, Christer Holmberg wrote:
> Hi,
> 
> Thanks for submitting the document!
> 
> A couple of initial comments.
> 
> Q1: Remote endpoint support (SIP): 
> --------------------------------------------
> 
> You say that, before the first offer is sent, one SHOULD determine
> whether the remote endpoint supports trickle ICE.
> 
> For SIP, you give RFC 3840 as an example. I am not sure how that will
> work. Yes, you can use 3840 to request that the offer is sent to an
> entity which supports trickle ICE (for that, btw, you will also need
> to define an option tag, or something similar),

Right, but we were hoping this would happen in a separate spec that
details use of trickle ICE with SIP.

> but you cannot use it
> to determine whether the remote endpoint supports trickle ICE. In
> addition, you typically use 3840 at the same time when you send the
> initial offer.
> 
> Of course, you could use SIP OPTIONS.

Yes, that was the idea. The way 3840 describes it in Section 8.

> But, there are a number of issues related to that, 
> and I don't think we want to define a
> mechanism which relies on the usage of OPTIONS.
> 
> And, if we simply say that it's "outside the scope of the document",

I was just about to say that ;).

But, seriously, determining and negotiating caps happens very
differently in different signalling protocols, so it doesn't seem
reasonable to try and find answers for all of them in the generic
trickle ICE spec.

XMPP for example, has this part covered pretty well. If we determine
that 3840 does not provide a way of doing the same then we can find
another way for SIP.

Eric had this idea, where a trickle ICE agent would simply fire a first
offer that only other trickle ICE agents would accept and that any other
SIP endpoint would answer with an error. This would be enough of a check
and if it fails the caller can fall back to vanilla ICE.

Another option would be for trickle ICE agents to send empty INVITEs
that somehow indicate they will be trickling but contain no actual
offer. The offer that the remote side then adds in an OK response (or a
provisional one) would clearly indicate whether they support vanilla,
trickle, or no ICE at all, so the trickle agent would be able to answer
accordingly with the ACK.

> we could do the same for BUNDLE, and we wouldn't have issues with
> re-using the same ports in multiple m- lines etc :)

Well, we are not saying that they should not be addressed at all, or
even now. Just that maybe they shouldn't be addressed by this specific
document.

> Q2: Offer/Answer Alignment: ------------------------------------
> 
> I assume the offers and answer are sent according to the rules in RFC
> 3264.
> 
> If so, when you talk about offers and/or answers "being sent at any
> point", I think it needs to be clear that it's within the rules of
> 3264.

Good point! I think the text is indeed a bit unclear in that regard and
we might be making some non-stated assumptions about the relation
between 3264 Offer/Answer, the actual call answering, and the
connectivity checks phase. We'll fix this.
> 
> 
> Q3: Enough is enough: ----------------------------
> 
> I think it could be useful for the answerer to tell the offerer that
> it doesn't want/need any more candidates.

Yes, sounds useful. Do you have any specific use cases in mind?

I am also wondering what would happen if the answerer says "enough" too
early in the process and causes negotiation to fail. Is there a reason
why an agent would be willing to risk that? Or are we going to say that
it would only do that after finding at least one valid pair for every
component?

Cheers,
Emil

> Thanks!
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> ________________________________________ From:
> mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Emil
> Ivov [emcho@jitsi.org] Sent: Wednesday, October 10, 2012 5:29 PM To:
> MMUSIC IETF WG Subject: [MMUSIC] Trickle ICE
> 
> Hey all,
> 
> Eric, Justin and I have just submitted a first version of the 
> specification of a mechanism for incremental provisioning of ICE 
> candidates, also known as "Trickle ICE".
> 
> The spec is in an early state and will undoubtedly see a lot of
> changes as implementations progress. It does however describe the
> main idea so comments and questions are most welcome!
> 
> Cheers, Emil
> 
> 
> -------- Original Message -------- Subject: New Version Notification
> for draft-rescorla-mmusic-ice-trickle-00.txt Date: Wed, 10 Oct 2012
> 07:16:00 -0700 From: internet-drafts@ietf.org To: emcho@jitsi.org CC:
> justin@uberti.name, ekr@rtfm.com
> 
> 
> A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt has
> been successfully submitted by Emil Ivov and posted to the IETF
> repository.
> 
> Filename:        draft-rescorla-mmusic-ice-trickle Revision:
> 00 Title:           Trickle ICE: Incremental Provisioning of
> Candidates for the Interactive Connectivity Establishment (ICE)
> Protocol Creation date:   2012-10-10 WG ID:           Individual
> Submission Number of pages: 14 URL: 
> http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.txt
>
> 
Status:
> http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle 
> Htmlized: 
> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00
> 
> 
> Abstract: This document describes an extension to the Interactive
> Connectivity Establishment (ICE) protocol that allows ICE agents to
> send and receive candidates incrementally rather than exchanging
> complete lists.  With such incremental provisioning, ICE agents can
> begin connectivity checks while they are still gathering candidates
> and considerably shorten the time necessary for ICE processing to 
> complete.
> 
> The above mechanism is also referred to as "trickle ICE".
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> _______________________________________________ mmusic mailing list 
> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31