At 12:54 AM 2/11/2005, Marian Dumitru wrote:
I have to admit I'm not so much involved in the theoretical discussions. But from practical point of view, I see no difference on doing the NAT traversal on the main server or remotely (via SBC) - you still have to do some media relaying, so QoS and delay will be affected in the same way.
For a worldwide spread VoIP provider, having a centralized NAT traversal will not scale, risking a bandwidth exhaustion because of media relaying. We came up with a solution based on a distributed set of NAT traversal server, configuration which will eliminate bandwidth bottle-necks and the existence of the single point of failure. Even better, you will get a better QoS since the media doesn't have to cross half of globe just for the sake of NAT traversal.
That's very interesting. so how do you do things such as failover during existing call and how do you do guarantee that RTT is not unnecessarily long?
We can also see this approach in Skype design and this is one of the think that contributes to its success.
I think that's a different approach -- see http://arxiv.org/pdf/cs.NI/0412017 skype attempts not to distribute but to completely offload media processing away from service provider.
-jiri
ps -- for the rest of conversation, I suggest we give up on use of the term "SBC" which has no real technical meaning.