[Gelöst] FreePBX Plötzlich keine ausgehenden Verbindungen mehr (Telekom)

[qupfer2]

Hi,

ich bräuchte mal Unterstützung bzw. Hilfe. Seit heute kann ich keine Verbindungen mehr nach außen aufbauen. Einkommende klappen nach wie vor. Auch nach Neustart.
Habe auch mal den Transport von UDP auf TLS geändert, ohne Änderung.

Weiß auch nicht so recht, wo/wie ich mit Debuggen anfangen kann.

pjsip show endpoint zeigt auch an, dass der Endpunkt nicht verfügbar ist.
Gestern lief noch alles und es wurden auch keine Updates eingespielt oder andere Veränderungen durchgeführt.

Der Tarif ist: DeutschlandLAN IP Start Premium

Endpoint:  123-pjsip                                          Unavailable   0 of inf
    OutAuth:  123-pjsip/+491234567
        Aor:  123-pjsip                                        0
      Contact:  123-pjsip/sip:[email protected] 769c17ed98 Unavail         nan
  Transport:  0.0.0.0-tls               tls      3     96  0.0.0.0:5061
   Identify:  123-pjsip/123-pjsip
        Match: 217.0.25.97/32
        Match: 217.0.29.32/32
        Match: 217.0.28.32/32
        Match: 217.0.25.99/32
        Match: 217.0.29.36/32
        Match: 217.0.28.34/32


ParameterName                      : ParameterValue
=========================================================
100rel                             : yes
accept_multiple_sdp_answers        : false
accountcode                        : 
acl                                : 
aggregate_mwi                      : true
allow                              : (g722|alaw|gsm)
allow_overlap                      : true
allow_subscribe                    : true
allow_transfer                     : true
allow_unauthenticated_options      : false
aors                               : 123-pjsip
asymmetric_rtp_codec               : false
auth                               : 
bind_rtp_to_media_address          : false
bundle                             : false
call_group                         : 
callerid                           : <unknown>
callerid_privacy                   : allowed_not_screened
callerid_tag                       : 
connected_line_method              : invite
contact_acl                        : 
contact_user                       : +491234567
context                            : from-pstn
cos_audio                          : 0
cos_video                          : 0
device_state_busy_at               : 0
direct_media                       : false
direct_media_glare_mitigation      : none
direct_media_method                : invite
disable_direct_media_on_nat        : false
dtls_auto_generate_cert            : No
dtls_ca_file                       : 
dtls_ca_path                       : 
dtls_cert_file                     : 
dtls_cipher                        : 
dtls_fingerprint                   : SHA-256
dtls_private_key                   : 
dtls_rekey                         : 0
dtls_setup                         : active
dtls_verify                        : No
dtmf_mode                          : rfc4733
fax_detect                         : false
fax_detect_timeout                 : 0
follow_early_media_fork            : true
force_avp                          : false
force_rport                        : true
from_domain                        : tel.t-online.de
from_user                          : +491234567
g726_non_standard                  : false
ice_support                        : false
identify_by                        : username,ip
ignore_183_without_sdp             : false
inband_progress                    : false
incoming_mwi_mailbox               : 
language                           : en
mailboxes                          : 
max_audio_streams                  : 1
max_video_streams                  : 1
media_address                      : 
media_encryption                   : no
media_encryption_optimistic        : false
media_use_received_transport       : false
message_context                    : 
moh_passthrough                    : false
moh_suggest                        : default
mwi_from_user                      : 
mwi_subscribe_replaces_unsolicited : no
named_call_group                   : 
named_pickup_group                 : 
notify_early_inuse_ringing         : false
one_touch_recording                : false
outbound_auth                      : 123-pjsip
outbound_proxy                     : 
pickup_group                       : 
preferred_codec_only               : false
record_off_feature                 : automixmon
record_on_feature                  : automixmon
refer_blind_progress               : true
rewrite_contact                    : true
rpid_immediate                     : false
rtcp_mux                           : false
rtp_engine                         : asterisk
rtp_ipv6                           : false
rtp_keepalive                      : 0
rtp_symmetric                      : true
rtp_timeout                        : 0
rtp_timeout_hold                   : 0
sdp_owner                          : -
sdp_session                        : Asterisk
send_connected_line                : no
send_diversion                     : true
send_history_info                  : false
send_pai                           : false
send_rpid                          : false
set_var                            : 
srtp_tag_32                        : false
stir_shaken                        : false
sub_min_expiry                     : 0
subscribe_context                  : 
suppress_q850_reason_headers       : false
t38_udptl                          : true
t38_udptl_ec                       : redundancy
t38_udptl_ipv6                     : false
t38_udptl_maxdatagram              : 0
t38_udptl_nat                      : true
timers                             : yes
timers_min_se                      : 90
timers_sess_expires                : 1800
tone_zone                          : 
tos_audio                          : 0
tos_video                          : 0
transport                          : 0.0.0.0-tls
trust_connected_line               : yes
trust_id_inbound                   : false
trust_id_outbound                  : false
use_avpf                           : false
use_ptime                          : false
user_eq_phone                      : false
voicemail_extension                : 
webrtc                             : no

 

