Calls not transffering out of VM

[bluewhite4]

I think that Mattymayn is on to something.

I think that when the voicemail tries to transfer the call to the 800 number its trying to also pass the caller id of the inbound call, back out, to the 800 number. The PRI that 800 calls are routed out, is rejecting the use of a non-native CLID, and then because the transfer was cancelled, the voicemail drops the call back at the top most level.

Try this. From your cell phone, call your desk phone. Answer on your deskphone, and then transfer the call to the speed dial. Does the transfer complete?

[pakman]

Thanks for the reply bluewhite4

when I go into " Trunks->Digital->ISDN->ISDN Protocol and changing "Replace External CLID" to true" there are two modules protocol NI2 and DMS 250 not sure which one I should change this on both perhaps?   Also, for your suggestion maybe I am missing something but If I take my cell and call my desk the only way I know how to transfer folks is to hit the Trans/conf key the "arrorw|3 heads" then dial the number. I can complete the call and hang up my deskphone and have it carry over to me cell. Not sure if there's another way to transfer calls?

[bluewhite4]

The two modules you're seeing are two different trunks. You'd have to get into ARS, and trace back which trunk group, and therefore which circuit, your outbound 800 call is being routed out of. That would tell you which one to enable the "Replace External CLID" on.

You've got the right process, but rather than supervise the transfer I'd like you press the conf/transfer key, dial the #5600, and immediately hang-up your desk phones handset.

[pakman]

Ok, when I call my desk and hit the transfer key and dial #5601 and hang up immediately it just hangs up on the transfer and my cell and desk are still connected. But If I try that same test with an internal ext. it does the same thing. Don't I have to wait for the other person or line to pickup before I can press the trans key then hang up? If not something must not be setup correct. Also, I do know which trunk the 800 numbers are going out but in the ISDN Protocol form there's no way I can tell how to identify which one PRI uses which Protocol. I will just change one then both and see what happens.

[pakman]

Thought I would update this. I called our telco vendor last week before I started all of this and they said no issues on their end. After, exhausting what I felt was all options I called telco back spoke to another tech. Wouldn't you know it they've had DTMF issues now for awhile.......I created my work around and hopefully they will resolve this soon on their end. They went from switched to dedicated in terms of how they handle 800 number calls which started all of this mess.

[LoopyLou]

Is this a cluster or a stand-alone system? In other words are the voicemail ports on the same controller as the PRI's that the call comes in on and the call to the 1-800 will  go out on?

If you have an incoming PRI call that the voicemail then will transfer to an external number does the COS of the PRI's have the options for forwarding external and public to public enabled?

[pakman]

Yes, this is a cluser and all our voicemail is embedded on the same controller as the PRI. Now when a customer calls the 800 number it first comes in on one PRI it gets sent over the WAN to the other PBX that has the voicemail and the other PRI that they system transfers customers out to those 800 numbers that are giving us a problem. I looked in the COS for that PRI trunk and yes public to public is enabled and forward external. Not sure if you had a chance to read the my last post but the issue is on the Vendors side.

Thanks though.

[ralph]

Don't forget to check the COS of the IP trunks.

Have you played with the ISDN protocol yet?
I'm thinking you may have to adjust the "Replace External CLID" to be "true".

It may also be possible to route the calls to a system speed dial where the actual number looks like this: <network element>91-xxx-xxx-xxxx.
The network element would be the system where the originating PRI exist.

Ralph