So,
I have a complicated setup and one particular issue that is causing me fits. I am rolling out Unity Connection 8.6 Centralized voicemail in an environment that has a rather large division on Avaya Communications Manager 5.2. They also have a an 8.6 Cisco UCM cluster, a 6.1 Cisco UCM cluster, and an 8.5 Cisco UCM Cluster. The company went through some mergers, and this is why so many clusters.
Everything is talking now, via SIP Trunks, even between the Avaya and Cisco systems. I am working on now getting all systems centralized on 8.6 Connection voicemail, and eventuallly we will migrate all phones to the 8.6 UCM cluster, but not immediately. During my testing and setups, I have now gotten an Avaya test phone to have their CFNA/CFB paths to point to the UCxN Cluster, and it works good. I can press the messages button, it asks me for PIN, I can log in, hear it, etc, ao all is well. I also have the MWI lights working. I can leave test messages on the Avaya set, the MWI lamp comes on, delete the message, it goes away. So, basic calling between Cisco and Avaya is working, and basic VM access and setup from the Avaya side is working as well.
The issue occurs when a call is redirected from the Avaya side into the UCxN, it is not sending the redirecting number I/Unity Connection is expecting, and thus when "Coverage Paths" are setup on the Avaya side, they are not working as designed. An example, let's say an executive DN is 1234 and his Admin is 2234. If a coverage path is set up to route calls bound for the executive phone to ring first at the Exec phone, 1234 for 4 rings, and then if he/she does not answer the call would roll to Admin @ 2234 for 4 rings before going to the Voicemail box of the executive phone, which is VM box 1234, not of the Admin, 2234. However, when this setup is done on the Avaya side when the call is getting to Unity Connection, it is sending it to "2234".
This is occurring even though I have not changed the default setting within Unity Connection:
"Use Last (Rather than First) Redirecting Number for Routing Incoming Call" this box is still unchecked.
When I test this scenario with Cisco phones, it is working. It recognizes the first redirecting number (the orginal called number) and puts me into the Mailbox of the executive, not of his admin.
Has anyone run into this issue with SIP trunks between an Avaya and a Cisco UC environment, and if so, what are the workarounds? Will qsig for example relay the correct diversion header information?
