Avaya CM Upgraded to 8.1, now having issues with all Stations that have EC500 configured

[Louis87]

Hi everyone,

Upgraded to 8.1 now it appears that EC500 does not work correctly. If a station has a coverage path, and EC500 is disabled, it is still following as if EC500 is active. For information, all stations that have EC500 programmed and a coverage path are presenting this issue.

Someone has some suggestions for solve this issue? Maybe can be a bug in Cm 8.1?

Bellow is the List Trace from one of these configured stations, for better understanding:

8-2-2019 9:41 AM - Report for Voice System name: CM6.3 - list trac pre

"t"
"09:38:30 TRACE STARTED 08/02/2019 CM Release String cold-01.0.890.0-25517"
"09:38:53 dial 84347592 route:ARS"
"09:38:53 term trunk-group 20 cid 0x1b5f"
"09:38:53 G711MU ssff ps:20"
"rgn:1 [10.27.54.62]:16308"
"rgn:1 [10.25.52.197]:39816"
"09:38:53 dial 8434759288 route:ARS"
"09:38:53 route-pattern 1 preference 1 location 1/ALL cid 0x1b5f"
"09:38:53 seize trunk-group 20 member 42 cid 0x1b5f"
"09:38:53 Setup digits 8434759288"
"09:38:53 Calling Number & Name 8437923875 LORI TEST"
"09:38:54 Proceed trunk-group 20 member 42 cid 0x1b5f"
"09:38:56 Alert trunk-group 20 member 42 cid 0x1b5f"
"09:39:08 no answer cid 0x1a23"
"09:39:08 coverage-path 98 point 2 cid 0x1a23"
"09:39:08 call-forwarding #9924488#"
"09:39:08 term trunk-group 998 cid 0x1a23"
"09:39:08 call-forwarding #9924488#"
"09:39:08 route-pattern 999 preference 1 location 1/ALL cid 0x1a23"
"09:39:08 seize trunk-group 998 member 49 cid 0x1a23"
"09:39:08 Calling Number & Name 8437923875 LORI TEST"
"09:39:08 idle trunk-group 20 cid 0x1b5f"
"09:39:08 Proceed trunk-group 998 member 49 cid 0x1a23"
"09:39:09 active trunk-group 998 member 49 cid 0x1a23"
"09:39:09 G711MU ssff ps:20"
"rgn:99 [10.25.40.217]:8004"
"rgn:1 [10.25.52.197]:40180"
"09:39:09 xoip options: fax:T38 modemff tty:US uid:0x5008b1"
"xoip ip: [10.25.52.197]:40180"
"09:39:15 idle station 10988 cid 0x1a23"
"09:39:17 Calling party station 10988 cid 0x1c64"
"09:39:17 Calling Number & Name 10988 LORI TEST"
"09:39:17 dial 24568"
"09:39:17 ring station 24568 cid 0x1c64"
"09:39:19 active station 24568 cid 0x1c64"
"09:39:31 idle station 10988 cid 0x1c64"
"09:41:11 TRACE COMPLETE station 24568 cid 0x0"

 

[kyle555]

That's very weird. Can you turn ec500 on and off and see if that make a difference? I guess the station stat's normally with 'ec500 disabled'. I'd open a ticket.

 

[Louis87]

Hi Kyle, I turn on and off and it didn't make any difference.

Also, a new station was created, disabled EC-500 on the station, called it directly and the cell phone wasn’t called. Then add that new extension to coverage answer group 1 by itself and called another station that covered to c1 and the cell phone was called as if EC500 was enabled again.

All EC500 programming were also removed via Provision, did a save translations all, then imported back in from an export in July. Initially was thought that removing it and building it back helped as it appeared that one on one test station.

If you have any new suggestion, please let me know.

 

[kyle555]

open a ticket! A lot of things change in a major CM release and even if you're just bringing a backup to the current release, that doesn't mean a lot of stuff that your config uses under the hood didn't change.

One example i had recently was going to CM 8.1 and the voicemail sip sig group got corrupted. There's a new feature in CM 8 around clustered SM sig groups where you can administer 2 node names for SM as a 'pair' and make a 'cluster sig group' that uses a single trunk group of up to 10K members. You can even point each station on the last page of it's station form whether it uses "sm east" or "sm west" first. It makes SIP admin less of a chore not having to do AAR and route patterns and just having a single sig/trunk group be good for 2 SMs.

And for whatever reason CM 8.1 thought our voicemail sig group was using that. The corruption engineer asked "are you using clustered sm sig groups?" and I said no and he said "but that's what you have programmed" and while it wasn't programmed in our sig group form, something under the hood sure thought it was.

So yeah, if you have SIP stations and you're using off-pbx station-mapping for OPS and EC500, I could conceivably see a bug that makes CM go goofy and routes calls out both all the time even if EC500 is off.