[VoiceOps] Bizarre toll-free routing issue

PE peeip989 at gmail.com
Mon Aug 27 15:51:34 EDT 2012

Interesting. Never saw that one before. But I have seen situations where
the far end's voicemail/IVR/conference bridge has misbehaved similarly when
the call has been deflected. That is, when we send a Diversion header. Any
such commonality here?

Your last

On Mon, Aug 27, 2012 at 2:42 PM, Jay Hennigan <jay at west.net> wrote:

> This is driving us nuts.  We use Inetwork/Bandwidth/Dash to terminate
> SIP calls to toll-free numbers.
> About one out of every 50 calls results in something I have never seen
> before.  The caller hears an IVR of a company other than the one dialed.
>  After a few seconds, it skips to a different, totally unrelated IVR,
> then another, and so on.  It seems to be related to load, occurs more
> often during peak calling hours, rarely if ever off-hours.  We have
> never gotten connected to a live operator, only IVRs.  The jump to a
> different IVR occurs after the initial greeting if we don't enter any DTMF.
> The numbers we've had problems with are:
> 866-841-0143 - AAA
> 888-792-4900 - Franchise Tax Board (CA)
> 800-627-8797 - Anthem Blue Cross
> 877-776-2436 - Drive Insurance
> I'm told that AAA and Franchise Tax Board terminate on AT&T and Anthem
> and Drive terminate on Verizon.
> Getting Inetwork to fix it results in, "An intermediate carrier that
> shall not be named" (Voldemort?) says that another downstream carrier
> says that the customer has equipment problems.
> Examples:
> Call to 8668410143 supposed to answer "Triple A" went to Pacific Western
> Sales, jumps to ATT, then Child Support Division of the Office of
> Attorney General, then Free 411 then Comcast over the 1 minute 51 second
> duration of the  call.
> 8006278797 duration 1:40, was supposed to be Anthem but answered with
> Wells Fargo, then skipped to Employment Development Department then
> Classic Vacations.
> 8006278797 duration 2:28, was supposed to be Anthem but answered with
> Wells Fargo, then skipped to Citicard then S.M.U.D.
> This is tough to troubleshoot.  It takes multiple calls to replicate as
> the vast majority go through without issue.  Most of our customers just
> assume that they mis-dialed and try again.  Where we become painfully
> aware of it is when a customer has one of these numbers on speed-dial
> and it becomes obvious that it isn't a mis-dial.
> Has anyone else on the list run across this?  Other than "Don't use
> Inetwork", any ideas on getting it fixed?  My fear is that it may not be
> Inetwork but something beyond them, perhaps the companies involved
> outsource their call centers to a common hosted service that is having
> issues.
> _______________________________________________
> 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/20120827/14dffc31/attachment.html>

More information about the VoiceOps mailing list