Telekom All IP Privat endlich erfolgreiche Registierung SSL/TLS möglich

Meester Proper

Neuer User
Mitglied seit
24 Mai 2014
Beiträge
127
Punkte für Reaktionen
8
Punkte
18
Welches Problem löst RFC5009, was nicht mit 180 Ringing bzw. 183 EarlyMedia schon gelöst ist?
RFC5009 löst das Problem, wenn innerhalb der Early Phase eine Offer/Answer-Prozedur stattgefunden hat, der Medientransport aber nicht erlaubt wird (gated), dass dann bspw. ein "P-Early-Media: inactive, gated" signalisiert wird, damit dann anstatt auf einen Medienstrom zu warten, ein lokaler Klingelton generiert wird. Wie das gewünschte Verhalten auszusehen hat, ist übrigens in 1TR114 , 4.2.6 geregelt: https://www.telekom.de/hilfe/downloads/1tr114.pdf#page=21

Wenn ein 180 Ringing kommt, heißt das doch, dass das ring back lokal erzeugt werden muss. Bei 183 mit SDP weiß man, dass das ring back remote erzeugt wird (oder was auch sonst immer als Ansage kommt). Wieso muss man da dann mit 183 ohne SDP daherkommen (was dann de facto einem 180 entspricht) oder auf der anderen Seite 180 mit SDP (was dann einem gewöhnlichen 183 entspricht)? Das erschließt sich mir absolut noch nicht und scheint auch irgendwie Telekom-spezifisch zu sein, weil ich das so noch nirgendwo gesehen habe (ok, das heißt jetzt nicht allzu viel).
Für die Signalisierung ist nicht die Telekom zuständig, sondern der Endpunkt (=das Rufziel). Lediglich bei einem Medienübergang (Mediagateway ins ISDN bspw.) generiert die Telekom die Signalisierung.
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
61
Punkte für Reaktionen
1
Punkte
8
RFC5009 löst das Problem, wenn innerhalb der Early Phase eine Offer/Answer-Prozedur stattgefunden hat, der Medientransport aber nicht erlaubt wird (gated), dass dann bspw. ein "P-Early-Media: inactive, gated" signalisiert wird, damit dann anstatt auf einen Medienstrom zu warten, ein lokaler Klingelton generiert wird. Wie das gewünschte Verhalten auszusehen hat, ist übrigens in 1TR114 , 4.2.6 geregelt: https://www.telekom.de/hilfe/downloads/1tr114.pdf#page=21
Irgendwie ist das aber nicht das, was die Telekom konkret praktiziert (zumindest in den mir bekannten Fällen): Hier findest Du einen konkreten Trace, der das darstellt, was auch ich hier so sehe. Da kommt ja explizit das ring back (zumindest in diesem Fall ist es ein ring back - ich habe da auch schon Ansagen gehört stattdessen) von der Telekom im Mediastream (wer auch immer es schlussendlich de facto initiiert hat) via 180 (warum nicht das Übliche 183 / SDP?). Ich sehe da einfach keinen Unterschied - abgesehen davon, dass das (scheinbar) selbe auf anderem Weg erreicht wird.
 

Meester Proper

Neuer User
Mitglied seit
24 Mai 2014
Beiträge
127
Punkte für Reaktionen
8
Punkte
18
Ohne das konkrete Ziel zu wissen, kann ich nicht sagen, wer diese Signalisierung erzeugt. Es gilt aber auch weiterhin die Ansage: Das IMS der Telekom ist für die Signalisierung transparent: Der angerufene Teilnehmer erzeugt die Signalisierung, die der Anrufer sieht.

In diesem Fall legt das Anrufziel mittels 180 w/ SDP einen Medienstrom an (Ringbacktone). Das Anrufziel scheint auch eine positive Early Media Autorisierung zu haben, denn der Medienstrom erreicht den Anrufer und PEM steht auf sendonly.
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
61
Punkte für Reaktionen
1
Punkte
8
In diesem Fall legt das Anrufziel mittels 180 w/ SDP einen Medienstrom an (Ringbacktone). Das Anrufziel scheint auch eine positive Early Media Autorisierung zu haben, denn der Medienstrom erreicht den Anrufer und PEM steht auf sendonly.
Bis ca. kurz vor Weihnachten war das noch das klassische unproblematische 183 w/ SDP. Wieso jetzt plötzlich 180 w/ SDP - ich sehe leider einfach immer noch keinen Unterschied in dem, was de facto erreicht wird. Nach welchen Kriterien wird denn nun 180 w/ SDP oder 183 w/ SDP verwendet? Ich glaube ja nicht, dass das Zufall ist. Scheint irgendwie providerabhängig zu sein. Mir ist bisher eigentlich nur der Zielprovider Vodafone aufgefallen.
 

