So I had a weird one recently that I had been troubleshooting for ages, a previously working paging unit was reconfigured to use a new IP address and would no longer register to the Sonus SBC2000.
All the obvious things were checked…
- Sip Server table had been updated
- Federated IP/FQDN for the Signalling Group had been updated
- 5060:TCP connectivity had been verified between both ends
- The registration table was cleared and the SBC restarted
So I fired up LX and jumped in to find the SBC is throwing logs for Incomplete Message SIP messages
We then started to think as the network had changed that there was perhaps a SIP Helper or ALG mangling the packets.
Typically these are designed to help with more complex networks but are sometimes written by someone who has never seen a SIP packet in their life, or introduce massive security holes (I’m looking at you Watchguard!) So I usually turn them off.
After checking a few key routers and switches along the path it was obvious this customer didn’t have ALG’s or SIP helpers enabled and we were stuck back at square one.
So after I do a quick packet capture on the SBC (Sonus SBC 2000’s have internal storage for packet captures) and open the .pcap in Wireshark I’m greeted with this.
So we can see that the SBC is getting a REGISTER packet and it is replying.
But if we inspect the packet..
We can see that the SBC is in fact rejecting the REGISTER with 423 Interval Too Brief… not the Incomplete Message as indicated by the LX logs.
The SIP protocol itself tells us a lot about what’s wrong here and gives us clues on how to fix it. If we look in the rest of the response we can see that the Min-Expires is 600 (seconds) and if we look at our REGISTER packet we see..
I’m trying to register with an expires attribute (Registration Timeout) of 360 seconds. Well below the minimum of 600 Seconds defined in the SBC.
A quick change of the devices registration settings to set the registration expiry to 10 minutes and boom. We’re working.
So why did a simple network change cause this? The only theory we can come up with is that when the network engineer changed the IP their autofill may have changed it to 360 or it was changed by another engineer trying to troubleshoot another issue..
A simple issue that took far too long to resolve thanks to a dodgy error message. Which I’ll be sure to poke someone at Ribbon about 🙂 I just hope this helps someone else so they don’t spend as much time chasing it down.
Now excuse me, I have to write an email about a stupid error message.