[Meester Proper]

Ohne Mediasec-Patch kann SIP over TLS nicht genutzt werden.

Kann es sein, dass du die Umstellung von A-Records auf NAPTR/SRV-Records verschlafen hast?
Was sagt denn ein Packet-Trace (PCAP)?

Ich würde wie folgt bei der Entstörung vorgehen und dabei folgende Fragen prüfen?
1. Funktioniert die DNS-Abfrage?
2. Ist die Registrierung erfolgreich?
3. Was passiert bei ausgehenden Rufen? Werden ausgehende INVITES generiert und wenn ja, wie werden diese beantwortet?

 

[gehtdoch]

Ohne Mediasec-Patch kann SIP over TLS nicht genutzt werden.

Oh, habe ich da was verpasst? Dachte, mediasec wird nur zur Verschlüsselung des RTP-Streams benötigt? Ich muss allerdings zugeben, dass ich schon länger kein TLS-only - Signaling mehr gefahren habe.

qupfer2:

pjsip show registrations

ist erstmal relevant.

Dann solltest Du in /etc/asterisk/logger_logfiles_custom.conf das Logging für pjsip aktivieren:

pjsip.log => debug

Was steht da drin (das File findest Du unter /var/log/asterisk normalerweise bei Sangoma-CentOS Systemen) im Rahmen einer Registrierung?

Dann solltest Du das Logging von Asterisk allgemein erhöhen:

core set verbose 5 (Ausschalten mit off)
core set debug 5 (Ausshalten mit off)
pjsip set logger on (Aushalten mit off)
pjsip set verbose on

Was kommt da dann im Rahmen der Registrierung (kommt so nur auf der Konsole - nimm also eine ordentliche Konsole wie die von KDE z.B. (das Programm heißt da Konsole - damit kannst Du sogar direkt im Output suchen - zumindest in den aktuellen Versionen))? Du kannst diese erzwingen mit

pjsip send unregister [DeinTrunkname]
pjsip send register [DeinTrunkname]

Ich vermute allerdings, dass bereits der unregister nicht durchgeht, weil ich glaube, dass Du ein NAT-Problem hast (falls Du NAT nutzt). Siehe Tips zu NAT hier.

Noch was zur Konfig mit den Matches:
Die kannst Du Dir sparen, wenn Du das line-Feature nutzt. Siehe hier. Das ist die erheblich einfachere und erheblich sicherere Variante (damit ist auch die Zuordnung zu den einzelnen Trunks, falls Du mehrere Rufnummern registriert haben solltest, absolut sicher gewährleistet).

 

[qupfer2]

Ohne Mediasec-Patch kann SIP over TLS nicht genutzt werden.

Kann es sein, dass du die Umstellung von A-Records auf NAPTR/SRV-Records verschlafen hast?
Was sagt denn ein Packet-Trace (PCAP)?

Ich würde wie folgt bei der Entstörung vorgehen und dabei folgende Fragen prüfen?
1. Funktioniert die DNS-Abfrage?
2. Ist die Registrierung erfolgreich?
3. Was passiert bei ausgehenden Rufen? Werden ausgehende INVITES generiert und wenn ja, wie werden diese beantwortet?

Zur ersten Antwort:

Glaube nicht, dass es am DNS liegt. Möchte ich aber nicht auschließen. Kann ich das irgendwie verbindlich prüfen?
1. jup
2. jup
3. es werden keine invites generiert, log folgt gleich

Zweite Antwort gehe ich gerade durch

 

[gehtdoch]

Glaube nicht, dass es am DNS liegt. Möchte ich aber nicht auschließen. Kann ich das irgendwie verbindlich prüfen?

dig +noall +answer tel.t-online.de NAPTR

Dann für TLS:
dig +noall +answer _sips._tcp.tel.t-online.de SRV
oder für TCP
dig +noall +answer _sip._tcp.tel.t-online.de SRV
oder für UDP
dig +noall +answer _sip._udp.tel.t-online.de SRV

Update:
Da Du eingehende Verbindungen bekommst, muss die Registrierung funktionieren - sonst würdest Du keine eingehenden Calls bekommen.

Bei den SRV-Auflösungen kommen in der Regel 3 Server als Antwort. Wichtig für ausgehende Calls ist, dass Asterisk dafür den gleichen Zielserver verwendet, wie den, zu dem er registriert ist. Das kann Asterisk nicht. Daher prüfe mal, ob der ausgehende Call zum gleichen Server geht wie die Registrierung.

 

[qupfer2]

Vielen, vielen Dank für eure ganzen Hinweise. Werde morgen der Sache auf dem Grund gehen.
Das mit den verschiedenen Servern klingt plausibel.

 

[chrsto]

Ich würde da erstmal nicht zu viel Arbeit reinstecken. Es gab gestern eine Störung bei der Telekom die einzelne Geschäftskunden betraf. Da fällst du mit deinem Tarif auch drunter.
Fehlerbild ist wie beschrieben. Abgehend nicht möglich, ankommend schon. Der Fehler wurde diese Nacht behoben.

Die Störung wurde behoben.

• In Einzelfällen kann es vorkommen, dass VoiP Rufnummern sich nicht registrieren. Ein Restart des Routers kann helfen.
• Hat der Kunde eine manuelle Konfiguration durchgeführt und für den Sprachdienst eine spezielle IP ausgewählt, soll er bitte das Ziel "tel.t-online.de "eintragen, um das Problem zu beheben.

 

[qupfer2]

Jup, heute morgen ging es auch wieder ;-)

Aber trotzdem Danke für die Unterstützung. Habe noch einiges über Asterisk gelernt

Wobei ich gestern Abend auch noch die /etc/hosts neu geschrieben und um die Hostnamen der einzelnen Server ergänzt habe.

217.0.28.32 tel.t-online.de d-epp-100.edns.t-ipnet.de h2-epp-100.edns.t-ipnet.de n-epp-110.edns.t-ipnet.de

Vielleicht lag es doch auch daran, weil registrieren ging ja (was ja laut Störungsmeldung nicht hätte gehen sollen)

 

[Meester Proper]

Ich würde da erstmal nicht zu viel Arbeit reinstecken. Es gab gestern eine Störung bei der Telekom die einzelne Geschäftskunden betraf. Da fällst du mit deinem Tarif auch drunter.
Fehlerbild ist wie beschrieben. Abgehend nicht möglich, ankommend schon. Der Fehler wurde diese Nacht behoben.

Diese Störung betraf nur Kunden, deren Router/Telefonanlagen kein korrektes Failover beherrschten.
Es war nämlich ein Standort gestört. Da per SRV-Abfrage drei Proxys geliefert werden, sollten einfach die anderen beiden genutzt werden. Das hat aber offenbar nicht bei allen Endgeräten korrekt funktioniert.
Der nicht funktionierende Standort / Proxy wurde nun über Nacht aus der DNS-Auflösung entfernt.

 

[gehtdoch]

Heute hatte ich das von Meester Proper beschriebene Szenario erleben dürfen (allerdings zu einer anderen Zeit), weil meine Überwachung angeschlagen hat, die ich hier in groben Zügen schon vor langer Zeit mal beschrieben habe:

• Aktiver call bis 11:01:19
• 11:00:00 dns change detected
• Aug 11 11:00:02 localhost check-t-online[22490]: There are active calls - try again 60s later ..
  Aug 11 11:01:02 localhost check-t-online[22565]: There are active calls - try again 60s later ..
• Aug 11 11:02:02 localhost check-t-online[23412]: unregister trunk entries ...
• Update RPZ
• Aug 11 11:02:05 localhost check-t-online[23426]: register trunk entries ...
• Aug 11 11:02:11 localhost named[1406]: client @0x7f363c0d5780 192.168.6.170#48494 (tel.t-online.de): rpz QNAME Local-Data rewrite tel.t-online.de via tel.t-online.de.rpz-tonline (-> Anfrage von Asterisk für den Register)

=> Damit war die nicht bemerkte Offlinezeit 9s (die meiste Zeit verstrich seitens Asterisk, bis er den Register-Befehl umgesetzt hat - 6s)

