[Problem] O2 BSA VDSL mit Asterisk 13 PBX

[koyaanisqatsi]

Ich will damit sagen, daß Du doch ebenso NAT RTP Probleme kennen mußt, sofern Dein Asterisk in die Außenwelt will? Oder ist der Trunk über den SIP Client auf der AVM Kiste realisiert und Dein innernetzseitiger Asterisk dient als Trunk zur AVM FritzBox?

Beides.
Es registrieren sich Asteriskseitig an Fritz!Box Registrare, welchen z.B. 1&1 Nummern zugewiesen wurden.
Und es registrieren sich Fritzboxseitig Internetrufnummern an Asterisk Peers.
3. Möglichkeit: Fritz!Box Calltrough
Das geht sogar als SIP Call Uri zum Asterisk aus dem Internet wenn eine in der Fritz!Box angelegte Asterisknummer dazu verwendet wird.
...erhöht allerdings den "Angriffsvector".
Jede in der Fritz!Box angelegte VoIP-Nummer ist im Internet via SIP Call Uri auf öffentliche IP oder DNS und Port 5060 erreichbar.
Sie schmettert aber unauthorisierte Anfragen (registry,options) besser ab als ein schlecht konfigurierter Asterisk.

 

[Eisenfaust]

Ich weiß nicht, was AVM als Betriebssystem auf der FritzBox einsetzt, ich vermute aber, es wird ein Linux sein. Asterisk, vielleicht auch FreeSwitch oder ein AVM Eigengebräu, ist ja prinzipiell nur ein Klient im Kontext des Betriebssystems. Die Autorisierung und Anbindung am Betreibernetz wird vermutlich über ein PTM-fähiges Modem (VDSL?) vollzogen? Das Modem sitzt bei der Fritzbox onboard, ich habe ein externes VDSL "Bridge"-Modem, ein kleiner SoC übernimmt dann via PPP alles weitere. Aber da bewegen wir uns auf der Betriebssystemebene, auch die IP Filter, ob das PF, IPFW IPtables oder was auch immer sein mag, agieren hier inklusive NAT. Und irgendwie muß hier etwas zwischen Asterisk und dem Layer 3 passieren.

sipgate.de teilt einem klar mit, aus welchem IP Kreis deren SIP Anfragen kommen. So konnte ich dann auch den IP Filter so einrichten, daß Anfragen an meinen Asterisk, Port 5060, von diesen IPs erlaubt sind. Im Asterisk kann man ja via PJSIP dieses "Identify" Objekt für den Endpunkt auf Prüfung der IP anlegen - aber das ist sicher bekanntes Grundwissen.

Ich sehe leider nicht, woran die Kontaktaufnahme mit O2 nun scheitert. Ein Entwickler hat mir gestern bezüglich einer NAT Traverse von SIP einiges erklärt, wovon ich nur wenig verstand. SIP/RTP Kommunikation nach außen durch eine Stateful Firewall mit (Full Cone) NAT ist fast immer möglich, denn die Innenseite ist Initiator einer RTP Sitzung und der Filter kann eben den Port öffnen. Umgekehrt ist das aber nicht mehr generalisierbar. Und hier scheint es Probleme zu geben, die mir verborgen sind.

Bei unserem Test meines Routers am TKom Netz mußten wir auf IPv6 umkonfigurieren - was letztlich meinen Fall mit O2 unvergleichbar macht. Da klappte dann die Telephonie via Asterisk ohne Probleme - ich meine: mit der eingangs umrissenen Konfiguration und den TKom Entsprechungen (PW, Registrar usw.).

Was ich bedauerlich finde ist, daß O2 so wenig Hilfe leistet - vermutlich auch nicht kann, denn das Personal an der Hotline ist meistens nicht sonderlich kompetent und mit etwas Grundwissen weiß man meistens selbst schon mehr. Ich vergeliche das mit sipgate.de, deren Hotline ein ganz anderes Kaliber hat. Und man bedenke: beide Unternehmen bieten TK Dienstleistungen an. Aber das ist ein anderes Thema.

 

[hai]

Bevor ich jetzt die Konfiguration des AOR, AUTH und Registrierens hier abwerfe, wüde ich gerne wissen, ob jemand hier im Forum bereits erfolgreich einen Asterisk mit einem O2 SIP Server verbunden hat.

