Subject: [MMUSIC] ICE and offer/answer terminology

From: Ari Keränen <[email-masked]>
Date: Wed, 5 Mar 2014 17:39:26 +0000

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?

Cheers,
Ari

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 6 Mar 2014 09:56:28 +0000

I think this is fine

Regards
Thomas

> 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?
> 
> 
> Cheers,
> Ari

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 06 Mar 2014 14:25:33 +0100

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

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
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
Surveillance is pervasive. Go Dark.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Mar 2014 13:47:42 +0000

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 <[email-masked]>wrote:

> happen in a particular sequence, I suggest that we call this "exchange of
> candidates", not "offer/answer".
>
> - 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
>
>
>
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> --

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 6 Mar 2014 14:02:10 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
On 03/05/2014 06:39 PM, Ari Keränen wrote:

Hi all,

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

- 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

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Emil Ivov <[email-masked]>
Date: Thu, 6 Mar 2014 19:15:32 +0000

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 <[email-masked]> 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 <[email-masked]> wrote:
>
>> 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".
>>
>> 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?
>>
>>

--
https://jitsi.org

---

From: Ari Keränen <[email-masked]>
Date: Thu, 6 Mar 2014 19:27:04 +0000

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

That would be great! Thanks.

>> There also needs to be the decision about who's the controlling endpoint by

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