Re: [MMUSIC] ICE and offer/answer terminology

On 3/6/14 7:15 PM, Emil Ivov wrote:
> 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.

That would be great! Thanks.

> On Thu, Mar 6, 2014 at 2:02 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>> There also needs to be the decision about who's the controlling endpoint by
>> default.

Or can we let the ice-breaker just handle this in cases where there's 
ambiguity?

Also Harald's server-side storage scenario was interesting, but I guess 
the tie-breaker is sufficient also for that. I would still be inclined 
to call that "ICE offer" and "ICE answer" though.

Cheers,
Ari

>> On Mar 6, 2014, at 1:47 PM, Justin Uberti <juberti@google.com> 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 <harald@alvestrand.no>
>> 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
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>