Symposium ROUTE command problem 1

[tonyrico]

Option 61C, 3.0, Call Pilot 2.02, Symposium 5.0

We did not experience this problem until our systems were without power a few times during Hurricane Katrina.

This is what we are having difficulty with.

Normal: A call is transferred from a Call Pilot menu to a CDN. Symposium script has the call, and does everything as programmed. In each script we determine what is sufficient time for a caller to wait in queue and when that time is reached we use a ROUTE command to send the call to a phoneset that is independent and external to Symposium's control.
Problem: if the phone is not answered the call goes to that phones voice mail, but if the phone is busy the system for some reason looks for the CDNs voice mail, which doesn't exist and bombs.
Temporary Workaround. We added the CDN for each script as an additional DN in those external mailboxes. It now works on busy but it also restricts the capability of Symposium Scripting. The result is that now if you had three "IF" statements that Routed to three different DNs, on busy conditions they can only go to one mailboox of the three and that is whichever one you add the CDN to as an additional DN.

I've heard there were patches that took care of this in the past. Any Ideas?

thanks

 

[charliesp]

Sounds like a patch has changed on your system. When we upgraded to Succession 3 the system started "forgetting" the original Symposium CDN. If yours has started "remembering" you need a patch removed. Not sure which one, but your maintainer should know.

 

[sandyml]

With those power failures, your patches may have been deactivated. Like charliesp suggested, contact your vendor to have them reactivate those patches.

 

[tonyrico]

I did open a ticket with the vendor and it was their tech support that suggested I add the CDNs to the mailboxes. I will call them back and ask that they contact Nortel for the specific patch.

If Anyone has any specific patch information, please pass it on.

Thanks for the replies

 

[yyrkroon]

make sure mplr19885 is in-service on the pbx, or have it installed.

19885 is a merge of a couple of patch...the one that address this particular problem is 18136