Buggy NAT Behaviour 7960 POS3-08-8-00 SIP Fimrware

Unanswered Question
Oct 17th, 2007

Hi,

I work for a service provider and have been looking into a problem with a 7960 phone that has recently been upgraded to the POS3-08-8-00 SIP firmware.

The problem is that the rules being applied to match incoming requests result in a lot of valid requests being rejected. In one phone's case the INVITEs are rejected with a 404. In another case the INVITEs are accepted but subsequent CANCELs and BYEs are rejected with a 404.

The problem only occurs when the phone is placed behind a NAT. It appears that the new firmware requires the request to arrive with the control port used by the phone in the request URI otherwise it rejects it. The rejection debug messages are along the lines of:

Unknown address in Request URI

Port Mismatch(UDP), URL Port: 60382, Port Used: 5060

sipSPICheckRequest: Request URI Not Found

SIPTaskProcessSIPMessage: Error: sipSPICheckRequest() returned error.

Following which a 404 Not Found response is sent.

I suspect that if the incoming request URI arrived at the phone with the control port it would be accepted. However that is going to be impossible in a lot of cases where the port will get changed by NAT or an ALG.

This behaviours seems to be a new problem and a number of older firmwares tried do not exhibit. Also different devices such as a Polycom IP500, Xten softphone, Netgear TA612V are all working ok behind the same NAPT the 7960 has problems with.

Has anybody else encountered this behaviour or know of a configuration option that can make the URI matching in incoming requests less aggressive? I've tried all the combinations of: nat_enable, nat_address and nat_received_processing to no avail.

Regards,

Aaron

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
AJAZ NAWAZ Wed, 10/17/2007 - 22:55

If it helps. I am using 8.8 and public SIP provider. My 7960g is sitting behind a NAT firewall and is finally working. But, it took me soooo long to sort it out. Have you made or been able to receive any successful calls?. Furthermore, my SIP provider is not renowned for it's interoperability with Cisco IP phones.

Ajaz

arclauson Thu, 10/18/2007 - 00:43

Hi Ajaz,

In this case I am the public SIP provider and generally we haven't had too many problems with the 7960's in the past.

With my own phone I can make and receive calls but I can't CANCEL or BYE a call unless it's done from the Cisco. In one of my user's case he can make outgoing calls but can't receive incoming, his incoming calls get rejected with a 404.

Regards,

Aaron

AJAZ NAWAZ Thu, 10/18/2007 - 02:04

In my case I found that tweaking UPnP and allowing NNTP provided the stability and reliability. This was done on the FW of course.

There are so many posts with regards to this topic on most Internet SIP forums as you probably already know. It's normally the CPE device causing the issue (NAT Firewall router). Another change I made was to place the phone within a DMZ. The NAT device or router needs to be SIP aware or allow all the necessary SIP protocols to pass through.

I appreciate it may not be related but hopefully this may help others who are going down the same path.

The point you can take from my post is that I am using SIP 8.8 with NAT device, and am not being affected by any SW defect (Bug), and indeed has been running just fine for over a month.

best regards & all the best

Ajaz

arclauson Thu, 10/18/2007 - 02:16

On my own router disabling UPnP didn't help as it seems to have an Application Layer Gateway inbuilt to "helpfully" adjust SIP private addresses. These ALG's are a real pain and there's normally no way to turn them off.

However that's not the real problem here. The 7960 should not be matching on the host portion of the URI it should be matching on the user portion only. Incidentally we have had similar problems in the past with the Nokia SIP stack. With NAPT's and ALG's being so prevalent these days it's often a miracle just to be able to get the SIP packet to the device in the first place. To have to get it there with a specific socket address in the URI it can be nigh on impossible!

Regards,

Aaron

Actions

This Discussion