Skip to main content
Warum O2
Warenkorb
Service
Gelöst

VoIP via Asterisk geht nach O2-Server-Umstellung nicht mehr

  • July 13, 2023
  • 9 Antworten
  • 504 Aufrufe

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 angesprochene 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 sehen unsere aktuellen “registers” so aus und bleiben weiterhin unbeantwortet:

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:49vvnnnnn@sip.alice-voip.de>;tag=400811f9-66fb-4ca5-b2c2-49a35f201d8e
       To: <sip:49vvnnnnn@sip.alice-voip.de>
       Call-ID: e04a6bc7-11a5-467c-b41b-b0633786ee26
       CSeq: 37555 REGISTER
       Contact: <sip:49vvnnnnn@62.54.aa.bb: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 steht und andere (mit eigenen Anlagen) die Umstellung problemlos verkraftet haben.

Ich bin für jeden Hinweis dankbar.

 

Viele Grüße

Jens

Lösung von jmozdz

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? igentlich 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...

 

Viele Grüße

Jens

9 Antworten

Klaus_VoIP
Legende

Mein Hinweis wäre …

Frag doch mal im IP-Phone-Forum. Asterisk-Betreiber sollten das Forum eigentlich kennen. 😉
Dort findest Du bestimmt Leidensgenossen.


  • Autor
  • Einsteiger:in
  • July 14, 2023

Hallo Klaus,

 

geschaut habe ich dort, allerdings noch nicht gefragt - die allgemeine “Stille” macht mich stutzig, da normalerweise bei einer großflächigeren Änderung diverse weitere Betroffene zu finden hätten sein sollen 🤔
Bei den wenigen posts im dortigen O2-Forum  wollte ich lieber erst einmal hier mein Glück versuchen, werde aber nun auch dort noch mal nachfragen.

Danke für die schnelle Reaktion!

Und falls hier dennoch jemand einen Vergleichs-”register” bereitstellen kann, bin ich immer noch dankbar :)


Klaus_VoIP
Legende

Hier sind nur ganz wenige Asterisk-Nutzer. Daher der Hinweis auf das andere Forum. Es sind auch nicht unbedingt flächendeckende Umstellungen. Jedenfalls kann man dort eher helfen. Eigentlich ist es doch ein gutes Zeichen, wenn dort keine Probleme gepostet werden.


  • Autor
  • Einsteiger:in
  • Lösung
  • July 15, 2023

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? igentlich 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...

 

Viele Grüße

Jens


theosch
Einsteiger:in
  • Einsteiger:in
  • July 18, 2023

Hi jmozdz,

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”).

Da 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-Nameserver, die selbst eine IPv6-Adressen haben, 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 IPv4-Server liefern.


o2_Sven
  • Moderator
  • July 19, 2023

Hallo zusammen,

das klingt alles sehr spannend auch wenn ich persönlich von Asterisk hiermit das erste Mal gehört habe und daher auch erstmal entsprechendes “Am Kopf Kratzen” stattgefunden hat. Daher ist es dann natürlich doppelt schön, dass ihr es hier bereits klären konntet. Vielen Dank dann auch nochmal für die ausführliche Erklärung theosch, da wird sich ja vielleicht auch noch der ein oder andere mit helfen können.

 

Schöne Grüße, Sven


  • Autor
  • Einsteiger:in
  • July 22, 2023
  • 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”).

Da 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.

[...]

Die O2-Nameserver, die selbst eine IPv6-Adressen haben, 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 IPv4-Server liefern.

Hallo theosch,

spannend, dass die IPv6-O2-DNS-Server zu einer anderen (richtigen) IPv4-Adresse der SIP-Server auflösen. Allerdings scheint es auch ohne IPv6 (bei der Fritzbox und Homebox) zu funktionieren: Die Geräte, bei denen es funktionierte und auch das, von de ich einen trace bekam, hatten kein IPv6 aktiviert…

Ich hoffe darauf, endlich den passenden trace zu bekommen und schauen zu können, woher die von mir in der Lösung erwähnte FB die Adresse bezieht.

