That error is symptomatic of the issue - you really need to run a network trace or use SIP Viewer and examine the registration sequence. Normally the first REGISTER sent by the UA does not include an authentication header, and SIPXecs responds with a 407 Response. The UA should then attach an authentication header on the next REGISTER. All things going well, SIPXecs will send back a 200 OK.
What you need to compare is the tag parameter that is present in the From header on the first REGISTER and second REGISTER messages described above. If the tag value changes, this causes nonce validation to fail. On Tue, Jan 5, 2010 at 11:27 AM, Grant Lang <grant.l...@amplussolutions.com>wrote: > 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/
