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.
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.
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.
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.
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!
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...