Re: [MMUSIC] ICE and offer/answer terminology

[Emil Ivov <[e-mail]>]

There's also need to negotiate support for options (such as trickle).

I think I like ICE Offer and ICE Answer because they are intuitive and
yet mark a difference with O/A.

We'd just need to come up with a little bit of text as to how their
semantics work and how they map to actual Offer/Answer.

I'd be happy to do that in the following days if that would help.

Emil

On Thu, Mar 6, 2014 at 2:02 PM, Jonathan Lennox <[e-mail]> wrote:
> There also needs to be the decision about who's the controlling endpoint by
> default.
>
> On Mar 6, 2014, at 1:47 PM, Justin Uberti <[e-mail]> wrote:
>
> The ICE ufrag/pwd and options do need to be exchanged somehow, but we could
> just call them the local and remote ICE configurations.
>
>
> On Thu, Mar 6, 2014 at 1:25 PM, Harald Alvestrand <[e-mail]>
> wrote:
>>
>> On 03/05/2014 06:39 PM, Ari Keränen wrote:
>>
>> Hi all,
>>
>> We didn't have time for this open issue on Monday meeting so we'll take it
>> here on the list.
>>
>> While ICE is no longer bound to SIP and SDP offer/answer, the document
>> uses terms "offer" and "answer" heavily, starting in the title ("ICE: A
>> Protocol for NAT Traversal for Offer/Answer Protocols") and abstract ("ICE
>> can be used by any protocol utilizing the offer/answer model [...]").
>>
>> I think we need to update the title and abstract so that it's more clear
>> that protocols that don't follow the o/a model are not excluded. Text
>> suggestions are welcome. Maybe in title we call this just "ICE: A Protocol
>> for NAT Traversal".
>>
>> Then, throughout the text we need to refer to the exchange of candidates
>> somehow. Originally this was referred to as the "SDP offer" and "SDP
>> answer". Currently we use "ICE offer" and "ICE answer". My suggestion would
>> be to keep the "(ICE) offer/answer" terminology here but clarify in the
>> beginning of the document that with the offer and answer we refer to the ICE
>> candidate exchange.
>>
>> Opinions?
>>
>>
>> Given that we do not have any requirement that exchange of candidates
>> happen in a particular sequence, I suggest that we call this "exchange of
>> candidates", not "offer/answer".
>>
>> Examples of models where offer/answer would be a misnomer:
>>
>> - All participants write their candidates into a common server-side store;
>> participants wishing to communicate fetch the candidate sets for the
>> entities they wish to communicate with, as long as the candidate set is
>> fresh enough.
>>
>> - Trickle ICE
>>
>> Cheers,
>> Ari

--
https://jitsi.org