|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Fri, 10 Nov 2006 09:55:44 +0000 From: "Alexander Harrowell" <a.harrowell@gmail.com> To: "Sean Donelan" <sean@donelan.com> Cc: nanog@merit.edu In-Reply-To: <Pine.GSO.4.64.0611091439310.11805@clifden.donelan.com> Errors-To: owner-nanog@merit.edu "Centralised switching guarantees QOS!" Keep saying it and it might be true! On 11/9/06, Sean Donelan <sean@donelan.com> wrote: > > On Tue, 7 Nov 2006, 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) > > 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. > >
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |