My issue is exactly like what's posted in an older thread which has been closed (
Our all-in-one XEN based solution (MSS and MAS vms) .. the MAS was hosed and there was no way that Avaya could get it to come back alive. It pinged but they could in no way get console access to it. So, after running a backup on the MSS, they re-deployed the template solution. Anyhow, after re-deploying and patching to 5.2 Patch 15 (9.2.723.15000) -- the data looked to be restored fine. But, then, the FE mentioned to check MWI. And, that was when we noticed it wasn't actually working.
So, Avaya has been banging their heads on it for 2 days. A tier 3 person spent the better part of 5 hours on it before they handed it off to someone who supposedly knows MWI better than them. But, I think that was just a excuse to get off because it seems like I know more about MWI at this point than the person handling the case (let's put it like this, I don't deal with voice at all on a day to day basis. I was just a hot body at the time available to manage the Avaya FE).
[highlight #FCE94F]ChuckRCT mentions this in the thread and I'm curious how to go about doing it ... "I'm not sure if this is your particular problem, but I've seen a similar problem on a couple systems at MM 5.2. When you change the SIP Gateway info sometimes the data is changed, but not removed from the VMD database. If you look at it in VMSC the Gateway info appears to be correct, but in reality you have additional Gateway info that doesn't display and has not been removed. I'd look at the traces as Ken suggests and just verify that the MWI SIP Notify messages are really going to the AudioCodes gateway and not something else that doesn't exist."[/highlight]
I do have the advanced sip logging on. All the IP info in there looks correctly to be destined for the PBX/SIP gateway. There is one thing that makes me think it could be DNS related since the SIP domain (domain.local) is the same as our internal Windows domain. And, the MAS windows server is set to use our corporate DNS servers for lookups. So, when I ping from the MAS 'domain.local' -- it does resolve to one of our domain controller IPs. Oddly enough, other than MWI, voicemail is being received and played back fine.
In the VMSC, the gateway looks correct but how do I go about verifying it outside of the GUI like ChuckRCT says? Thank you for reading.
[highlight #FCE94F]06/11/15 13:06:06, "", 21048, "Information", 71, "MMAS", "SIP IN :INVITE sip:3135@domain.local SIP/2.0
From: "doe, john" <sip:3453@domain.local>;tag=06661e7741de51a662542dee8500
To: sip:3135@domain.local
Call-ID: 06661e7741de51a762542dee8500
CSeq: 1 INVITE
Max-Forwards: 71
Route: <sip:192.168.50.22;lr;phase=terminating;transport=tcp>
Record-Route: <sip:192.168.50.10;lr;transport=tcp>
Via: SIP/2.0/TCP 192.168.50.10;branch=z9hG4bK06661e7741de51a862542dee8500
User-Agent: Avaya CM/R015x.02.1.016.4
Supported: timer, replaces, join, histinfo, 100rel
Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER, OPTIONS, INFO, PUBLISH
Contact: "doe, john" <sip:3453@192.168.50.10;transport=tcp>
Session-Expires: 1200;refresher=uac
Min-SE: 1200
P-Asserted-Identity: "Klurfe", 1, , ""[/highlight]
[highlight #FCE94F]06/11/15 13:06:06, "", 21048, "Information", 71, "MMAS", "SIP OUT :SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.50.10;branch=z9hG4bK06661e7741de51a862542dee8500
From: "doe, john" <sip:3453@domain.local>;tag=06661e7741de51a662542dee8500
To: sip:3135@domain.local
Call-ID: 06661e7741de51a762542dee8500
CSeq: 1 INVITE
Server: Modular Messaging
Content-Length: 0
", 1, , ""
![/highlight]
MWI request to 'Reset' the lamp has been called for extension: 101463 on port 0
WARNING NT significant event with ID '3221227238' was reported with strings 'Reset\n101463\nProxy/gateway temporarily unavailable\n'.
MWI request to 'Reset' the lamp has been called for extension: 101496 on port 0
MWI notification being sent to high-level component for extension 101486, error Reset, request Proxy/gateway temporarily unavailable from port 0
MWI request to 'Set' the lamp has been called for extension: 101497 on port 0
MWI notification being sent to high-level component for extension 101497, error Set, request Proxy/gateway temporarily unavailable from port 0
Our all-in-one XEN based solution (MSS and MAS vms) .. the MAS was hosed and there was no way that Avaya could get it to come back alive. It pinged but they could in no way get console access to it. So, after running a backup on the MSS, they re-deployed the template solution. Anyhow, after re-deploying and patching to 5.2 Patch 15 (9.2.723.15000) -- the data looked to be restored fine. But, then, the FE mentioned to check MWI. And, that was when we noticed it wasn't actually working.
So, Avaya has been banging their heads on it for 2 days. A tier 3 person spent the better part of 5 hours on it before they handed it off to someone who supposedly knows MWI better than them. But, I think that was just a excuse to get off because it seems like I know more about MWI at this point than the person handling the case (let's put it like this, I don't deal with voice at all on a day to day basis. I was just a hot body at the time available to manage the Avaya FE).
[highlight #FCE94F]ChuckRCT mentions this in the thread and I'm curious how to go about doing it ... "I'm not sure if this is your particular problem, but I've seen a similar problem on a couple systems at MM 5.2. When you change the SIP Gateway info sometimes the data is changed, but not removed from the VMD database. If you look at it in VMSC the Gateway info appears to be correct, but in reality you have additional Gateway info that doesn't display and has not been removed. I'd look at the traces as Ken suggests and just verify that the MWI SIP Notify messages are really going to the AudioCodes gateway and not something else that doesn't exist."[/highlight]
I do have the advanced sip logging on. All the IP info in there looks correctly to be destined for the PBX/SIP gateway. There is one thing that makes me think it could be DNS related since the SIP domain (domain.local) is the same as our internal Windows domain. And, the MAS windows server is set to use our corporate DNS servers for lookups. So, when I ping from the MAS 'domain.local' -- it does resolve to one of our domain controller IPs. Oddly enough, other than MWI, voicemail is being received and played back fine.
In the VMSC, the gateway looks correct but how do I go about verifying it outside of the GUI like ChuckRCT says? Thank you for reading.
[highlight #FCE94F]06/11/15 13:06:06, "", 21048, "Information", 71, "MMAS", "SIP IN :INVITE sip:3135@domain.local SIP/2.0
From: "doe, john" <sip:3453@domain.local>;tag=06661e7741de51a662542dee8500
To: sip:3135@domain.local
Call-ID: 06661e7741de51a762542dee8500
CSeq: 1 INVITE
Max-Forwards: 71
Route: <sip:192.168.50.22;lr;phase=terminating;transport=tcp>
Record-Route: <sip:192.168.50.10;lr;transport=tcp>
Via: SIP/2.0/TCP 192.168.50.10;branch=z9hG4bK06661e7741de51a862542dee8500
User-Agent: Avaya CM/R015x.02.1.016.4
Supported: timer, replaces, join, histinfo, 100rel
Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER, OPTIONS, INFO, PUBLISH
Contact: "doe, john" <sip:3453@192.168.50.10;transport=tcp>
Session-Expires: 1200;refresher=uac
Min-SE: 1200
P-Asserted-Identity: "Klurfe", 1, , ""[/highlight]
[highlight #FCE94F]06/11/15 13:06:06, "", 21048, "Information", 71, "MMAS", "SIP OUT :SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.50.10;branch=z9hG4bK06661e7741de51a862542dee8500
From: "doe, john" <sip:3453@domain.local>;tag=06661e7741de51a662542dee8500
To: sip:3135@domain.local
Call-ID: 06661e7741de51a762542dee8500
CSeq: 1 INVITE
Server: Modular Messaging
Content-Length: 0
", 1, , ""
![/highlight]
MWI request to 'Reset' the lamp has been called for extension: 101463 on port 0
WARNING NT significant event with ID '3221227238' was reported with strings 'Reset\n101463\nProxy/gateway temporarily unavailable\n'.
MWI request to 'Reset' the lamp has been called for extension: 101496 on port 0
MWI notification being sent to high-level component for extension 101486, error Reset, request Proxy/gateway temporarily unavailable from port 0
MWI request to 'Set' the lamp has been called for extension: 101497 on port 0
MWI notification being sent to high-level component for extension 101497, error Set, request Proxy/gateway temporarily unavailable from port 0