[VoiceOps] FCC issues Declaratory Ruling on Call Termination

[Frank Bulk]

I know the capacity issue has been mentioned as a "reason" that IXCs haven't
been "able" to terminate calls, but from my (limited) knowledge that has not
been the case in our state - it's always been traced back to LCR issues or
the carrier refusing to terminate an expensive call.

 

In regards to GV, I suspect that Google will make the same argument that
they are not a carrier but an application provider and aren't held to the
same standard
(http://www.marketingpilgrim.com/2009/10/fcc-eyes-google-voices-rural-call-b
locking.html).  

 

Regards,

 

Frank

 

From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org]
On Behalf Of Scott Berkman
Sent: Tuesday, February 07, 2012 7:20 PM
To: 'Carlos Alvarez'; VoiceOps at voiceops.org
Subject: Re: [VoiceOps] FCC issues Declaratory Ruling on Call Termination

 

+1 on Carlos' note about the free services that are the underlying cause for
this issue.  They put the services in these locations on purpose knowing
full well that the low costs they were paying for termination meant higher
costs on the other side.  As those services grew, there were obvious
consequences to the capacity the IXC's had into those areas.

 

As I was once told by someone at a major carrier that may or may not have
been mentioned by name in the OP, at some point when the call volumes to a
certain area are exponentially larger than what they should be based on the
actual population or even population growth expectations, it doesn't make
sense to build out the needed capacity to serve that growing volume of calls
if there are no paying end users to help cover the costs.

 

I find it "interesting" that not only did the FCC ignore the underlying
cause of these issues in the ruling, but it seems they have basically now
given the free conference and similar service providers the go ahead to keep
doing what they are doing without consequence, knowing the FCC has their
back.

 

As far as GV, they are not a "carrier" in the traditional sense because they
don't operate as a CLEC or IXC in any way that I have seen yet.  For
inbound, all their TNs (at least the ones I have checked) are ported to
either Level 3 or Bandwidth.com, which basically just makes them a big VoIP
customer of the big carriers.  Outbound is a little harder to trace, but in
all likelihood they mainly use the same carriers, perhaps some others as
well, so for their customers (or is it users for a free service?) to stop
having issues the IXC's they use will have to upgrade their trunking
capacities into the affected "rural" areas.

 

  -Scott

 

From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org]
On Behalf Of Carlos Alvarez
Sent: Tuesday, February 07, 2012 11:58 AM
To: VoiceOps at voiceops.org
Subject: Re: [VoiceOps] FCC issues Declaratory Ruling on Call Termination

 

I'm optimistic about this, though not knowledgeable enough to know the full
legal implications.  But it does seem like GV/L3/others will be forced to
change their ways.  Though maybe not GV, are they even considered a
"carrier?"

 

I wonder what will happen to those "free" fax and conference call providers
who caused the problem to start with?  Can the locals refuse service to
them?  Will the FCC look at their practices independently?

 

On Mon, Feb 6, 2012 at 9:13 PM, Frank Bulk <frnkblk at iname.com> wrote:

The FCC issued a Declaratory Ruling today in regards to call termination.
The ruling prevents originating carriers from passing the buck to LCR, puts
responsibility on them if they are aware of degraded service, and attaches
some stiff fines.

It would seem to me that this would prevent Google Voice and others, such as
Level3, from not terminating to certain (more expensive) NPA/NXXes.

Frank

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops





 

-- 

Carlos Alvarez

TelEvolve

602-889-3003

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120207/9a588cf6/attachment.html>