[VoiceOps] Terminating 800 traffic with Caller ID of an 800 #

[Scott Berkman]

So is there anything other than industry best practice on this?

 

Something official maybe from a LEC or IXC at least, FCC or NANPA would be
even better.  I've had this argument with customers again and again, and I
can tell them what may happen, but I've never had any document from someone
they'd believe to back it up.

 

 

From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org]
On Behalf Of Mark Holloway
Sent: Wednesday, February 15, 2012 11:55 PM
To: Darren Schreiber
Cc: VoiceOps at voiceops.org
Subject: Re: [VoiceOps] Terminating 800 traffic with Caller ID of an 800 #

 

Some providers require a charge number to be present. They won't route the
call if only the 800# exists. 

 

On Feb 15, 2012, at 4:29 PM, Darren Schreiber wrote:





Hi folks,

                We have a customer who is insisting on setting their
outbound Caller ID to an 800 #. They are complaining that they can't call
other 800 #s. Our testing reveals that many carriers are refusing to route
the call when the Caller ID is set as an 800 #.

 

                In addition, if we try setting the ANI as one number via the
From: header and then add a remote party ID header as Caller ID, it seems
that most carriers use the From: and deliver that as the Caller ID to the
alternate/receiving 800 #.

 

                Any thoughts on this? I am aware that it's up to the
receiving 800 # to decide what NPAs to allow through and that what they're
proposing complicates billing, so I suspect I just need to tell the client
to deal, but they are insisting that this used to work on their PRI. My
theory is that it did not work on their PRI but nobody ever noticed before.

 

- Darren

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120216/19378aee/attachment.html>