11 Feb
2005
11 Feb
'05
2:21 a.m.
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.