Aura Messaging, Communication Manager and Session Manager: MWI stopped working, no changes. ASM responds with 404 (No Route Found)

Doc ID		SOLN279251
Version:		4.0
Status:		Published
Published date:		22 Sep 2017
Created Date:		20 Nov 2015

Author:

Charles Kuhn

Details

Two Session Managers (ASM), two application servers (AAM), one Communication Manager (CM), H.323 phones (registered to CM).

Problem Clarification

Watching a traceSM from ASM the NOTIFY for message-summary (MWI) came from AAM2 to ASM2 to which ASM2 would respond with a 404 (No Route).

Cause

Configuration issue which worked fine for many months but because of how ASM interprets location based routes was bound to fail eventually.

Incorrect Configuration:

In System Manager > Routing > Locations, A single location was built for both AAM application servers. The SIP entities for the two AAM application servers (two different IPs) pointed to the same location. A dial pattern and routing policy defined could route fine if AAM1 sent the NOTIFY/message-summary to ASM1 this would correctly go to CM based on routing policy. But if NOTIFY/message-summary was AAM2 to ASM2 because the location didn't have a clear definition the route policy for ASM to CM didn't account for if AAM2 was the originating device. This is a similar issue that could be seen with overlapping location's IP ranges.

Failure was essentially a misunderstood location where ASM only trusts when MWI originated from AAM1 to ASM1 in order to route to CM.

Solution

Corrected Configuration:

An additional location was added for each AAM application server, SIP entity then set to specified location, and route policy added so if message-summary (MWI) came from AAM2 to ASM2, then ASM2 also had a route to CM.

Note, this is one way to do this. Use of Local Host Name Resolution (LHNR) could have been used also.

Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy