Hallo,
mit der 9.24.0266 registrieren sich meine LANCOMs mit Kabel-Deutschland-SIP-Leitungen nicht mehr. Mit der 9.24.0252 war noch alles ok. Als Zwischenversion habe ich nur die 9.24.0261-RU5 gefunden, mit der geht es auch nicht.
In den Release-Notes stehen keine Änderungen drin, die das Verhalten erklären können. Anscheinend wurde jedoch das Verhalten beim REGISTER geändert. Es wird jetzt nicht mehr, wie zuvor, erst mal ohne Authentifizierung probiert, sondern gleich mit. Dabei passiert anscheinend der Fehler, dass das "opaque" vergessen wird, mit anzugeben. Und das mag der SIP-Server wohl nicht...
So sah es bisher aus:
Code: Alles auswählen
[SIP-Packet] 2017/06/24 16:42:41,630 [PACKET] :
Sending datagram with length 566 from 31.16.16.16:12294 to 83.169.182.113:5060 using UDP
REGISTER sip:reg141.kabelphone.de SIP/2.0\r\n
Via: SIP/2.0/UDP 31.16.16.16:12294;branch=z9hG4bK-20d88f01-be79df7c\r\n
From: <sip:3022334455@reg141.kabelphone.de>;tag=-1948117760--116403184\r\n
To: <sip:3022334455@reg141.kabelphone.de>\r\n
Call-ID: 3022334455-reg141.kabelphone.de-ad208ddc@00a0572e968d\r\n
CSeq: 3 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: <sip:3022334455@31.16.16.16:12294;transport=UDP>\r\n
Expires: 480\r\n
User-Agent: LANCOM 1781EW / 9.24.0252 / 18.05.2017\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2017/06/24 16:42:41,662 [PACKET] :
Receiving datagram with length 480 from 83.169.182.113:5060 to 31.16.16.16:12294 using UDP
SIP/2.0 401 Unauthorized\r\n
Via: SIP/2.0/UDP 31.16.16.16:12294;branch=z9hG4bK-20d88f01-be79df7c\r\n
From: <sip:3022334455@reg141.kabelphone.de>;tag=-1948117760--116403184\r\n
To: <sip:3022334455@reg141.kabelphone.de>;tag=SDi6fs599-c8d8b67f+1+37920029+f8345731\r\n
Call-ID: 3022334455-reg141.kabelphone.de-ad208ddc@00a0572e968d\r\n
CSeq: 3 REGISTER\r\n
WWW-Authenticate: Digest realm="b-grad-safaricms-1.kabel-bb.de",nonce="84ddd05f9e69145a061b3bd7bc710927",opaque="DEADBEEF"\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2017/06/24 16:42:41,664 [PACKET] :
Sending datagram with length 804 from 31.16.16.16:12294 to 83.169.182.113:5060 using UDP
REGISTER sip:reg141.kabelphone.de SIP/2.0\r\n
Via: SIP/2.0/UDP 31.16.16.16:12294;branch=z9hG4bK-956e7ac2-b7d0d881\r\n
From: <sip:3022334455@reg141.kabelphone.de>;tag=-1948117760--116403184\r\n
To: <sip:3022334455@reg141.kabelphone.de>\r\n
Call-ID: 3022334455-reg141.kabelphone.de-ad208ddc@00a0572e968d\r\n
CSeq: 4 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: <sip:3022334455@31.16.16.16:12294;transport=UDP>\r\n
Expires: 480\r\n
User-Agent: LANCOM 1781EW / 9.24.0252 / 18.05.2017\r\n
Authorization: Digest username="3022334455", realm="b-grad-safaricms-1.kabel-bb.de", algorithm=MD5, uri="sip:reg141.kabelphone.de", nonce="84ddd05f9e69145a061b3bd7bc710927", opaque="DEADBEEF", response="e9ef0f19599a98db710057a00490dc37"\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2017/06/24 16:42:41,695 [PACKET] :
Receiving datagram with length 418 from 83.169.182.113:5060 to 31.16.16.16:12294 using UDP
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 31.16.16.16:12294;branch=z9hG4bK-956e7ac2-b7d0d881\r\n
From: <sip:3022334455@reg141.kabelphone.de>;tag=-1948117760--116403184\r\n
To: <sip:3022334455@reg141.kabelphone.de>;tag=SDi6fs599-c8d8b67f+1+37920029+f9bace39\r\n
Call-ID: 3022334455-reg141.kabelphone.de-ad208ddc@00a0572e968d\r\n
CSeq: 4 REGISTER\r\n
Content-Length: 0\r\n
Contact: <sip:3022334455@31.16.16.16:12294;transport=UDP>;expires=3600\r\n
\r\n
Code: Alles auswählen
[SIP-Packet] 2017/06/24 16:40:18,370 [PACKET] :
Sending datagram with length 784 from 31.16.16.16:12294 to 83.169.182.113:5060 using UDP
REGISTER sip:reg141.kabelphone.de SIP/2.0\r\n
Via: SIP/2.0/UDP 31.16.16.16:12294;branch=z9hG4bK-71686b8f-144a0783\r\n
From: <sip:3022334455@reg141.kabelphone.de>;tag=869458404--1772611671\r\n
To: <sip:3022334455@reg141.kabelphone.de>\r\n
Call-ID: 3022334455-reg141.kabelphone.de-8896d020@00a0572e968d\r\n
CSeq: 3 REGISTER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, REFER, NOTIFY, OPTIONS, PRACK, UPDATE, SUBSCRIBE\r\n
Max-Forwards: 70\r\n
Contact: <sip:3022334455@31.16.16.16:12294;transport=UDP>\r\n
Expires: 480\r\n
User-Agent: LANCOM 1781EW / 9.24.0261 / 09.06.2017\r\n
Authorization: Digest username="3022334455", realm="b-grad-safaricms-1.kabel-bb.de", algorithm=MD5, uri="sip:reg141.kabelphone.de", nonce="323ec190b346384982f492c49f479492", response="5b0bf3a2bad3e92aeee1e825031918dc"\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2017/06/24 16:40:18,405 [PACKET] :
Receiving datagram with length 354 from 83.169.182.113:5060 to 31.16.16.16:12294 using UDP
SIP/2.0 400 Bad Request\r\n
Via: SIP/2.0/UDP 31.16.16.16:12294;branch=z9hG4bK-71686b8f-144a0783\r\n
From: <sip:3022334455@reg141.kabelphone.de>;tag=869458404--1772611671\r\n
To: <sip:3022334455@reg141.kabelphone.de>;tag=SDtr3m299-c8d8b67f+1+be7d0024+a01844ad\r\n
Call-ID: 3022334455-reg141.kabelphone.de-8896d020@00a0572e968d\r\n
CSeq: 3 REGISTER\r\n
Content-Length: 0\r\n
\r\n
Quelle: https://www.ietf.org/mail-archive/web/s ... 20292.htmlThe server can put anything it wants to into the value.
The client MUST just return that value if present in the
Authorization header.
RFC-2617 says:
Because the client is required to return the value of the opaque
directive given to it by the server for the duration of a session,
the opaque data may be used to transport authentication session state
information.
RFC-2617 also says:
Note that any such use can also be accomplished more
easily and safely by including the state in the nonce.
which was a nicer way of saying 'opaque is pointless and insecure'
because the opaque value is not protected by the response hash, it can
be replayed by an attacker. If you're implementing a server, it is best
not to include it. If you're implementing a client, just send it back
and ignore it.
Der SIP-Server von Kabel Deutschland findet nach einer authorisierten Registrierung eine unauthorisierte übrigens eine zeitlang auch ok, so habe ich das bei anderen SIP-Servern auch schon gesehen. (Natürlich unter der Voraussetzung, dass sich die IP-Adresse und sowas nicht geändert hat und auch nicht zu viel Zeit vergangen ist.)
Nach dem Bad Request kommt der LANCOM-Router übrigens nicht einmal auf die Idee, es mal mit einem normalen REGISTER (unauthorisiert) zu probieren, er schickt nach Schema F immer das gleiche Paket.
Vielen Dank und viele Grüße,
Jirka
P.S.: Falls hier bei jemandem die Frage aufkommt, woher der VCM denn die Authorization-Daten hat, die er in der RU5 oben beim REGISTER angibt: Na ja, vor dem ersten REGISTER macht der LANCOM-Router ja immer ein DE-REGISTER, und das macht er erst mal ohne Authorization, weil da hat er noch nichts. Die merkt er sich dann (wobei er eben das opaque vergisst) und versucht dann das REGISTER eben gleich mit Authorization.