Einige Zeit später wurde dann der ursprünglich vorhandene Server wieder eingesetzt - gleiches Spielchen also nochmal.

Damit hat sich gezeigt, dass mein beschriebenes Vorgehen sauber arbeitet und kein relevanter Ausfall entstanden ist. Eine wie auch immer gelagerte statische Lösung führt unweigerlich zum dauerhaften Ausfall, wenn der betroffene Server entfernt wird oder eben kaputt ist.

Was ich bisher noch nicht umgesetzt habe, ist, das Logfile von Asterisk miteinzubeziehen, um auch timeouts, falls sie wiederholt auftreten, zu erkennen, um dann den derzeit aktiven Server selbständig aus der Liste zu nehmen - falls es die Telekom nicht macht.

Da per SRV-Abfrage drei Proxys geliefert werden, sollten einfach die anderen beiden genutzt werden. Das hat aber offenbar nicht bei allen Endgeräten korrekt funktioniert.
Der nicht funktionierende Standort / Proxy wurde nun über Nacht aus der DNS-Auflösung entfernt.

Dass ihr den halblebigen Server aus der Liste genommen habt, war die vollkommen korrekte Entscheidung. Wie soll denn ein Client das Szenario vernünftig managen mit einem halblebigen Server? Wenn ein Register durchgeht, muss der Client ja davon ausgehen, dass der Server ok ist - er kann ja nicht ahnen, dass später ein ausgehender Call z.B. in den Wald läuft oder evtl. noch später in einem bereits laufenden Call das Sessionhandling den Bach runter geht und der Call dann deshalb abbricht.

Daher muss ein wie auch immer nicht einwandfrei funktionierender Server grundsätzlich aus der Liste genommen werden! Alles andere führt zwangsweise zu Ärger.

@qupfer2:
Dein Szenario entstand dann wahrscheinlich dadurch, dass der Register mit dem damaligen zweiten Server der Liste durchging (der erste hat nicht funktioniert - daher ist Asterisk auf den 2. ausgewichen). Danach hat sich der erste Server in der Liste wieder beruhigt (oder dort gingen nur Registrierungen nicht - wie auch immer - halblebig eben) und Asterisk hat den nächsten ausgehenden Call wieder zum ersten Server geschickt - und der hat ihn abgelehnt (was kein Grund ist für Asterisk, zum zweiten Server zu gehen), weil Du dort nicht registriert warst (Asterisk kennt keine Abhängigkeit zwischen registriertem Server und den später nachfolgenden Requests).
Eingehende Calls funktionieren (zumindest unter bestimmten Bedingungen), weil die ja von dem Server kommen, an dem sich Asterisk registriert hat.

 

[Meester Proper]

Dass ihr den halblebigen Server aus der Liste genommen habt, war die vollkommen korrekte Entscheidung. Wie soll denn ein Client das Szenario vernünftig managen mit einem halblebigen Server? Wenn ein Register durchgeht, muss der Client ja davon ausgehen, dass der Server ok ist - er kann ja nicht ahnen, dass später ein ausgehender Call z.B. in den Wald läuft oder evtl. noch später in einem bereits laufenden Call das Sessionhandling den Bach runter geht und der Call dann deshalb abbricht.

Daher muss ein wie auch immer nicht einwandfrei funktionierender Server grundsätzlich aus der Liste genommen werden! Alles andere führt zwangsweise zu Ärger.

Mir ist nichts von einem "halblebendigen Server" bekannt, nur von einem kompletten Ausfall eines Standortes.

 

[gehtdoch]

Mir ist nichts von einem "halblebendigen Server" bekannt, nur von einem kompletten Ausfall eines Standortes.

Mir ging es nicht darum, festzustellen, was im Detail passiert ist (das weiß ich nicht und ich wollte Deine Aussage auch keineswegs auch nur ansatzweise in Abrede stellen. Ich gebe zu, dass ich das nicht explizit geschrieben habe - ich war gedanklich schon zu weit beim Grundsätzlichen).

Für das grundsätzliche Fehlerszenario an sich ist es aber relativ irrelevant, ob und was am Ende des Tages alles halb oder ganz kaputt ist - die Auswirkung für den Client bleibt (von Details abgesehen) immer das Gleiche: es funktioniert eben nicht mehr, wie es soll und der Client hat so oder so keine Chance, mit der Situation sinnvoll umzugehen (woher soll er denn als weiteres Bsp. wissen, wann der Server wieder ok ist und er ihn wieder nehmen kann, wenn er nie verschwunden ist - das ist doch reine Orakelei). Daher ist zwingend nötig, dass ein Server, genauer, dessen Eintrag im DNS, verschwinden muss, wenn er (was auch immer die Ursache ist) aus Sicht des Clients nicht mehr vollständig und verläßlich funktioniert.

 

