Recently I had an issue with a couple of SIP trunks configured on an LG IPECs system when the WAN IP Address Changes.
TL;DR Version – I was getting a SIP2.0 502 Bad Gateway Error, turns out that the SIP provider (sip.iboss.com.au) had a setting that restricted the IP address that was being used to initiate the connection.

Basic Setup:
Router -> Switch <- IPECS The switch is a Cisco POE managed switch, with Voice Traffic on a VLAN. All the IPECS phones connect to the switch. The IPECS unit and the Router also connect into the switch. SIP trunks were setup on 2x of the CO lines. I was swapping the router from ADSL to NBN (vDSL). How to begin to troubleshoot the VoIP Connection issue. When I switched the router over (NBN), and tried dialling out on the phone they would say something like "Normal Call Clearing", and not ring. Yet, when I switched back to the original router (ADSL), it would work as normal. A lot of Googling suggested using Wireshark to inspect. How to start to troubleshoot VoIP Issues with Wireshark: Step 1) Install Wireshark on a machine Step 2) On one of the Switch ports, enable 'Mirror Mode'. On the Cisco web UI this was under Admin > Diagnostics > Port Mirroring. – Note: because VLANS were in use, I needed to mirror a VLAN, but first I had to remove the port from the VLAN, then choose that VLAN in the Port Mirroring Setup.
Step 3) Fire up Wireshark, choose the LAN connection that is connected to the Mirrored port and start the capture.

It’s always nice to see what something looks like when it ‘works’, so I first setup the ADSL router, hooked up wireshark and started the capture, I tried calling my mobile and answered it, then hung up, then stopped the capture.
Then in Wireshark you can click on ‘Telephony’ in the top menu and select SIP and will show you the connection, then click on ‘Prepare Filter’ and it will limit the main screen down to the packets that were involved in the phone call. Pretty Cool.
Closing the Telephony screen, if you right click on the first packet in the list (The Info column should say something like “Request: INVITE sip…….”), go down to Follow, then UDP Stream and a somewhat human-readable stream appears. I copied that screen out into Text File (notepad, notepad++, etc) for use later.

I then swapped over the router, did the same process as above and copied the new flow of data into another Text File.
I then compared the two files side by side using WinMerge.

The first part, looks ok. It’s natural that the IDs would change between calls.

Scroll down a bit and o dear, here is where we hit a problem.

From there it a was a case of trying various configurations. I swapped around routers (SIP ALG causes all sorts of issues with SIP lines), I tired 4G connections, finally I rang the VoIP provider – who last week told me that there wasn’t any IP address security restrictions – I was informed (I think by asking the right question and being blunt – “Are the VoIP Trunks tied to an IP Address?”) that yes they could change the configuration for me.

Side note: To make things a little easier in the testing, I copied the config from the iPECS into a Free Open Source Softphone – MicroSIP. I also had a secondary SIP account to test with a completely different provider, so my test process went something like this:
Bring up WAN connection on Router:
– Bring up Working secondary SIP account – call mobile. – Call connects and works. Router is working OK.
– Bring up Primary SIP account – call mobile. – Call works / fails.
– Change something (firewall rule, WAN connection, entire router)
– Repeat process.

By doing it this way, I have a ‘known’ test (Secondary SIP Account) that I can try, before trying the ‘unknown’ (Primary SIP Account)

Secondary Side Note: The LG iPECS has a field for “Firewall IP Address”, I believe that this is better described as “WAN IP Address”. It’s changed under ‘System&Device IP’ PGM 102 / PGM 103. It appears to use this in the SIP packets. I updated this before doing my WAN testing. Interestly, even with it set to the ‘Wrong’ IP address, things still worked?

Safe to say, I’m currently hating knowing this much about VoIP packets right about now…