VoIP: Linksys SPA2102: Keine Registrierung mehr bei Telekom

[oliaros]

Hallo allerseits,

seit dem dem 05.04.22 registriert sich mein analoger Telefonadapter SPA2102 nicht mehr. Die Fehlermeldung ist: Registraion failed.

Bei der Konfiguration von Router/ATA habe ich nichts geändert, Nachfrage bei der Telekom-Hotline nach Veränderung um den 05.04.22 hat nichts ergeben. Anmeldung erfolgt per SRV-Record, als DNS sind 8.8.8.8 und 1.1.1.1 eingetragen.

Hier gings noch (Auzug aus dem log):

Mar 22 06:37:02 spa2102-2 Addr Change(0) d9001c21:5060->d9001502:5060
Mar 22 06:37:05 spa2102-2 last message buffered 3 times
Mar 22 09:30:29 spa2102-2 RTPMAP 101 --> 136
Mar 22 09:30:29 spa2102-2 RTPMAP 101 --> 136
Mar 22 09:30:29 spa2102-2 [0:0]AUD ALLOC CALL (port=16602)
Mar 22 09:30:29 spa2102-2 [0:0]RTP Rx Up
Mar 22 09:30:32 spa2102-2 [URL='https://www.ip-phone-forum.de/CID%3AOnHookTx']CID:OnHookTx[/URL] Pol
Mar 22 09:30:32 spa2102-2 DTMF/FSK
Mar 22 09:30:32 spa2102-2 [URL='https://www.ip-phone-forum.de/CID%3ADONE']CID:DONE[/URL]
Mar 22 09:30:53 spa2102-2 CC:Connected
Mar 22 09:30:53 spa2102-2 [0:0]ENC INIT 8
Mar 22 09:30:53 spa2102-2 [0:0]RTP Tx Up (pt=8->d90005b4:22948)
Mar 22 09:30:53 spa2102-2 [0:0]RTCP Tx Up
Mar 22 09:30:53 spa2102-2 [0:0]RTP Rx 1st PKT @16602(2)
Mar 22 09:30:54 spa2102-2 [0:0]DEC INIT 8
Mar 22 09:31:10 spa2102-2 [0:0]LAT-- 7(2)
Mar 22 09:31:18 spa2102-2 [0:0]LAT-- 6(2)
Mar 22 09:31:26 spa2102-2 [0:0]LAT-- 5(2)
Mar 22 09:31:34 spa2102-2 [0:0]LAT-- 4(2)
Mar 22 09:31:42 spa2102-2 [0:0]LAT-- 3(2)
Mar 22 09:32:18 spa2102-2 [0:0]LAT-- 3(2)
Mar 22 09:32:34 spa2102-2 [0:0]LAT++ 4(2)
Mar 22 09:32:51 spa2102-2 CC:Ended
Mar 22 09:32:51 spa2102-2 [0:0]AUD Rel Call
Mar 22 09:33:23 spa2102-2 Terminated 287144
Mar 22 09:33:23 spa2102-2 Terminated
Mar 22 09:33:24 spa2102-2 CC:Clean Up
Mar 22 09:33:24 spa2102-2 OBJ POOL STAT ---
Mar 22 09:33:24 spa2102-2 OP:RTPRXB = 96 ( 96 192)
Mar 22 09:33:24 spa2102-2 OP:RTPREB = 40 ( 40 48)
Mar 22 09:33:24 spa2102-2 OP:RTPTXB = 64 ( 64 108)
Mar 22 09:33:24 spa2102-2 OP:TIMEOU = 102 (120 52)
Mar 22 09:33:24 spa2102-2 OP:SIPCOR = 0 ( 1 28)
Mar 22 09:33:25 spa2102-2 OP:SIPCTS = 30 ( 32 588)
Mar 22 09:33:25 spa2102-2 OP:SIPSTS = 32 ( 32 6064)
Mar 22 09:33:25 spa2102-2 OP:SIPAUS = 0 ( 8 588)
Mar 22 09:33:25 spa2102-2 OP:SIPDLG = 10 ( 10 148)
Mar 22 09:33:25 spa2102-2 OP:SIPSES = 12 ( 12 8456)
Mar 22 09:33:25 spa2102-2 OP:SIPREG = 0 ( 4 468)
Mar 22 09:33:25 spa2102-2 OP:SIPLIN = 0 ( 2 140)
Mar 22 09:33:25 spa2102-2 OP:SUBDLG = 2 ( 2 6444)
Mar 22 09:33:25 spa2102-2 OP:STUNTS = 16 ( 16 68)

