North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Verizon PSTN continued

  • From: Alexander Harrowell
  • Date: Fri Nov 10 04:58:38 2006
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Xclc4TfJzW6SYCxoo+52ycG5SsfcrkqTCZqwfoOI9UrjxAk+czIQMgd8Wj7sJMcGlerOxuTEAsQolJq7/qA+XAu7F5DLTsJS8IAKAUDQdI0W0j1hlFAgm9AE5IlQJ4chEVVXzVyv4EAR5un8tqvjWqjvpdWNBjDeGXK3nSfx1zM=
"Centralised switching guarantees QOS!" Keep saying it and it might be true!

On 11/9/06, Sean Donelan <[email protected]> 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.