Working with 2 other carriers on a similar issue, response I rec'd was
congestion due to automated political dialers. Not sure if I believe
that or not...
-Keith
you'd think they'd have systems monitoring that and trimming down the
'fat'? or can they do that? (legally I mean, sorta like QOS for the phone
network I suppose)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris L. Morrow wrote:
Working with 2 other carriers on a similar issue, response I rec'd was
congestion due to automated political dialers. Not sure if I believe
that or not...you'd think they'd have systems monitoring that and trimming down the
'fat'? or can they do that? (legally I mean, sorta like QOS for the phone
network I suppose)
- ------------------------
I guess it depends on the type of VoIP deployment.
http://www.softarmor.com/wgdb/docs/draft-camarillo-sipping-sbc-funcs-02.txt
regards,
/virendra
They can, and do. But SS7 interconnect battles between carriers are about as much fun as peering battles between ISPs, lots of finger pointing and blustering and more lawyers. If you lose SS7 links between carriers, and there is not enough SS7 capacity remaining, the SS7 systems start "flapping" (the SS7 folks probably use a different term, but it gives the IP folks some idea of what happens). It has happened a few times. I expect the SS7 vendors and protocol wizards are thinking up more clever ways to address it.
It has nothing (essentially) to do with the type of calls being made, although high call volumes always make any problem worse. Another time
it happened was just before Christmas a few years ago, during peak shopping time and the dialup credit card authorization numbers (and lots of other types of numbers) got jammed up during a SS7 incident as I found out doing my Christmas shopping that afternoon.
At around 1345 Central it was brought to my attention that we had lost
access to a number of websites out on the 'net... Two big-name examples
are Oracle, which has our development team screaming for my blood. The
other that's come to light as well is, of course, Yahoo... which means
the rest of the userbase hates me. Traceroutes like the two below for
Oracle generally die after one of Sprint's routers or its peer with
Level3. I've already opened a case with SprintLink's broadband group
and the tech I've spoken to said that there have been an influx of calls
about routing/website availability problems, but nothing had been
identified inside Sprint yet.
Just curious if anybody else is seeing this sort of action.
At around 1345 Central it was brought to my attention that we had lost
access to a number of websites out on the 'net... Two big-name examples
are Oracle, which has our development team screaming for my blood. The
other that's come to light as well is, of course, Yahoo... which means
the rest of the userbase hates me. Traceroutes like the two below for
Oracle generally die after one of Sprint's routers or its peer with
Level3. I've already opened a case with SprintLink's broadband group
and the tech I've spoken to said that there have been an influx of calls
about routing/website availability problems, but nothing had been
identified inside Sprint yet.Just curious if anybody else is seeing this sort of action.
Sprint has been made aware of the issue, as has Level3.
Matt
"Centralised switching guarantees QOS!" Keep saying it and it might be true!