Link to home
Start Free TrialLog in
Avatar of durango099
durango099Flag for United States of America

asked on

Mitel - SIP - one way audio

Hello Experts

Having found my issue with the VLAN setup I am left with one more issue:

I have no inbound audio to the endpoints (Mitel 5330e)

Networks looks like this:

SIP provider - Sonicwall TZ-180 - HP 2910al with 2 VLAN's (10.1.1.0 & 10.1.2.0)
Mitel vMCD - 10.1.1.241 static on VLAN 1
Mitel endpoints - 10.1.2.100-199 via DHCP VLAN 2

Peer to peer audio internally works both ways
Outbound audio on SIP trunks works
Inbound audio on SIP trunks - no worky

Attached is the SonicWall access rules - I can monitor the connections and I see the active call; however only the tx byte increment and the rx bytes stay at 0

So it would appear to be a NAT issue, however I can't seem to find my way around it.

Ideas?

Thankssonicwall-rules---Redacted.rtf
Avatar of agonza07
agonza07
Flag of United States of America image

Check out this link.

https://www.experts-exchange.com/questions/24093308/SIP-no-audio-Asterisk-SonicWall-TZ-190-SonicWall-TZ-150-SIP-Devices.html

1) Upgrade the Sonicwall firmware

2) Turn off the SIP transformations as suggested by the link.
Avatar of durango099

ASKER

I am unclear:

1) Upgrade the Sonicwall firmware

to a Standard higher version, or to Enhanced OS?
latest version of what you have. I'm assuming standard...
I have the most current standard version installed - I do however have Enhanced license on this unit that I could load.
I would upgrade to enhanced just in case there's something in there that can help. Doubtful, but you might as well if u own the license.

Then try out messing around with the SIP transformations.

Worst case you'll have to put in a sniffer to figure out what exactly is going on. My bet is on the Sonicwall, but try to work it out. Havent called Sonicwall support in a long time, but they sucked back then.
still sucks - even worse since dell took over!

will give the enhanced a go as clearly something is not nat'ing correctly
Still no joy - I get audio outbound, but not inbound - IE: I can't hear the caller, but they can hear me. The SIP transforms are not enabled, still same results.

Any more ideas?
Put a sniffer on the inside and outside of the firewall, and run a test call. Then check them out to see if the payload has the correct addressing.
Here is a small graph of a call without audio - the cap files are too large to attach.graph---no-inbound-audio---Redac.txt
I'll need the packet captures. Try to just filter it by port or IP, and just do a quick 3sec test call so as to not make the cap files too large.

My guess is that the SIP transformations are not working right, but it could be something else so I would try to dismiss that first, and only way to check is with the cap files.

Or call up your provider, sometimes their tech support will give you the cap files from their end.
Ok, will try that tomorrow - I am getting the boot for the night. I could put the cap files up on my ftp if that helps

Thanks
Ok. PM me if you need to.
I did not know there was PM here - can you point me to it? I clicked on your username , but no PM option.
Sorry, I rememeber in one of the newsletters they introduced private something... but its not what I thought.

http://ow.ly/eADY5
ftp://ftp.xxx.com/wireshark%20caps/

There is a active call cap listed - ip phone is at 10.1.2.153 - internal server at 10.1.1.241 - and external SIP provider at 69.WW.WW.54

Of note, during the peer session it seems to change over to 69.WW.WW.55

I questioned the SIP provider about this - waiting on the answer.
Also, if I turn off SIP transforms my outbound calls are rejected - turn it on and I can make outbound calls.
ASKER CERTIFIED SOLUTION
Avatar of agonza07
agonza07
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks for checking out the cap's

I only have 1 WAN address, so putting a hub on and capturing the data is going to be tough...any ideas?

I will be back onsite tomorrow - Will also be checking on the links you provided.

Thanks for the assist
Can't confirm without captures from the WAN side, but maybe playing around with the Sonicwall may do the trick.

One of the sites says to enable "Consistent NAT" another says to make sure you are forwarding the UDP ports which in your case it ls 50000-50511 or something like that.

Try those out and see if it helps.
Will see if I can get the cap from WCI (SIP provider) from the WAN side

I have enabled consistent nat, and created a rule in the sonicwall to allow all from the 69.WW.WW.54 & .55 to LAN 10.1.2.0

Do I need to do something more than that to "forward" the ports?
Not sure. You might wanna open up a case with sonic wall on that, or maybe another expert will chime in
Was able to get a external cap - loaded it up in my ftp called external.pcapng

I also opened a ticket with sonicwall - lord help if I can only get someone that speaks clear english inside of 2 weeks...no word since the email saying the case was opened...Ugh
So after a very long conversation with SonicWall support - I am eff'ed

The Enhanced OS doesn't like the VLAN tagged packets coming from VLAN 2 (phones)

The Standard OS doesn't correct transform the payload data and they want the Enhanced OS to correctly forward the NAT'ed packets.

So I have to either re-do the entire network to a 255.255.254.000 netmask so the phones can exist in the base VLAN 1, or get some different type of device to correctly interface with the public SIP provider.

Ideas?
or figure out how to untagg VLAN 2 when it hits the base VLAN 1 network???

is that even possible?
Not for the untagging of packets, you would need a router or another device to do NAT and it would just complicate things.

Best way to do this would be to do a SIP proxy. not much experience with Mitel, but get with their people to find out how you can do it. May be native to their server or something.

That way your communication happens between the server and your provider, the phones stay local to your network.
Solved issue with a new firewall that understands VLAN 2 and is now passing audio bothways

Yea!