Meester Proper

Neuer User
Mitglied seit
24 Mai 2014
Beiträge
127
Punkte für Reaktionen
8
Punkte
18
Das musst du den Endpunkt / Anrufziel fragen. Meiner Meinung muss die SIP-Implementierung aber darauf vorbereitet zu sein, in irgendeiner 18x Antwort eine SDP Answer zu erhalten.

Ich würde aber nun vorschlagen: Back to topic.
 

reinhardmunz

Neuer User
Mitglied seit
15 Feb 2018
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Ich habe mit asterisk 13.24.x / pjsip und freepbx 13 und der Telekom kein Problem mit SIP / RTP bzw. SIPS / RTP (allerdings ist manuelle Konfig in pjsip.registration_custom.conf, pjsip.transports_custom_post.conf und pjsip.endpoint_custom_post.conf nötig - es wird also vieles quasi direkt gemacht). Neuerdings sind auch noch zwei Patches bei outbound calls nötig, weil das ring back zu bestimmten Providern fehlt.
Hallo gehtdoch,
ich habe Probleme den SIPS Teil mit pjsip, Asterisk 15 und freepbx am Telekom SIP-Trunk zum Laufen zu bekommen. Wäre es möglich eine funktionierende pjsip Konfiguration von Ihnen einzusehen?
Vielen Dank
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
61
Punkte für Reaktionen
1
Punkte
8
Hallo gehtdoch,
ich habe Probleme den SIPS Teil mit pjsip, Asterisk 15 und freepbx am Telekom SIP-Trunk zum Laufen zu bekommen. Wäre es möglich eine funktionierende pjsip Konfiguration von Ihnen einzusehen?
Vielen Dank
Ich kann nur was zu Asterisk 13 sagen - Asterisk 15 habe ich nicht im Einsatz. Aber ich denke mal, dass das kompatibel sein sollte. Außerdem beziehe ich mich auf freepbx 13 - da ich die line-Konfig nutze, habe ich die userpezifische Konfig aktiv - das sollte mit dem neuen freepbx alles direkt in der GUI gehen, wenn ich das noch richtig in Erinnerung habe - musst Du eben übertragen:

pjsip.registration_custom.conf

[Name_des_Trunks]
type=registration
transport=0.0.0.0-tls
outbound_auth=Name_des_Trunks
retry_interval=60
max_retries=10000
expiration=3600
auth_rejection_permanent=yes
contact_user=+49.... (eigene Rufnummer im E164-Format)
server_uri=sip:tel.t-online.de
client_uri=sip:+49...(eigene Rufnummer im E164-Format)@tel.t-online.de
line=yes
endpoint=[Name des Trunks]

-> wichtig ist, dass der transport 0.0.0.0-tls in FreePBX in den SIP-Einstellungen aktiviert ist.

In der FreePBX-GUI wird dann auch noch folgende Einstellung vorgenommen:
SIP Server: tel.t-online.de
SIP Server Port: 5061

Definition des SSL-Protokolls in
pjsip.transports_custom_post.conf

[0.0.0.0-udp](+)
tos=0xb8

[0.0.0.0-tls](+)
method=tlsv1_2
tos=0xb8


Im Prinzip weichen nur drei Konfigurationen ab: SIP Server Port und transport sowie Angabe der zu verwendenden TLS-Version. RTP seitig ist ja nichts zu machen, da das ja noch nicht funktioniert.
 
Zuletzt bearbeitet:

Meester Proper

Neuer User
Mitglied seit
24 Mai 2014
Beiträge
127
Punkte für Reaktionen
8
Punkte
18
SRTP wird voraussichtlich im ersten Halbjahr auch ohne RFC3329 und mediasec-Erweiterungen gemäß draft-dawes-sipcore-mediasec-parameter-09.txt funktionieren.
Ich muss mich leider korrigieren, es werden auch weiterhin die speziellen Header, wie in 1TR114 beschrieben, benötigt. Die beabsichtigte interne Manipulation konnte nicht vorgenommen werden, daher muss das Endgerät dies weiterhin hinzufügen.
 

reinhardmunz

Neuer User
Mitglied seit
15 Feb 2018
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Vielen Dank @gehtdoch und @Meester Proper für die Hilfe.

Im Tarif DeutschlandLAN SIP-Trunk funktionieren TLS und SRTP ohne Probleme sobald man aus der Schnittstellenbeschreibung herausgelesen hat in welchem Format die Telekom welchen Parameter denn gerne hätte.

