One way audio issue with a single site

[chewie]

Hi all.  At my wits end diagnosing this one thus far...

We are running a Mitel 3300 here at this site, on version 44.0.1.26. The other site in question runs a 3300 on 40.2.0.16.

When we call that site by using their 4 digit extension, we can hear them, but they can't hear us.
If we dial their full DID, they can hear us, and we can hear them.

Normally, I'd say, well this is a networking issue, as the sites are connected via VPN and thus this would have to be a firewall and/or routing issue....except...it sure as heck does not appear to be.
They are running their site off a Model 200 Dell NSA, and we are using a 4600 series, so my thoughts have somewhat strayed to thinking maybe there is a VOIP setting we need to turn on there, but... previoulsy, we ran another 3300 from another vendor with a slightly older version of the software (same as the other site), and two way audio worked just fine.

The only changes have been to the 3300 box itself (different box, different vendor), the software it runs (new version on this end), and a VLAN change (We implemented the VLAN for voice at the same time).  Now, the firewalls I can verify all have the correct setup for in and out traffic, where it's allowing what, and they all know about each other's networks including our new VLAN.  We have two other sites with 3300's that talk to us internally via the same exact VPN channels with the same settings with 0 issues. It's only this one site.

Now, my boss mentioned to me that there was an issue like this when the last box was first implemented, and there was a CoS setting that had to be tweaked here for it to work.  We haven't been able to find our notes (it was so long ago) and I have been pouring over everything I can to figure it out.

Settings between systems seems to match up. The only glaring difference was that in our LAN Policy (QoS) settings, Voice Signalling is set to 24, and on the old system it was 26, and on all the other sites it's 26. But the other sites work just fine, and the DHCP settings for the phones being handed out have the correct 26 setting for the same voice signalling setting. So...still not sure.

But..that being said, any ideas here? I am considering trying to race the call via the maintenance interface, but not sure how to do that, and our vendor keeps pointing us to our network settings. While it still could be something obscure, I'd still like to rule out the 3300 itself and see if there is anything offhand anyone can think about to try that won't require a reboot per say (as that would have to be done after hours, and noone will be at that site then).

I also tried placing the call to the site on hold and picked it back up, as I read that someone had that kind of issue that alluded to being a 3300 issue and not networking.

But, out of ideas at the moment. I went down the networking path a dozen times now, and everything says both sites can talk between our VLAN and theirs, etc. And again, it's the only site with an issue as such.

Appreciate any insight.

[VinceWhirlwind]

You are probably better off viewing the call on your firewall. Watch the signalling packets (which obviously are getting there, because the call is being setup) and then look for the RTP packets.
Network issues are easy to rule out - put a laptop on the voice VLAN (make an untagged port for it) and give it the *exact* same IP addressing details as the phones get (use the phones' DHCP to be sure) and then ping the remote phones as well as the remote controller, then do the same thing on the remote site.
So long as that is all setup correctly, you're bound to be having a firewall problem, which is easy to spot if you look on the firewall for dropped packets in either of the voice or controller subnets.
 
When you dial the full DID, is it being routed externally instead of over the private link?

 

[chewie]

I've combed the logs and I am not seeing a darn lick of VOIP traffic being dropped on either end.
It really is crazy.

The only thing I can see is that there is some complaints on this end about irregular voip traffic coming from the mitel 3300 here to the other site's 3300, but no corresponding log entry on the other side.

I do see, whenever I make a test call to the other site, in their firewall log, alerts about voip-apps sip, coming from the micollab and MBG systems we have setup along with this 3300, with a destination to their 3300, port 5060 and UDP, but it isn't saying it's dropping it, just alerting.  Plus those IP's aren't matching the IP's of the actual call system here...unless the new 3300 system setup talks through MiCollab and MBG? I mean, did that change?

[x-man]

Daft question; has SIP-Alg been enabled on a firewall by mistake? Or of course vice versa if its needed?

[chewie]

No for all firewalls involved.
I had that thought as well.

[Dogbreath]

I've combed the logs and I am not seeing a darn lick of VOIP traffic being dropped on either end.

You won't see MiNet being logged as VoIP, because Sonicwall won't recognise MiNet traffic as being VoIP. It doesn't actually sound like you're having a problem with SIP anyway as you say that external calls work fine.

Before you start a test call, find out the IP address of each handset. Use the Connection Monitor tool in the Sonicwall to look at all connections to/from the IP address of that handset. Make a test call, leave it running and look in the Connection Monitor at the Tx Bytes/Rx Bytes columns. You are looking for a connection where there's a 0 in either column, indicating that traffic only flows in one direction - that will be your problem connection. Alternatively, use the Packet Monitor, filter on the IP address of the handsets and tick the "Dropped Packets Only" option.

..unless the new 3300 system setup talks through MiCollab and MBG? I mean, did that change?

You can't expect anybody here to know that! It depends on how it was set up.

[x-man]

The few times we have had problems like this a wireshark trace has revealed (mostly) the problem and allowed us/mitel to solve the problem.I use a decoder that puts out lots and lots of info from the trace itself. ClearSight is its name; I believe it uses a thrid party decoder to give the info in a clear understandable way.

[chewie]

What was the problem for you guys?
Also how DO you properly wireshark with the desk phone?

I turned on port mirroring, plugged my laptop into the back of the phone on the PC port, started wireshark across that NIC, and then made a call and I'm not seeing it dump anything out about it.

[x-man]

 You need to port mirror the main phone port to see what the phone is doing and sending etc. You need to mirror the network port to get at some information and you need to mirror the MBG port(if using one as a proxy)  if that doesn't reveal any issues.

Personally I would mirror the network port of the switch in question, run wireshark and then make a couple of calls. Then stop wireshark. You need to then sort out all that happens from the phone address because, as you know, once the call is established it is peer to peer and the 3300 only monitors the call for cleardown. If you can do it at a quiet time there will be a lot less traffic to confuse matters.

Our problem was a call timer issue. The SIP trunks were clearing after 10 minutes even though the call timer was disabled for trunks and set at 300 minutes anyway. It turned out that the INTERNAL call timer had been set and it was THIS that was terminating the calls NOT the external call timer even though they, the SIP, were trunks. Eventually we noticed that it was the 3300 that was sending the bye message but no cleardown from the phone was being sent and Mitel eventually saw something that indicated that it was the internal timer. They wouldn't say why or what that was.