Re: [MMUSIC] Trickle ICE

[Christer Holmberg <[e-mail]>]

Hi,

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.

Sure, but that is not checking for trickle support before sending the trickle offer :)

Also, I guess I still haven't completely understood the backward compatibility issue, but I guess I need to do some more reading.

> 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.

I don't think we want to rely on empty INVITEs either, because there are a number of issues related to that.

>> 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.

Perhaps we shouldn't say anything about finding out in advance, then. At least not use SHOULD. 

We CAN describe what may happen if the remote peer does not support trickle ICE, but leave it to that.


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.

Thanx! :)


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?

Well, I guess any case where the remote peer knows it has a public IP address (it will most likely be an ICE lite entity).

> 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?

Well, the indication could mean please-try-whether-the-candidate-works-before-you-send-me-additional-ones :)

Regards,

Christer