On Wed, 2009-01-28 at 09:16 +0100, Rene Pankratz wrote: > Hello, > we want to use a Aastra SIP-DECT (SW-Version=1.1.4) station for our > portable DECT devices. > The devices are already able to place calls, but are unable to register > with SipX. > > The user and the password settings are okay. A snom360 registers fine > with these settings. I compared the SIP flow of both devices an the only > difference i can see is that the Aastra SIP-DECT doesn't send its own > SIP port. But that should not be a problem as it uses the standard port > 5060 for sip. > > I attached the Register-SIP-flow to this message (but replaced our > domain)...
Please don't include trace data in text - attach the file (the list passes attachments just fine); and sipXecs logs are easier than pcap files. The problem is that the phone is changing the From tag value when it resends with authentication. > Request-Line: REGISTER sip:voip.domain.de SIP/2.0 > Via: SIP/2.0/UDP 172.17.99.200;branch=z9hG4bK-11170237293d9 > Route: <sip:voip.domain.de;lr> > From: "David Bollati" <sip:[email protected]>;tag=f-ea607fae2a2f > Request-Line: REGISTER sip:voip.domain.de SIP/2.0 > Via: SIP/2.0/UDP 172.17.99.200;branch=z9hG4bK-4e2012b6432f > Route: <sip:voip.domain.de;lr> > From: "David Bollati" <sip:[email protected]>;tag=f-271048aff64a The nonce values used by sipXecs are keyed to the call, so the call-id and from tag values must not change. RFC 3261 section 8.1.1.4 Call-ID: ... Note that when requests are retried after certain failure responses that solicit an amendment to a request (for example, a challenge for authentication), these retried requests are not considered new requests, and therefore do not need new Call-ID header fields; see Section 8.1.3.5. and then section 8.1.3.5 Processing 4xx Responses: Certain 4xx response codes require specific UA processing, independent of the method. If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is received, the UAC SHOULD follow the authorization procedures of Section 22.2 and Section 22.3 to retry the request with credentials. [...] 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. Note that RFC 2119 defines SHOULD: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