Hier geht' s nicht mehr:

Apr 5 21:04:44 spa2102-2 RSE:GetServerAddrErr(tel.t-online.de,1)=-101
Apr 5 21:04:44 spa2102-2 Addr Change(0) d9001c21:5060->0:5060
Apr 5 21:04:44 spa2102-2 last message buffered 1 times
Apr 5 21:04:44 spa2102-2 TP:?Tx->0
Apr 5 21:04:44 spa2102-2 [0]SIP:ICMP Error 0 (0:5060, 3)
Apr 5 21:04:44 spa2102-2 RSE:GetServerAddrErr(tel.t-online.de,1)=-101
Apr 5 21:04:44 spa2102-2 Addr Change(0) d9001c21:5060->0:5060
Apr 5 21:04:44 spa2102-2 last message buffered 1 times
Apr 5 21:04:44 spa2102-2 TP:?Tx->0
Apr 5 21:04:44 spa2102-2 [0]SIP:ICMP Error 0 (0:5060, 3)

Die Abfrage SRV-Abfrage lierfert folgendes:

[root@eisfair /]# dig _sip._udp.tel.t-online.de SRV

; <<>> DiG 9.16.20 <<>> _sip._udp.tel.t-online.de SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2047
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_sip._udp.tel.t-online.de.     IN      SRV

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 1335 IN      SRV     20 0 5060 h2-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 1335 IN      SRV     10 0 5060 hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 1335 IN      SRV     30 0 5060 d-epp-110.edns.t-ipnet.de.

;; Query time: 7 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Mon Apr 11 10:47:42 CEST 2022
;; MSG SIZE  rcvd: 205

Was kann ich machen? Hat jemand eine Idee? Danke für die Unterstützung,

Gruss
oliaros

[CODE] TAGs [/CODE] gestezt by stoney

 

[sonyKatze]

Telekom Deutschland hat in den letzten Wochen viel geändert. Lauter Kleinigkeiten, die dann je nach Konfiguration fatal sein können. Daher könnte das alles Unmögliche sein. Ideal wäre, Du könntest die SIP-Nachrichten mitschneiden. Einige SPAs haben so einen Menüpunkt. Deiner scheinbar nicht, jedenfalls finde ich es auf die Schnelle nicht. Welche Router bzw. Firewall nutzt Du? Vielleicht kann der/die das. Ansonsten ein konfigurierbarer Switch mit Port-Mirroring (Liste).

als DNS sind 8.8.8.8 und 1.1.1.1

Reine Neugierde: Warum nicht die Telekom eigenen bzw. die Deines Interne-Anbieters?

 

[oliaros]

Hallo,
danke für die Nachricht. Hier läuft ein fli4l hinter einem Zyxxel als Modem. Ich habe auf dem Router mit tcpdump Sequenzen mitgeschnitten und mittels Wireshark untersucht. War (für mich) nichts erhellendes dabei, ausser das auth nicht funktioniert.
Zu den DNS: Ich meine irgendwo gelesen zu haben, das diese Server beim connect keine Probleme machen sollen.
Mit dig erreicht man die sip-Server:

[root@eisfair /]# dig _sip._udp.tel.t-online.de SRV

; <<>> DiG 9.16.20 <<>> _sip._udp.tel.t-online.de SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61524
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_sip._udp.tel.t-online.de.     IN      SRV

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 536  IN      SRV     20 0 5060 h2-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 536  IN      SRV     10 0 5060 hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 536  IN      SRV     30 0 5060 d-epp-110.edns.t-ipnet.de.

;; Query time: 3 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Apr 13 15:38:55 CEST 2022
;; MSG SIZE  rcvd: 205

Gruss, oliaros

[CODE] TAGs [/CODE] gestezt by stoney

 

[PeterPawn]

Anmeldung erfolgt per SRV-Record

Angesichts von

