[gelöst] VoIP via Asterisk geht nach O2-Server-Umstellung nicht mehr

jmozd

Neuer User
Mitglied seit
14 Jul 2023
Beiträge
5
Punkte für Reaktionen
1
Punkte
1
Hallo allerseits,

seit Jahren nutzen wir einen O2-DSL-Anschluss (letzte technische Umstellung in 2020, VDSL), mit Zugang über Draytek Vigor als “Modem”, eigene Firewall und unter anderem einer Asterisk VoIP-Anlage.

Vor ca. drei Wochen war wieder einmal der Fall aufgetreten, dass nach einer 24h-Trennung (die trotz fester IP stattfindet) ein neuer O2-SIP-Server anzusprechen war. Das passiert alle paar Monate und wir haben einen “Prozess” zum Ermitteln der neuen IP und passender Änderung der Firewall etc. Normalerweise kann Asterisk danach wieder die Rufnummern registrieren und alles funktioniert wieder.

Nicht so dieses Mal: Wir sehen die SIP-Pakete (“register”) per UDP in Richtung O2-SIP-Server gehen, bekommen aber keine Antwort. Das “riecht” danach, dass sich Wunschwerte des SIP-Servers bzgl. der mit dem register mitgesandten Parameter geändert haben und es daher der Server nicht mehr für nötig hält, uns zumindest eine Ablehnung zu senden. Zumindest war das vor Jahren bei der Ersteinrichtung des Asterisk ein von uns beobachtetes Phänomen.

Mit der O2-Box konnten wir keine Telefonieverbindung herstellen (wurde aber auch nur für diesen Test frisch ausgepackt und entsprechend alt - wir hatten auch nach der VDSL-Umstellung gleich eigene hardware am Start), daraufhin schickte man uns einen Techniker, dessen Fritzbox beim ersten Start ebensowenig die VoIP-Registrierung schaffte, aber nach einem testweisen Neustart dann eben doch. Freundlicherweise liegt mir ein Abzug der von der FB ermittelten SIP-Konfiguration vor, bspw. findet sich dort die vor ein paar Wochen in einem thread bei O2 angesprochene jetzt notwendige Konfiguration des Proxy wieder (outboundproxy = "sip.alice-voip.de").

Findet sich hier jemand, dessen Telefonie auch über den O2-Server mit der IP 62.53.28.195 (erfolgreich) abgewickelt wird und mir einen (um private Daten bereinigten) Mitschnitt des “register”-Paketes zeigen kann? So hätte ich die Chance, die von unserer Anlage gesendeten Werte (und das TOS-Feld) gegenzuprüfen und ggf. die Konfiguration des Asterisk anzupassen.

Nach vielen Fehlversuchen mit unterschiedlichen Änderungen sehen unsere aktuellen “registers” so aus und bleiben weiterhin unbeantwortet:
Code:
21:01:41.524697 dsl0  Out IP (tos 0x68, ttl 63, id 35337, offset 0, flags [DF], proto UDP (17), length 666)
62.54.aa.bb.5060 > 62.53.28.195.5060: [udp sum ok] SIP, length: 638
REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP 62.54.aa.bb:5060;rport;branch=z9hG4bKPj971109ad-76c4-425d-8a22-7c0ec3aa8aaa
Route: <sip:sip.alice-voip.de;lr>
From: <sip:[email protected]>;tag=400811f9-66fb-4ca5-b2c2-49a35f201d8e
To: <sip:[email protected]>
Call-ID: e04a6bc7-11a5-467c-b41b-b0633786ee26
CSeq: 37555 REGISTER
Contact: <sip:[email protected]:5060;line=yimitvc>
Expires: 900
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: path
Max-Forwards: 70
User-Agent: Asterisk PBX 18.6.0
Content-Length:  0
Der Unterschied zu den ursprünglichen, jahrelang davor funktionierenden “register”-Paketen sind die beiden zusätzlichen header “Route” und “Supported: path”, zudem wurde als TOS-Wert “0x00” genutzt - bis vor der O2-Umstellung erfolgreich.
Es wundert mich, dass es bei uns “plötzlich” nicht mehr geht, jedoch ansonsten kein Aufschrei durch die Nutzerschar geht. Das klingt durchaus danach, dass der Fehler auf unserer Seite liegt und andere Nutzer (mit eigenen Anlagen) die Umstellung problemlos verkraftet haben.

Ich bin für jeden Hinweis dankbar.

Viele Grüße
Jens
PS: Bei Bedarf kann ich auch die von der Fritzbox ermittelten viop.cfg-Parameter beisteuern, wollte nur nicht gleich den ersten "post" überfrachten :)
 
Rückmeldung: Das Problem konnte gelöst werden.

