[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] Comments on draft-rosenberg-mmusic-ice-nonsip
On Sun, 9-Mar-08, at 09:26 , Jonathan Rosenberg wrote:
> I think the real meta-question on this draft, is whether:
>
> a. it is the same functionality as ICE, but not tied to SIP
> b. it is (a) plus a subsetting, removing features that we think
> only SIP needs
>
>
> The list of things in the (b) bucket that I removed were:
>
> 1. multiple streams
> 2. multiple components per stream
> 3. updating ICE parameters mid-negotiation
> 4. restarting ICE
> 5. role conflict detection
> 6. ICE mismatches
> 7. default candidates
> 8. ice-lite
> 9. forking support
> 10. frozen algorithm
> 11. remote candidates mechanism
>
>
> So first we need to decide path a or b, and then we can discuss
> which of the above get included or not.
Right now, I vote for (a) for the following reasons:
* I think we want to encourage just one "ICE" protocol, not an ICE
and a NICE protocol. This is because I think we will find things we
want to change/fix with ICE and having two protocols will make things
harder.
* I think that selecting the list in the (b) bucket will be hard, at
least until we get more experience.
>
> few more comments below:
>
> Philip Matthews wrote:
>> Below are some comments on this draft. I have grouped the comments
>> by subject matter.
>> Comments on the subset of ICE chosen:
>> * I think this draft should allow multiple streams between the two
>> clients. I feel this is useful in non-SIP contexts. For example,
>> my draft draft-matthews-p2psip-id-loc requires multiple streams
>> for non-SIP purposes. I suggest this draft simply point out the
>> simplifications that occur if there is only one stream.
>> Comments on the MIME object:
>> * I think this draft should not require the MIME object of section
>> 15, but simply present it as one possible encoding. The draft
>> should instead list the parameters that ICE needs as input, and
>> allow protocols to use other encodings instead. Protocols may also
>> derive some of these ICE-related parameters from other fields in
>> their protocol messages, rather than pass them explicitly.
>> For example, right now the HIP work is proposing to use an
>> encoding that is more consistent with HIP. HIP is a binary
>> protocol, so a text-based encoding seems a bit out-of-place.
>> Moreover, the HIP work is proposing to not generate an ICE-
>> specific username fragment and password, but use the Host Identity
>> Tag (HIT) as the username fragment, and the keying material
>> derived from the Diffie-Helmman exchange as the password. Thus
>> these fields of the MIME object are not needed for HIP.
>
> OK. I got a few folks that said they hated this MIME thing. THe
> intention was that it was optional - there if you want it. I think
> it would be a fine idea to have a section that also lists the
> params you'd need to include if you didn't use the MIME object.
Sounds like we agree.
>
>> Comments on Terminology:
>> * I dislike the term "session protocol". In SIP/SDP, it is the
>> direct connection which is the "session", not the signaling
>> protocol, so the "session protocol" should be the protocol that
>> runs over the direct connection. I suggest that you replace the
>> sentence "NICE works only with protocols that fit the pattern of a
>> session protocol" with "NICE only works with signaling protocols
>> that have a rendezvous mechanism".
>
> OK.
>
>> * In section 2, the document talks about establishing sessions
>> between "hosts". I think it should instead talk about sessions
>> between clients or protocol instances or similar.
>> * The document introduces the terms "Initiate Message/Accept
>> Message" and "Initiator/Responder" in place of ICE's "Offer/
>> Answer" and "Offerer/Answerer". Though the new terms might be
>> better than the existing terms, I think it will just be confusing
>> to have to different sets of terms for the same concept. Anyone
>> who implements NICE and any protocol designers who use NICE will
>> have to at least skim draft-ietf-mmusic-ice and become familiar
>> with the Offer/Answer terminology there, so I don't see the point
>> of introducing new terminology.
>
> Hmm, well I thought it was confusing to use the same terms when
> this is not based on O/A anymore.
Personally, I have not found it confusing. For the NAT traversal for
HIP work, I think in terms of an "ICE Offer" and an "ICE Answer" and
of two endpoints (the Offerer and Answerer) even though it has
nothing to do with SDP.
>
> -Jonathan R.
> --
> Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
> Cisco Fellow Edison, NJ 08837
> Cisco, Voice Technology Group
> jdrosen at cisco.com
> http://www.jdrosen.net PHONE: (408) 902-3084
> http://www.cisco.com
>
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic