Wednesday, December 13, 2017

SIP issue with Sonicwall - Sanity check?

First time ever requesting advice here, mostly lurk. Just looking for port/session behavior clarification.

I'm working on a VOIP issue whereby user A makes a call, then completes the call/hangs up. If they pick up the phone to make another call within ~10 seconds of hanging up, they can dial but get dead air before the line goes dead after bout 30 seconds.

From a packet side of things, a successful call seems to look like:

  • Device handling SIP trunk at client site sends SIP invite with a destination of the public ip of voip provider.
  • Sonicwall takes it, NAT's it so that the source IP is the sonicwall's WAN IP and the source port is 53XXX, destination port 5060
  • All sip communication for the call from that point on uses source and destination ports of 5060, until the session ends.

If we pick up the phone and try to dial out in the next 10 seconds, the only difference I can see is that the sonicwall no longer gives the first SIP invite a dynamic source port. it continues to use 5060/5060 as if the previous session didn't end. The SIP device on the clients end continues trying to send invites for about 30 seconds and gives up.

If we wait over 10 seconds, we can usually make a call with the same success behavior.

I'll be very frank, I'm a mid-tier MSP tech trying to figure this out on my own on principle at the moment. Just trying to see if I'm missing something about SIP/NAT behavior.

Weirder still is that the VOIP provider claims they would rather have every packet use 5060/5060. I can force that, so that no invites or sip packets ever get a dynamic port/mapping, but then no calls can be made at all.



No comments:

Post a Comment