1616 Phones

[gotchaback]

First of all im not a data guy, that being said this companies IT guy set up a VLAN and tagged everything at the switch.
I was given a 192.168.2.211 - 214 for my phones at the remote office, which is running over a VPN using Sonicwall TZ100 gear.
The IPO is at 192.168.2.20 back at the main office behind another TZ100.
Problem is that since the VLAN was setup the phones started to have problems like when an outside call comes in about 2 min's into the call the person taking the call can no longer hear the caller, but the caller can hear the user? Then the call drops off and the phone reboots itself, finds the router and goes back to idle.

I started them off just using the VPN with no VLAN but they said the echo was very bad and so I was told that even though i just had 4 IP phones i needed the VLAN for QoS. The IPO is a 500v2 running 8.1.43.
I've called my support a few times about this and i changed the codec and a couple of other minor settings but im still having this very bad problem. I dont know if its something i need to do different with the IPO or if its a network issue, but even if it is a network issue any help would be great. By the way they have 6 down and 1.5 up at each location

 

[intrigrant]

The problems you describe are related to ports 1718, 1719 and 1720 which are used for registeringthe phones.
IP Office will send registration acks to all registered IP Phones, these are UDP IP Packets. During a call it will do the same but just to seen if the call is still ongoing as the IP Office does not control the audio path. If a phone does not react after a number of messages then IP Office will terminate registration, audio pathh will stop and IP Phone will reboot.
So you have to check your VPN routers if all UDP keep alive packets send by IP Office can reach the IP Phones and the reaction of the phones must come backto IP Office.

A simple mind delivers great solutions

 

[gotchaback]

so those ports should be pointed to the pbx? in your solution what should i tell the IT guys to look at? "check the VPN routers to make sure UDP keep alive packets sent by the IPO can reach the phones and vise versa

 

[IPOfficeIreland]

in the voip settings for the sonicwalls you have H323 fixups - make sure these are disabled. also, your network vpn doesn't make sense - both remote phones and local IPO are on 192.168.2.x subnet. I assume a mistake on your side as it wouldn't work otherwise. what data is going over the vpn? tz100 doesn't support QoS either, I am 90% sure of this!

 

[gotchaback]

yes you are correct the IPO is at 51.20 and phones are 2.211-214 Also we have the H323 disabled on sonicwalls. the setup is all traffic for this remote office with 4 workstations and 4 phones go over the VPN which is separated with a VLAN on each side, but the VLAN cannot pass through the tunnel so everything comes together over the VPN then splits back apart. Managed switches are doing the tagging so no VLAN ID set on the phones, the sonicwall does do QoS and it has a bandwidth meter so the IT guys have played around with that so that they can allow x amount of bandwidth for data and y amount for voice. Before the VLAN the problem was echo and lag now the calls are crystal clear but audio intermittently cuts out on one side then the entire call drops and phone reboots, finds the router and comes back to an idle state. I sent over the ports that intrigrant brought up so that the IT guy can make sure those are open. I would think that 1.5 up would be enough to run this small remote branch; i have the phones set at G.729 instead of G.711, which is something i did before the VLAN was set up to help with the echo.
Im very much lost on this and support has just said to tell them its a network/bandwidth problem and the phones are set up correctly from the config i sent over; so not a lot of help there. Thank you in advance for the help; the customer is very upset and im at a loss which upsets me as well.

 

[intrigrant]

There are three things do do here:
1 Don't panic
2 DON'T PANIC
3 setup some wiresharks monitoring PC's and start monitoring which H.323 packets leave IPO and do or do not reach the phones and vice versa.

Then in the end if you still cannot locate the problem : PANICPANICPANICANDKILLYOURSELF or get a cold beer

A simple mind delivers great solutions