Mediatrix SIP ATA through Sonicwall Site-to-Site VPN - No Audio

[sceaton]

Hello!

IPO500V2 8.1.43 Sonicwall TZ215 <-> SonicWall TZ205 site2site VPN.

I have a mediatrix 2102 ATA adapter and required 3rd party licenses in the IPO. If on the same LAN as the IPO, everything works great. I can place and receive calls to the ATA extensions and other IP extensions, as well as outbound SIP trunks without issue.

Moving the ATA to the other end of the VPN, though doesn't work.

First, I got this: prn: MZ stubs sip_cbk_fetchTxn no element found

and the ATA wouldn't register.

Sonicwall support determined the IPO (192.168.1.49) was not responding to traffic on a different subnet than it's own, so they created a NAT Policy to rewrite traffic coming from the ATA (192.168.2.148) to appear as though it's coming from the IPO's gateway (192.168.1.1).

This worked great, the ATA now successfully registers. I can place and receive calls, but ... there's no audio.

ATA extensions do NOT have "Allow direct media path" checked.

ENABLNG SIP transformations in the Sonicwalls will PREVENT the ATA from registering when the custom NAT rule is in place. Without the nat rule and sip transformations ENABLED, the ATA will register, but will not even setup calls, let alone no audio.

THIS IS INTERESTING:
I mirrored the IPO in the network switch and ran a wireshark trace on a test call. The call appears as an H.323 call between the IPO and the local IP Extension and I can hear the audio from the IP extension.

The other half of the call (from the remote ATA) appears as a SIP call, and I can hear audio being sent to the IPO from that remote extension. There is no RTP stream from the IPO TO the SIP extension.

It would appear that both halves of the audio are making it TO the IPO, but the IPO isn't connecting the dots between the two.

How do I troubleshoot from here?

 

[atcom]

We'd need to see the SIP INVITE packets to help troubleshoot this. The call might appear as H323 simply because of the port number it uses.

You should probably wireshark the packets at the ATA to see exactly how the Sonicwalls are mangling them. Sonicwall routers often change packets they have no business touching.

-----------------------------------

Calgary Telephone Systems, Avaya LG Asterisk (FreePBX) VOIP & TDM

 

[sceaton]

It would appear that I've been banging my head against the wall all week because I failed to enter a route in the IPO for the 192.168.2.0 subnet and the default route was sending traffic out to the internet.

I've rolled back customizations in the sonicwalls (no wonder the IPO wasn't responding to traffic from the 192.168.2.0 subnet, it was sending it out to the web) and it seems things are working. More testing is needed, but this was definitely a problem.