Ted, >The overlay ends up being a path of last resort
Having the media go over 5-10 hops, some of which may pass via several continents due to the hashing in the DHT makes such real time media worthless due to the delay and cut-offs. Bruce: Can you comment on this? Reload-03 has no clear text on symmetric routing for media. This is an important topic (though not directly related, so I have changed the Subject name). All commercial products I know have some sort of two hop tunnel via a media server as the path of last resort or openVPN. Tunnels were however not presented in any I-Ds, since they violate the IT rules of using well known ports. I don't know why openVPN is not an IETF standard. http://en.wikipedia.org/wiki/OpenVPN Given the reticence of going public will stuff that IT organizations don't like, I cannot volunteer any products names, but I know several products using tunnels. Unless the IETF comes up with a better 100% sure way of NAT traversal, tunnels will continue to be used in NAT traversal products. A better solution would be HIP, but the nitty-gritty work and OS code for HIP NAT traversal has not yes been published AFAIK. If this is not accurate, HIP folks, please correct me. Thanks, Henry -----Original Message----- From: Ted Hardie [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 9:46 AM To: [EMAIL PROTECTED]; Henry Sinnreich Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP At 5:10 AM -0800 3/1/08, [EMAIL PROTECTED] wrote: > > > a. Churn can break the return path. For a example a 95% probability >> for success in the presence of churn over 10 hops each will result in a >> total probability of success of 099^10=0.59, that is 59%. The media path >> cannot work well if the two end points cannot see each other and there >> is no solution given here for the media path. Perhaps another media >> relay or using HIP? This is a missing item. In any case the media path >> MUST NOT follow the symmetric search path since the delay will be >> unacceptable over so many hops and unknown geographic locations that can >> be anywhere on the Internet. >> > >Most people believe that media should never be routed across the overlay >regardless of the routing mode. TURN is assumed for deployments where a >direct connection can't be established, like regular SIP. I find statements like "media should never be routed across the overlay" to be invitations to Murphy to muck things up. It's clear that the base case should be that media should be routed directly between nodes where possible. It's also clear that where a deployment provides adequate infrastructure (like TURN servers), using those is preferable to routing media over the overlay. But never? Sorry, I'm more pessimistic than that. The overlay ends up being a path of last resort, and I have a strong suspicion that paths of last resort always get used sometime. The protocol document should be clear that it is a last resort and why, but I believe we need to provide guidance on how to use an overlay as a media path. If we don't, it will get used in whatever way is easiest, with whatever consequences that entails. After some of the recent proposals, I can't even come up with a scenario I'm sure is parody. I thought about suggesting TCP over DATA URIs, but I'm pretty sure Jonathan has a draft on that in the works..... Ted _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
