Re: [MMUSIC] ICE offer/answer terminology

[Ari Keränen <[e-mail]>]

On 11/06/15 01:07, Pal Martinsen (palmarti) wrote:
>
>> On 10 Jun 2015, at 20:36, Ari Keränen <[e-mail]> wrote:
>>
>> Thank you for the review Pål-Erik!
>>
>> I will have a closer look at the detailed comments a bit later, but first let's discuss the main issue, offer/answer terminology (and hence the new subject for the thread).
>>
>> I agree that the offer/answer as ICE terminology is not optimal since it implies to many that this would be RFC3264 o/a. However, we have not yet been able to come up with a better term.
>>
>> This was also discussed at the IETF #90 MMUSIC meeting:
>> http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.1yc63e74pbhi
>>
>> (See “Offer/Answer Terminology (slide 10)")
>>
> Ahhh. That was a good summary. I think I remember now.. Sorry for not checking previous discussions, but I wanted do have a “clean” read thought the document.
>
>> The consensus was roughly that we *do* have offer and answer kind of messages when doing ICE, calling that ICE offer/answer is a bit confusing, but we'll go with that unless a better alternative emerges.
>>
>> What would you suggest as new terms that we could use here that would fulfill the requirements?
>>
>
> Candidate exchange?
>
> We need to have wording in there that explains there are a some more information that just the pure candidates that needs to be exchanged.

IIRC, "candidate exchange" was one proposal that was rejected exactly 
due to the fact that there is quite a bit more information than just the 
candidates that is exchanged. "ICE exchange" perhaps could be used, but 
still it would be good to be able to refer to the -- for the lack of 
better word -- offer and answer parts of the exchange.

That's why I like "ICE offer"; it implies that there is undefined amount 
of "ICE information" offered to the other endpoint which can then 
decide, based on the offer, how/if to proceed.

However, would be great to hear more opinions on this.

> Regarding controlling/controlled we can eiter let the tie breaker fix that. Or have some wording if you are first to send the candidates you are controlling and so on.

While the tie-breaker is a SIP specific feature, one argument for 
keeping the tie breaker in the generic ICE was to have easier proxy'ing 
to other ICE (SIP) domains that require this kind of check.
See: 
https://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01#section-5.2.3
(rest of the draft is pretty good read too)

> We should consider having the ufrag and password tied closer to the candidate. We might have missed some information when removing the medialine and session level descriptions of that.

Good point. However, I'm thinking that this would probably be the role 
of the usage documents to define; whether they allow multiple 
ufrag/passwords and how to handle that in the signaling.


Cheers,
Ari