[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] Comments on draft-rosenberg-mmusic-ice-nonsip
Le Saturday 08 March 2008 00:05:10 ext Philip Matthews, vous avez écrit :
> 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. 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.
Every single intricacy from ICE could be made non-SIP specific... This is just
a matter of definition.
Multiple streams (and worse, multiple components, and worse multiple streams
AND multiple components) are the biggest implementation annoyance in ICE:
- First, it forces the implementor to run some "global" pacing algorithm for
the whole ICE session. Normally, multiple streams and multiple components are
isolated (e.g. separate RTP and RTCP flows sessions), that need not know
about each other. It also makes timer computation more complicated.
- Second, multiple components and multiple streams increase the amount of ICE
traffic and setup delay linearly.
- Third, they multiply the chance of traversal failure exponentially.
If you design a NEW protocol, you definitely want to avoid multiple streams
and/or multiple components. You can still have multiple flows between a pair
of nodes at a given time, e.g. a "DHT" flow, a phonecall signaling flow and a
media flow. *But* you should NOT negotiate them in the same ICE session -
they have independent time span anyway.
SIP needs multiple streams *because* it is Offer/Answer. If it weren't for
O/A, SIP could do ICE with only one stream per session and one component per
stream. It could simply serialize the ICE session setups. Unfortunately, O/A
is too rigid for this.
> For example, the ID-LOC application is not SIP-specific.
> If you read what NICE says about multiple streams, it just says "do
> ICE with just one component".
> 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.
I DO expect people to do both. Those who have SIP will want to use a common
ICE stack. Those who have something more NAT-friendly, will want to have
something MUCH simpler (e.g. an RTSP server on a public IP address).
--
Rémi Denis-Courmont
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic