sending directly to VM from a script (ICM or CRS), Unity uses CTI RP as DN

[mmcgille]

I am using CM 3.2.3, Unity 4.0 and ICM 5.0.

I have an ICM script that is suppsoed to take a call and dump it directly

into Unity voicemail (using the *XXXX voicemail profile)

The problem is, Unity sees the call as a forward from the originating cti

route point that fired the ICM script. Since I have no mailbox set up for

the cti route point, all calls are going to the opening greeting.

If I want all calls to go to a single VM box, I can set up a VM profile

and stick it on the cti route point - that works fine. But the tickler is that my ICM script is supposed to dynamically route to different voicemail boxes depending on what caller-entered digits there are.

So the question is - can I ever make the voicemail box disappear from the

cti route point so that Unity never tries to use that?

[oliviers]

If you can indentify what DNs are going into which skinny fields and what you don't want, I'd suggest pushing this post to perhaps one of the IP phone services forums. What you want to do is outside the scope of Unity.

Unity is going to use the same fields for called, and calling numbers regardless of how the call got to Unity.

[mmcgille]

So you are saying that no matter what, Unity will always look at the call as a forward from the original dialed number- no matter how it gets to Unity?

I don't think that is exactly true because if you call my phone from the outside, then I transfer you to *5555 - you will get put into 5555's mailbox - not mine.

I want to replicate that behavior - take a call from the outside, then be able to dump it into VM, but not the VM box of the orignal called number, just like in the scenario above.

[adignan]

Have you figured this one out yet?

[oliviers]

Unity will always look at the same fields in the skinny station call information message for gathering called and calling numbers.

In your transfer example, you've established a completely new call as you've initiated the transfer. For that call, guess what the original called party is? 5555.

If you were to forward your cell phone to 5555, the results could be different.

[mmcgille]

> you've established a completely new call as you've initiated the transfer

I agree... I just thought that transferring the call using the IVR step (or sending the call to a label using ICM) would also establish a completely new call. Is this not the case?

Thanks,

Matt

[hai.vo]

We ran into the same issue with a client of ours recently. To resolve this issue we had ICM populate a Peripheral Call Variable with the Unity VM # and then sent the call to the IPIVR to collect the ICM data and then execute an .aef script that redirects the call based on the call variable. That worked for us.

[mmcgille]

Cool... thanks for the reply. A few questions, though: was the Unity VM# the pilot number? And when you did the redirect step, did you redirect it just to the Unity pilot#... if so, how were you able to specify which mailbox to go to?

Thanks,

Matt

[hai.vo]

We did not direct it to the Unity pilot number. We just created a VM extension as a directory number as a CTI Route Point associated to no users within CallManager and listed that as a secondary extension associated with the Unity VM user. This let us send the call directly to the users voicemail box and avoid it ringing on the agent phone first.

[mmcgille]

Okay, thanks! I knew there had to be some way to trick it into working. Thanks for you help!

Matt

[sashworth]

How did you get the ICM script to forward the call to the Unity voice mailbox? I do have a mailbox created in Unity and a cti route point in CCM...I do not want to send the call back to the IVR.