Läuft hier einwandfrei (abgehende und ankommende Anrufe) seit ein paar Wochen. O2 BSA VDSL, LEDE (Linux) auf einem alten O2-Router, Asterisk 13, mit genau den Daten, die O2 per Post geschickt hat. Mehr Informationen waren nicht nötig.
Allerdings habe ich auch nicht versucht, Extrawürste zu braten. Ich verwende den jeweiligen DNS-Server, den O2 bei der Einwahl zuteilt. Asterisk läuft direkt auf dem Router. Genutzt habe ich eine der vielen Anleitungen im Netz, die historisch bedingt noch auf chan_sip aufsetzen.

Meines Wissens nutzt O2 ja ebenfalls IPv6.

Echt? Seit wann?

Ich weiß nicht, was O2 will oder macht. Das Unternehmen hat sich entschieden, einen Kunden loszuwerden.

Heißt das, dass sich Dein Problem durch einen Providerwechsel erledigt hat?

 

[Eisenfaust]

Es ist schön, daß es bei Dir problemlos läuft.

Ich benutze ja auch "genau die Daten, die O2 per Post ..." mir zugesandt hat - nur eben in einem Kontext, und der Kontext heißt chan_pjsip. Wie löst Du das NAT Problem? Trägst Du Deine Dir zugewiesene IP händisch ein? Oder verwendest Du eine DDNS Auflösung deiner zugewiesenen IP? Oder benutzt Du einen öffentlichen STUN Server?

Der TKom STUN läßt sich interessanterweise von allen(!) öffentlichen DNS auflösen - nur nicht von den DNS des ITSP Telefonica mit seinem Ableger O2.

Telefonica scheint derzeit/aktuell 4 DNS zuzuweisen:

dns1.telefonica.de 193.189.250.100
dns2.telefonica.de 193.189.250.101

sie lösen nur IPv4/A Einträge auf, sowie

dns3.telefonica.de 62.109.121.1/2a01:c30::530
dns4.telefonica.de 62.109.121.2/2a01:c30::531

die auch mit IPv6 (scheinbar) können.

Ich benutze dns3 und dns4 - um meine internen Netze auflösen zu können, verwende ich einen DNS mit "split horizon" Konfiguration - habe ich das nicht bereits erwähnt? Solange ich diese DNS verwende, kann auch sip.alice-voip.de aufgelöst werden, das ist derzeit IP 213.20.127.47, es war allerdings auch schon IP 213.20.127.40. Eine reverse DNS Auflösung geht ins Leere.

Es ist so, daß mit diesen Daten und den eingangs dargelegten Konfigurationsdaten (mit leichten Änderungen) die SIP Signalisierung in eine, nämlich inwärts orientierte Richtungen (vom PBX aus gesehen, also eingehende Anrufe) funktionieren - mehr nicht. Es klingelt. Audio wird nicht übertragen, weder in die eine noch in die andere Richtung. Abgehende Verbindungen können gar nicht etabliert werden.

 

[hai]

Ich benutze ja auch "genau die Daten, die O2 per Post ..." mir zugesandt hat - nur eben in einem Kontext, und der Kontext heißt chan_pjsip.

Ich probier mal chan_pjsip aus und melde mich wieder.

Wie löst Du das NAT Problem? Trägst Du Deine Dir zugewiesene IP händisch ein? Oder verwendest Du eine DDNS Auflösung deiner zugewiesenen IP? Oder benutzt Du einen öffentlichen STUN Server?

Ich verwende kein NAT. Asterisk nutzt bei mir direkt die öffentliche IP. Damit spare ich mir das ganze Zeug.

Hast Du mal versucht, eine Fritzbox hinter das NAT zu hängen und dort die O2-SIP-Zugangsdaten einzutragen? Dann kannst Du auf dem Router mit tcpdump nachschauen, wie sich der SIP-Verkehr zwischen (kaputter) Asterisk-Instanz und Fritzbox unterscheidet. Notfalls sollte auch irgendein SIP-Softphone gehen.

Das ist bei mir immer die erste Wahl, Probleme zu debuggen: Funktionierendes (aber so nicht erwünschtes) Setup als Referenz, anhand der ich das nicht funktionierende (aber erwünschte) Setup messen und anpassen kann. Üblicherweise gefolgt von "AARGH! Warum habe ich das nicht früher gesehen!".

 

[Eisenfaust]

Ich probier mal chan_pjsip aus und melde mich wieder.

Danke, sehr nett.

Ich verwende kein NAT. Asterisk nutzt bei mir direkt die öffentliche IP. Damit spare ich mir das ganze Zeug.

