PBX-Plugin

[Apfelbaum]

Hallo,

ob ich in diesem Forum richtig bin, weiß ich nicht. Falls ich hier falsch bin: Bitte - wenn möglich - weiterleiten - und: Sorry!

Ich möchte eine Firewall einrichten, welchen ebenfalls die Funktion einer PBX übernimmt. Nach einigem Lesen, glaube ich, gelernt zu haben, dass Asterisk zwar verbreitet, aber überladen und unstrukturiert ist.

Demzufolge suche ich ein Plugin für Freeswitch (https://freeswitch.org) inklusive GUI, z. B. FusionPBX (https://www.fusionpbx.com), sowie fertig implentierten entsprechenden Schutzmechanismen (z. B.  FailtoBan, etc.) nebst einfacher Konfiguration.

Gibts so was?
Will jemand das mal implementieren?

Oder gibt es bessere Ideen / Alternativen? Bzw. habe ich mich bezüglich der Suche nach ner Alternative für Asterisk verrant? Wie käme ich in dem Fall zu Asterisk?

Danke

[NicholasRush]

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 hier

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

[JeGr]

Zu dem PBX Background kann ich nicht viel beisteuern - als Security Guy nicht meine Baustelle und an der Stelle gehe ich sehr konform mit Nick und sage auch: PBX hat auf einer Firewall (außer in Form von Proxy Möglichkeit weil Gateway) nichts zu suchen. Auch kein Browser, Mailserver & Antispam etc. auch wenn das noch so "praktisch" ist, sind das meines(!) Erachtens Dinge, die in eine nachgelagerte DMZ sollten und dort entsprechend auch auf eine eigene Box/Appliance etc. Schon alleine weil man sich dann nicht damit herumschlagen muss, dass man diverse Komponenten updaten muss oder andere nicht kann, weil es Querabhängigkeiten gibt.
Wenn das aus Stromspar- oder Managing-Gründen auf einer physikalischen Box laufen soll - nunja, ist ja machbar. Dann virtualisiert man gewisse Teile eben (mit den Vor- und Nachteilen bzw. Bedenken aber eben in Abwägung dessen was man braucht).

Interessant an der Stelle z.B. genau mit der gleichen Idee im Hinterkopf (jetzt eher für Unternehmen): https://www.scope7.de/hardware/scope7-proxmox-basic
Genau dafür: eine Appliance, aber durch den Hypervisor Layer eben getrennte Firewall, PBX, AntiSpam etc. Geschichten möglich.

Ansonsten würde mich noch interessieren, wo

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

herkommt. Rein informativ, denn ein Kollege von mir setzt gerade wieder ein Projekt mit ner FreePBX um. Das sah mir jetzt nicht so dramatisch aus. VoIP/SIP generell ist keine einfache Baustelle, dass die meisten Sachen da "schwierig zu konfigurieren sind", überrascht mit bei dem Komplexitätslevel jetzt eher weniger. Ist eben kein Klingeldraht mit Kuperader und Telefon mehr :D (manchmal: leider...)

[NicholasRush]

OpenSource PBX Distros gibt es ja wirklich nicht mehr viele. Kommerzielle dafür umso mehr.

Damals als Azkozia aufkam als Freie PBX, wäre ich damit als Home PBX zufrieden gewesen. Leider gab es dann später keine Updates mehr. Und die Software ging in einem Unternehmen auf, welches jetzt 3CX gehört. Und die haben "AzkoziaPBX" eingestellt. Diese Software hätte ich sogar als Privatnutzer Lizenziert, weil das Konzept wirklich gut war. Alternativ gäbe es als Komerzielle noch: MobyDick von Pascom. (Lässt sich privat nur umständlich nutzen, weil die Software dafür nicht gedacht ist und auch nur 3 Nutzer inklusive sind).
Dann noch "IPTAM" und "Ansitel", "Starface" etc.

Bei den Herstellern in Übersee das gleiche (ausser FreePBX), aber da sind leider die Deutsche Sprachanpassung problematisch bis nicht vorhanden.

Das Problem ist, auch wenn es einige Hersteller so halten das sie eine kostenlose Version anbieten, ist diese meist so eingeschränkt, das sie sich auch Privat als unbenutzbar herausstellt. Die Software ist dann zwar meistens unbegrenzt lange nutzbar, aber eben mit den Einschränkungen.

Ich habe nichts dagegen, das die Firmen damit Geld verdienen wollen, darum geht es auch nicht. Aber kein Privatnutzer wird dafür Geld ausgeben, weil diese auch nicht die Zielgruppe der Firmen sind. Nur stellt keine Firma eine Software für Privatnutzer bereit, ob kostenlos oder auch nicht. Kostenlos wäre natürlich besser.

Und bei FreePBX nervt mich halt, das das erste was man nach der Installation zu Gesicht bekommt, "Choose a Plan".
=> https://youtu.be/77KzDLij8eQ?t=16m57s
Wird in dem Video gezeigt.

Wer die Software nur Privat einsetzt wird irgendwann denke ich mal davon genervt sein.
Bei einer Firma die die Software nutzt wäre das was anderes, denn die meisten Firmen setzen sowieso nur Software ein wo sie Support durch den Hersteller bekommen können. Und ob die Gui dann immer noch diese dauer hinweise zeigt weiß ich nicht.

Ich bin damals zu den Telefonanlagen gekommen, da waren sie noch Analog, und alles wurde mit Relais geschaltet. Später habe ich mich mit DeTeWe Varix Anlagen beschäftigt, da war DeTeWe allerdings schon eine Aastra Marke. Und so kam ich dann zu Asterisk und VOIP, wobei Asterisk 1.2 und 1.4 früher wirklich keinen Spaß gemacht haben und ich mir da noch nicht vorstellen konnte, das mal das ganze Telefonnetz so betrieben werden sollte.

Letztlich, auch wenn ich hier im Forum wohl hauptsächlich Fragen zu VOIP beantworte, beschränkt sich mein Tätigkeitsfeld nicht nur darauf.

[mimugmail]

Also ich persönlich hätte nix gegen ein Asterisk Plugin. Vielleicht runtergetrimmt auf SIP only damit nicht so viele Requests bzgl. dahdi Treiber kommen. Aber Dialplans schreiben oder besser templaten damit andere die schreiben können ist echt kein Spass. Vielleicht nach 19.1 oder so, vorausgesetzt die Prioritätenliste wächst nicht weiter mit anderen Sachen :)

