SV9500 - UM8700 2 MG VoIP Users Cannot Connect To Vmail

[PRE-CD]

I recently migrated our UM8700 to a virtual machine because our old server was just that...old.

2 of my MGs on the SV9500 cannot dial the UM8700 if they are VoIP users. The other two can with no issues. Using Protims.

I switch to the old server and boom...everything works as normal.

 

[DoubleDriveLine]

What data do you have in AIVCL and ALOCL?



There are 10 kinds of people in the World.

Those that understand Binary and those that don't.

 

[DoubleDriveLine]

are your terminals IP or TDM?

Please include a little bit more of your setup.



There are 10 kinds of people in the World.

Those that understand Binary and those that don't.

 

[PRE-CD]

What data do you have in AIVCL and ALOCL?"

In AIVCL I have G.711 for TYPE and 40ms for Size. Priority is 46 with DIFFSERV for IP PRECEDENCE. In ALLOCL I have LOC-ID set to 1. IP PRECEDENCE is not set on our domain IPs and Type of Signaling Packet as well.

"are your terminals IP or TDM?"

The terminals I am having trouble with are IP. And only in MG0 and MG1. MG2 and 3 process calls the voice mail just fine. All TDM phones in all MGs work fine. We cannot figure out why some MGs cannot dial the system yet others can. We have moved a working IP terminal from MG3 to MG0 and that broke it.

 

[DoubleDriveLine]

Lets look at the IP Phones first. Look at the firmware versions of the phones that work vs the phones that don't.

I once had phones that could not call the UM8700 because their firmware was too old. I upgraded the firmware and that fixed it.

How did you move a phone from one MG to the other MG?

In ALOCL you should have location group 0 and 1 at a bare minimum. Even if you don't have QOS turn on within the network set the Diffserve value to 26 or 28. Note that 40 might be the new standard but I still use 26 or 28. This DSCP value sets the QOS for the SIP control packets not voice or RTP packets. NOTE changes or assignments to ALOCL require a PBX reset. You can simply reset the PH but a Power off reset might be a good idea for your system anyway. Note Power off reset not a reboot.

Location ID 0 covers the CPU and is required
Type Network Address
IP Address 0.0.0.0
Location ID 0
Mask 32
DSCP 26 or 28
Don't define the IPPad

Location ID 1 - 4095 cover the actual devices. I usually cover the range with a blanket and that works well. The blanket will cover all IP Addresses possible in the IP Class. The 3 possible blankets are
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Type Network address
IP Address 10.0.0.0
Location ID 1
Mask 8
DSCP 26 or 28
Don't define the IPPad

For AIVCL you must have an entry for each location ID to each location ID. The DSCP value here defines the RTP / Voice Packets and is required. The default for payload is 40 milseconds but there are issues with using 40 milliseconds universally. Since all SIP trunk providers specify 20 ms packets I have standardized on 20ms on all of my installs. Certain Servers (UCE IVR) don't like anything other than 20ms also. The UM8700 will function fine with 20ms. really old documents from the UM8700 will tell you 40ms only. Those days are gone it supports 20ms just fine.

LOC ID to assign
0 to 0
0 to 1
1 to 0
1 to 1

A LOC-ID 0
B LOC-ID 0
Jitter Buffer (optional but 20 is a safe number) 30 is the MAX
Diffserv
DSCP 46
Setting of Payload
PRI 1 = G.711 @ 20ms Payload
PRI 2 = G.729 @ 20ms Payload (if needed) Internally it should not be needed unless network bandwidth is an issue.

Note when you assign location ID 0 to 1 the reverse is automatically assigned.
A LOC-ID 0
B LOC-ID 1
Jitter Buffer (optional but 20 is a safe number) 30 is the MAX
Diffserv
DSCP 46
Setting of Payload
PRI 1 = G.711 @ 20ms Payload
PRI 2 = G.729 @ 20ms Payload

A LOC-ID 1
B LOC-ID 1
Jitter Buffer (optional but 20 is a safe number) 30 is the MAX
Diffserv
DSCP 46
Setting of Payload
PRI 1 = G.711 @ 20ms Payload
PRI 2 = G.729 @ 20ms Payload

If those are all already good I would go with a Power off reset. I have had freaky unexplainable issues before that were fixed by the power off reset.

Before reseting check the conditions of your CPUs and the SIP servers. Are you a redundant CPU? If you are one CPU is active and the other in Standy sort of. Both CPUs have SIP servers running on them. If one of the CPUs is having an issue the phones registered to that CPU might not function correctly.

Use caustion and make sure you have a backup of the systerm software, Office data, License file and Activation code before you do the power off reset.




There are 10 kinds of people in the World.

Those that understand Binary and those that don't.

 

[PRE-CD]

Thanks for the response.

We will take a look at firmware.

To move the phone from a working MG to a MG which is experiencing the issue we simply deleted the phone in AISTL and reconfigured on another address within the MG that has issues.

This weekend I did a shutdown of the system. SINZ, Shutdown, powered down CPUs, all PIMS and highway module. Then reversed the order as written. No change.

I have forwarded your comments over to our NEC technician who is working through this with us. We will take a look at all these settings you mentioned and see if they are correct.

I sent our database and ALOCL/AIVCL/Wireshark + other info over to NTAC last week. They responded that no issue was found in the PBX. However it is very puzzling as to why 2 MGS can call and 2 others cannot. When I fire the old server up, which has different firewall settings than this new server, all is normal.

What would be specific to the different MGs that would cause this? That is the question I cannot answer but would lead me to the answer.

 

[DoubleDriveLine]

What would be specific to the different MGs that would cause this? That is the question I cannot answer but would lead me to the answer.

I actually don't have a clue how that is possible with IP. If the phone X can call phone Y both in different MGs then either should be able to call the voicemail.

But now I though of an issue I saw with a SV9100 a few years ago. The SV9100 had all the phones in static IP Addresses. The PBX subnet mask was not set correctly so some phones failed to connect. The phones were using a /23 address and the PBX was a /24.

The IP range the phones were in was

192.168.0.0 - 192.168.1.255

But the PBX only saw this range.

192.168.0.0 - 192.168.0.255

The gateway was the same so some of the phones could connect. The phones that had their IP address in 192.168.1.x couldn't

If you are using DHCP then this will not be the issue.

I guess the thing to look at is the Static IP of the voicemail and make sure it matches the actual subnet.





There are 10 kinds of people in the World.

Those that understand Binary and those that don't.