[LINK] Resilient Broadband Network needed for Australia

[Adrian Chadd]

On Thu, May 08, 2008, Kim Holburn wrote:

> >>Of course if the standard VOIP protocols like SIP and H323 had been
> >>written by someone with a clue about internet routing then VOIP would
> >>be up and running in a big way already.
> >
> >Citation, please?
> 
> I have no idea who created them.  I speak purely as someone who has  
> tried to route them.

Right.

> Why do they have source and destination IP addresses in the data?   
> Forcing a router doing what should be normal internet routing stuff  
> like NAT to root around in the data section of packets.  Also how hard  
> would have been to set up one UDP "stream" and put internal  
> application header data in the packets for the application to sort out.

NAT wasn't a big deal when H.323 and SIP were designed.

Seperation of payload and signaling is a big deal in the telco world, and
I bet H323/SIP tried to mirror that. It makes sense, if you live in a world
where everyone has a real IP address and you don't have devices in the path
which try to "track state". You have out of band signaling to determine
where the call needed to go; then the units would exchange media (voice,
video, whatever) directly without requiring the phone "switches" to care.

This hasn't worked out. Primarily, you need to bill for it somehow, and from
my basic exposure to such stuff, letting end-points talk directly to each
other makes billing minutes very difficult. So a lot of "VoIP interconnect"
that i've seen involves phone switches which act as media gateways so calls
can be accurately tracked; they're not just "routed"..

So its messy for telco, and its messy for end-point stuff (which is what
I think you were alluding to - NATs primarily being customer/business edges.)
Damn. :)

> To route this stuff properly requires a fairly sophisticated "tracker"  
> when it would have been simple to use the built-in capability of most  
> routers.

I think you're "crossing the streams" a little. The protocol design occured
far before the proliferation of stateful firewalls and NAT devices, back
when the notion of having a device on the internet meant it was assumed to
be secure. Why this isn't the case is left as an exercise to the reader.



Adrian