Call forwarding to cellphones from DID #

[pabell]

We have a call center setup where afterhours and on weekends it calls (route to xxxx ..an x-ported extension
with cover remote to offsite ...it works fine with Land
lines but its BLOCKED when trying to use a cell numbers in the cover remote field ...has anyone seen something like this ????? I can actually see the Trunk go idle and receive
a carrier message saying to check the number
"list trace station" command shows it
(customer decided to change numbers to cellphones)

you can call the x-ported extension and with a cell number it goes through

you can call the VDN and with a cell number it goes through

yet if I call the DID number (same as VDN)the call will not forward if its a cell number IT WILL FORWARD TO ANY NUMBER BUT A CELLPHONE ...we just found out that we can not forward to a 800# when coming in on the PRI with
a DID call.....carrier says its not making them money
(actual words)so they don't allow it yet I can call an
800# from them ( I guess they see the Trunk To Trunk
function and BLOCK the call ...trunk does the same thing
original inbound trunk goes IDLE and tag message)
is it possible they see it as fraud / abuse
its not a FRL or restriction because I can use out of state
non cellphone numbers ... I can set my daytime dest in
regular Loop trunk group as 8540 (vdn) and am able to get cellphones

*has anyone come up against anything like this
it took the carrier weeks to admit the would not pass
a 800# call if it was forwarded ....trying to convince
the customer its NOT A SWITCH ISSUE again has been
rough they see it as we do not know what we are doing
but I tried to explain that we can not tell the differnce
between Cellphone or land line and its the carrier
stopping the forwarded calls to cellphones

 

[BuckWeet]

Not sure how they could be blocking it. Since its coming in on a PRI and being basically "called" by the PBX itself. The calls will always be nailed through the PBX. I've seen some wierd issues like what you're mention and the resolution was to change the numbering plan to "unknown" on the trunk group and it fixed it..


BuckWeet

 

[n00benduser]

Maybe a xmobile station will do the trick?

 

[avaya2004]

Try this...Record a blank announcement and play it before route to number step in your vector...I hope it should work..

Cheers

 

[2gordo]

It sounds like your ars table is blocking the call. With all the new prefixs for cell phones you might check the partitions and make sure the prefixs are listed. You can use "disp ars analysis partition 1 xxx" to check for your prefix.

 

[Toni269]

I had this same problem and it's because my codeset to send display was wrong. I had it set for 6 but my LD carrier needed it set to 0.

If you do a "change trunk-group x" 1/2 way down the page it the codeset to send display. (Check with your LD or Local carrier whichever it may be first)

 

[pabell]

It sounds like your ars table is blocking the call. With all the new prefixs for cell phones you might check the partitions and make sure the prefixs are listed. You can use "disp ars analysis partition 1 xxx" to check for your prefix.
------------------------------------------------------------
We can Dial(ext #) the number straight through without an issue

We can call the station thats cover path is usuing COV REMOTE

We can call the VDN without issue and it forwards

I can point the VDN as the incomng Dest for Copper trunk group 1 and it works

its just when it COMES IN AS A DID does it fail

not a COR issue I have checked trunks / stations

possible issue with carrier NOT WANTING SEND

we have put a TICKET w/Carrier

 

[manfmmd]

Have all of the sucessful calls been internal calls?

 

[phoneguy4u]

I had a similar problem where employees were call-forwarding their extension to a cell phone. It wouldn't work when the call came in over our AT&T MegaCom800 T1 and went back out over the same T1 to a LD cellphone. The problem, AT&T found out with a D channel monitor, was that the protocol was set wrong on the Definity, and they were getting two progress messages. By my changing the protocol to AT&T Custom (to match their 4E) it works!.

 

[pabell]

Phoneguy4u
I'll try that but we could not even send it off a another trunk group ( in this case comes in on AT@T Megacom
800 trunk group 2 as did and we send it back out on trunk group 1 through ars routing which is a copper pots trunk group loop-start ....thanks for all the replys