[NicholasRush]

Also ich persönlich hätte nix gegen ein Asterisk Plugin. Vielleicht runtergetrimmt auf SIP only damit nicht so viele Requests bzgl. dahdi Treiber kommen. Aber Dialplans schreiben oder besser templaten damit andere die schreiben können ist echt kein Spass. Vielleicht nach 19.1 oder so, vorausgesetzt die Prioritätenliste wächst nicht weiter mit anderen Sachen :)

Dahdi ist unter BSD ohnehin nicht gerade unproblematisch. Ich komme nur irgendwie nicht auf einen Nenner, wie ich in diesem Fall ein Konzept entwickeln kann, das dann auch "Sicher" ist. Denn diesbezüglich ist nichts unsicherer als Chan_Sip. Aber leider ist auch nichts kompatibler als Chan_SIP. Mit PJSIP und einigen Telefonen (Cisco) hatte ich schon Probleme, eine nahtloser Schwenk auf Chan_SIP hat sie gelöst. Wie ich nachher herausfand lag das an einer einzelnen Zeile im SIP Header, die Chan_SIP anders ausgibt. Die Telefone waren bei Cisco allerdings sowiso EoL, und damit ziemlich unwahrscheinlich das von denen bezgl. Firmware noch was kommt.

Das beste ist ich schaue mal was diesbezüglich Kamaillio so hergibt, ein Registrar kann man damit abbilden und das macht 1und1 zum Bsp. auch so. Wenn es möglich ist Kamaillio bei einem SIP Registrar zu Registrieren und die jeweiligen Accounts mit Virtuellen nur in Kamaillio erstellten Accounts zu verknüpfen, wäre das genau das was die meisten suchen. Ein umkonvertieren von Voice Codecs kann Kamaillio zwar nicht, aber die Basis Sip Routing Funktionalität lässt sich dafür doch nutzen.

