crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
Hallo Telekom Hilft Community,
ich hoffe Ihr könnt mir weiterhelfen. Wir haben ein Schreiben der Telekom vom 01.09.2020 erhalten, in dem es heißt:
"... haben wir festgestellt, dass Ihre Router statt einer SRV-Diensteauflösung einen veralteten DNS-Konfigurationseintrag über A-Record nutzen, den die aktuelle Plattform ab Herbst nicht mehr unterstützt.
Um auch künftig telefonieren zu können, müssen Sie die aktuellste Firmware auf Ihren umseitig aufgeführten Routern installieren. Dafür genügt in der Regel ein einfaches Update..."
Das betrifft insgesamt 3 All-IP Anschlüsse (jeweils Mehrgeräteanschlüsse - falls die noch so heißen), von denen nur zwei für Telefonie verwendet werden.
Nun befürchte ich, dass es mit einem Router-Update nicht getan ist, da wir die SIP-Accounts nicht direkt im jeweiligen Router konfiguriert haben. Statt dessen ist am ersten Anschluss hinter dem Router eine IP-Telefonanalage "Tiptel / Yeastar MyPBX SOHO" installiert, und am zweiten Anschluß sind hinter dem Router zwei ATA-Adapter "Linksys PAP2T" installiert.
Meine Vermutung ist, dass sowohl in der IP-Telefonanlage, als auch in den ATA-Adaptern etwas eingestellt werden muss, was mit dem Eintrag "tel.t-online.de" zu tun hat.
Bei der Telekom Störungshotline konnte man mir keine Details nennen, außer immer wieder den Hinweis "bitte alle Router und Geräte updaten". Das hilft mir so aber nicht weiter, wenn ich nicht weiß, ob es damit wirklich getan ist.
Im Internet habe ich dazu bislang nur wenig gefunden. Ich habe aber bereits gelesen, dass man jetzt bei der Telekom anscheinend hinter dem Eintrag "tel.t-online.de" den Port "0" angeben muß, und dass der Service "NAPTR" aktiviert werden muss.
Kann mir jemand evtl. auf die richtige Spur helfen?
Vielen Dank im Voraus
BTG
Gelöst! Gehe zu Lösung.
20.09.2020 14:32 Zuletzt bearbeitet: 18.02.2021 08:22 durch den Autor
Hallo @btg, halllo @Telefisch,
Sie haben ja bereits viele Tipps und Unterstützung von den anderen Usern erhalten. Vielen Dank dafür an dieser Stelle.
Hier erhalten Sie noch ein paar Infos zu dem Thema.
Der Hintergrund ist, dass die Telefonie über tel.t-online.de registriert wird. Momentan wird die Auflösung von tel.t-online.de noch über A-Record erlaubt. Dabei fragt das registrierende Gerät wer tel.t-online.de ist und bekommt über den A-Record eine IP-Adresse von unserem Telefonie-Server zurück. Zukünftig wollen wir, dass das registrierende Gerät tel.t-online.de über SRV (so wie bei SIP-Trunk) auflöst, dann gibt’s als Antwort 3 mögliche IP-Adressen von unserem Telefonie-Server. Im Falle eines Ausfalls etc. vom Server wird die Telefonie sichergestellt.
Der Kunde sollte bei dem Endgerät, welches die Telefonie-Registrierung durchführt, auf die aktuellste Firmware aktualisieren und überprüfen, ob als SIP-Proxy und Registrar „tel.t-online.de“ eingetragen ist.
Wichtig ist dabei, sollte das betroffene Endgerät den SRV-Record nicht unterstützen, kann das Gerät ab Abschaltung des A-Record, keine Telefonie registrieren.
Eine Besonderheit ist die Digitalisierungsbox. Diese Kunden nutzen ein Universelles Basisprofil der CloudPBX, z.B. zur Nutzung eines Fax-Gerätes, an der Digitalisierungsbox. Dabei ist die Firmware der Digitalisierungsbox aktuell bzw. unterstützt die SRV-Auflösung, nur die Konfiguration ist nicht korrekt.
Die Konfiguration der Digitalisierungsbox muss dem Screenshot im Anhang entsprechen.
Auch bei Fremdgeräten muss geprüft werden, ob die Firmware auf dem aktuellen Stand ist und, ob dieses Endgerät die DNS-Auflösung über SRV unterstützt. Wenn ja, sollte in der Konfiguration des registrierendes EG geprüft werden, wie die DNS-Auflösung konfiguriert ist und ob der "DNS-Typ" auf "SRV" eingestellt ist.
In der Konfiguration, im SIP-Server-Feld muss immer die Domäne tel.t-online.de eingetragen sein, nicht die IP-Adresse.
Im Anhang finden Sie noch ein paar Beispiele von der Konfiguration der DNS-Einstellungen in einer Fremd-Anlage und im IP-Telefon.
Sollte noch weitere Unterstützung benötigt werden, melden Sie sich gern wieder hier bei uns.
Beste Grüße
Tanja R.
17.09.2020 15:12
20.09.2020 14:32 Zuletzt bearbeitet: 18.02.2021 08:22 durch den Autor
Hallo @btg, halllo @Telefisch,
Sie haben ja bereits viele Tipps und Unterstützung von den anderen Usern erhalten. Vielen Dank dafür an dieser Stelle.
Hier erhalten Sie noch ein paar Infos zu dem Thema.
Der Hintergrund ist, dass die Telefonie über tel.t-online.de registriert wird. Momentan wird die Auflösung von tel.t-online.de noch über A-Record erlaubt. Dabei fragt das registrierende Gerät wer tel.t-online.de ist und bekommt über den A-Record eine IP-Adresse von unserem Telefonie-Server zurück. Zukünftig wollen wir, dass das registrierende Gerät tel.t-online.de über SRV (so wie bei SIP-Trunk) auflöst, dann gibt’s als Antwort 3 mögliche IP-Adressen von unserem Telefonie-Server. Im Falle eines Ausfalls etc. vom Server wird die Telefonie sichergestellt.
Der Kunde sollte bei dem Endgerät, welches die Telefonie-Registrierung durchführt, auf die aktuellste Firmware aktualisieren und überprüfen, ob als SIP-Proxy und Registrar „tel.t-online.de“ eingetragen ist.
Wichtig ist dabei, sollte das betroffene Endgerät den SRV-Record nicht unterstützen, kann das Gerät ab Abschaltung des A-Record, keine Telefonie registrieren.
Eine Besonderheit ist die Digitalisierungsbox. Diese Kunden nutzen ein Universelles Basisprofil der CloudPBX, z.B. zur Nutzung eines Fax-Gerätes, an der Digitalisierungsbox. Dabei ist die Firmware der Digitalisierungsbox aktuell bzw. unterstützt die SRV-Auflösung, nur die Konfiguration ist nicht korrekt.
Die Konfiguration der Digitalisierungsbox muss dem Screenshot im Anhang entsprechen.
Auch bei Fremdgeräten muss geprüft werden, ob die Firmware auf dem aktuellen Stand ist und, ob dieses Endgerät die DNS-Auflösung über SRV unterstützt. Wenn ja, sollte in der Konfiguration des registrierendes EG geprüft werden, wie die DNS-Auflösung konfiguriert ist und ob der "DNS-Typ" auf "SRV" eingestellt ist.
In der Konfiguration, im SIP-Server-Feld muss immer die Domäne tel.t-online.de eingetragen sein, nicht die IP-Adresse.
Im Anhang finden Sie noch ein paar Beispiele von der Konfiguration der DNS-Einstellungen in einer Fremd-Anlage und im IP-Telefon.
Sollte noch weitere Unterstützung benötigt werden, melden Sie sich gern wieder hier bei uns.
Beste Grüße
Tanja R.
Welche Asterisk-Version benötigt man denn?
Habe den Brief gestern ebenfalls bekommen, hier läuft ein Asterisk 16.6.2.
In pjsip.conf steht:
;srv_lookups=yes ; Perform SRV lookups for provided hostnames. (default: yes)
"default: yes" bedeutet ja, dass da eigentlich SRV-Lookups gemacht werden sollten … Allerdings:
; <<>> DiG 9.16.4 <<>> srv tel.t-online.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22792
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ea1eee6f82790a3b010000005f6cf189bf104aae6d4977e7 (good)
;; QUESTION SECTION:
;tel.t-online.de. IN SRV
;; AUTHORITY SECTION:
tel.t-online.de. 10800 IN SOA ns1.edns.t-ipnet.de. hostmaster.t-ipnet.net. 2018022700 43200 1800 1209600 21600
;; Query time: 59 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Sep 24 21:20:41 CEST 2020
;; MSG SIZE rcvd: 149
SRV-RRs gibt es nicht … die bereits genannten NAPTR gibt es:
; <<>> DiG 9.16.4 <<>> naptr tel.t-online.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56944
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 286bf6b339609f32010000005f6cf195b03853f91f06aa22 (good)
;; QUESTION SECTION:
;tel.t-online.de. IN NAPTR
;; ANSWER SECTION:
tel.t-online.de. 7200 IN NAPTR 30 0 "s" "SIP+D2T" "" _sip._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 10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
Die werden aber vermutlich von Asterisk nicht abgerufen.
25.09.2020 01:25
@Tanja R. & Co.
Ich konnte nicht wirklich etwas darüber finden:
(Ab welcher Version) unterstützt der Android SIP-Client den SRV-Record?
Welche App(s) für Android unterstützen den SRV-Record?
25.09.2020 07:26
@dl8dtl schrieb:
[...]"default: yes" bedeutet ja, dass da eigentlich SRV-Lookups gemacht werden sollten … Allerdings:
[...]
SRV-RRs gibt es nicht … die bereits genannten NAPTR gibt es:
[...]
tel.t-online.de. 7200 IN NAPTR 30 0 "s" "SIP+D2T" "" _sip._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 10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
Die SRV records gibt es natürlich aber nicht direkt für tel.t-online.de sondern für die NAPTR. Aber das ist Standard und deswegen bekommen das auch die clients hin, die keine NAPTR unterstützen:
dig _sips._tcp.tel.t-online.de SRV +short
20 0 5061 h2-eps-110.edns.t-ipnet.de.
30 0 5061 d-eps-110.edns.t-ipnet.de.
10 0 5061 b-eps-100.edns.t-ipnet.de.
dig _sip._udp.tel.t-online.de SRV +short
30 0 5060 d-epp-110.edns.t-ipnet.de.
10 0 5060 b-epp-100.edns.t-ipnet.de.
20 0 5060 h2-epp-110.edns.t-ipnet.de.
dig _sip._tcp.tel.t-online.de SRV +short
30 0 5060 d-epp-110.edns.t-ipnet.de.
10 0 5060 b-epp-100.edns.t-ipnet.de.
20 0 5060 h2-epp-110.edns.t-ipnet.de.
25.09.2020 08:16 Zuletzt bearbeitet: 25.09.2020 08:17 durch den Autor
Hallo @Maximilia,
von uns erhalten Sie keinen Support für jegliche Apps.
Bitte an den Entwickler der App wenden, ob die App mit der von uns vorgegebenen Schnittstellenbeschreibung (z.B. 1TR114) kompatibel ist.
Lieben Gruß, Melanie B.
25.09.2020 08:45
Danke für die schnelle Rückmeldung.
Ist es als Kunde wirklich zu viel verlangt, die Telekom, die etwas an ihrem Netz ändert, woran sich der Kunde anpassen muss, in der Bringschuld zu sehen?
25.09.2020 08:54
@Maximilia schrieb:
Ist es als Kunde wirklich zu viel verlangt, die Telekom, die etwas an ihrem Netz ändert, woran sich der Kunde anpassen muss, in der Bringschuld zu sehen?
Die SRV records gibt es schon immer und jeder, der es von Anfang an richtig konfiguriert hat, muss gar nichts ändern.
Und eingeschränkte clients, die SRV records gar nicht unterstützen, sollte man auch mal durch was brauchbares ersetzen.
25.09.2020 09:15
25.09.2020 09:52
OK, danke, verstanden.
Habe mal bisschen weiter geguckt, eigentlich sollte res_pjsip auch in Asterisk 16.x bereits NAPTR-Abfragen machen. Da muss ich mal debuggen, warum das bei mir nicht passiert.
26.09.2020 22:06
Bei mir läuft ein asterisk 16.9.0 auf Debian Buster. Die Namensauflösung mittels DNS SRV funktioniert:
dig SRV _sip._udp.t-online.de
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> SRV _sip._udp.t-online.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54819
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_sip._udp.t-online.de. IN SRV
;; ANSWER SECTION:
_sip._udp.t-online.de. 86400 IN SRV 0 0 5060 tel.t-online.de.
;; Query time: 0 msec
;; SERVER: X.X.X.X#53(X.X.X.X)
;; WHEN: Sa Sep 26 22:03:24 CEST 2020
;; MSG SIZE rcvd: 85
26.09.2020 22:18
wenn du
dig SRV _sip._udp.tel.t-online.de
anstatt
dig SRV _sip._udp.t-online.de
benutzt hättest, wäre das Ergebnis richtig.
26.09.2020 23:16
Die Frage ist ja: macht der Asterisk denn nun NAPTR/SRV-Auflösung oder nicht? (Dass man das mit dig machen kann, ist mir klar.)
Wenn ja, mit welcher Konfiguraton?
29.09.2020 15:12
07.10.2020 13:59
23.10.2020 09:51
23.10.2020 09:56
23.10.2020 17:14
Ich benutze zwar keinen Raspberry Pi sondern FreeBSD, aber ebenfalls mit Asterisk.
Da mein Brief angedroht hatte, dass die A-Records bereits am 16. 10. abgeschaltet würden (offensichtlich nicht der Fall ;), habe ich mich nun endlich nochmal durch PJSIP durchgewühlt. Wie heißt es doch so schön: "All documentation files usually end up in .c"
In sip_resolve.c findet sich folgende Logik:
/* If port is not specified, start with SRV resolution * (should be with NAPTR, but we'll do that later) */ PJ_TODO(SUPPORT_DNS_NAPTR); /* Build dummy NAPTR entry */ // … /* Start DNS SRV or A resolution, depending on whether port is specified */ if (target->addr.port == 0) { // … } else { /* Otherwise if port is specified, start with A (or AAAA) host * resolution */
Das heißt also: die ":5060" muss man weglassen, ansonsten werden A- oder AAAA-Records gesucht! Wenn man sie weglässt, wird zwar (zumindest hier in Asterisk 16) kein direkter NAPTR gesucht (sondern einer synthetisiert), aber es werden danach zumindest SRV-RRs gesucht.
Ich habe alle meine :5060 entfernt, jetzt telefoniert mein Asterisk nicht mehr mit 217.0.128.133 (A-RR für tel.t-online.de) sondern mit 217.0.25.32.
02.11.2020 15:22
02.11.2020 15:28
Die benutzten IP-Adressen habe ich mittels "tcpdump" auf dem Firewall/Router herausgefunden.
Direkt im Asterisk habe ich bislang dazu keine Möglichkeit gesehen, kann natürlich sein, dass sich das mittels irgendwelcher Debug-Einstellungen sichtbar machen ließe. Die Firewall-Kommunikation zu tracen, war in meinem Falle einfacher.
12.02.2021 00:19
Hallo,
ich habe nun auch das besagte Schreiben erhalten.
Mein Router ist der ASUS DSL-AC68VG. Woher weiss ich, ob das Gerät die erforderliche SRV-Anfrage unterstützt?
Beim Hersteller habe ich schon angefragt, bisher jedoch keine Antwort erhalten.
Vielen Dank!
12.02.2021 09:00
Kann man den in diesem Router irgendwie ein Protokoll bekommen, zu welcher IP-Adresse er die SIP-Verbindung aufbaut? (SIP ist der Signalisierungskanal für VoIP.)
Der ("klassische") A-Record für tel.t-online.de zeigt auf 217.0.128.133.
Die SRV-Records zeigen auf verschiedene Server, die allesamt andere IP-Adressen haben. Für UDP wäre das beispielsweise hh-epp-100.edns.t-ipnet.de mit der Adresse 217.0.25.32.
12.02.2021 09:07
- Der ("klassische") A-Record für tel.t-online.de zeigt auf 217.0.128.133.
Wenn man einen Telekom DNS-Server nutzt, zeigt tel.t-online.de, bei mir, auf 217.0.27.53.
12.02.2021 09:15
> Wenn man einen Telekom DNS-Server nutzt, zeigt tel.t-online.de, bei mir, auf 217.0.27.53.
Interessant … warum auch immer sie nach draußen einen anderen Eintrag rausgeben als über ihre eigenen Server.
Ja: ich benutze meinen eigenen DNS-Server.
Dann muss ich einschränken: zumindest bei mir liegen die Antworten für die SRV-Records allesamt in den Netzbereichen 217.0.25/24, 217.0.28/24 und 217.0.29/24. Wenn die Verbindung also zu einer dieser Adressen aufgebaut wird, kann man davon ausgehen, dass SRV benutzt wird.
Sie benötigen eine persönliche Kaufberatung? Das Geschäftskundenteam der Telekom berät Sie gerne.
Informieren Sie sich über unsere aktuellen Festnetz- & Internet-Angebote.