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 1.2.3.4:110900;branch=z9hG4bKabcdef...
ERROR:core:parse_via: parsed so far:<SIP/2.0/UDP 1.2.3.4: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 appended zero.

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 1.2.3.4:11090.

But it didn't say 192.168.1.33:5060, it said 192.168.2.201:5060! So, 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 still does 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.

opensips log