Damit hätte dann OPNsense eine Custom PBX, den "FritzBox" Ersatz den alle suchen ohne die riesen Sicherheitslücken. Und weil das eben von Sip Providern auch eingesetzt wird, ist der Kamaillio SIP Stack als relativ sicher anzusehen.

Das größte Problem bleibt aber, das Kamaillio dafür entweder eine PostgreSQL oder MySQL Datenbank braucht. Ob mittlerweile XML oder Textfiles gehen, kann ich nicht sagen, weil es auch auf die Funktionalität der Plugins ankommt die geladen werden.

Eine andere Idee von mir wäre, OPNsense nur die Proxyfunktionaliät zu lassen und eine eigene SIP PBX Distro auf Hardened BSD Basis auf die Beine zu stellen, was Asterisk anbelangt, dürfte das wohl einfacher sein, als zu versuchen eine so umfangreiche Software als Plugin in ein vollwertige Firewall Appilance wie OPNsense zu quetschen. Ich denke zumindest deshalb so, da auch die GUI von OPNsense dann an die Grenze dessen, was man machen kann, und wirklich tun sollte, stößt. Und eine Plugin Sektion namens "Asterisk" mit über 30 Tabs stelle ich mir nicht gerade als übersichtlich vor. Denn es geht ja schließlich darum den Nutzer von den Konfigurationsdateien fern zu halten und die Konfiguration so einfach wie möglich zu gestalten.

Auf PFSense gab es damals mal Asterisk, habe das auch ausprobiert, aber es hatte schon seinen Grund weshalb das Plugin nie den "DEV" Status verlassen hat. Ob es noch existiert weiß ich nicht. Jedenfalls konnte man den SIP Port per Formular einstellen, aber den rest musste man über die Konfigdateien im Browser machen.

Das Plugin hatte ich jedenfalls nicht lange installiert. Und daher ist das leider kein leichtes Thema.

Ich hoffe zumindest dieser Post hier wird auch von den Leuten gelesen die unbedingt in einer Firewall eine Telefonanlage wollen. Um zu verstehen warum das alles nicht so einfach ist und das auch ein hoher Kosten / Nutzen Faktor ist. Klar kann man alles als Plugin in OPNsense integrieren und das das für jeden Entwickler eine menge Arbeit ist, ist klar. Nur wenn das Plugin nachher niemand nutzt wäre die ganze Zeit verschwendet. Und deshalb sehe ich das Thema so schwierig, denn gerade was VOIP und SIP angeht und vor allem weil jeder Hersteller/SIP Provider etc. seine eigene Suppe Kocht, ist das alles nicht einfach.

[mimugmail]

Ich muss gestehen ich bin was Asterisk und Security betrifft kein Experte, trotzdem muss ich doch mal fragen wieso Kamailio sicherer sein soll wie Asterisk?

Also wir hier in der Firma haben ein selbst installiertes Linux mit Asterisk drauf. Wir (der Kollege gegenüber) schreiben unsere Dialplans in txt. Wenn ich da jetzt ein System mit ner GUI hätte wäre doch super?! Es muss ja nicht die Perimeter Firewall sein :P

Wenn ein Kunde intern im Netz einen Radiusserver braucht würde ich ihm dafür auch ne OPNsense hinstellen, weil es m.M.n. keine anständige GUI für FreeRadius gibt, ausser vielleicht noch pfSense.

Und wenn Unbound auf Forward Lookup Zonen verwalten könnte würde ich auch anfangen zu überlegen :P

[NicholasRush]

Ich muss gestehen ich bin was Asterisk und Security betrifft kein Experte, trotzdem muss ich doch mal fragen wieso Kamailio sicherer sein soll wie Asterisk?

Also wir hier in der Firma haben ein selbst installiertes Linux mit Asterisk drauf. Wir (der Kollege gegenüber) schreiben unsere Dialplans in txt. Wenn ich da jetzt ein System mit ner GUI hätte wäre doch super?! Es muss ja nicht die Perimeter Firewall sein :P

Wenn ein Kunde intern im Netz einen Radiusserver braucht würde ich ihm dafür auch ne OPNsense hinstellen, weil es m.M.n. keine anständige GUI für FreeRadius gibt, ausser vielleicht noch pfSense.

Und wenn Unbound auf Forward Lookup Zonen verwalten könnte würde ich auch anfangen zu überlegen :P

