Re: [MMUSIC] ICE offer/answer terminology

["Pal Martinsen (palmarti)" <[e-mail]>]

> On 12 Jun 2015, at 03:16, Ari Keränen <[e-mail]> wrote:
> 
> 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.
> 
ICE information exchange?

I still do like “candidate exchange” as it is pretty descriptive and cover almost everything you need to kickstart ICE.  

Ufrag and pwd is part of the candidate and affects how connectivity checks are conducted. The fact that SDP has a session level and media level set of attributes I find limiting. If I want to, I should be able to have different ufrag/pwd on each of my candidates. 

Both ICE-lite and the nomination method would not be covered by the candidate exchange wording. This should be fixable with words in the document?

Side comment regarding ICE-lite. Can this be deducted by never receiving STUN requests and only host addresses. Or can the Responses contain a ICE-lite flag to help the remote side? The importance here is that controlling side do not happen at the ICE-lite side. (ICE-lite to ICE-lite must then just rely on both offering host addresses?)

Agree with Ari, would be nice to know what others think.
This is word smithing, but somewhat important if ICE starts to get used outside the VoIP bubble. For example TAPS might need an ICE like mechanism to probe network paths.


>> 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)
> 
The problem occurs when you do not know who initiates the “session”. I think their might be many use cases out there where this is true.
Based on external events two agents want to communicate. They both have posted the candidates on a web page. Scenarios like that make the tiebreaker nice.

>> 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.
> 
I am leaning in the opposite direction.. Every candidate MUST have a ufrag and password associated with it. The ufrag and password can be shared across multiple candidates. This allows the SIP usage document to say that if it is a session level attribute all the candidates have this ufrag/pwd, if it is a media level attribute all candidates associated with this medialine share the same ufrag/pwd. 


.-.
Pål-Erik

> 
> Cheers,
> Ari