Nur am DNS muss man Hand anlegen. Ich habe in freepbx und asterisk keine Option gefunden um ausgehende Anrufe zwingend an die IP des Telekom Servers zu senden bei dem asterisk aktuell registriert ist. Soweit ich das sehe hat z.B. 3CX eine solche Funktion nachgerüstet (und mich würde nicht wundern wenn es ausschließlich am Verhalten der Telekom Server läge ;)).
 

Meester Proper

Neuer User
Mitglied seit
24 Mai 2014
Beiträge
127
Punkte für Reaktionen
8
Punkte
18
Wieso sollte man denn ein INVITE für einen ausgehenden Call an einen SIP-Server schicken, mit dem keine Registrierung besteht? Macht für mich keinen Sinn...
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
61
Punkte für Reaktionen
1
Punkte
8
Im Tarif DeutschlandLAN SIP-Trunk funktionieren TLS und SRTP ohne Probleme sobald man aus der Schnittstellenbeschreibung herausgelesen hat in welchem Format die Telekom welchen Parameter denn gerne hätte.
Kennst Du eine Möglichkeit, wie man via FreePBX / Asterisk zusätzliche Parameter konfigurativ ergänzen kann? Kannst Du da mal bitte ein Beispiel posten?

Nur am DNS muss man Hand anlegen. Ich habe in freepbx und asterisk keine Option gefunden um ausgehende Anrufe zwingend an die IP des Telekom Servers zu senden bei dem asterisk aktuell registriert ist.
Hmm, das verstehe ich nicht wirklich. Sobald Asterisk den Trunk registriert hat, nimmt er immer diese IP, mit der er registriert ist für outbound calls (pjsip). Welche Asterisk-Version hast Du? Zumindest Asterisk 16 hat damit überhaupt keine Probleme, weil die jetzt auch NAPTER und multiple DNS SRV-entries unterstützt, wie sie die Telekom liefert (das Feature ist AFAIK seit Version 14 drin - bin mir aber nicht mehr ganz sicher).

Ich habe mittlerweile auf die 16 migriert (und FreePBX 14), aber ich kann mich nicht daran erinnern, dass ich zuletzt Probleme gehabt hätte mit der 13er diesbezüglich. Mag aber evtl. auch daran liegen, dass ich einen eigenen Resolver laufen habe (bind), gegen den Asterisk geht (der geht nicht gegen den Telekom-DNS). Allerdings habe ich Bind derart konfiguriert, dass alle relevanten Zonen (t-online.de, t-ipnet.de, dtag.de) für Telekom / VoIP gegen einen DNS der Telekom geforwardet werden (die liefern andere IPs als der freie Resolver).
 

reinhardmunz

Neuer User
Mitglied seit
15 Feb 2018
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Kennst Du eine Möglichkeit, wie man via FreePBX / Asterisk zusätzliche Parameter konfigurativ ergänzen kann? Kannst Du da mal bitte ein Beispiel posten?
Meine aktuelle Konfiguration nutzt ausschließlich die GUI. Ich hatte früher, als der Anschluss an die Telekom noch über ISDN lief, eine Config-Datei basierte Konfiguration. Bei freepbx gibt es Config-Dateien welche die Konfiguration von der GUI überschreiben und solche, die sie ergänzen. Das genaue Verhalten kommt auf die Asterisk Version an. Ich hatte beides benutzt um eine ISDN Karte einzubinden. Leider habe ich diese Dateien nicht mehr. Damals musste ich diverse Funktionen ersetzen um Echo-Cancelling und Jitterbuffer für Fax- und Modemverbindungen anders als normal zu handhaben. Dabei habe ich die neue Funktion in die Konfigurationsdatei mit override freepbx im Dateinamen gepackt. Ich glaube diese Datei wurde bei freepbx einfach als erstes in die Hauptkonfigurationsdatei integriert und damals war das Verhalten von Asterisk so, dass ein Funktionsaufruf immer die erste Funktion mit dem richtigen Namen genommen hat.