Kamaillio ist eben ein aus Einzelmodulen bestehende SIP Anwendung. Im Grunde so etwas wie lighttpd+PHP nur für SIP und mit noch mehr einstellbaren Funktionen. Während man sich bei Asterisk nur unwesentlich ums SIP Protokoll selbst kümmern muss, kann jemand der nicht das SIP Protokoll versteht mit Kamaillio gar nichts anfangen. Und ich habe selber vor knapp 3 Jahren noch Wochen damit verbracht zu verstehen wie Kamailio den nun funktioniert.
In der Konfigurationsdatei von Kamaillio, geladene Module vorausgesetzt, ist es möglich wirklich jeden Protokollzustand einzeln auszuwerten und so z.B. auch Angriffe in Form von bestimmten SIP Messages direkt zu unterbinden. Das kann Asterisk nicht und ist dort auch nicht vorgesehen.

So sieht z.B. die bei 1und1 und vielen anderen SIP Providern genutzte Infrastruktur aus:
https://www.kamailio.org/events/2013-KamailioWorld/03-Henning.Westerholt-Large-VoIP-Deployments.pdf

In dem Zusammenhang ist auch das hier interessant:
https://www.pascom.net/de/dokumentation/pascom/server/server-installieren/
Denn Pascom rät selbst davon ab Ihr Asterisk Produkt direkt an einer öffentlichen IP zu betreiben. Wie es überall mittels Portforwarding ja gehandhabt werden müsste. Klar stelle ich mir da auch die Frage warum sie Kamaillio nicht in ihre PBX integriert haben, bei der anderen Software von denen, dem Cloudstack, ist Kamaillio dagegen die Zentrale Proxy- und SIP Routinginstanz.

Letztlich bleibt für mich aber eines, wenn selbst ein etablierter Hersteller wie Pascom seinen Kunden davon abrät  die von Ihnen Entwickelte Software so zu betreiben, wie sie normalerweise vorgesehen ist, sollte man doch nach Möglichkeiten schauen diese Probleme irgendwie vorher in den Griff zu bekommen.

Klar kann man auch wie bei dir in der Firma Asterisk so betreiben wie du es beschrieben hast, aber ich gehe mal davon aus, dass dein Kollege genau weiß was er da macht, auch Firewall spezifisch, sonst hätte eure Firma wohl schon eine ziemlich hohe Telefonrechnung bekommen mit Anrufe in Länder wo gar keine Kunden sind, und zu Zeiten in der eigentlich niemand da ist der Telefonieren könnte.  :o

s. hier: https://www.ip-phone-forum.de/threads/bin-gehackt-worden.295929/#post-2230608

Ist z.B. ein relativ aktuelles Bsp. dafür was ich meine. Wenn sollten die Nutzer doch etwas richtiges bekommen, und nicht etwas was ihnen mehr schaden als nutzen bringt. Zugegeben viele Leute sind als das Forum damals an einen anderen Betreiber verkauft wurde ebenfalls gegangen, daher ist es nicht ungewöhnlich wenn einem das Gefühl überkommt das in einigen Threads buchstäblich nichts los ist.
Und verlangen das jeder Asterisk mal eben konfigurieren kann, wird leider auch mit einer GUI nichts. Außer der Benutzer bekommt gar nicht mit, das Asterisk da drunter werkelt.
Alles in allem kann man aber verallgemeinern, dass jedes Asterisk Produkt, ohne entsprechende Absicherung wie ein Sip Proxy, ein gefundenes Spielzeug für Hacker ist, oder eben Leute die einfach nur kostenlos telefonieren wollen. Und wie ich bereits ähnlich im Vorpost schrieb, hat gerade der Chan_SIP driver in Asterisk viele Fehler wodurch ein Angreifer leicht einen Buffer Overflow auslösen kann. Und da nützt es dann leider auch nicht viel, das in der sip.conf die Einstellungen so gesetzt sind das das normalerweise nicht passieren dürfte.

[mimugmail]

Eine Frage noch, kann Asterisk denn nicht nur auf LAN hören (für Clients) und auf WAN nur Outgoing zum SIP-(Trunk-)Provider? Das wäre doch kein großes Sicherheitsrisiko?

