[LINK] Resilient Broadband Network needed for Australia

[Richard Chirgwin]

Kim Holburn wrote:
> On 2008/May/08, at 12:54 PM, Adrian Chadd wrote:
>> 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"..
>
> Yeah, so it's the attempt to add billing that's killing VOIP. I 
> remember someone telling me that more than half the telephone 
> equipment and telco processes are just for billing. I always wondered 
> why a telco that was set up to use line rental instead of billing by 
> the second or byte wouldn't be a much simpler and leaner and more 
> economic operation. Of course you'd have to get the monopoly to 
> somehow release its strangle-hold on PSTN billing. Seems to be a 
> fingernail by fingernail operation.
Partly, Kim, because one telco billing on rental alone isn't enough. 
Telcos charge each other for minutes when passing calls. Even if "my 
telco" skipped per-call charging, if "your telco" doesn't, then I have 
to have a billing/settlement mechanism at interconnect.

I'd also guess that consumer expectation / inertia comes into play here. 
What if an incumbent said "you will all pay $50 per month but no call 
charges"? - there would be an outcry from consumer representatives 
saying "why should I cross-subsidise the calling habits of heavy users?"

Offering free on-network calls is trivial, and almost all telcos do so 
in one form or another (for example, free on-network mobile calls). 
Remember also that some of those overweight billing mechanisms are a 
response either to public pressure or to regulatory requirements (for 
eg, public demands for itemised bills, regulatory demands for call 
auditing, and so on).

"The attempt to add billing that's killing VoIP" is oversimplified: is 
there any good reason that a telco should accept a call from a VoIP 
provider and pass it on for nothing? Call billing is only an issue in 
VoIP for calling the PSTN.

The VoIP providers themselves are no model of co-operation. There's only 
a tiny handful that peer each others' services (I would guess fewer than 
twenty in Australia, out of a couple of hundred). They show very great 
reluctance to agree on QoS mechanisms that would allow consistent call 
behaviour across VoIP services. The idea of number portability is 
anathema to the VoIP provider - and so on.

>
> Seems to me the whole "VOIP is not capable of emergency calls" thing 
> is a beat up to try and claw back VOIP gains. Telcos could do VOIP 
> emergency calls if they really wanted to, or if they were forced by 
> legislation to. And they do often have to be forced, mobile number 
> portability being one example.
VoIP providers are divided: some offer 000 calls with the caveat that 
there's no reliable location data; others block 000 dialling. Some are 
completely silent on the issue.


>
>> 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.
>
>
> As I said: it'd be nice to see a voice video streaming protocol 
> created by someone with a clue about the modern internet. H323, SIP 
> and their family of protocols are so complex as to be difficult to 
> really upgrade. Not keeping application layer and transport layer 
> stuff separate makes a protocol that is very difficult to add to, let 
> alone use. Almost the opposite of the underlying philosophy of the 
> internet and internet protocol.
>
> Of course because of the vested interests it probably won't happen 
> until a proprietary protocol like skype that just gets through 
> firewalls like they weren't there takes over.
>
> Kim
> -- 
> Kim Holburn
> IT Network & Security Consultant
> Ph: +39 06 855 4294 M: +39 3494957443
> mailto:kim at holburn.net aim://kimholburn
> skype://kholburn - PGP Public Key on request
>
> Democracy imposed from without is the severest form of tyranny.
> -- Lloyd Biggle, Jr. Analog, Apr 1961
>
>
>
> _______________________________________________
> Link mailing list
> Link at mailman.anu.edu.au
> http://mailman.anu.edu.au/mailman/listinfo/link
>