Hmm, das verstehe ich nicht wirklich. Sobald Asterisk den Trunk registriert hat, nimmt er immer diese IP, mit der er registriert ist für outbound calls (pjsip).
Für den SIP-Trunk werden SRV Records im DNS verwendet. Asterisk scheint diese bei jedem neuen Anruf neu aufzulösen. Werden mehrere Server IPs aufgelöst nimmt er die mit der höchsten Priorität oder die erste. Ein zwei Tage geht das auch als gut, dann werden Anrufe geblockt. Immer wenn Anrufe geblockt werden hatte sich bei mir die Reihenfolge der Server IPs für die DNS SRV Record geändert. Ich habe deshalb Bind so konfiguriert, dass er sich gegenüber freepbx als authoritativ für reg.sip-trunk.telekom.de ausgibt und eine einzelne feste IP liefert. Sollte dieser Server bei der Telekom ausfallen hätte ich keine Verbindung mehr. Das ist bisher allerdings noch nicht vorgekommen oder wurde bisher nicht bemerkt. Die Probleme der geblockten Anrufe hatte ich jedoch seitdem nicht mehr. Falls jemand weiß wie ich pjsip dazu bekomme Anrufe nur an die registrierte IP zu schicken wäre ich für einen Hinweis dankbar.

Bei den Privatkundenprodukten tritt dieses Problem nur auf wenn man die zugewiesenen DNS Server nicht nutzt. Ich hatte das Problem einmal an einem Hybrid Anschluss. Solange ich über die Google Server habe auflösen lassen wurden Anrufe geblockt, sobald ich jedoch die von der Telekom in der pppoe Verbindung gelieferten DNS Server genutzt habe funktionierte alles wunderbar. Beim SIP-Trunk hat dieser Trick jedoch nicht funktioniert. Beim SIP-Trunk wird soweit ich weiß keine Anschlussbindung durchgesetzt. Ich schätze dass es deshalb keine anschlussspezifischen DNS Einstellungen gibt und einfach das bereits implementierte Load-balancing Verfahren der freien DNS Server verwendet wird. Aber da mutmaße ich nur. Bei der Telekom blicke ich oft nicht ganz durch. :)
 

reinhardmunz

Neuer User
Mitglied seit
15 Feb 2018
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Asterisk 15 aufwärts kann damit umgehen. Das ist die Lösung!
Dann weiß ich nicht was mein Asterisk 15.5.0 / freepbx 14.0.5.25 haben sollte. Seit ich ihm nur noch einen SRV Eintrag vorsetze funktioniert alles. Sobald ich den DNS Hack entferne werden ausgehende Anrufe nach einiger Zeit blockiert. Ich habe es soweit debugged dass ich gesehen habe dass ausgehende Anrufe an eine andere Server-IP gehen und dieser Server dann mit "forbidden" antwortet. Ich wüsste nicht was es sonst sein sollte.

Es gibt dabei nur Probleme wenn sich die Reihenfolge der SRV Einträge im DNS ändert. Wenn ich mit dig die SRV Einträge abrufe sind die Privatkundeneinträge immer in der gleichen Reihenfolge, mit Priorität 10 20 30, (dig @ns1.edns.t-ipnet.de srv _sip._udp.tel.t-online.de) die SIP-Trunk Einträge waren bei mir innerhalb kurzer Zeit in unterschiedlicher Reihenfolge (dig @dns00.dns.t-ipnet.de srv _sip._tcp.reg.sip-trunk.telekom.de). Ich weiß dass das nicht viel zu heißen hat, auch die Privatkundeneinträge könnten irgendwann ihre Reihenfolge wechseln.

Irgendwie scheint der PJSIP Resolver nicht das zu machen was die Dokumentation sagt. Immerhin hat hier: https://community.asterisk.org/t/pjsip-settings-for-two-german-telekom-products/79293/2 jemand das gleiche Problem und es wird vermutet dass der PJSIP Resolver anstatt der IP mit der höchsten Priorität lieber den ersten Eintrag nimmt. Das würde zu den Symptomen passen. Es ist dabei auch möglich dass eine neuere Asterisk oder besser gesagt PJSIP Version dies endlich richtig macht. Laut Doku nimmt PJSIP nämlich nicht den ersten Eintrag sondern den Eintrag mit der höchsten Priorität. Diese hat sich bei meinem kurzen Test bisher nicht geändert.

Allerdings müsste ich das automatisiert und viel länger testen um das jetzt mit Sicherheit sagen zu können. Am Ende liegt es an etwas ganz anderem. Vielleicht fällt der Resolver entgegen der Doku auch auf den A Eintrag im DNS zurück. Im Unterschied zum SIP-Trunk löst tel.t-online.de nämlich auch zu einem A Eintrag auf.
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
61
Punkte für Reaktionen
1
Punkte
8
Dann weiß ich nicht was mein Asterisk 15.5.0 / freepbx 14.0.5.25 haben sollte. Seit ich ihm nur noch einen SRV Eintrag vorsetze funktioniert alles. Sobald ich den DNS Hack entferne werden ausgehende Anrufe nach einiger Zeit blockiert. Ich habe es soweit debugged dass ich gesehen habe dass ausgehende Anrufe an eine andere Server-IP gehen und dieser Server dann mit "forbidden" antwortet. Ich wüsste nicht was es sonst sein sollte.
Ab Asterisk 14 sollte das grundsätzlich sogar schon gehen. Dann ist das ein Bug. Ich hatte das mit der 13er grundsätzlich auch - aber die konnte auch offiziell nicht damit umgehen. Allerdings ist mir das im Zusammenhang mit meinem lokalen Bind praktisch nie untergekommen. Wahrscheinlich hat der für Stabilität gesorgt, indem die Reihenfolge nie geändert wurde.

