Inbound toll free on circuit A will not complete call if routed back out circuit A

[AvayaGuy72]

Hi I have CM6.3 and several different long distance carriers for voice circuits. Most of our inbound toll free traffic routes to vectors that provide options to enter. Some of those options will route the caller back out of our switch to either a long distance, local or toll free number. We recently added a couple new circuits from AT&T called AVPN or IP Flex. The come in as SIP and are stepped down to PRI in a router before they terminate to DS1 boards in our G650s. Local, long distance and toll free calls are able to be received as inbound and we are able to make those types of calls outbound. What doesn't work on them is when an inbound toll free number comes in on that circuit, the caller selects an option that routes them out to a local, long distance or toll free number back over that same circuit. The call either disconnects or is routed to the AT&T announcement, "Your call cannot be completed as dialed..".

I submitted a ticket to our Avaya vendor and the engineer said they see this sometimes and is because the call is tagged as an inbound call and when transferred back out doesn't lose that inbound tag and the carrier isn't allowing the call. They also said the carriers have a way to accept that call or strip the inbound tag and to call them. I submitted a ticket to AT&T and they said the problem isn't on their end.

My temporary fix is routing all those specific numbers in the ars analysis table over local CBC PRIs or a different carriers long distance PRIs.

Does anyone know if there is something in the CM I can change to allow these calls to route back over the same circuit or if this is an AT&T problem they can fix?

Thanks

 

[montyzummer]

So im guessing that this is something to do with the way the outbound leg of the call is presented to AT&T , im not familiar with the US way of ARS specifics , but i will bet it is the call type presentation.

Can you run a list trace on the specific TAC ring in and post the results to see how CM presents the call back to network , as that will give a really good indication of what is going on , there are lots of techs who are US based who may know the issue , but if you can also give us a screen shot of "list ars ana" and specify the trunks in question along with the list trace , thats a real good starting point , also post your public numbering table.

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[joe2938]

Typical answer from AT&T, they always claim it's never their issue when it is, escalate it back to them!

 

[kyle555]

Eesh. Depends!

What magic is happening in that "SIP to PRI step down box"?
How does AT&T want to validate you, and what do they use for CLID?

I've seen SIP services use a field called P-Asserted Identity for both CLID and authentication - if that field isn't a number subscribed to your trunking service, it's rejected.
I've seen other services use FROM for CLID and let you use something like a billing number on P-Asserted Identity and you can pass out your originating caller's #.

So, if I get what you're saying, calls in to toll frees on your SIP trunk can't be routed out the same SIP trunk.
Calls to other DIDs on that trunk can be routed out to local/LD/TF.
You can even reproduce that be routing out a call to a terminating number but failing the same flow when calling the toll free.

It'd really be up to whoever manages the SIP/PRI translation layer - whether that's a AT&T box or something you guys provided to figure out what's getting rejected and what AT&T says they allow and really allow to pass through their network.