Ansonsten Kamailio (ohne MySQL/PGSQL), wir können es ja wieder wie bei siproxd machen? :P
Aber Voraussetzung xml, oder, eher wahrscheinlich, sqlite?

[NicholasRush]

Eine Frage noch, kann Asterisk denn nicht nur auf LAN hören (für Clients) und auf WAN nur Outgoing zum SIP-(Trunk-)Provider? Das wäre doch kein großes Sicherheitsrisiko?

Ansonsten Kamailio (ohne MySQL/PGSQL), wir können es ja wieder wie bei siproxd machen? :P
Aber Voraussetzung xml, oder, eher wahrscheinlich, sqlite?

Ehrlich gesagt wäre mir XML, da auch am liebsten, weil Sqllite ansonsten immer als BLOB in die config.xml müsste. Allerdings weiß ich momentan ohnehin noch nicht so recht ob ich das OPNsense Konfig-Backend so richtig verstanden habe. Eher nicht, denke ich, habe den Code ja auch nur mal überflogen.

Zu deiner Frage zu Asterisk, ja und nein, denn um sich bei einem SIP Provider zu registrieren braucht man erst mal keinen eingehenden offenen SIP Port, aber wenn dieser Anrufe bei mir platzieren soll, muss der Port ja wieder geöffnet sein, sonst kann man ja nicht angerufen werden.

Das ganze ist und bleibt leider ein schwieriges Thema.
Werde das ganze mal durchdenken und dann einige Lösungansätze machen und hier vorstellen.

Bin ja sowiso seit einiger Zeit schon an der Kamailio Konfig dran die Siproxd mal ersetzen soll. Diese wird in Kombination mit Asterisk dann ebenfalls vonnöten sein. Ich werde mich allerdings mal mit den Kamailio Leuten in Verbindung setzen, den besser wäre es wenn man komplett auf Asterisk verzichten könnte.

[NicholasRush]

Also soweit so gut, habe aus dem Kamailio IRC die Antwort bekommen, das es ohne weiteres nicht möglich ist, nur Kamailio als einfache PBX einzusetzen. Das mag für nur WebRTC Anwendungen funktionieren, aber nicht so wie ich mir anfänglich dachte.

Ich stelle ein PDF zusammen indem ich Detailliert vorstelle, wie sich so etwas umsetzen lässt und welche Hürden das ganze noch mit sich bringt.

Eines nehme ich noch vorweg, Asterisk und Kamailio, wo Kamailio alle SIP-Funktionen übernimmt, setzt immer eine Datenbank vorraus, auf die Kamailio und Asterisk zugreifen können müssen. Das nennt sich dann Asterisk Realtime. Das kann und möchte ich aber so nicht realisieren, zuerst wegen der Datenbank und zweitens da dieses System viel zu Oversized wäre für ein paar Telefone und VOIP Provider Accounts.

Ich denke ich werde das so lösen, dass Asterisk alles macht, vom Dialplan über die Provider Registrierung sowie Extension Bereitstellung. Aber Asterisk wird nur an den localhost gebunden bsp. 127.1.0.8:5060. Sodass jede Kommunikation von und zu Asterisk über Kamailio laufen muss. Damit wird Kamilio die Schnittstelle zum WAN sowie zum LAN. Kamailio übernimmt als Proxy, alle NAT, STUN und Sicherheitsfunktion wie Anti-Spoofing, Anti-DDoS etc. Aber Kamailio bekommt hier noch Verstärkung durch Fail2BAN. Sodass es nach 3 oder 5 versuchen eine Anwendungssperre in Kamailio sowie eine Firewallsperre durch Fail2Ban gibt.

Mein ziel ist es das jeder Pluginnutzer dieses Plugin nachher so bedenkenlos einsetzen kann wie bisher seine FritzBox.

Soviel schon mal wie ich mir das gedacht habe. Detailliert gehe ich dann darauf im PDF ein, aber dafür brauche ich noch ein paar Tage, da es ziemlich viel arbeit ist, die ganzen Möglichkeiten durchzugehen.

[mimugmail]

Hört sich nach nem Haufen Arbeit an, ich bin dabei  8)

[NicholasRush]

