Robbie Cannings

Grandstream SIP error across multiple sites

Robbie Cannings -

I recently came across a Grandstream bug which caused major issues establishing SIP sessions between a remote site (over VPN) and the PBX.

Synopsis

A network exists between two locations (192.168.0.0/24 - Home, and 192.168.1.0/24 - Warehouse). These two locations are connected via a VPN ("Gateway to Gateway" Cisco RV042G VPN).

The Home end of the network is a Cable Internet connection, 100Mbps down and 1.5Mbps up

The Warehouse end of the connection is ADSL2+, 4Mbps down and 0.5Mbps up.

All devices have direct access to each other via the VPN (i.e. we can ping from any device in 192.168.0.0/24 to any device in 192.168.1.0/24, plus establish other socket connections such as HTTP etc), there is no NAT in place for these sessions.

A GransStream UCM6104 is situated at the Home location (192.168.0.5).

For about 18 months, IP telephony between the two sites was reliable.

The problem

Telephone calls involving the Warehouse end (the "remote end" - not where the GrandStream PBX is located) suddenly stopped working correctly. An outgoing telephone call could be established, however no audio was heard on either end of the connection, and after approximately 35 seconds the call was terminated (presumably by the PBX). This behaviour was observed for both external calls, as well as calls from one internal SIP client (at Home) to another SIP client (at the warehouse).

Troubleshooting steps

We performed the following without any success

  • Replacement of Cisco RV042G Gateway devices
  • Reconfiguration of VPN settings (in case anything needed to be tuned)
  • Replacement of the GrandStream GXV3175 Handset at the remote location
  • Reconfiguration of SIP Extension settings
  • Firmware updates of all devices (Cisco Gateways, Handsets, PBX etc)

Was about to start looking at PCAPs, but found the cause of the fault.

Solution

On the GrandStream web UI, there is a settings tab "SIP Settings" —> "NAT", where the local networks need to be manually defined. I'm not sure if this is a new feature included in recent releases of the (automatically updated) firmware (this would explain why it was working fine then suddenly stopped working without us instigating any changes). The local network (192.168.0.0/24) was included here by default, but the remote network (which does not require NAT) was not included here. As soon as we added it, normal functionality was restored.