Ich glaube auch du gehst davon aus, dass ich vorhabe auf Kamailio Basis einen neuen SIP-Server zu entwickeln, nein das habe ich nicht, denn ich habe neben OPNsense auch noch ein Privatleben.
Und die Richtlinien für SIP und RTP sind nicht so lose wie du denkst[...]
Und ein Provider hat heutzutage nichts davon, wenn ihm die Kunden weglaufen, wenn die Telefone aufgrund des SIP Protokollstacks des Providers Probleme machen.
Full disclosure: Mein Arbeitgeber stellt eine kommerzielle VoIP/ISDN-Lösung auf Asterisk-Basis her. Das ist aber nicht der Hintergrund warum ich dich bitte dein Vorhaben zu überdenken. Ich bin hier in privater Funktion. FOSS ist mein kink
Ich habe es so Verstanden das du einen Kamalio vor einen Asterisk setzt um eine vollständige PBX (ohne DAHDI ) zu implementieren. Inklusive Provisioning von Endgeräten. Und Providertemplates. Im Kontext einer Firewall.Ich warte auf dein Konzept, aber mein Bauchgefühl sagt mir das die Ziele sehr hoch gesteckt sind, unabhängig von deiner oder mimugmails Expertise (die ich nicht anzweifle). Es geht mir um die reinen Mannstunden. Und den Sicherheitsaspekt. Jail hin oder her, die Attacksurface vervielfacht sich. Müssen ja auch nicht direkt RCEs sein.
Das hat nur leider niemand den Providern erzählt So was wie RFC3261 und 3550 / 4566 wird (meist) eingehalten. Da gebe ich dir Recht. Mir geht es eher um die Vermittlung (pots / inter-provider) und Signalisierung.Ein Beispiel das ich gerne nehme sind Nummernformate. Welches Format soll die Zielrufnummer haben? Wie unterscheidet es sich lokal, national, international (das Unterscheidet sich auch nochmal per Provider und Zielregion)? Der Brüller: Nationale Sonderrufnummern.In welchem Header wird die CLIP erwartet? PAI? PPI? Oder doch lieber FROM?Wie signalisiere ich CLIR? Redirection / reflection?¯\_(ツ)_/¯Und dann die Fehlermeldungen... Was kommt bei Besetzt / Rejected zurück? Ungültige Rufnummer? Gesperrtem Account?Am tollsten sind die Provider die Munter im Fehlerfall mit 200 OK antworten und eine Sprachnachricht über RTP drücken.Ich kenne keine zwei Provider welche identische Spezifikationen befolgen. Es ist nicht mal garantiert das die Spezifikation innerhalb des selben Providernetzes konsistent sind. SIP INVITES kommen mit führender +49... von dem einen SBC, 49... von dem nächsten und drei Tage später mit 0..., dann komplett ohne Präfix vom dritten SBC.
Tun sie nicht! Warum? "Die PBX ist schuld!" Es ist immer, grundsätzlich die PBX."Oh. Keine Fritz- / Digitalisierungsbox? Kein Support. Ach du willst nur die Specs? Die kann ich dir nicht geben. Kauf dir lieber die supportete™ PBX©".Selbst wenn man einen PCAP mit RFC violations (INVITE nach 407 ohne Hash wiederholt, 407 Response ohne NONCE, unilateraler Codecwechsel ohne SDP, COMEDIA ignoriert, ...) vorweisen kann wird es im besten Fall still und heimlich gefixt und ohne Ankündigung ausgerollt. Schuld bleibt *drumroll* die PBX. Es wird gelogen, getrickst und intrigiert. Bis jemand weint.Zugegeben, es gibt Provider die sehr transparent Arbeiten. Mit denen es Spaß macht solche Fehler auszuräumen. Der staatlich geförderte Monopolist ist keiner davon.So. Ich gehe jetzt erst mal einen Kaffee trinken um von meinem Nerdrage wieder runter zu kommen. Hoffe ich konnte meine Punkte rüber bringen. Ich will euch nichts böses.
Naja, das es keine gute Idee ist, auf einer Firewall eine Vollwertige PBX laufen zu lassen, mal den Sicherheitsaspekt beiseite gelassen ist der, dass eine Vollwertige PBX zuallererst auch andere Dienste bereitstellt. z.B. vollwertiges Endgerätemanagement, das heißt, Boot und Konfigurationsserver (DHCP, DNS, TFTP) sowie einen Datenbankserver für die Konfiguration sowie LDAP für ein Zentrales Telefonbuch. Mal angenommen es gäbe für OPNsense Asterisk als Plugin, was alleine schon an Integrationsarbeit in die Weboberfläche und ins Konfig Management, eine Arbeit von mehreren Monaten wäre. Würde es nicht lange dauern und es gäbe Featurerequests in diese Richtung, diese oben genannten Features nachzureichen. Indem Falle wäre sogar einfacher gleich direkt eine eigenständige PBX Distribution aus dem Boden zu Stampfen. Die eben nur eine Telefonanlage bereitstellt und einfach zu konfigurieren wäre. Leider gibt es großartige keine OpenSource PBX Distributionen mehr, da die meisten alle Kommerzialisiert sind.Dazu gehört meiner Meinung nach auch FreePBX. Sie wird zwar von vielen genutzt aber nur weil es keine alternativen gibt. Und FusionPBX ist zwar ohne Vorbehalte Frei verfügbar, aber ebenso schwer zu konfigurieren, selbst wenn man eine Anleitung hat. Das Freeswitch Wiki ist leider auch nicht wirklich gut Dokumentiert. Wer Asterisk und Freeswitch über die Konfigurationsdateien konfigurieren kann, der braucht natürlich keine GUI, aber für alle die ihre FritzBox los werden wollen ist das wiederum keine Lösung. Eben sowenig eine Mobydick von Pascom. Nun zu den Sicherheitsaspekten, würde Asterisk auf OPNsense als Plugin vorhanden sein, gäbe es irgendwann hier im Forum lauter Beschwerden, gehackt worden zu sein etc. Da Chan_SIP und PJ_SIP leider noch nicht ausgreift sind in Public Netzwerken zu lauschen. Und für Chan-SIP existieren Mittlerweile Scripte um Automatisiert Buffer Overflows zu erzeugen und dessen Sicherheitslücken sind ja nun weit bekannt. PJSIP soll ja in Zukunft CHAN_SIP ersetzen, ist aber leider noch nicht so ausgereift das es wirklich funktioniert. Bei FreeSwitch gibt es diese Problematik nicht, aber dafür ist diese Software auch nicht so weit verbreitet. Es wurden dort zwar Dinge völlig neu bei der Programmierung durchdacht und dabei raus gekommen ist ansich eine gute Software, die aber leider etwas schlecht Dokumentiert ist und von Hand auch nur schlecht konfiguriert werden kann. Und leider Frisst FreeSwitch auch ziemlich viel CPU und RAM wenn man darüber viele Calls abwickeln möchte. In FusionPBX ist Fail2Ban allerdings fest integriert. siehe hierMan muss natürlich nicht mit dem von mir hier geschriebenen Meinungskonform gehen. Viele mögen auch eine andere Sichtweise auf die Dinge haben. Aber du kannst relativ gefahrlos Asterisk oder FreeSwitch hinter OPNsense mit dem Siproxd Plugin betreiben. Und das sollte ohnehin die einzige Aufgabe sein die eine Firewall wie OPNsense mit VOIP hat. Nämlich das Relayen von SIP und RTP. So findet zwar keine Direkte Komunikation mit den Provider Servern statt.Aber auch eingehende Anfragen auf deine IP werden gar nicht an deine PBX weitergeleitet, sofern in Siproxd keine Information hinterlegt ist, das dies erwünscht ist. Angriffe enden also am Proxy ohne an die PBX weitergeleitet zu werden. Das heißt Ausländische Häcker könnten auch bei einem Konfigurationsfehler von Asterisk nicht teure Anrufe über deine Accounts leiten. Da Siproxd dich ja nicht bei deinem Provider registriert.Villeicht wäre https://www.astlinux-project.org/ was für dich? Bei Fragen bitte einfach wieder schreiben.
Konferenzräume wären noch geil
In den meisten Firmen ist es z.B. so, jemand der OpenSource einsetzt ist dann selber für die Sicherheit und im Fehlerfall Verantwortlich. Daher wollen die meistens IT-Chefs gerne nur Software einsetzen wo ihnen die Verantwortung abgenommen wird und der Hersteller dafür in die Bresche springt. Also im Endeffekt jemanden der im Schadensfall zahlt.
Sinnvolle Funktionen für Asterisk sind:B2B = Asterisk registriert sich beim Provider und stellt über den Lokalen SIP Registrar diese Leitung zur Verfügung. Zudem Normalisierung durch Provider Templates.Provider Templates = Einfache Registrierung bei Providern ohne Try and Error. Zur Ausarbeitung von Providertemplates muss herausgefunden werden, was Provider verändern können um inkompatibel zu einer Standard Konfig zu sein, SIP Header, Auth Header, user-agent, Rufnummern etc. Durch eingrenzen der Möglichkeiten ein Formular entwickeln die das Anpassen vereinfacht, darauf basieren dann die Templates. => Vorausgefülltes Formular. + AGI Skript im Hintergrund, welches sich um die Verarbeitung die den Wählplan betreffen kümmert.Wahlregeln = Rufsperren, Umleitungen, einfaches RoutingAnruflisteInterne Anrufe = Festlegen eigener Interner Rufnummern im Bereich XX.Sicherheit = Schutz vor Missbrauch durch die oben genannten Vorkehrungen. Konfigurierbar ohne Asterisk und Kamailio Kenntnisse = Durch die hohe Integrationsdichte aller Komponenten. Daher, ein in sich geschlossenes Plugin welches Asterisk und Kamailio in vorkompilierter Form unabhängig von einem Frei Konfigurierbaren Asterisk oder Kamailio Paket mitbringt. Das heißt, eigene Ordnerstruktur und Asterisk oder Kamailio sind nicht separat unabhängig voneinander nutzbar, eben auch wegen der Funktionseinschränkungen.
Auch wenn der Thread schon etwas älter ist und das nach meinem Verständnis eh schon als Feature angedacht ist:ich würde v.a. eine Protokollumsetzung von IPv4<->IPv6 sinnvoll finden. Dafür besteht IMO echt Bedarf:Bisher hab ich nur bei Grandstream bezahlbare SIP-ATAs mit IPv6-Unterstützung gesehen (und bei einem anderen chinesischen Hersteller, den man kaum herkriegt und dessen Namen ich konsequenterweise schon vergessen habe). Umgekehrt gibt es Provider (M-Net), die VoIP nur über IPv6 machen; andere (easybell) bieten es zwar nur zusätzlich zu VoIP über IPv4 an, dort würde ich es aber trotzdem vorziehen, weil man dann bei DS-Lite keine VoIP-Streams über den AFTR-Tunnel leiten muss.
