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?