Per Zufall gab es einen anderen Anschluss mit FritzBox, bei dem der DNS-Name “sip.alice-voip.de” auf die gleiche IP-Adresse aufgelöst wurde (62.53.28.195) und mir ein tcpdump des “REGISTER” zur Verfügung stand.

Nach etwas Augenwischerei fiel mir dann auf, dass die SIP-Kommunikation mit 62.52.28.195 stattfand (also ein anderes zweites Oktett!) und habe das testweise in unser System übernommen - sofort funktionierten unsere SIP-Verbindungen wieder.

Ein Gegencheck zeigt, dass auch bei uns weiterhin vom O2-DNS-Server die Auflösung zu 62.53.28.195 erfolgt und diese Adresse weiterhin nicht antwortet.

Da kommen zwei Fragen auf… woher hat die FritzBox die “richtige” IP, wenn nicht vom O2-DNS-Server (nutzt sie einen anderen Server?)… und wird uns das beim nächsten Wechsel wieder treffen? Eigentlich sollte doch der Name “sip.alice-voip.de” auf jene IP-Adresse auflösen, unter der der O2-VoIP-Server dann auch zu erreichen ist...
 
Zuletzt bearbeitet von einem Moderator:
Prinzipiell ist es denkbar, daß die FRITZ!Box tatsächlich einen anderen DNS-Server für den voipd verwendet - das hängt von der konkreten Konfiguration ab und die findet man (am ehesten) in den Supportdaten (bei der Suche nach SipIfaces).
 
Der Vollständigkeit halber kopier ich hier die Antwort rein, welche ich schon im O2-Community-Forum gepostet habe...

Ich habe dasselbe Problem mit meinem Asterisk auf meinem OpenWRT-System an einem VSDL-Anschluss, und habe deshalb rumgeforscht. Bin nicht sicher, ob ich die Ursache gefunden habe; es wird sich in den nächsten Tagen oder Wochen zeigen, ob die SIP-Registrierungen wieder zuverlässig funktionieren.

Also (alles unter Vorbehalt):
  • Um sip.alice-voip.de aufzulösen, muss ein Nameserver von O2 genutzt werden.
  • Darüberhinaus funktioniert das nicht dauerhaft stabil mit den über das PPP-Protokoll empfangenen Nameservern. Dort werden IPv4-Adressen von O2 übermittelt.
  • Stattdessen müssen die Nameserver genutzt werden, welche über das DHCPv6-Protokoll empfangen werden. Dort werden IPv6-Adressen von O2 übermittelt, und das wird in bestimmten Abständen auch aufgefrischt. Dazu läuft bei mir ein DHCPv6-Client (Programm “odhcp6c”).
Es gibt es ja noch dieses DHCPv6-Protokoll, was über die PPP-Verbindung läuft, und mit dem O2 gewisse weitere IPv6-Spezialitäten (z.B. auch den “delegated prefix”) übermittelt.

Ich habe jetzt deshalb bei mir das OpenWRT so konfiguriert, dass die PPP-empfangenen O2-Nameserver ignoriert werden. Nur die über DHCPv6 gemeldeten Nameserver werden dann von meinem Resolver dnsmasq genutzt.

Die O2-IPv6-Nameserver melden übrigens zur Zeit bei mir für sip.alice-voip.de immer noch eine IPv4-Adresse :), welche aber abweicht von der Adresse, welche die O2-IPv4-Server liefern.
 
[...]

Also (alles unter Vorbehalt):
  • [---]
  • Stattdessen müssen die Nameserver genutzt werden, welche über das DHCPv6-Protokoll empfangen werden.[...]
Vielen Dank für diese Rückmeldung - leider ist dies kein Allheilmittel, denn das Problem tritt an einem "IPv4 only"-Anschluss auf und dies lässt sich bei uns nicht ändern, da O2 die Merkmale "feste IPv4" und "Zuweisung eines IPv6 prefix" nicht zusammen freischalten will/kann.

Ich warte noch auf einen Mitschnitt aus dem FritzBox-Lager (ab dem initialen Aufbau der DSL-Verbindung) und werde dort versuchen herauszufinden, wie die FritzBox dazu kommt, eine andere als die vom Standard-O2-(IPv4)nameserver zurückgemeldete Adresse zu nutzen. Sobald ich dazu neue Erkenntnisse habe, melde ich die natürlich hier zurück.
 
werde dort versuchen herauszufinden, wie die FritzBox dazu kommt, eine andere als die vom Standard-O2-(IPv4)nameserver zurückgemeldete Adresse zu nutzen
Sehr wahrscheinlich wird da die Telefonie über eine zweite Verbindung mit einer anderen VLAN-ID bereitgestellt.
 
