While looking through opensips logs of a customer, sometimes we would see the following:
ERROR:core:parse_via: invalid port number <110900> ERROR:core:parse_via: <SIP/2.0/UDP 126.96.36.199:110900;branch=z9hG4bKabcdef... ERROR:core:parse_via: parsed so far:<SIP/2.0/UDP 188.8.131.52:110900;branch=z9hG4bKabcdef... ERROR:core:get_hdr_field: bad via
As you can see, that 6-digit port number is invalid. Furthermore, when sniffing this traffic, we could see that the port number is almost right. The traffic came from port 11090 (one less zero at the end).
Not only the
Via header, the
Contact header too had the extra
The first thought — a broken SIP ALG — was too simple an explanation. It seems implausible that an ALG broken that badly would be allowed to be deployed. Unless it's a spurious error, caused by some extra environmental influence.
Recently I was at someones house and couldn't get a SIP client to register remotely. It turned out that they had this exact same issue. And that gave me a chance to investigate.
The cause, turned out that the issue was a sum of the following:
- Double NAT — a wireless router doing NAT and an ADSL-modem doing NAT.
- ALG in the Zyxel ADSL-modem doing blind replacements of Via and Contact.
- Human readable RFC1918 addresses of different sizes — in my case 192.168.1.33 for the wireless router and 192.168.2.201 for my laptop.
My SIP clients sends out
Via: SIP/2.0/UDP 192.168.2.201:5060;..., the
wireless router doesn't touch it, but changes the source IP to
192.168.1.33, the Zyxel ALG sees the SIP traffic and replaces a
string of length "192.168.1.33:5060" with
But it didn't say
192.168.1.33:5060, it said
the altered SIP packet gets a leftover zero from the original message.
The moral of the story: even though SIP ALGs may come in handy, too often they're not coded correctly. Failing to check the SIP packet for the source IP and simply blindly replacing it, breaks more than it fixes.
P.S. Altering your IP to be the same "size" doesn't fix things. The ALG
Via replacements for replies. You'll receive packets in
which the top-most Via IP is not your own — but the wireless router's —
discouraging SIP clients from accepting these replies.