Oh ok, sorry. The next post i won't paste traces and follow your advice. But thank you very much for the great explanation of the problem with the register. Although I cannot see a solution for this problem right now. I think I will try to use a newer Firmware for the Aastra DECT station if possible.
René > 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
