Re: [MMUSIC] Trickle ICE

[Emil Ivov <[e-mail]>]

Hey Olle,

On 11.10.12, 22:00, Olle E. Johansson wrote:
> 
> 11 okt 2012 kl. 11:53 skrev 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.
> 
> I think that we should start that work in parallell. Doing trickle ICE with SIP O/A
> can be trick(l)y and the solution for that may affect the Trickly ICE core.

Agreed.

Emil

> I do think trickle ICE will help SIP quite a lot, especially in a b2bua situation.
> 
> /O
> 
>>>
>>>> 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
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[e-mail]                        PHONE: [phone]
https://jitsi.org                      FAX:   [phone]