Apr 5 21:04:44 spa2102-2 RSE:GetServerAddrErr(tel.t-online.de,1)=-101
Apr 5 21:04:44 spa2102-2 Addr Change(0) d9001c21:5060->0:5060

würde man ja jetzt nicht zwangsläufig auf die Idee kommen, daß die Firmware des Geräts tatsächlich auch nach einem SRV-Record (oder auch NAPTR als "Einstieg") suchen würde - dann würde man ja eher auch ein _sip._udp.tel.t-online.de. als zu suchenden Eintrag erwarten (wenn da tatsächlich beliebige Records gesucht werden (-> any) und nicht spezielle Typen). Um von tel.t-online.de (wie im Log zu sehen) auf _sip._udp.tel.t-online.de zu kommen, müßte da - sofern UDP und SIP nicht "fest" vorgegeben sind - ohnehin erst mal über einen NAPTR-Record nach dem korrekten Namen für den SRV-Record gesucht werden.

Wenn da aber doch nach einem A-Record gesucht wird (IPv4 ist ja anhand der Adresse(n) d9001c21 "gesetzt" - das ist 217.0.28.33), dann GIBT es da seitens der Telekom keine Antwort mehr:

vidar:~ $ dig tel.t-online.de any

; <<>> DiG 9.16.25 <<>> tel.t-online.de any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32087
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7ec9cd2c3ba0de1b010000006256cf9acda365a3f0690e97 (good)
;; QUESTION SECTION:
;tel.t-online.de.               IN      ANY

;; ANSWER SECTION:
tel.t-online.de.        10800   IN      SOA     ns1.edns.t-ipnet.de. hostmaster.t-ipnet.net. 2018022700 43200 1800 1209600 21600
tel.t-online.de.        7200    IN      NAPTR   20 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
tel.t-online.de.        7200    IN      NAPTR   10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
tel.t-online.de.        7200    IN      NAPTR   30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.
tel.t-online.de.        596     IN      NS      ns2.edns.t-ipnet.de.
tel.t-online.de.        596     IN      NS      ns4.edns.t-ipnet.de.
tel.t-online.de.        596     IN      NS      ns6.edns.t-ipnet.de.
tel.t-online.de.        596     IN      NS      ns5.edns.t-ipnet.de.
tel.t-online.de.        596     IN      NS      ns3.edns.t-ipnet.de.
tel.t-online.de.        596     IN      NS      ns1.edns.t-ipnet.de.

;; Query time: 127 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Apr 13 15:26:50 CEST 2022
;; MSG SIZE  rcvd: 417

vidar:~ $

und das würde dann wieder die 0 als Adresse nach dem "change" erklären (auch die weiterhin verwendete Portnummer 5060 KÖNNTE ja über einen SRV-Record geändert werden - das ist "nicht Gesetz", daß der Registrar auf 5060 lauschen muß).

Seitens der Telekom wird da (auch künftig) eher keine Unterstützung mehr zu erwarten sein - die "Rundschreiben", mit denen Kunden auf den Wechsel aufmerksam gemacht wurden, bei denen die Telekom noch das "alte" Verfahren, basierend auf der Auflösung von A-Records, detektieren konnte, sind ja "legendär" und wurden (iirc) mindestens über 18 Monate immer wieder in Umlauf gebracht. Jetzt hat man die A-Records wohl dann tatsächlich deaktiviert - wer bisher nichts unternommen hat und weiterhin danach sucht, greift halt ins Leere.

Als Diagnose-Möglichkeit würde es sich auch hier noch anbieten, erst einmal einen LOKALEN DNS-Server als Resolver für den SPA einzusetzen, dem man dann auch wieder einen oder mehrere (nicht-öffentliche) A-Records für tel.t-online.de unterjubeln kann - die Adressen dafür kann man ja selbst über die passenden NAPTR-Records (hier ja wohl für SIP über UDP, also mit den SRV-Records für _sip._udp.tel.t-online.de.) periodisch neu zusammensuchen (auch automatisiert - ein dig leistet da gute Dienste) und somit auch auf Änderungen seitens der Telekom reagieren.