Es gibt dabei nur Probleme wenn sich die Reihenfolge der SRV Einträge im DNS ändert.
Was Du beschreibst ist aus meiner Sicht ganz klar ein Bug, den ich bisher mit Asterisk 16 noch nicht nachvollziehen konnte. Ich überwache aber trotzdem mal jetzt den kompletten relevanten DNS-Verkehr dauerhaft, damit ich was in der Hand habe, falls das Problem auftritt (ich werde dann einen Bug eröffnen). Außerdem schaue ich immer wieder mal rein, um zu sehen, ob sich da über die Zeit Änderungen im Ergebnis ergeben haben.

Irgendwie scheint der PJSIP Resolver nicht das zu machen was die Dokumentation sagt. Immerhin hat hier: https://community.asterisk.org/t/pjsip-settings-for-two-german-telekom-products/79293/2 jemand das gleiche Problem und es wird vermutet dass der PJSIP Resolver anstatt der IP mit der höchsten Priorität lieber den ersten Eintrag nimmt.
Zumindest mit Asterisk 16 kann ich das (bis dato) nicht bestätigen. PJSIP ist an dieser Stelle irrelevant, weil Asterisk seinen eigenen Resolver verwendet.

Allerdings müsste ich das automatisiert und viel länger testen um das jetzt mit Sicherheit sagen zu können. Am Ende liegt es an etwas ganz anderem. Vielleicht fällt der Resolver entgegen der Doku auch auf den A Eintrag im DNS zurück. Im Unterschied zum SIP-Trunk löst tel.t-online.de nämlich auch zu einem A Eintrag auf.
Damit wäre das Problem bei ALLIP ja noch größer und beim professionellen SIP-Trunk würde es das dann ja gar nicht geben?

Wie auch immer, ich poste hier mal für alle Interessierten meine komplette relevante Konfig und das hiermit bei mir vorhandene Verhalten (für die ALLIP-Consumer-Variante mit SIPS und ohne RTP-Verschlüsselung):

Basis: CentOS 7
FreePBX: 14
Code:
rpm -q unbound-libs-1.6.6-1.el7.x86_64

lsof | grep unbound
asterisk   3182  9047 asterisk  mem       REG              253,0   1070376    9120474 /usr/lib64/libunbound.so.2.5.5
=> Asterisk arbeitet mit unbound!

Durchgeführte relevante Queries (gegen den Telekom-Nameserver):
Queries
    tel.t-online.de: type A, class IN
Answers
    tel.t-online.de: type A, class IN, addr 217.0.27.53

Queries
    _sips._tcp.tel.t-online.de: type SRV, class IN

Answers
    _sips._tcp.tel.t-online.de: type SRV, class IN, priority 20, weight 0, port 5061, target h2-eps-100.edns.t-ipnet.de
    _sips._tcp.tel.t-online.de: type SRV, class IN, priority 10, weight 0, port 5061, target s-eps-110.edns.t-ipnet.de
    _sips._tcp.tel.t-online.de: type SRV, class IN, priority 30, weight 0, port 5061, target d-eps-100.edns.t-ipnet.de

Die werden aufgelöst:
Answers
    s-eps-110.edns.t-ipnet.de: type A, class IN, addr 217.0.20.195

Answers
    d-eps-100.edns.t-ipnet.de: type A, class IN, addr 217.0.28.34

Answers
    h2-eps-100.edns.t-ipnet.de: type A, class IN, addr 217.0.29.36


Damit geht Asterisk wie folgt um:
Register:
<--- Transmitting SIP request (612 bytes) to TLS:217.0.20.195:5061 --->
REGISTER sip:tel.t-online.de SIP/2.0

Outbound Call:
<--- Transmitting SIP request (1272 bytes) to TLS:217.0.20.195:5061 --->
INVITE sip:[email protected] SIP/2.0

# netstat -tpn |grep 5061
tcp        0      0 93.235.x.y:12393     217.0.20.195:5061       VERBUNDEN   3182/asterisk

