Re: [MMUSIC] Comments on draft-rosenberg-mmusic-ice-nonsip

[Philip Matthews <philip_matthews at magma.ca>]

On Sun, 9-Mar-08, at 09:19 , Jonathan Rosenberg wrote:

> inline:
>
> Philip Matthews wrote:
>> On Fri, 7-Mar-08, at 07:36 , Rémi Denis-Courmont wrote:
>>> Le Friday 07 March 2008 14:04:45 ext Philip Matthews, vous avez  
>>> écrit :
>>>> 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.
>>>
>>> IMHO, if you need multiple streams, you better use plain ICE. If  
>>> NICE gets
>>> support for multiple streams and/or components, it will become so  
>>> much like
>>> ICE, that I don't think there will be significant added value... ?
>>>
>>> On the other hand, multiple streams multiply the chance of  
>>> traversal failures
>>> and the setup latency. I would especially expect that an overlay  
>>> network
>>> would mux/tunnel over a single network flow between any couple of  
>>> peers.
>> In my view, what the NICE document does is separate out the SIP- 
>> specific parts of ICE from the rest of ICE, something that we  
>> should have done from the start.
>
> We DID do that from the start. Early versions of ICE were defined  
> as a meta-protocol. But it was so hard to understand we punted it.

My apologies. I do remember that. And I remember finding the MIME  
schema totally incomprehensible...


>
>
>> All the other stuff that Jonathan mentions in the NICE document is  
>> SIP-specific, but I don't see multiple streams as being SIP- 
>> specific. For example, the ID-LOC application is not SIP-specific.
>
> I'll respond to this directly from your first note..
>
>> If you read what NICE says about multiple streams, it just says  
>> "do ICE with just one component".
>
> Right.
>
>> One other thing. I don't actually expect people to do NICE  
>> implementations that are distinct from ICE implementations. All  
>> the document really does is give people guidance on how to use ICE  
>> for non-SIP applications.
>
> Correct. NICE is not meant for SIP, its meant for non-SIP. And  
> thats a worry - if we end up making NICE simpler and then people  
> use it with SIP instead of ICE, that would be bad. Though I believe  
> it would interop.

Personally, I think we want just one set of implementations that can  
be used with both SIP and other protocols. I think that SIP will be  
the application that will drive the initial ICE deployment and help  
find all the bugs. The other protocols can then ride SIP's coat-tails  
and use well-tested ICE implementations.

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