Irgendwo muß es ja auch noch einen anderen DNS-Resolver geben, denn das dig in #1 und in #3 kriegt seine Antwort ja von der 192.168.0.1 - das wäre ja in jedem Falle schon mal ein ANDERER Resolver, als die wohl im SPA eingetragenen DNS-Server 1.1.1.1 und 8.8.8.8 ... das schränkt die Aussagekraft eines solchen Tests auch ein.

Wenn die 192.168.0.1 dann noch ein fli4l sein soll, dann ist es ja erst recht kein Problem mehr, dem dort laufenden dnsmasq (das sollte der DNS-Server sein, der in der DHCP/DNS-Erweiterung verwendet wird: http://tarball.fli4l.de/3.10/testing/x86_64/dns_dhcp.tar.gz) für ein paar Abfragen entsprechende statische Daten unterzuschieben: https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html (Parameter --host-record) und zum Test/zur Bestätigung reicht ja schon ein einziger aktueller Eintrag (auch bei drei SRV-Records DARF sich der Client ja noch aussuchen, wen er nutzt, denn die Prioritäten sind nur VORSCHLÄGE des Providers).

Natürlich alles unter der Prämisse, daß da tatsächlich auch A-Records abgefragt werden - ich sehe halt keinen "Beweis" dafür, daß der SPA wie angenommen nach SRV-Records suchen würde. Das gezeigte Protokoll spricht - zumindest nach meiner Ansicht - sogar direkt dagegen.

 

[oliaros]

Hallo,
danke für die ausfürliche Antwort. Die Spec des SPA sagt folgendes:

MAC-Adresse (IEEE 802.3)
IPv4 – Internet-Protokoll v4 (RFC 791) mit Aktualisierungsmöglichkeit auf Version 6 (RFC 1883)
ARP – Address Resolution Protocol
DNS – A-Eintrag (RFC 1706), SRV-Eintrag (RFC 2782)
DHCP-Client – Dynamic Host Configuration Protocol (RFC 2131)
DHCP-Server – Dynamic Host Configuration Protocol (RFC 2131)
PPoE-Client – Point to Point Protocol over Ethernet (RFC 2516)
ICMP – Internet Control Message Protocol (RFC 792)
TCP – Transmission Control Protocol (RFC 793)
UDP – User Datagram Protocol (RFC 768)
RTP – Real Time Protocol (RFC 1889) (RFC 1890)
RTCP – Real Time Control Protocol (RFC 1889)
DiffServ (RFC 2475), Type of Service – TOS (RFC 791/1349)
VLAN-Kennzeichnung – 802.1p
SNTP – Simple Network Time Protocol (RFC 2030)
Begrenzung der Übertragungsrate für hochzuladende Daten – statisch und automatisch
QoS – Priorisierung von Sprachpaketen im Gegensatz zu anderen Pakettypen
Betriebsmodi: Router oder Bridge
Kopieren der MAC-Adresse
Port-Weiterleitung

In der config steht "use DNS SRV" sowie "DNS SRV Auto Prefix" auf "yes"

Der 192.168.0.1 ist ein fli4l. Allerdings habe ich in der dns_dhcp.txt keinen -- --host-record Eintrag gefunden. Wie würde ein entsprechender Eintrag aussehen?

Bei dig tel.t-online.de any bekomme ich folgende Antwort:

; <<>> DiG 9.16.20 <<>> tel.t-online.de any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20581
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;tel.t-online.de.               IN      ANY

;; ANSWER SECTION:
tel.t-online.de.        10194   IN      NS      ns1.edns.t-ipnet.de.
tel.t-online.de.        10194   IN      NS      ns2.edns.t-ipnet.de.
tel.t-online.de.        10194   IN      NS      ns3.edns.t-ipnet.de.
tel.t-online.de.        10194   IN      NS      ns4.edns.t-ipnet.de.
tel.t-online.de.        10194   IN      NS      ns5.edns.t-ipnet.de.
tel.t-online.de.        10194   IN      NS      ns6.edns.t-ipnet.de.
tel.t-online.de.        6594    IN      NAPTR   10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
tel.t-online.de.        6594    IN      NAPTR   20 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
tel.t-online.de.        6594    IN      NAPTR   30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.
tel.t-online.de.        10194   IN      SOA     ns1.edns.t-ipnet.de. hostmaster.t-ipnet.net. 2018022700 43200 1800 1209600 21600

;; Query time: 35 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Apr 13 16:40:44 CEST 2022
;; MSG SIZE  rcvd: 387

[CODE] TAGs [/CODE] gestezt by stoney

 

[PeterPawn]

Da fli4l über die Konfiguration des dnsmasq ja noch eigene Variablen legt (iirc), sollte sich auch da eine Option für die Konfiguration einer STATISCHEN IP-Adresse für einen Host finden lassen - ganz dunkel im Hinterkopf habe ich noch etwas, daß da irgendwelche hosts-Files generiert werden können, die dann vom dnsmasq in die Auswertungen einbezogen werden (was der automatisch macht, solange man es ihm nicht über no-hosts (oder so ähnlich) verbietet).

Da würde ich dann doch auf die Webpräsenz von fli4l verweisen - auch wenn's da wohl immer noch kein "Forum" gibt (https://www.fli4l.de/hilfe/newsgruppen-irc-forum/). Wenn es bei dem Erweiterungspaket KEINE Option geben sollte, zusätzliche Parameter für den dnsmasq in dessen "natürlicher Form" anzugeben, dann muß man sich die richtigen Variablen suchen. Gleichzeitig glaube ich aber auch nicht daran, daß Du der erste Benutzer wärst, bei dem die Frage nach dem korrekten Weg für das Konfigurieren einer statischen Auflösung eines DNS-Namens auftaucht - also stehen die Chancen vermutlich SEHR GUT, daß Du im Archiv der dortigen Newsgroups auch zu diesem Thema fündig wirst.

Der in der Spezifikation referenzierte RFC 2782 beschreibt auch nur SRV-Records im Allgemeinen - daraus würde ich jetzt nicht zwingend die Schlußfolgerung ableiten, daß die Adresse (entgegen dem, was im Log steht) mit _sip._udp als Präfix erweitert wird bei der Suche - zumal dann das offensichtliche "nichts gefunden" ja auch nicht mehr zum Ergebnis passen würde, denn das beantwortet auch der Google-Server 8.8.8.8 dann richtig:

vidar:~ $ dig @8.8.8.8 tel.t-online.de any

; <<>> DiG 9.16.25 <<>> @8.8.8.8 tel.t-online.de any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9252
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;tel.t-online.de.               IN      ANY

;; ANSWER SECTION:
tel.t-online.de.        10800   IN      NS      ns1.edns.t-ipnet.de.
tel.t-online.de.        10800   IN      NS      ns2.edns.t-ipnet.de.
tel.t-online.de.        10800   IN      NS      ns3.edns.t-ipnet.de.
tel.t-online.de.        10800   IN      NS      ns4.edns.t-ipnet.de.
tel.t-online.de.        10800   IN      NS      ns5.edns.t-ipnet.de.
tel.t-online.de.        10800   IN      NS      ns6.edns.t-ipnet.de.
tel.t-online.de.        7200    IN      NAPTR   10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
tel.t-online.de.        7200    IN      NAPTR   20 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
tel.t-online.de.        7200    IN      NAPTR   30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.
tel.t-online.de.        10800   IN      SOA     ns1.edns.t-ipnet.de. hostmaster.t-ipnet.net. 2018022700 43200 1800 1209600 21600

;; Query time: 75 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Apr 13 17:32:54 CEST 2022
;; MSG SIZE  rcvd: 387
vidar:~ $

Vielleicht funktioniert die Suche nach der passenden IP-Adresse ja tatsächlich, wenn Du den Präfix selbst angibst ... nur würde ich davon eher negative Auswirkungen auf den Inhalt der SIP-Messages und der SIP-URIs, an die diese gesendet werden, erwarten. Jedenfalls wird kein DNS-Server auf die Abfrage tel.t-online.de mit einem SRV-Record antworten, der auf _sip._udp.tel.t-online.de lautet.

Was aber auch noch sein KÖNNTE, ist das "selbst die Beine weghauen" durch die Verwendung von 1.1.1.1 - denn der verweist dann (zumindest bei mir) einfach auf den SOA-Record für die Domain, wenn man ihn nach A- oder SRV-Records explizit befragt:

vidar:~ $ dig @1.1.1.1 tel.t-online.de a

; <<>> DiG 9.16.25 <<>> @1.1.1.1 tel.t-online.de a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50423
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;tel.t-online.de.               IN      A

;; AUTHORITY SECTION:
tel.t-online.de.        9901    IN      SOA     ns1.edns.t-ipnet.de. hostmaster.t-ipnet.net. 2018022700 43200 1800 1209600 21600

;; Query time: 23 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Apr 13 17:36:52 CEST 2022
;; MSG SIZE  rcvd: 119

vidar:~ $ dig @1.1.1.1 tel.t-online.de srv

; <<>> DiG 9.16.25 <<>> @1.1.1.1 tel.t-online.de srv
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40366
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;tel.t-online.de.               IN      SRV

;; AUTHORITY SECTION:
tel.t-online.de.        10764   IN      SOA     ns1.edns.t-ipnet.de. hostmaster.t-ipnet.net. 2018022700 43200 1800 1209600 21600

;; Query time: 15 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Apr 13 17:36:55 CEST 2022
;; MSG SIZE  rcvd: 119

vidar:~ $

(EDIT: Er macht also offensichtlich KEINE rekursiven Abfragen.)

Da das eigentlich keine "negativen" Antworten sind, gibt es (wenn man's falsch macht) auch keinen Grund, einen weiteren Server zu befragen - man hat dann halt keine Adresse. Paßt dann zwar nicht zu meinem Verständnis des Protokolls, aber kann natürlich ebenso gut sein - nirgendwo steht, daß ein Log auch aussagekräftig sein MUSS.

Vielleicht stellst Du ja doch mal als Allererstes Deinen Router als DNS-Server ein im SPA - spätestens wenn Du statische Einträge erzeugen willst, mußt Du das ohnehin tun.

 

[sonyKatze]

mitgeschnitten und mittels Wireshark untersucht […] ausser das auth nicht funktioniert

Kannst Du mir das in einer privaten Nachricht (über einen File-Hoster, weil wir hier nichts anhängen können) zukommen lassen? Wenn nicht, ein Beispiel findest Du hier. Die Frage ist, ob das zweite REGISTER gesendet wird. Und wenn ja, ob die Telekom irgendeine Status-Beschreibung im SIP selbst schreibt. Neuerdings steht da irgendwas von CC … IMS … und so weiter. Den bräuchte ich. Wenn bereits das erste REGISTER abgelehnt wird, mit welchem Status-Code und Beschreibung(en)?

Ich meine irgendwo gelesen zu haben, das diese Server beim connect keine Probleme machen sollen.

Ja, so in etwa. Für uns reiht es. Die Frage war, warum überhaupt andere.
Übrigens: Wenn das REGISTER beantwortet wird, bist Du über DNS schon erfolgreich hinaus.

 

[sonyKatze]

Wenn bereits das erste REGISTER abgelehnt wird, mit welchem Status-Code und Beschreibung(en)?

Siehe Cross-Post im Forum Telekom-Hilft … CC_SIP_UNAUTHORIZED_401

Ich konnte den Fehler mit meinem Tisch-Telefon Cisco 7821 (MPP) nachstellen. In der Web-Oberfläche steht unter „Info → Debug Info → messages.0“ danach „voice-TP Parser error: 15“. Das Telefon macht nicht weiter, es schickt im nächsten REGISTER einfach den Header Authorization nicht. Die Ursache ist ein zu langes „Tag“ im Header To. Ich habe das mal mittels SIPp nachgebaut. Reduziere ich dieses Tag auf etwa 80 Zeichen, akzeptiert dies Cisco. Alles was länger ist, führt zu einem Parser-Error.

Ich sehe hier keine Möglichkeit, dass Du das als Endnutzer ändern könntest. Stattdessen müsste Cisco den Zeichen-Puffer vergrößern, also seine Firmware erneuern. Oder die Telekom Deutschland wieder das Tag verkürzen.

Edit: Lösungsansatz weiter ausgeführt und in nächsten Post verschoben

 

[sonyKatze]

Noch fünf Anmerkungen:

Telekom Deutschland, unterschiedliches Verhalten:
Die Server der Telekom senden unterschiedlich lange Tags, mal 124, mal 114, mal kurze. In letzterem Fall klappt die Anmeldung dann für eine kurze Zeit. Das hängt nicht von der IP-Adresse des Servers ab. Selbst unter der selben IP-Adresse ändert sich das Verhalten. Das ist für ein nicht-transparenten Load-Balancing ungewöhnlich, alle Server im Verbund müssten sich eigentlich gleich verhalten. @Meester Proper @Telekom hilft Team könnte jeder von Euch sich das mal anschauen? Sieht für mich nach falschen, nicht intendierten Verhalten aus. Besonders auch weil das Tag mal 114 Bytes hat und dann mal wieder 114 Byte plus noch ein Präfix. Auch ist die Reihenfolge der SIP-Header je nach Lust und Laune unterschiedlich.

Bug-Fix:
Cisco hat den Fehler bereits im August 2020 als Seiteneffekt behoben (Quelle bzw. Selbststest):

CSCvu68891 Parser error when tag on header in INVITE contains more than 79 characters​

Die Firmware-Updates (für aktuelle Produkte) finden sich unter ATA-Adapter bzw. Tisch-Telefon. Am Einfachsten war für mich, in das Suchfeld lediglich die Nummer des Produkt einzugeben, also beim Cisco ATA 191 einfach nur „191“. Die Webseite vervollständigte dann die von Cisco erwartete Schreibweise.

ATA-Adapter ersetzen:
Hat man einen ATA-Adapter ohne Update, dann ist der aktuelle Nachfolger der Cisco ATA 191. Aber in dem Fall bietet sich direkt eine FRITZ!Box oder eine Digitalisierungsbox als ATA-Adapter an. Die sind getestet und man bekommt sie gebraucht wirklich günstig, z. B. die FRITZ!Box 7412 oder die Digitalisierungsbox Smart.

Tisch-Telefon ersetzen:
Hat man ein Telefon ohne Update, dann ist der aktuelle Nachfolger für Sipura bzw. Linksys SPA die „Multiplatform-Firmware Series“ (MPP). Solche Telefon haben 3PCC oder 3PW in ihrer Modell-Nummer (SKU).

Gerät retten:
Einen SIP-B2BUA zwischen Telekom und Gerät schalten. Ein solcher wäre z. B. eine FRITZ!Box, eine Digitalisierungsbox, ein Lancom mit All-IP Option, gebraucht in eBay für kleines Geld. Daran kannst Du das Cisco als IP-Telefon anschließen. Die Box übernimmt dann die Übersetzung zur Telekom Deutschland.

 

[Telekom hilft Team]

Hallo zusammen,

ich kann adhoc dazu leider nichts sagen. Ich mache mich aber schlau und melde mich.

Gruß, Kai M.

Nachtrag:
Magst du mir bitte "Register"-Meldungen aus dem Telefon oder die betroffene Rufnummer geben, dann können wir nachschauen warum die Registrierung nicht funktioniert.
Nutze hierfür bitte unser Kontaktformular.

Gruß, Kai M.

 

[ConiKost]

Bug-Fix:
Cisco hat den Fehler bereits im August 2020 als Seiteneffekt behoben (Quelle bzw. Selbststest):

CSCvu68891 Parser error when tag on header in INVITE contains more than 79 characters​

Die Firmware-Updates (für aktuelle Produkte) finden sich unter ATA-Adapter bzw. Tisch-Telefon. Am Einfachsten war für mich, in das Suchfeld lediglich die Nummer des Produkt einzugeben, also beim Cisco ATA 191 einfach nur „191“. Die Webseite vervollständigte dann die von Cisco erwartete Schreibweise.

Kann es sein, dass das beim ATA 191 nicht repariert worden ist? Ich habe ein ATA 191 und bekomme leider das selbe Problem, dass weiterhin wegen CC_SIP_UNAUTHORIZED_401 keine Verbindung klappt. Es taucht ebenfalls "TP Parser error: 15", also vermutlich genau das Problem, was du schilderst.

@Telekom hilft Team Gibt es hierzu Neuigkeiten von eurer Seite?

 

[Telekom hilft Team]

Nein, dazu liegen mir keine weiteren Erkenntnisse vor.

Gruß, Kai M.