=> Alles verweist auf die korrekte IP 217.0.20.195 - es hat auch die korrekte Auswahl stattgefunden, trotz abweichender Reihenfolge (die 217.0.20.195 ist auf Basis der Ergebnisliste der zweite von drei Einträgen)!


Einstellungen in FreePBX 14:
Connectivity -> Trunks
Nummer 1 der Telekom

PJSIP Settings -> General
Username: +49... (vollständig zu registrierende eigene Nummer)
Secret: geheim
Authentication: Outbound
Registration: Send
SIP Server: tel.t-online.de
SIP Server Port: 5061
Context: from-pstn
Transport: 0.0.0.0-tls

PJSIP Settings -> Advanced
Permanent Auth Rejection: Yes
Forbidden Retry Interval: 10
Fatal Retry Interval: 0
General Retry Interval: 60
Expiration: 3600
Max Retries: 10000
Qualify Frequency: 240
Outbound Proxy: [leer]
Contact User: +49.... (vollständig zu registrierende eigene Nummer)
From Domain: tel.t-online.de
From User: +49.... (vollständig zu registrierende eigene Nummer)
Client URI: sip:[email protected]
Server URI: sip:tel.t-online.de
Media Address: [leer]
AOR: [leer]
AOR Contact: sip:[email protected]


Config für bind
# rpm -q bind
bind-9.9.4-73.el7_6.x86_64:

# cat /etc/named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
        listen-on port 53 { 192.168.45.13; };
        # listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query             { 192.168.45.13; };
        allow-query-cache       { 192.168.45.13; };
        recursion yes;

        dnssec-enable yes;
        dnssec-validation auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";

};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

zone "t-online.de" IN {
        type forward;
        forwarders { [die im Rahme des ppp-Login zugewiesenen DNS-Server] };
        forward only;
};

zone "t-ipnet.de" IN {
        type forward;
        forwarders { [die im Rahme des ppp-Login zugewiesenen DNS-Server] };
        forward only;
};

zone "dtag.de" IN {
        type forward;
        forwarders { [die im Rahme des ppp-Login zugewiesenen DNS-Server] };
        forward only;
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
[Edit Novize: Configs in [ code ] Tags gefasst - das erleifchtert die Lesbarkeit doch immens ;)]
Die /etc/resolv.conf auf den Listener des bind richten, hier im Beispiel:
nameserver 192.168.45.13;

-- Aktualisiert --

Es gibt dabei nur Probleme wenn sich die Reihenfolge der SRV Einträge im DNS ändert. Wenn ich mit dig die SRV Einträge abrufe sind die Privatkundeneinträge immer in der gleichen Reihenfolge, mit Priorität 10 20 30, (dig @ns1.edns.t-ipnet.de srv _sip._udp.tel.t-online.de) die SIP-Trunk Einträge waren bei mir innerhalb kurzer Zeit in unterschiedlicher Reihenfolge (dig @dns00.dns.t-ipnet.de srv _sip._tcp.reg.sip-trunk.telekom.de). Ich weiß dass das nicht viel zu heißen hat, auch die Privatkundeneinträge könnten irgendwann ihre Reihenfolge wechseln.
Gerade mal gegen meinen eigenen DNS getestet (über den geht ja auch Asterisk 16 hier):

dig srv _sips._tcp.tel.t-online.de​

=> Das Ergebnis ist bei so gut wie jedem Aufruf in anderer Reihenfolge, was die 3 Server angeht. Ich konnte aber bisher trotzdem noch absolut kein Problem feststellen. Aber vielleicht kommt es ja noch - so viele Outbound-Calls habe ich auch wieder nicht. Von daher könnte es auch grundsätzlich sein, dass ich das (temporäre) Problem nur nicht bemerke. Ich hatte es aber selbst mit Asterisk 13 nicht (was ja offiziell noch gar nicht damit umgehen konnte).

Ach ja, zumindest vor Asterisk 14 konnte man ja noch steuern, auf welche Weise man den Lookup machen wollte. Wird ab Asterisk 14 aufwärts wohl nicht mehr gehen, da ja ein anderer Resolver zum Einsatz kommt. Aber vielleicht trotzdem mal testen?
 
Zuletzt bearbeitet von einem Moderator:

reinhardmunz

Neuer User
Mitglied seit
15 Feb 2018
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
@gehtdoch: Du hast Recht. Die Reihenfolge scheint egal, nur die Prioritäten scheinen ausschlaggebend. Ich habe es zwar nicht abschließend getestet, aber auf die schnelle hat mein Asterisk keine Probleme wenn ich ihm mehrere SRV Records vorsetze. Die Reihenfolge ändert sich dabei bei jeder Abfrage. Die Prioritäten bleiben jedoch pro Eintrag gleich.

