Thanks for the excellent answers. Couple of comments inline with some snips:
> 2) TCP isn't supported, because it doesn't make any sense to run RTMFP > over TCP. RTMP exists and works over TCP, but only for the client-server > cases. So presumably the DHT put/get operations are less than a MTU so fragmentation and corresponding reliability issues don't kick in? Media over TCP is necessary for traversing UDP blocking firewalls. If the goal is to reduce load on the publisher by doing p2p, then ideally, peers need to have all types of NAT/firewall traversal mechanisms in their toolbox. However, as you pointed, there maybe business reasons for not doing so -: One may also argue based on the available data that there are too few UDP blocking firewalls, or too few clients behind such firewalls so it does not really matter... > 3) Flash Player 10.0 and later can play Nelly-Moser, Speex, MP3, and AAC > and can encode Nelly-Moser and Speex. Transcoding to/from Speex isn't > difficult. > > 4) No official comment. I follow the P2PSIP work, and I used to comment > more back when I had time to actually be on the list, so you can read > some of those older comments for my views. Generally I personally > believe that (while it does have the drawback of being proprietary at > this time) RTMFP is a superior transport to trying to do signalling over > SIP+SDP and media over RTP, and I believe reuse of the cost of session > setup is better than the flexibility one might have by completely > separating signaling from media. A quick demo of a maximum rate file > transfer between a pair of peers along with higher-priority voice > traffic helps explain why I think that RTMFP is a better media transport > protocol, especially since you also get encryption and IP address > mobility with no added complexity. Are you saying that RTMFP has a mechanism of prioritizing audio/video over file transfer? > 6) Most of what Skype does can be implemented using the pre-Groups > RTMFP. The peer-to-peer directory service could be re-implemented using > RTMFP Groups. Some of what Skype does, Flash Player won't do mostly for > business/security reasons... while Skype was able to have a EULA that > lets your computer open up TCP server ports and relay media, you'd never > let Flash Player generally have that capability, so Flash Player is > definitely more limited in how aggressively it can try to make > peer-to-peer work... though client-server fallback is at least as good > if not better in Flash Player. Ok, so the question really is can RTMP/RTMFP(pre/post groups) be run together in a way that allows peer-to-peer media sessions where possible but falls back to client server? Do you think the solution will be seamless for RTM* protocol series? If I was building a Skype-like system, I will need to ensure that session establishment does not fail due to protocol or architecture artifacts. Thanks Salman _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
