Avaya IPO 500 v4.2(17) SCN & Centralized voicemail

[GDeaks]

Hi there,
We have a customer that has a problem with a remote site (they have 5 in total 1 being the central site with a VM Pro PC)
all seem to be fine except this one, the voicemail is set to centralized, when I look at system status voicemail is none, and SCN on the IP trunk is "Not enabled"
The central site on the trunk shows as being "Up"

When I look at the non working site using monitor I get:

10878333mS PRN: VPNN: SendRIP to pbx {Central site IP}
10878333mS AVRIP Tx: v={Central site IP} send=0 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0
10888333mS PRN: VPNN: SendRIP to pbx {Central site IP}
10888333mS AVRIP Tx: v={Central site IP} send=0 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0
10898333mS PRN: VPNN: SendRIP to pbx {Central site IP}
10898333mS AVRIP Tx: v={Central site IP} send=0 receive=0
requiresvoicemail 1 operational 0 version 0 recordsupported 0
IPaddr 255.255.255.255 hops=0 voice=0

On a working site I can see:
4153978513mS PRN: VPNN: SendRIP to pbx {Central site IP}
4153978513mS AVRIP Tx: v={Central site IP} send=0 receive=0
PLATFORM: voice=00000000 ipad=0.0.0.0 operational 0 version 0 recordsupported 0
Platform Id 0 Version 4.2(17)
Name WorkingSite
Codepage 2, Unicode UnicodeSupportOn
Time offset: 0
RIP: IPaddr {Working site IP} hops=0 voice=00000000 ipad=0.0.0.0
Name Site1
Time offset: 0
RIP: IPaddr {Non working site IP} hops=0 voice=00000000 ipad=0.0.0.0
Name <-- THIS IS BLANK?????
Time offset: 0
RIP: IPaddr {Working site IP} hops=0 voice=00000000 ipad=0.0.0.0
Name Site2
Time offset: 0
RIP: IPaddr {Working site IP} hops=0 voice=00000000 ipad=0.0.0.0
Name Site3
Time offset: 0

The central site appears to receive the Tx's from the bad site and appears to respond.

They have sonicwall firewalls on each end of the VPN's and swear blind there is nothing blocking.
I've got them to untick the "Enable H323 Transformation"

Has anyone out there got any idea's?

Thanks
Garry

 

[hairlessupportmonkey]

it wont be the h323 transforms messing it up it will be some other transformation that is killing it.

might be a process of elimination with this one until it springs into life

ACSS - SME

 

[GDeaks]

Thanks for your reply, have you seen something similar before in the past, I'm convinced it's networking & doing a google search convinces me even more.....

 

[hairlessupportmonkey]

not really, but then we dont use sonic wall so dont suffer their inflictions!

ACSS - SME

 

[intrigrant]

IPO use IP port 50795 UDP for SCN, appearantly this port is blocked from the central sit to the remote site.
If all SCN traffic from the central site passes through the same Sonic Wall then the problem is in the remote site firewall/VPN router.
Ethereal can enlighten your vision on this.

 

[GDeaks]

Cheers, I am suggesting a little bit of wireshark action, it's in london, and i'm in manchester so don't want to nip down myself )

 

[mcoliver]

Did you ever figure this out? Running into the same problem on my network. I can get both IP Offices to have SCN up but as soon as one side's internet connection is lost I lose the SCN. I'm running Untangle Firewall's on both sites with an OpenVPN site to site tunnel. I have opened up everything across the tunnel but for some reason the remote site will not bring up SCN. Seeing the same issue where the central server will show SCN up but the remote site shows SCN down and does not show any AVRIP Rx messages.

Finished writing this but never sent it. Turns out Stopping and Starting the VPN link between the two sites fixed the problem. Need to dig further into what is going on but stoping and starting the site to site OpenVPN seems to have fixed the problem.