Anrufe werden erst geblockt wenn ich die Prioritäten tausche. Es scheint also kein Bug in Asterisk. Er nimmt für ausgehende Anrufe den Server mit der höchsten Priorität. Also entweder war (1) beim Aufsetzen der Maschine damals ein anderer Bug in Asterisk und durch ein Update wurde der behoben, oder (2) bei der Telekom haben sich manchmal die Prioritäten geändert, oder (3) der Server mit der höchsten Priorität war kurz nicht erreichbar und Asterisk ist zum nächstbesten gegangen. Da wir seit ich nur einen Eintrag vortäusche nie wieder Probleme hatten würde ich Nummer 3 fast ausschließen. Ich würde in dem Fall auf Nummer (2) tippen.

Unabhängig davon woran es damals bei mir lag geht es erwiesenermaßen jetzt schief wenn sich die Prioritäten ändern. Das ist allerdings valides DNS Verhalten auch wenn es selten oder vielleicht nie vorkommt. Gibt es bei Asterisk eine Konfigurationsmöglichkeit um ausgehende Anrufe immer an die IP zu senden bei der man registriert ist? Nur dadurch könnte man das Verhalten der Telekomserver bei einem Wechsel der SRV Prioritäten handhaben.
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
61
Punkte für Reaktionen
1
Punkte
8
@gehtdoch:
Unabhängig davon woran es damals bei mir lag geht es erwiesenermaßen jetzt schief wenn sich die Prioritäten ändern. Das ist allerdings valides DNS Verhalten auch wenn es selten oder vielleicht nie vorkommt. Gibt es bei Asterisk eine Konfigurationsmöglichkeit um ausgehende Anrufe immer an die IP zu senden bei der man registriert ist? Nur dadurch könnte man das Verhalten der Telekomserver bei einem Wechsel der SRV Prioritäten handhaben.
Genau das kam mir gerade beim Rasenmähen in den Sinn - das wäre ein klarer Bug in Asterisk (habe da gerade eine entsprechende Anfrage gestellt hinsichtlich des exakten Handlings).
Ich habe nämlich den Verdacht, dass folgende race condition vorliegt:

Startzeitpunkt: REGISTER zu IP 1 (Timeout: 660s)
300s später: outbound call: Asterisk macht einen dedizierten lookup für den INVITE - der Server vom REGISTER ist nicht mehr im Ergebnis (oder andere PRIO) und Asterisk verwendet dann IP 2 für den outbound call, ohne vorher ein REGISTER mit dieser neuen IP 2 durchgeführt zu haben (weil er die Differenz nicht prüft).
Mal sehen, was bei meiner Anfrage rauskommt.
Die Lösung würde entweder darin bestehen, die Differenz zu erkennen oder eben grundsätzlich für den INVITE die gleiche IP wie für den REGISTER zu verwenden.

Ich könnte mir auch noch folgende race condition vorstellen:
Es ist ja wahrscheinlich mehr als 1 Nummer registriert. Die REGISTERS der einzelnen Nummern können aber zeitlich auseinanderlaufen, so dass es passieren kann, dass 1 Nummer schon bei der neuen IP ist und die anderen noch bei der alten. Wenn asterisk nun die IPs jetzt einmalig pro Destination ablegt, wird's natürlich blöd ... . Mal sehen.
 

reinhardmunz

Neuer User
Mitglied seit
15 Feb 2018
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
das wäre ein klarer Bug in Asterisk
Ich bin mir nicht sicher ob das wirklich ein Bug ist. Ich glaube dass man von Asterisk Seite die Annahme macht, dass hinter allen verteilten SIP Servern aus dem DNS eine verteilte Datenbank stehen muss und alle Server immer über alles Bescheid wissen. Es ist unter dieser Annahme egal bei welchem Server ich mich registriere, zu welchem ich OPTIONS schicke und zu welchem INVITE. Ich glaube nicht, dass irgendein Standard diese Annahme explizit verbietet. Es ist unter dieser Annahme konform zu sagen dass man sich bei IP 1 registrierst aber aus welchen Gründen auch immer später zu IP 2 ein INVITE schickt. REGISTER ist dachte ich auch eigentlich dazu gedacht dem anderen System zu sagen wo eingehende Anrufe hingeschickt werden müssen und nicht um eine pre-authorisierung von ausgehenden Anrufen durchzuführen.