Gut, das ist auch ein Weg, den ich aber kategorisch aus mehreren Gründen ausgeschlossen habe. Das gesamte VoIP Geraffel ist bei mir in einem dedizierten VLAN, der Asterisk ist in einem JAIL vergattert und kommuniziert geroutet über die Firewall (zu Testzwecken ist die aber für den Asterisk offen, um hier Probleme auszuschließen).

Hast Du mal versucht, eine Fritzbox hinter das NAT zu hängen und dort die O2-SIP-Zugangsdaten einzutragen? Dann kannst Du auf dem Router mit tcpdump nachschauen, wie sich der SIP-Verkehr zwischen (kaputter) Asterisk-Instanz und Fritzbox unterscheidet. Notfalls sollte auch irgendein SIP-Softphone gehen.

Das ist bei mir immer die erste Wahl, Probleme zu debuggen: Funktionierendes (aber so nicht erwünschtes) Setup als Referenz, anhand der ich das nicht funktionierende (aber erwünschte) Setup messen und anpassen kann. Üblicherweise gefolgt von "AARGH! Warum habe ich das nicht früher gesehen!".

Nein, ich habe keine Fritzbox. Bei mir steht nur generische Hardware. Allerdings: ich habe zwei vollwertige VoIP Telephone, ich habe bisher einfach keine Laune gehabt, eine davon mal für O2 zu konfigurieren ;-)

Mit tcpdump habe ich auch einige MBytes an Datenbergen produziert - man müßte sie nur "lesen" können ;-)

Derweil kamen auch ein paar Informationen seitens des Port Maintainers des Asterisk Ports auf meiner Plattform und einigen Entwicklern eingeflogen. PJSIP unterscheidet sich wohl doch vom bisherigen chan_sip.

Bei mir ist jetzt folgender status quo:

Ich kann mich auf der O2 Leitung anrufen, aber selbst abgehend anrufen kann ich nicht. Wenn ich mich anrufe, kann ich abheben, aber es ist kein Audio vorhanden.

Eine ähnliche Situation kann ich auch mit der an sich funktionierenden sipgate Konfiguration provozieren, wenn ich im AoR- oder auth-Objekt herumspiele - ich vermute, daß die Authentifikation der Endpunkte nicht funktioniert. Bei sipgate kann man im Objekt type=auth für den registrierenden Endpunkt ein Realm via realm=sipgate.de angeben. Bei O2 muß man hier realm=ims.telefonica.de eintragen - man erwischt dieses Realm nur dann, wenn man mit "pjsip set logger on" das Logging einschaltet. Aber auch mit realm= funktioniert das abgehende Telephonieren/Anrufen/Signalisieren nicht.

Ich habe heute den ganzen Tag die Doku gewälzt und bin offenbar nicht der einzige, der etwas an Verwirrung bzgl. "Contact", "AoR" und "Auth" leidet. Joshua Colb von Digium ist aber sehr entgegenkommend, wenn es um eine Erklärung geht.

 

[hai]

Aaaalso... chan_sip und pjsip sind tatsächlich sehr unterschiedlich. Insbesondere hat pjsip ein Feature, das mit O2 nur sehr eingeschränkt kompatibel ist, aber angeblich (hab das RFC noch nicht vollständig gelesen) 100% RFC-konform ist. pjsip macht einen DNS-Lookup bei jedem Vorgang, sei es REGISTER oder INVITE. Damit passiert es in einem erheblichen Teil der Fälle (insbesondere bei Round-Robin-Antworten aus dem DNS), dass das INVITE an eine andere IP-Adresse geht als REGISTER, und bei O2 authentisiert man sich mit REGISTER immer nur bei der IP, die das REGISTER bekommen hat.

Das sorgt dafür, dass (Szenario abgehender Anruf) ein INVITE von Asterisk an O2 je nach aktueller DNS-Abfrage stattdessen ein "SIP/2.0 403 Forbidden" von O2 zurückbekommt.

Soweit ich Dich verstanden habe, dürfte das halbwegs passen. Schau einfach mal, was Wireshark sagt. Wireshark kann SIP gut dekodieren (bzw. im Zweifelsfall kann man den Text im tcpdump auch direkt lesen). Zu prüfen ist also, welche IPs im Spiel sind (d.h. von wo nach wo geht REGISTER, von wo nach wo geht INVITE bei ausgehenden Anrufen) und welche Statuscodes von wo nach wo wann gesendet werden.

Protokoll einer funktionierenden Registrierung und eines nachfolgenden abgehenden Anrufs:

So sollte das REGISTER von Asterisk zu O2 aussehen:

REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5060;branch=foobar;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=honk
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 REGISTER
Supported: replaces, timer
User-Agent: Asterisk PBX 13.17.2
[...]

Zurück kommt von O2:

SIP/2.0 401 Unauthorized 11030030330
Via: SIP/2.0/UDP x.x.x.x:5060;received=x.x.x.x;rport=5060;branch=foobar
To: <sip:[email protected]>;tag=foomp
From: <sip:[email protected]>;tag=honk
Call-ID: [email protected]
CSeq: 102 REGISTER

Erneutes REGISTER von Asterisk an O2, diesmal mit Authentisierung

[...]

Endgültige Bestätigung von O2:

SIP/2.0 200 OK
[...]

Ein Anruf nach außen sieht aus wie folgt:
Asterisk zu O2:

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5060;branch=blubber;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=argh
To: <sip:[email protected]>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 IN

Antwort von O2:

SIP/2.0 100 Trying
Via: SIP/2.0/UDP x.x.x.x:5060;received=x.x.x.x;rport=5060;branch=blubber
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=argh
Call-ID: [email protected]
CSeq: 102 INVITE
Content-Length: 0

Antwort von O2:

SIP/2.0 183 Session Progress
[...]

Antwort von O2, sobald es beim Gegenüber klingelt:

SIP/2.0 180 Ringing
[...]

Antwort von O2, sobald es das Gegenüber abnimmt:

SIP/2.0 200 OK
[...]

Erklärungen:
x.x.x.x ist die eigene öffentliche IP-Adresse
0170123456789 ist die gewählte Rufnummer
493012345678 ist die eigene O2-Festnetz-Rufnummer ohne führendes +

 

[Eisenfaust]

Hallo @hai.

Danke für Deine Bemühungen. Sehr nett von Dir.

Auf welches RFC bezieht sich Deine eingangs gemachte Bemerkung?

In meiner Konfiguration läuft es jetzt auch problemlos mit O2. Zum einen habe ich meine DNS Server etwas so umstricken müssen, so daß die O2 Server angefragt werden, wenn ich sie nach Hosts der Domäne alice-voip.de suchen lasse.

Der andere Aspekt, der zur Funktion geführt hat, ist dann PJSIP selbst und die Art, wie Asterisk 13 eine NAT Traverse selbst analysiert, geschuldet. Ich bin davon ausgegangen, daß ich in meiner Konfiguration _zwingend_ im Transport die Optionen "external_xxxxxx" setzen muß. Um hier nicht mit ungandlichen Skripten hantieren zu müssen, hatte ich dort meinen DDNS FQDN eingetragen - ein grober Fehler, wie sich in der Analyse der mit "pjsip set logger on" extrahierten Logs herausstellte.

 

[hai]

Hallo @hai.

Danke für Deine Bemühungen. Sehr nett von Dir.

Gerne.

Auf welches RFC bezieht sich Deine eingangs gemachte Bemerkung?

RFC3261 sowie einige Updates. Das ist inzwischen ein Dickicht von RFCs, die andere RFCs modifizieren, und ich bin nur eingeschränkt willens, alle komplett zu lesen.

In meiner Konfiguration läuft es jetzt auch problemlos mit O2.

Sehr schön. Könntest Du evtl. die pjsip.conf (Logindaten durch xxx ersetzt) hier veröffentlichen? Danke.

 

[Eisenfaust]

Hallo @hai.

Danke für Deine Koorperation ;-)
RFC 3261 "kenne" ich - heißt nicht, daß ich es auch von Alpha bis Omega gelesen habe ;-) Die von mir erwähnten Optionen im PJSIP Core beeinflussen nicht SIP, sie führen dazu, daß im SDP eine Felder umgeschrieben werden. Das allerdings wird in den entsprechenden Dokuemnten (RFC4566) nicht beschrieben, hier muß man in den Dokumentationen zu PJSIP suchen. Ich habe es nicht selber eruiert. Digium hat mir hier - oberflächlich - auf die Sprünge geholfen. Asterisk/PJSIP sind in der Lage, "einfaches NAT" selber zu traversieren - wie ich das bis ins Detail steuern kann, verriet mir leider niemand.

Sobald ich meine PJSIP Konfiguration bereinigt habe und exakt weiß, was notwendig und was Extra ist, stelle ich sie selbstverständlich hier hinein. Allerdings weiß ich noch immer nicht genau, welche Rolle NAT nun genau spielt. Ich arbeite im Moment an einem RasPi PBX, den ich hinter dem NAT Router im Telephonnetz unterbringen will. Das wird mir weitere Möglichkeiten offerieren, das Verhalten und Problem zu studieren.