[Meester Proper]

Aus meiner Sicht ist das ausreichend im Abschnitt 4.2.7.3 der 1TR114 beschrieben, wie das erwartete Verhalten ist.
Für das Retry-Verhalten wird letztendlich auf Abschnitt 4.5 von RFC 5626 verwiesen.

 

[sonyKatze]

Vielleicht sollte die Telekom überlegen, einen Test-Server einzurichten, der periodisch einen fehlerhaften Server enthält. Solch eine Flow-Recovery dürften nur wenige Implementierungen getestet haben (und solch ein Fehlerfall selbst aufzubauen bzw. zu simulieren dürfte für viele System-Integratoren zu schwierig sein).

 

[gehtdoch]

Vielleicht sollte die Telekom überlegen, einen Test-Server einzurichten,

Wäre eine coole Sache.

Abschnitt 4.5 von RFC 5626

RFC 5626 definiert den Begriff Flow als statische TCP oder UDP-Verbindung zwischen Client und Server, welche vom Client via Register geöffnet wird. Diese eine Verbindung wird in Folge sowohl vom Client als auch vom Server für die gesamte Kommunikation genutzt. Daraus ergibt sich logischerweise auch die Anforderung, dass alle nachfolgende Kommunikation zum selben Server geschickt werden muss.

Was heißt das auf Asterisk / pjsip gemapped?

• Asterisk kennt den Schalter support_outbound im outbound Register. Ist per default false, wenn man es aktiviert kommt der Header

  Supported: outbound

  dazu. In der Doku steht hierzu auch der Verweis auf RFC 5626.
• PJSIP selbst unterstützt RFC 5626 grundsätzlich und ist dort per default aktiviert - wird aber von Asterisk quasi umgangen, da trotzdem für jeden Invite z.B. ein DNS-Lookup erfolgt (Asterisk gerift ja an dieser Stelle nicht auf pjsip zurück, sondern macht das selbst) - was natürlich den grundsätzlichen Anforderungen eines Flows gemäß RFC 5626 widerspricht.

Ich kann im Code nicht erkennen, dass Asterisk mit "support_outbound" tatsächlich mehr macht als den Supported header einzuhängen im Register. Das erklärt dann auch wiederum das beobachtete Verhalten trotz Aktivierung von outbound. Der simple Verweis auf RFC 5626 in der Doku ist daher ziemlich irreführend - mit dem Schalter geht es de facto im Prinzip um tarnen, täuschen und ... .

Dass das Ganze trotzdem einigermaßen out of the box funktioniert im "Gewurstel" zwischen Asterisk und pjsip ist schon erstaunlich. Die exakten Grenzen zwischen den beiden (also: wer ist wofür im Detail zuständig und welche Wechselwirkungen entstehen daraus) ist mir derzeit noch nicht vollständig transparent. Immerhin ist es so, dass Asterisk darauf reagiert, wenn ein Flow auf transport-Ebene geschlossen wird (egal, ob jetzt durch pjsip veranlasst oder durch den Provider). Ich müsste mal testen, was passiert, wenn das Sessionhandling des Flows auf Fehler läuft (Szenario: plötzlich nicht mehr erreichbarer Server - der Client ist ja für die Aufrechterhaltung des Flows verantwortlich). Der Test sollte ja mit geeigneter Manipulation der Paketfilterregeln möglich sein (offene Verbindung nachträglich blockieren). Mal sehen.

Update 13.08.21 - 15:41 Uhr:
Ja, die Flowüberwachung schlägt immer noch nicht (Punkt 2) an. Damit wird ein Serverausfall erst nach Ablauf der reRegister-Zeit bemerkt und einem danach folgenden Timeout, bis sich pjsip dazu herabläßt, die Verbindung neu aufzubauen. Diese Timeouts (im Logfile protokoliiert) nehme ich nun zum Anlass, den defekten / nicht mehr erreichbaren Server zu blacklisten und damit einen neuen Server zu präsentieren. Mit dem sollte er ja dann sofort wieder loslegen. Mal sehen, was die Tests ergeben. Falls die positiv sind, kommt noch die Auswertung der SIP-Fehlermeldungen dran, bei denen die Telekom einen Change erwartet.