Von Telekom Seite her scheint allerdings die Annahme zu gelten, dass man sich am Anfang einen Server aussucht. Mit diesem Server registriert man sich und nur dieser Server sendet dann eingehende Anrufe und nur dieser Server akzeptiert andere Kommunikation (OPTIONS, INVITE). Ich denke diese Annahme vereinfacht die Implementierung immens. Auch dieses Verhalten widerspricht denke ich keinem Standard.

Leider sind beide Annahmen jedoch nicht kompatibel. Generell scheint mir die Annahme von Asterisk allgemeingültige, fehlertoleranter, und für "dümmere" Clients geeigneter. Bei der Telekom müssen die Clients intelligenter sein und so gesehen eine "Session" mit einem Server aufrechterhalten. Bei der Telekom scheint auch der Client erkennen zu müssen wenn der Server ausgefallen ist und dann aktiv eine neue "Session" mit einem anderen Server aufbauen. Wobei das ins Blaue hineingeraten ist. Solange die Telekom Systeme hinter den einzelnen DNS Namen ausfallsicher sind liege ich nämlich falsch. Allerdings würde ich mich dann wundern warum die Daten in dem Fall zwischen Haupt- und Backupsystem synchronisiert werden können, zwischen den Hauptsystemen jedoch nicht synchronisiert werden können.

Solange beide Seiten auf ihren Annahmen beharren wird es keine optimale Lösung geben.

Hört sich für mich so an als sollte ich meinen DNS Hack noch ein bisschen weiter pflegen. :)
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
61
Punkte für Reaktionen
1
Punkte
8
Kann ich nachvollziehen. Ich kann aber auch nachvollziehen, wie die Telekom vorgeht: viele "kleine", möglichst unabhängig laufende verteilte Systeme - das hält den Schaden gering (was die Anzahl der betroffenen User angeht) bei Ausfällen und sorgt gleichzeitig für ordentliche Performance und Qualität. Andererseits muss der Client eben intelligenter sein - die HA-Fähigkeit wird auf den Client verschoben. Außerdem kann man aus einer großen Zahl an Maschinen einfach welche (geplant) rausnehmen - einfach aus dem DNS nehmen und leer laufen lassen.

Ich habe übrigens schon die Info, dass es tatsächlich so ist, wie ich vermutet habe: im Rahmen eines outbound calls wird ein Lookup gemacht - aber nicht geprüft, ob der ein anderes Ergebnis hat als der bestehende REGISTER-Connect. Jetzt geht es darum, ob die Anforderung zur Optimierung (die Destinations für REGISTER und INVITE gleichzuhalten) als Featurerequest durchgeht (sieht eher schlecht aus derzeit).

Dein Workaround mit einer quasi festen IP behebt das Problem auch nicht wirklich. Irgendwann verschwindet die IP - dann hast Du den Switch und damit den Race auch. Verschwinden kann im Rahmen eines geplanten Changes durchaus regelmäßig möglich sein ... bei der Menge an "Maschinen" kann ich mir das durchaus öfter vorstellen.

Länger als 11 Minuten sollte der Fehler allerdings nicht anhalten - spätestens nach dem REGISTER timeout sollte es wieder gehen. Aber 11 Minuten sind natürlich schon ziemlich viel gefühlt. Vielleicht kannst Du ja versuchen, die TTL des REGISTER zu überschreiben - sprich, zu kürzen (falls das überhaupt geht - wahrscheinlich lässt das Asterisk nicht zu, weil der ja im OK der Telekom mitkommt). Würde die Telekom allerdings vermutlich auch nicht toll finden.
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
11,307
Punkte für Reaktionen
187
Punkte
63
Moinsen


Vielleicht kannst Du ja versuchen, die TTL des REGISTER zu überschreiben - sprich, zu kürzen (falls das überhaupt geht - wahrscheinlich lässt das Asterisk nicht zu, weil der ja im OK der Telekom mitkommt). Würde die Telekom allerdings vermutlich auch nicht toll finden.
Nennt sich Expire.
SIP Server können so konfiguriert werden, dass es eine Minimale und eine Maximale Expiry gibt und Klienten können normalerweise schon eine Wunschexpiry ( zwischen Min/Max ) anfordern.
Code:
  Reg. min duration       300 secs
  Reg. max duration:      7200 secs
  Reg. default duration:  300 secs
( Aus Asterisk: sip show settings )
Es bestimmt immer der SIP Server ob er dies auch macht.
 

Zurzeit aktive Besucher

3CX PBX - GRATIS
Linux / Win / Cloud

Neueste Beiträge

Statistik des Forums

Themen
232,385
Beiträge
2,021,836
Mitglieder
349,993
Neuestes Mitglied
pierps