upgraded Cisco ICM to V5 / VRU /G3R

[lisalisa173]

Hello,
Need a little help on a tricky problem..
Our company upgraded Cisco ICM to V5 in late Oct. Since that time Cisco has changed the MAPD requirements and are only supporting MAPD 3.0 and up.
We are have a MAPD 2.1 which at the time of installs 2 months ago seemed fine.

We have call traffic is pointed to this GeoTel ICM and into the PBX GR3 V10 the calls hit a Vector go the VRU but data is getting lost and some calls are bouncing to the agents on the floor. This only happens after 10 minutes of a heavy call load.

Anyone has experience with a similar problem? Any ideas on how to fix it ? The MapD is not showing any errors and we can not find the route of the problem. Programming has been checked

HElp! thanks Lisa

 

[mclellan]

Hello,

Do you have multiple MAP-D's, or more than one port assigned for your adjunct route requests?

can you post what your adjunct routing vector looks like?


Barry

 

[lisalisa173]

We do have Multiple MAPD ‘s and have both in the Vectors. If one fails it go’s to the next one. Our switch programming has not changed for this setup in years. But here is a snap shoot.
This is 1 flow. We broke them down a little yesterday to try and track a pattern but it’s happening on multiple options.We don’t think it’s related to the Switch programming. That parts seems to work fine until we after 10 minutes with heavier loads coming into the system . When we swing traffic to a different State with a different VRU and – NOT upgraded GEOTel call traffic is fine. thanks lisa

VECTOR DIRECTORY NUMBER

Extension: 26899
Name: Fr Geo Invld# Coll 16 Rtry
Vector Number: 999

Allow VDN Override? y
COR: 90
TN: 1
Measured: external

CALL VECTOR

Number: 999 Name: CS Coll 16 Rtry
Lock? n
Basic? y EAS? y G3V4 Enhanced? y ANI/II-Digits? y ASAI Routing? y
Prompting? y LAI? y G3V4 Adv Route? y CINFO? y BSR? y Holidays? y

01 wait-time 0 secs hearing silence
02 announcement 26204
03 route-to number 26831 with cov n if unconditionally
04 stop
05

VECTOR DIRECTORY NUMBER

Extension: 26831
Name: Fr Geotel Coll 16 Acct ARL
Vector Number: 931

Allow VDN Override? y
COR: 90
TN: 1
Measured: external


VDN of Origin Annc. Extension:
1st Skill:
2nd Skill:
3rd Skill:


isplay vector 931 Page 1 of 3 SPE B
CALL VECTOR

Number: 931 Name: CS Coll 16 ARL
Lock? n
Basic? y EAS? y G3V4 Enhanced? y ANI/II-Digits? y ASAI Routing? y
Prompting? y LAI? y G3V4 Adv Route? y CINFO? y BSR? y Holidays? y

01 wait-time 0 secs hearing silence
02 collect 16 digits after announcement 26143
03 adjunct routing link 20032
04 wait-time 2 secs hearing silence
05 adjunct routing link 20031
06 wait-time 2 secs hearing silence
07 route-to number 26804 with cov n if unconditionally
08 stop
09
10
11

 

[mclellan]

This may be a simple thing to try, but change the wait time in step 04 to 6 seconds.

If the MAPD-1 is down, it will cancel the 6 second wait step by default.

My thoughts are that your MAP-D is maybe becoming overtaxed and can't respond before the 2 second timeout.

Barry

 

[lisalisa173]

Thanks but the MapD are up when this happens. We have been doing 15 to 20 minute testing over the last few days. Each time a number of calls bounce after 10 minutes The MapD is not showing a errors.

 

[mclellan]

Hmmm, do you know if your PG's are failing over?

When this is occurring, can you do an asai_test from your PG and see if is still reaching your MAPD's?

If you do a display events, what errors are you seeing?


Barry

 

[jimbojimbo]

Have a friend who has been having sort of the same issue. My understanding is that it is related to a call conf/transfer to an extension not recognized by the ICM which in turn causes the ICM to dump. FYI, they are getting ready to dump the ICM. They are merging all the Avaya platforms together (you may not have this option if you have multiple vendors systems).

James Middleton
ACSCI/ACSCD/MCSE
Xeta Technologies
jim.middleton@xeta.com

 

[lisalisa173]

The Call transfer problem i know about. We had that as a BIG problem at my Last job. It was resolved since by having a different vendor change some setting and replacing many of the phones. They needed phones with more buttons for the call center staff so that calls would not get stuck.
Here we are only using the ICM between the VRU and the PBX for getting and moving data around with more advanced reporting.. Our problem seemed to clear up once BOTH PG's got powered down together and stayed off for a few minutes to clear anything thing in the memory that might have been corrupt. That fixed our problem.

Thanks Lisa