@o2_Sven Könnt ihr das intern noch mal klären, ob/warum eine unterschiedliche DNS-Auflösung für sip.alice-voip.de geliefert wird, je nachdem ob ein IPv4- oder IPv6-DNS-Server angesprochen wird? Da ja in beiden Fällen eine IPv4-Adresse geliefert wird, erfolgt die Kommunikation auch bei IPv6-aktivierten Anschlüssen über den IPv4-stack.

Viele Grüße

Jens


o2_Sven
  • Moderator
  • August 15, 2023

Hallo @jmozdz ,

dass die Auflösung von sip.alice-voip.de mit unterschiedlichen Adressen erfolgt ist erstmal nicht ungewöhnlich. Die IP-Adresse der VoIP-Server ändern sich immer mal wieder, vielleicht gab es in der Zwischenzeit ein Update der Software oder es wurde eine Hardwarekomponente ausgetauscht, vielleicht ging deine “Anfrage” dann auch an einen anderen Standort. Eure Beobachtungen in Bezug auf IPv6 konnten wir ehrlicherweise nicht nachvollziehen, da erfolgt für uns einfach gar keine Auflösung von sip.alice-voip.de.

 

Schöne Grüße, Sven


theosch
Einsteiger:in
  • Einsteiger:in
  • August 27, 2023

Jens hat meines Erachtens nach die hauptsächliche Ursache für die Instabilitäten herausgefunden und im IP-Phone-Forum beschrieben. Zusammenfassung:

  • Das Telefonieprogramm muss sogenannte “SRV”-Abfragen an das DNS-System verwenden, um die IP-Adressen der O2-SIP-Server herauszufinden.
  • Die abgefragte SRV-Domäne muss dann “_sip._udp.sip.alice-voip.de” lauten.

Weitere Anmerkungen von mir:

  • Für Asterisk unter Verwendung des SIP-Moduls chan_sip muss in der Konfigurationsdatei sip.conf der Eintrag “srvlookup=yes” stehen, damit SRV-Abfragen durchgeführt werden. Das chan_sip-Modul unterstützt dies aber wohl nur halbherzig: “Asterisk only uses the first host in SRV records” steht irgendwo in den Asterisk-Quellen.
  • Für Asterisk unter Verwendung des SIP-Moduls chan_pjsip erfolgt die SRV-Abfrage automatisch. Schlägt die fehl, dann wird wohl eine Standardabfrage nach sip.alice-voip.de durchgeführt.
  • Konfiguriert wird immer “sip.alice-voip.de”. Der Prefix “_sip._udp.” wird von den Telefonieprogrammen automatisch vorangestellt für SRV-Abfragen.
  • Es muss natürlich sichergestellt sein, dass SRV-Abfragen auch funktionieren. Wird beispielsweise - wie oftmals üblich - ein lokaler Caching-Nameserver “dnsmasq” eingesetzt, dann muss bei diesem die dnsmasq-Option “filterwin2k” ausgeschaltet sein.

Überprüfen unter Windows, ob SRV-Abfragen funktionieren:
> nslookup  -type srv  _sip._udp.sip.alice-voip.de.          und anschließend:
> nslookup  UAGHID07.sip.alice-voip.de                    bzw.
> nslookup  UAGHTT07.sip.alice-voip.de

C:\WINDOWS\system32>nslookup  -type=srv  _sip._udp.sip.alice-voip.de
Server: ip4-easyhn.ats
Address: 192.168.11.11

Non-authoritative answer:
_sip._udp.sip.alice-voip.de SRV service location:
priority = 20
weight = 100
port = 5060
svr hostname = UAGHID07.sip.alice-voip.de
_sip._udp.sip.alice-voip.de SRV service location:
priority = 10
weight = 100
port = 5060
svr hostname = UAGHTT07.sip.alice-voip.de

C:\WINDOWS\system32>nslookup UAGHID07.sip.alice-voip.de
Server: ip4-easyhn.ats
Address: 192.168.11.11

Non-authoritative answer:
Name: UAGHID07.sip.alice-voip.de
Address: 62.52.19.67