Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

NEC NEAXIVS2000 - MCI - Call transfer

Hi there,

Recently upgraded to Unity 2.4.6.161 from a 2.3 version. Integration to with the PABX is working fine. A problem with the NEC IAC call console when diverting calls to voicemail. PABX sends two *'s ( ** ) then the mail box number and trailing ( ,, ) when sending a call to voicemail. It is sending these commands through DTMF and the voicemail is recieving these as invalid packets. Shown in integration monitor. The call is dropped when it reaches the voicemail system. Does Unity have an option to exclude any preceeding DTMF * tones?

1 REPLY
Cisco Employee

Re: NEC NEAXIVS2000 - MCI - Call transfer

Hmmm... if you were using an analog (inband dtmf) integration you could just create packet definitions for this scenario and all would be well but since you're using the MCI serial integration you can't mix and match (at least as far as I know... someone like Steve might have some sneaky way around this I don't know about).

It looks like what's happening is the special "*" hang up action when you're in the subscriber sign in conversation. If the first digit you enter from the subscriber sign in conversation is *, Unity hangs up. By default when the call is handled by the opening greeting and you hit the first * that goes to subscriber sign in (the call handler has * mapped to this action, as all handlers do by default). The 2nd star then causes the hangup.

If calls diverted in this way ended up coming from a specific number or dialing a specific number or the like such that a routing rule could end up dumping the call to an alternative opening greeting somehow or another you could remap the "*" key on that handler to simply go back to itself... this would effectively "eat" the two *s being sent and it would then act on the other digits accordingly.

Users hitting this handler couldn't sign in using the normal * action, of course... you'd want to make sure only calls diverted in this manor got handled this way. not sure if this is practical or not.

Of course getting the switch to send just about any other digits other than *s would make this a bit easier - I'm assuming that's not on the table.

106
Views
0
Helpful
1
Replies