Subject: [MMUSIC] multiple streams and NICE

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Mar 2008 09:33:21 -0400

I wanted to take one part of this and put it in a separate thread:

Magnus Westerlund wrote:

>>    o  ICE supports the notion of multiple streams and multiple
>>       components per stream.  This was done specifically to address the
>>       needs of multimedia.  NICE provides the ability to establish a
>>       single connection between a pair of hosts.  Consequently, that
>>       capability is not present in NICE.
> 
> This is needed in RTSP as we commonly have multiple media streams.

It is possible to do this with NICE - you'd just run N parallel NICE 
instances, one for each media stream. The principle drawback is that you 
don't apply the frozen algorithm, and so the checks take more time. You 
also lose the ability jointly pace the checks - it would be done 
independently for each stream.

The loss of the frozen algorithm is, IMHO, the primary drawback. It will 
result in even longer setup times. For SIP, where call setup delays are 
a big deal, we took the extra complexity to reduce the setup delays. The 
question for RTSP and other protocols is whether the speed of setup is 
that important. Is an increase in setup (or an increase in stun 
bandwidth to compenate) worth the protocol complexity?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 09 Mar 2008 10:08:04 -0400

> independently for each stream.

Well, that is bad from a transport perspective as the pacing will 
overlap. I think the reasonable solution is to use the same pacer for 
all NICE transactions from the same same application. I don't see how 
this makes things particular more complex.

> bandwidth to compenate) worth the protocol complexity?

Yes, from a transport perspective this is a negative thing. I actually 
are for keeping the frozen algorithm.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------