Grundsätzlich aber funktioniert die Anleitung von Rotherland (http://www.rotherland.de/de/voip.html) hervorragend. Problematisch und essentiell sind aber bei O2 die Telefonica eigenen DNS Server. Verwendet man sie nicht - oder die "falschen", läuft man auf. Bei der TKom, zum Beispiel, kann man alle DNS Server, welche die TKom zur Nutzung auf deren Hilfeseiten angibt, nutzen - sie lösen die Telephonie-Server/Infrastruktur auf (nach meinem Kenntnisstand). Bei Telefonica/O2 ist das nicht der Fall. Scheinbar ist das O2 Netz heterogener aufgebaut.

 

[arnysch]

Hallo Eisenfaust,

ich bin bei O2 und bin vor einiger Zeit auf VDSL umgestellt worden
Benutze Asterisk 11 mit chan_sip auf einer eigenen Box im LAN, was also Network Address Translation ("Masquerading") durch den Router bedeutet. Sowohl Router als auch Asterisk-Box laufen mit OpenWrt.

Habe dieselbe Probleme wie Du, komme aber nur sporadisch dazu, dies zu debuggen.
Zum Glück habe ich eine langmütige Frau.

Bin immer noch am experimentieren. Momentaner Kenntnisstand bzw. Annahmen:

• Der O2-Telefonie-Zugang erfolgt natürlich über den/die SIP-Server sip.alice-voip.de
• Genutzt für VoIP wird IPv4, nicht IPv6.
• Angesprochen wird bei sip.alice-voip.de der Serverport 5060.
  
• Um die IP des SIP-Servers herauszufinden, müssen die Nameserver von O2 genutzt werden
• Und zwar die Nameserver, deren IP-Adresse beim Internet-Verbindungsaufaufbau durch das PPP-Protokoll von O2 vorgeschlagen werden.
• Hinweis: PPP ist nicht das DHCP-Protokoll. Es wird aber zusätzlich zu PPP noch DHCPv6 von O2 genutzt, um dem Router die IPv6-Adresse und einen IPv6-Adressbereich für Prefix-Delegation zuzuweisen. Ist aber für O2-VoIP irrelevant.
• Um eingehende Anrufe zu erhalten, muss chan_sip sich natürlich vorher beim SIP-Server sip.alice-voip.de registrieren. Ob die Registrierung einen Ablaufzeitpunkt hat, zu dem dann der Server die Registrierung tatsächlich vergisst, ist mir momentan nicht bekannt.
• chan_sip wiederholt standardmäßig die Registrierung alle 300 Sekunden. Dem O2-Server ist das zu kurz; er meldet dann, dass er min. 1800 Sekunden dazwischen haben möchte.
• Auch um einen ausgehenden Anruf durchzuführen, muss man sich vorher beim O2-SIP-Server sip.alice-voip.de registriert haben. Und der Anruf-Invite muss dann an diesen Registrierungsserver gerichtet werden.
  
• So und jetzt kommt die besonders nervige Spezialität: die IP-Adresse von sip.alice-voip.de ändert sich von Zeit zu Zeit. Die alte IP-Adresse funktioniert dann zwar üblicherweise noch weiterhin zum Sich-Registrieren für eingehende Anrufe, aber ausgehende Anrufe werden dann mit "forbidden" abgelehnt.
  => Man muss also irgendwie dafür sorgen, dass chan_sip sich bei der geänderten Adresse neu registriert.

Nur, wie erzwingt man eine Re-Registrierung bei der geänderten IP? Ein Reloaden von chan_sip re-registriert zwar, macht das aber bei der alten IP-Adresse.
Bin jetzt am Testen mit dem DNS-Manager in Asterisk.
Wenn das nicht hilft, dann könnte ich den Asterisk insgesamt stoppen und neu starten (unschön!).
Ansonsten, vielleicht macht es chan_pjsip besser?

Nachtrag: Ein Problem scheint das Connection-Tracking des Routers zu sein. Das Kernelmodul nf_conntrack_sip passt ja die IP-Adressen in den SIP-Protokollen an. Wenn sich die eigene öffentliche IP-Adresse ändert (z.B. wegen ppp-Zwangstrennung), dann scheint nf_conntrack_sip das nicht mitzubekommen.

Schaut so aus, als ließe sich das lösen, indem man in einem ip-up-Script von PPP explizit die Connection-Tracking-Tables des Kernels flusht:

"echo f > /proc/net/nf_conntrack".​