<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>The issue of peer-to-peer multicast is more complex than one of simply topology of nodes. For various reasons, one really wants to be able to send different parts of the same stream via different paths in order to accomplish this (made even more complicated if you believe that FEC is appropriate for this... which I don't, but that's a different argument altogether). Then it is no longer as simple as wiring together RTP In to RTP Out. (And, as I mentioned in a previous email, there might be good reasons for not even allowing such a connection, to prevent silent relaying from using up bandwidth at unsuspecting browsers)<div><br></div><div>Matthew Kaufman<br><div><br><hr><b>From: </b>"Justin Uberti" <juberti@google.com><br><b><br></b><div class="gmail_quote"><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>I guess for multi-peer RTC a different approach on the network would be required or would it be a full mesh?<br></blockquote><div><br></div><div>Conferencing is a key use case, and I think this design can support either centralized or distributed conferencing models. The nodes will connect to one another using the same wire protocol, but the overall topology of the nodes will be up to the application.</div>
<div><br></div></div></div></div></div></body></html>