Wird es auch, denn ich muss dafür ganz schön viel testen. Und ich werde mal wieder die FritzBox rauskramen und schauen ob sich die Provider Templates die AVM da eingepflegt hat nicht für dieses Projekt nutzen lassen. 1:1 übernehmen geht sowiso nicht, aber wenigstens steht dadrin welche Konfiguration welcher Anbieter erwartet. Kein Gerät ist ja mit so vielen Providern "out of the Box" kompatibel wie die FritzBox und ich fände es gut das direkt mit einzubauen.

Habe zudem in Erfahrung bringen können das PJSIP wohl endlich Produktiv nutzbar und fest in Asterisk 16 LTS gebündelt wird. Das macht die Sache dann zwar nicht einfacher, aber wird dann wohl kompatibler und sicherer sein als weiterhin mit chan_sip zu arbeiten.

Ich werde erstmal eine PDF-Präsentation mit den wichtigsten Details erstellen und mit einem Schaubild der Grundfunktionalität.

[Alphakilo]

Jungs... Ich will nicht meckern. Das wäre sicher Ruhmreich. Aber ihr übernehmt euch da gewaltig.
Ich kenne Firmen die eigene Teams allein für Providerintegrationen unterhalten.

Die VoIP-Protokolle (SIP / RTP) sind für fast alle Provider eigentlich nur lose Richtlinien. Je größer der Provider desto schlimmer der Protocolabuse.

Was ich sagen will: Das einmalig zu coden ist die eine Seite. Maintainen eine ganz andere Hausnummer.

Ich finde die Idee wirklich charmant, aber ich sehe keine Möglichkeit das in irgendeiner Weise sicher und langfristig stabil zu implementieren.

Falls ihr euch doch dazu entscheidet das durchzuziehen, meldet euch doch nochmal bei mir. @mimugmail hat meine Emailadresse.

[NicholasRush]

Jungs... Ich will nicht meckern. Das wäre sicher Ruhmreich. Aber ihr übernehmt euch da gewaltig.
Ich kenne Firmen die eigene Teams allein für Providerintegrationen unterhalten.

Die VoIP-Protokolle (SIP / RTP) sind für fast alle Provider eigentlich nur lose Richtlinien. Je größer der Provider desto schlimmer der Protocolabuse.

Was ich sagen will: Das einmalig zu coden ist die eine Seite. Maintainen eine ganz andere Hausnummer.

Ich finde die Idee wirklich charmant, aber ich sehe keine Möglichkeit das in irgendeiner Weise sicher und langfristig stabil zu implementieren.

Falls ihr euch doch dazu entscheidet das durchzuziehen, meldet euch doch nochmal bei mir. @mimugmail hat meine Emailadresse.

Bitte erst auf meine Präsentation warten und keine voreiligen Schlüsse ziehen. Übernehmen werden wir uns da nicht, weil die ganze Sache durchaus Struktur bekommt. Eine vollwertige PBX wird das sicher nicht (Gründe habe ich im zweiten Post genannt). Und es wird auch nichts neu gecodet, außer vielleicht das Frontend und einige Module die entweder in PHP oder Python abgearbeitet werden. Aber auf die "schnelle" geht das sowiso nicht. Planung ist hier der Schlüssel um den Weg ins Ziel zu finden.

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, vor einigen Jahren hätte ich dir damit noch recht gegeben, da noch neben SIP, H323 im Raum stand. Und Mittlerweile sieht es zumindest hier in Deutschland besser mit SIP aus, als ich gedacht hätte. Wenn es mit Provider im Ausland nachher Probleme geben sollte, gibt es ja die Möglichkeit der Anpassung des Plugins daran.

Und ein Provider hat heutzutage nichts davon, wenn ihm die Kunden weglaufen, wenn die Telefone aufgrund des SIP Protokollstacks des Providers Probleme machen.

Habe hier z.B. einen Cisco 2911 Router mit Voice Gateway Funktion SIP => ISDN. Und selbst der meldet sich noch bei Telekom Deutschland LAN an. Problemlos sogar mit Firmware von 2012 (IOS 15.2.3? glaube ich).

PS: Wenn ich die Präsentation vorstelle, darf sich natürlich gerne darüber ausgelassen werden, denn jede Meinung dazu ist mir da wilkommen. :)