AW: Auswirkung unterschiedlicher DNS-Settings auf SIP-Trunk

[#1]

So, dritter Versuch diesen Post abzusetzen....

Mir ist aufgefallen, dass die SRV-Lookups je nach verwendetem DNS-Server unterschiedliche Ergebnisse zurückliefern, z.B.:

Normales Endkunden-DSL:

nslookup -querytype=SRV _sip._tcp.reg.sip-trunk.telekom.de
Server:         192.168.207.1
Address:        192.168.207.1#53

Non-authoritative answer:
_sip._tcp.reg.sip-trunk.telekom.de      service = 0 5 5060 f-ipr-a01.sip-trunk.telekom.de.
_sip._tcp.reg.sip-trunk.telekom.de      service = 10 5 5060 d-ipr-a01.sip-trunk.telekom.de.
_sip._tcp.reg.sip-trunk.telekom.de      service = 1 5 5060 f-ipr-a02.sip-trunk.telekom.de.

Telekom-Business-DSL:

nslookup -querytype=SRV _sip._tcp.reg.sip-trunk.telekom.de fritz-vectoring.example.de
Server:         fritz-vectoring.example.de
Address:        10.9.12.1#53

Non-authoritative answer:
_sip._tcp.reg.sip-trunk.telekom.de      service = 10 5 5060 d-ipr-a02.sip-trunk.telekom.de.
_sip._tcp.reg.sip-trunk.telekom.de      service = 1 5 5060 b-ipr-a01.sip-trunk.telekom.de.
_sip._tcp.reg.sip-trunk.telekom.de      service = 0 5 5060 b-ipr-a02.sip-trunk.telekom.de.

Eigener, normaler recursing DNS:

nslookup -querytype=SRV _sip._tcp.reg.sip-trunk.telekom.de
Server:         10.10.100.19
Address:        10.10.100.19#53

Non-authoritative answer:
_sip._tcp.reg.sip-trunk.telekom.DE      service = 10 5 5060 d-ipr-a01.sip-trunk.telekom.de.
_sip._tcp.reg.sip-trunk.telekom.DE      service = 1 5 5060 n-ipr-a02.sip-trunk.telekom.de.
_sip._tcp.reg.sip-trunk.telekom.DE      service = 0 5 5060 n-ipr-a01.sip-trunk.telekom.de.

Ich habe mehrfach gehört, dass man den Telekom-DNS-Server aus der PPPoE-Aushandlung des Telekom-Anschlusses benutzen soll, um die SIP-Session zum "besten" Server zu bekommen. Da wir aber 2 redundante Internetanschlüsse haben und sie die DNS-Server der Telekom nur aus dem Telekomnetz ansprechen lassen, ist das leider nicht möglich. Daher wäre ich mal daran interessiert zu hören,

- was man in diesem Fall am besten macht, und

- welche Auswirkungen es überhaupt hat, wenn man einen der unterschiedlichen Server kontaktiert (funktionieren tut auf Anhieb
erstmal alles, egal welchen man nimmt).

Diese beiden Fragen konnte oder wollte mir der Support nicht beantworten, es kam der übliche Verweis auf die TR-118 Spezifikation,
die aber zu genau meinen Fragen eben nichts aussagt.

Da bei stabilem Netzzugang und stabiler Telefonanlage die SIP-Session über Monate bestehen kann, frage ich mich auch, warum die Gegenstellen überhaupt so "dynamisch" über das DNS eingerichtet werden. Wie soll man denn mitbekommen, wenn sich da was ändert? Ich habe jetzt schon mehrfach das Problem gehabt, das sich Telefonieprobleme dadurch beheben ließen, dass man die SIP-Session neu aufgebaut hat (und dadurch evtl. eine andere Gegenstelle bekommen hat).

Aktuell mal wieder "chan_sip.c: Got SIP response 500 "Server Internal Error" back from 217.0.15.67:5060", also eine nichtssagende
Fehlermeldung vom Telekom-SIP-Server, die kommt, wenn stabil kommt, wenn man genau eine Rufnummer anruft, die aus dem "normalen" Festnetz und dem Handynetz erreichbar ist. Laut Support ist das Problem mit der Gegenstelle bekannt, aber die "kaputte" Fehlermeldung führt leider dazu, dass der Fehler als lokaler Fehler angezeigt wird (FreePBX interpretiert das als "circuit-busy" und macht die Ansage, dass alle ausgehenden Leitungen belegt sind).

[#2]

Die Buchstaben B, N, D und F scheinen für Berlin, Nürnberg, Düsseldorf und Frankfurt zu stehen. Insofern ist der Zweck vielleicht wirklich nur, den nächstgelegenen Server ausfindig zu machen. Wie sich die Unterschiede in der Anbindung letztendlich auswirken konnte ich leider nicht testen, da sie auf Ping nicht reagieren.

[#3]

Über die DNS-Server wird eine Lastverteilung erreicht, so werden die Nutzer auf die verschiedenen regionalen Server verteilt.

---

@Thomas_Herrmann  schrieb:

Ich habe mehrfach gehört, dass man den Telekom-DNS-Server aus der PPPoE-Aushandlung des Telekom-Anschlusses benutzen soll, um die SIP-Session zum "besten" Server zu bekommen. Da wir aber 2 redundante Internetanschlüsse haben und sie die DNS-Server der Telekom nur aus dem Telekomnetz ansprechen lassen, ist das leider nicht möglich. Daher wäre ich mal daran interessiert zu hören,

- was man in diesem Fall am besten macht, und

---

Der lokale DNS-Resolver sollte möglichst immer den selben Upstream-Resolver nutzen, damit die DNS Resultate möglichst konstant sind.

---

@Thomas_Herrmann  schrieb:

- welche Auswirkungen es überhaupt hat, wenn man einen der unterschiedlichen Server kontaktiert (funktionieren tut auf Anhieb erstmal alles, egal welchen man nimmt).

---

Das hat keine unmittelbare Auswirkung, nur wird, wie oben geschrieben, eine Verteilung für gleichmäßige Last genutzt.

---

@Thomas_Herrmann  schrieb:

Da bei stabilem Netzzugang und stabiler Telefonanlage die SIP-Session über Monate bestehen kann, frage ich mich auch, warum die Gegenstellen überhaupt so "dynamisch" über das DNS eingerichtet werden. Wie soll man denn mitbekommen, wenn sich da was ändert? Ich habe jetzt schon mehrfach das Problem gehabt, das sich Telefonieprobleme dadurch beheben ließen, dass man die SIP-Session neu aufgebaut hat (und dadurch evtl. eine andere Gegenstelle bekommen hat).

Wenn bei der SRV-Abfrage ein neuer Server mit höchster Priorität mitgeteilt wird, sollte der SIP-Client entsprechend den Server wechseln und dort die Registrierung vornehmen. Zu beachten ist allerdings, dass laufende Sessions/Gespräche über die bestehende (alte) Registrierung/TCP-Session bedient werden müssen.

---

@Thomas_Herrmann  schrieb:

Aktuell mal wieder "chan_sip.c: Got SIP response 500 "Server Internal Error" back from 217.0.15.67:5060", also eine nichtssagende Fehlermeldung vom Telekom-SIP-Server, die kommt, wenn stabil kommt, wenn man genau eine Rufnummer anruft, die aus dem "normalen" Festnetz und dem Handynetz erreichbar ist. Laut Support ist das Problem mit der Gegenstelle bekannt, aber die "kaputte" Fehlermeldung führt leider dazu, dass der Fehler als lokaler Fehler angezeigt wird (FreePBX interpretiert das als "circuit-busy" und macht die Ansage, dass alle ausgehenden Leitungen belegt sind).

---

In der SIP-Welt werden die Responses von den Endpunkten generiert, wenn die gewählte Rufnummer also ein SIP500 generiert, dann wird das an den Anrufer zurückgegeben. Über die Interpretierung von Fehlercodes lässt sich natürlich streiten, dort wird man nie zu einem Konsens kommen.

[#4]

Hallo @Thomas_Herrmann,

vielen Dank für Ihren Beitrag.

Hilft Ihnen dazu diese Unterlage weiter?


Lieben Gruß, Melanie B.

[#5]

Die von Melanie B. verlinkte Unterlage half nicht wirklich weiter.

Die Hauptfrage, ob sich die Server von der Funktionalität her unterscheiden, wurde hier ja verneint, und ich denke, das stimmt auch soweit. Ich bin mit folgenden Links den Problemen vielleicht etwas näher auf der Spur:

https://community.asterisk.org/t/asterisk-16-and-naptr-srv/78492

https://community.asterisk.org/t/pjsip-settings-for-two-german-telekom-products/79293

Quintessenz: die aktuell von der Telekom verwendeten/geforderten SIP-Settings sind mit Asterisk nicht 100%ig vereinbar. Insbesondere der alte Chan_SIP-Treiber unterstützt viele Funktionen nur rudimentär. Daher werde ich jetzt auf PJSIP wechseln, wo auch aktiv an der Behebung der Kompatibilitätsprobleme gearbeitet wird.

Zum Zeitpunkt unserer Umschaltung auf SIP-Trunk habe ich nur Chan_SIP-Demo-Configs gefunden und bin daher auf den falschen Zug aufgesprungen. Dank der obigen Links sollte mit PJSIP hoffentlich alles besser werden.