I'm not sure that is related to your registration issue. Like the xlite, you are manually configuring the phone. Hardware based phones are more prone to manual configuration errors, since they contain more manually entered variables.
Do your preflight tests pass? Does the phone support DNS SRV records? A siptrace file (see the sipviewer entry in the wiki) would be helpful to observe the registration. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: tgrazi...@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: sipx-users-boun...@list.sipfoundry.org <sipx-users-boun...@list.sipfoundry.org> To: 'Justin Menga' <justin.me...@gmail.com>; 'sipx-users@list.sipfoundry.org' <sipx-users@list.sipfoundry.org> Sent: Mon Jan 04 17:27:10 2010 Subject: Re: [sipx-users] Nonce Validation Failures Hi, I seem to be having an error that is possibly because of this as well. I am trying to get a Netcomm V90 IP Phone (http://www.netcomm.com.au/product/voip/v90 ) to register with my SipX Server and I am getting the following errors in the sipregister.log file: "2010-01-04T20:08:17.652139Z":281:SIP:ERR:sipserver.internaldomain.net:SipRegistrarServer:B6CCEB90:SipRegistrar:"SipNonceDB::isNonceValid nonce signature check failed 'e4ff0ca014e6a7c492e14762a9aeb1874b424a9d'" Is there a work around for this or do I chuck the phone out? The phone can register directly with my ITSP no problem and I can use other softphones like X-Lite to register against the SipX Server. Can anyone point me in the right direction? Thanks in advance Grant Lang From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Justin Menga Sent: Thursday, 10 December 2009 1:12 p.m. To: sipx-users@list.sipfoundry.org Subject: [sipx-users] Nonce Validation Failures I've come across interop issues with various SIP UAs and now a commercial SBC (Cisco ASR 1000 Series SBC SP Edition) and SIPXecs, which stems from the SIPXecs use of the "Tag" parameter in the "From" Header for generating nonce values for SIP digest authentication. Basically the position of SIP Foundry is as follows (quoted from http://interop.sipxecs.org/): "The authentication nonces provided by sipX are specific to the from-tag in the request. Section 8.1.3.5 of RFC 3261 requires that a re-sent request has the same from-tag as the original request, so the nonce that sipX returns in a 401/407 response can always be used in a re-send of the request. However, some UAs will incorrectly use a different from-tag when resending a REGISTER. These UAs will not be able to register." This is what Section 8.3.1.5 of RFC actually states: "In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous." The key word above being "SHOULD" - i.e. it is not a requirement but a recommendation. Based upon this being a recommendation, not a requirement, in the interests of greater interoperability for SIPXecs, it would ideal if the developers could provide the capability to configure whether or not nonce validation is based upon the from-tag parameter. Also, a relevant draft IETF report is located at http://ietfreport.isoc.org/all-ids/draft-smith-sipping-auth-examples-01.txt-48149.txt - in here Section 2.3 addresses specifically the issue of interoperability failures related to nonce invalidation, although I'm not sure if SIP registration is considered a dialog-creating request: "2.3 Invalid validation of a nonce It has been observed that some implementations create, and then attempt to validate, nonces based on the contents of the request that has been challenged. This causes implementation problems where the partner does not maintain certain SIP header fields between the original and later, authenticated, request. RFC 3261 does not specify a mechanism for creating a nonce for use in an authentication challenge. An implementation is free to generate a nonce in whichever way it sees fit and may choose to do so such that it may be validated and stale nonces detected to avoid replay attacks. RFC3261 [1] section 8.1.3.5 describes how to act on receipt of a 4XX class response, including 401 and 407 challenges, and states the following: In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. This has been interpreted by some implementations to mean that an authenticated request can be relied upon to always contain the same Call-ID, To and From as the previous request. However this assumption is wrong in the case of dialog creating requests. If an initial dialog creating request fails, the dialog has ended. Reusing the same Call-ID and From tag appears to indicate that the dialog is expected to still exist. It does not and thus reuse of the same Call-ID and From tag should not be assumed. Nonces SHOULD NOT be generated based on information such as the Call- ID and tags unless a dialog has successfully been established and the request is therefore in-dialog." Any thoughts? Even better, any ideas on example modifications to current source code to enable me to get interoperability working in my environment? Regards Justin _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/