Vielen Dank für diese Rückmeldung - leider ist dies kein Allheilmittel, denn das Problem tritt an einem "IPv4 only"-Anschluss auf und dies lässt sich bei uns nicht ändern, da O2 die Merkmale "feste IPv4" und "Zuweisung eines IPv6 prefix" nicht zusammen freischalten will/kann.

Mit "Zuweisung eines IPv6 prefix" meinst Du vielleicht die Zuweisung eines delegated IPv6-Prefixes? Dies wird nur genutzt, wenn am Router ein oder mehrere LAN-Netze (z.B. normales WLAN und WLAN-Gastnetz) betrieben werden, und wenn diese auch öffentlich geroutete IPv6-Adressen verwenden sollen.

Du schreibst, dass Du das Draytek Vigor als Modem nutzt. Ich verstehe das so, dass Du dahinter dann noch den eigentlichen Router betreibst, auf welchem der PPP-Daemon läuft. Der bekommt bei Dir wirklich keine öffentliche IPv6-Adresse für die VDSL-Schnittstelle von O2 mitgeteilt?
(Evtl. muss eine vorhandene "noipv6"-Option aus der pppd-Konfiguration entfernt werden)
 
Zuletzt bearbeitet:
Der bekommt bei Dir wirklich keine öffentliche IPv6-Adresse für die VDSL-Schnittstelle von O2 mitgeteilt?
(Evtl. muss eine vorhandene "noipv6"-Option aus der pppd-Konfiguration entfernt werden)
Hallo arnysch,
die pppd-Konfiguration ist entsprechend vorbereitet, die IPv6 negotiation wird explizit vom provider-ppp abgelehnt. Und das passt auch zur Aussage der Kundenbetreuung O2: "feste IP" und "IPv6" lassen sich nicht zusammen auf einem Anschluss aktivieren.

-- Zusammenführung Doppelpost gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ by stoney

Ich warte noch auf einen Mitschnitt aus dem FritzBox-Lager (ab dem initialen Aufbau der DSL-Verbindung) und werde dort versuchen herauszufinden, wie die FritzBox dazu kommt, eine andere als die vom Standard-O2-(IPv4)nameserver zurückgemeldete Adresse zu nutzen. Sobald ich dazu neue Erkenntnisse habe, melde ich die natürlich hier zurück.
Hallo allerseits,
nachdem mit mittlerweile der tcpdump des initialen Verbindungsaufbaus der FritzBox vorliegt, etwas weiter unten die Erkenntnisse über dessen Vorgehen. Vorweg jedoch die Rückmeldung, dass mittlerweile seitens O2 das an unserem betroffenen Anschluss abrufbare DNS angepasst wurde und konsistente Werte zu liefern scheint (und dennoch die bisherige SIP-Ziel-IP weiterhin funktioniert).

Nun zur Fritzbox: Dort wird nicht direkt der DNS-Name "sip.alice-voip.de" genutzt, sondern gemäß tcpdump der Startphase der SRV-Eintrag zu _sip._udp.sip.alice-voip.de abgerufen, dann einer der dortigen Server-Einträge. Die dortigen Verweise gehen auf individuelle endpoints, z. B. "UAGSTR07.sip.alice-voip.de." und "UAGOFF07.sip.alice-voip.de." Es scheint, als würde der im TR069 gemeldete (DNS-)Name als Domain interpretiert.

Insofern ist es denkbar, dass vorübergehend im O2-DNS inkonsistente Werte geliefert wurden, d.h. eine andere Auflösung von sip.alice-voip.de als im SRV-Eintrag referenziert. Und es dürfte auch kein "DNS caching"-Thema gewesen sein, der A record wurde mit einer TTL von unter 3600 Sekunden gemeldet - über Wochen hinweg.

Wir werden unsere Prozesse anpassen und den indirekten Zugriff über den SRV record umsetzen, um zukünftige Probleme zu vermeiden.

(my) case closed.

Viele Grüße
Jens
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: arnysch
Jens/jmozd, danke für den Hinweis,die SRV-Abfragen zu verwenden. Ich kann Dich inzwischen voll bestätigen.

Habe ja einige Wochen lang mit einem Skript regelmäßig die Namensauflösung getestet und mitprotokolliert.
Seit der Verwendung von SRV-Abfragen funktioniert es bei mir sehr viel stabiler.

Der Asterisk/PJSip nutzt anscheinend automatisch eine SRV-Abfrage, mit einem Fallback auf normale A- (bzw. AAAA-) Abfragen. Allerdings hatte bei mir der dnsmasq (caching DNS server) die SRV-Antworten von O2 nicht weitergereicht. Ursache war eine aktivierte dnsmasq-Option "filterwin2k".

