Oubound transfer from Auto Attendant to answering service

[JimFed]

IP office latest build minus the new service pack that just came out this week. I have migrated old BCM to IP office and everything is working except today we found out if you choose 2 from the after hours greeting to be transferred to answering service and have your caller ID blocked the call is dropped.
It works fine if you don't have your caller ID blocked. Of course the one person at office that tested it has her caller ID blocked I tested multiple times and it works fine without caller id blocked

 

[budbyrd]

Would need much more information. Type of lines. VM Pro or essential.

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'

 

[sizbut]

As said, not really enough info. How is the caller ID being blocked? Did it ever work (BCM days) and is this the same line as used then? Does the line provider support witholding caller ID? (many don't).

Stuck in a never ending cycle of file copying.

 

[JimFed]

Sorry it is a PRI and VMPro. The users cell phone has the number blocked by the carrier. If I call from my cell and dial *67 then the number my cell number is blocked and the auto attendant drops the call as well
The user does not know if it worked on the BCM as she never tested it from her Cell with number blocked that she can recall. The carrier is Lumen and was TW telecom before the mergers. Not sure if they are blocking. I tried the PRI option of send original calling party for forwarded and twinning calls. That did not fix issue. I also tried Originator number for forwarded and twinning calls and put the main office number. That did not fix as well. I have unchecked the disallow outbound transfer as at first no calls would transfer out even unblocked numbers. I have also tried a virtual extension and set it to forward unconditionally but that does not work as when I put the extension number in the transfer option it goes to that extensions voice mail and does not forward out even though I have forward unconditionally checked and number of answering service in box. If caller ID is not blocked the virtual extension does forward out to the answering service but goes to voice mail if the number is blocked. Hope that is enough information

 

[IPGuru]

is this making an external transfer to a 3rd party answering service?
if so then it is the external service that is blocking the call (can you call then direct with withheld CLI?) & the old BCM was probably not forwarding on inbound CLI.

Options

1) reconfigure the outbound transfer to always present a fix CLI
2) use cli routing so that unknown/withheld callers progress through a different route & present a fixed CLI instead.
3) use a supervised transfer so that if the transfer fails it can be re-routed.

I would be inclined towards option 2 myself

Do things on the cheap & it will cost you dear

Avaya Remote Support Engineer (A.R.S.E)

 

[budbyrd]

I would use monitor and figure out where the call is failing. If you are expecting original CID to pass out a PRI that is a service you pay for to prevent CID spoofing. But I may be misunderstanding what you are doing.

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'

 

[JimFed]

Thanks for the suggestions.
I guess I don't know how to use cli routing so that unknown/withheld callers progress through a different route & present a fixed CLI instead.
Thanks for any help. I can call the answering service and with number blocked and it goes thru. I think it has to do with outbound transfer not working when caller id is blocked. It works fine if a caller chooses option and their number is not blocked.

 

[critchey]

Typically with PRI you would set the CLI manually in the 9N shortcode or the associated ARS table. Sometimes people don't specify CLI at all and the PRI just forces the main number... if that is the case this will not work. If you want to pass the originator CLI you typically have to use a Nss telephone number in your dial shortcode. So if you are manually setting the CLI, if the number you use to transfer offsite uses a shortcode specified CLI, you can simply use that shortcode to "force" the CLI you want. You would want to turn off the settings in the PRI to pass the originator CLI.

IE
9N
Dial
Nsi8005551212
50:Main

If you use 9+number to forward to answering service this should force the CLI to be 800-555-1212 based on the shortcode and not pass the originator CLI. In this case it would not matter if a caller has a withheld CLI or not.

I guess the big question is are you setting the CLI manually? If so is it in the shortcode or the ARS table? And are you using that same shortcode to forward offsite?

The truth is just an excuse for lack of imagination.

 

[JimFed]

I am using the default main ARS table. The short code 9N points to 50 main. I added your option to force the outbound caller id and the call still just gets dropped if inbound caller id is blocked. I have also created a Virtual extension and checked forward unconditionally to the answering service. That works for callers who caller id is not blocked but if caller id is blocked it now goes to voice mail. We recorded a message for now saying your call can not be forwarded to the answering service as your caller id is blocked. Send original caller id is not checked as well.

 

[critchey]

It sounds like you are not controlling the CLI at all the provider is. I would contact your provider and request that the PBX handle CLI. Also find out if the provider supports withheld numbers.

The truth is just an excuse for lack of imagination.

 

[TouchToneTommy]

Create a new ARS that sends your main number
Create a system Short Code like 8N / Dial / N / newARS
Create a VMPro module. Generic "free format" command STRING:$CP0=length$CLI)
Follow with Test Variable that validates $CP0 is 10
If True (Specific) transfer to 918005551212, if False (No Match) transfer to 818005551212
Route after hours calls to the voicemail module