Den interessierten Asterisk-Anwender empfehle ich also, diese Punkte zu beachten:
  • Vom Asterisk-Modul chan_pjsip werden wohl automatisch SRV-Abfragen verwendet. Keine Einstellung notwendig.
  • Das ältere Asterisk-Modul chan_sip benötigt die Einstellung srvlookup=yes in der Datei sip.conf.
    Allerdings kann dieses Modul nur eingeschränkt die gelieferten SRV-Antworten ausnutzen. In der Beispiel-sip.conf der Asterisk-Quellen steht dazu: "Note: Asterisk only uses the first host in SRV records".
  • Bei Verwendung von dnsmasq sicherstellen, dass die Option "filterwin2k" disabled ist.
Ob die SRV-Abfragen funktionieren, läßt sich testen z.B. mit diesem Befehle:
nslookup -type=srv _sip._udp.sip.alice-voip.de


Ansonsten schrieb jmozd:
Insofern ist es denkbar, dass vorübergehend im O2-DNS inkonsistente Werte geliefert wurden, d.h. eine andere Auflösung von sip.alice-voip.de als im SRV-Eintrag referenziert.
Ja, einerseits dies.

Andererseits auch das: Gemäß meinem Protokoll hat zumindest zeitweise der standard-aufgelöste SIP-Server nicht reagiert, während bei der SRV-Auflösung noch eine zusätzliche zweite Addresse geliefert wurde, welche dann ansprechbar war.
(1. Spalte=Nameserveradresse, srv-Spalte: "srv", wenn Auflösung via SRV-Anfrage, 3. Spalte: SIP-Serveradresse 4. Spalte: Reaktion des SIP-Servers)
(Die IPv4-Nameserveraddressen wurden vom PPP-Protokoll geliefert. Die IPv6-Nameserveradressen wurden über das DHCPv6-Protokoll mitgeteilt)

Code:
===========================================================
2023-08-27T03:33:00+02:00 called by cron (10 min poll)
62.109.121.1             62.52.28.195        no sip server response
62.109.121.1        srv  62.52.19.67         sip server alive
62.109.121.1        srv  62.52.28.195        no sip server response
62.109.121.2             62.52.28.195        no sip server response
62.109.121.2        srv  62.52.19.67         sip server alive
62.109.121.2        srv  62.52.28.195        no sip server response
2a01:c30::530            62.52.28.195        no sip server response
2a01:c30::530       srv  62.52.28.195        no sip server response
2a01:c30::530       srv  62.53.165.195       sip server alive
2a01:c30::531            62.52.28.195        no sip server response
2a01:c30::531       srv  62.52.28.195        no sip server response
2a01:c30::531       srv  62.53.165.195       sip server alive
Address from default resolver for sip.alice-voip.de is:             62.52.28.195
Address from default resolver for _sip._udp.sip.alice-voip.de is:   62.52.19.67 62.52.28.195
REG_o2-00/sip:sip.alice-voip.de  Registered
REG_o2-10/sip:sip.alice-voip.de  Registered
REG_o2-20/sip:sip.alice-voip.de  Registered
REG_o2-30/sip:sip.alice-voip.de  Registered
===========================================================
2023-08-27T03:43:00+02:00 called by cron (10 min poll)
62.109.121.1             62.52.28.195        sip server alive
62.109.121.1        srv  62.52.19.67         sip server alive
62.109.121.1        srv  62.52.28.195        sip server alive
62.109.121.2             62.52.28.195        sip server alive
62.109.121.2        srv  62.52.19.67         sip server alive
62.109.121.2        srv  62.52.28.195        sip server alive
2a01:c30::530            62.52.28.195        sip server alive
2a01:c30::530       srv  62.52.28.195        sip server alive
2a01:c30::530       srv  62.53.165.195       sip server alive
2a01:c30::531            62.52.28.195        sip server alive
2a01:c30::531       srv  62.52.28.195        sip server alive
2a01:c30::531       srv  62.53.165.195       sip server alive
Address from default resolver for sip.alice-voip.de is:             62.52.28.195
Address from default resolver for _sip._udp.sip.alice-voip.de is:   62.52.19.67 62.52.28.195
REG_o2-00/sip:sip.alice-voip.de  Registered
REG_o2-10/sip:sip.alice-voip.de  Registered
REG_o2-20/sip:sip.alice-voip.de  Registered
REG_o2-30/sip:sip.alice-voip.de  Registered
===========================================================

Anhang astdebug.sh.zip: Shell script (bourne, ash), um Sipserverauflösungen und Asterisk-Registrierungen für O2 anzuzeigen oder zu protokollieren.
 

Anhänge

  • astdebug.sh.zip
    2.5 KB · Aufrufe: 1
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.