Hilfe für Grundeinstellung Asterisk/Telekom benötigt

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
172
Punkte für Reaktionen
12
Punkte
18
Du hast meine Argumente nicht verstanden und zeigst auch nicht, dass Du sie verstehen willst.
Vielleicht möchtest Du Dir mal die Mühe machen, den letzten Absatz hier zu lesen.
Für alle Anderen: Die Deutsche Telekom schert sich nicht um Digium Asterisk, Sangoma FreePBX oder FreeSWITCH.
Kein Provider schert sich um irgendeine Software, die er nicht explizit als unterstützt einstuft. Hat also absolut nichts mit Deutsche Telekom im Speziellen zu tun. Ohne dass Du die grundsätzlichen Grundlagen kennst und wenigstens ansatzweise verstanden hast, kannst Du nicht wirklich einen eigenen SIP-Server dauerhaft betreiben (es gibt da obendrein auch noch sowas wie einen Lifecycle von SW und Hardware). Daher ist Deine spezifische Unterstützung hier zwar durchaus gut gemeint, führt aber dazu, dass irgendwelche $User irgendwas blind machen, was im Einzelfall durchaus mal zufällig funktionieren kann - oder eben auch nicht und er kennt auch potentielle Nebenwirkungen nicht (er weiß ja nicht, was er de facto tut, weil er es nicht versteht / weiß - von Ausnahmen sicher abgesehen). Er wird dann aufhören, sich mit der Materie zu beschäftigen, wenn es aus seiner Sicht gerade mal so "funktioniert" - warum und wie auch immer, ist dann irrelevant. Wenn es nicht mehr tut, steht er wieder im Regen. Das ist auch der Grund, warum ich auf meine eigene früher gepostete Beispielkonfig bewusst nicht verlinkt habe. Ganz abgesehen davon erwarte ich, dass fragende User diese Info selbst finden.

Nochmal zur grundsätzlichen Architektur: es wird ja gerne aus netztechnischen Gründen geraten, den Asterisk hinter den Voiceservern der Kaufrouter zu betreiben. Ja, klingt auf den ersten Blick einleuchtend. Ist es aber nicht, weil da u.a. exakt das gleiche gilt wie für die Schnittstelle Asterisk (oder whatever) <-> Provider. Dass Du Dir mit dieser Konstellation sogar noch viel mehr Komplexität und Schnittstellenprobleme ins Haus holst, darfst Du dabei nicht verschweigen.

Die einzige ordentliche, stabile und dauerhaft weniger aufwändige Lösung ist, einen eigenen Router aufzubauen und zu betreiben und den Asterisk (oder whatever) darauf zu betreiben (mit IPv6 könnte man evtl. zu einer anderen Bewertung kommen). Der Aufwand zu diesem Schritt ist relativ betrachtet nur noch minimal, weil man sich manches grundsätzliche Netzwissen eh schon für den Voiceserver aneignen musste. Eine FreePBX zum Router anzupassen z.B. ist mit einigem grundsätzlichen Linux-KnowHow durchaus machbar. Aber natürlich nur, wenn man vorher ein grundsätzlich vollständig durchdachtes Konzept hat. Und dann logischerweise auch die geeignete Hardware dafür.
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
172
Punkte für Reaktionen
12
Punkte
18
Ok. Du hast Recht und ich meinen Frieden.
 

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
1,537
Punkte für Reaktionen
143
Punkte
63
[Für] Asterisk hinter den Voice-Servern der Kauf-Router [gilt] exakt das gleiche […] wie für die Schnittstelle Asterisk ↔︎ Provider.
Nicht wirklich. Diese Kaufboxen sind ein Media-Plane B2BUA ähnlich einem SBC, jedenfalls die drei genannten Kaufboxen. VoIP/SIP-Provider wie Telekom Deutschland sind IMS ähnlich transparenten SIP-Proxies. Bei einem IMS kann die wirkliche Gegenstelle alles Unmögliche sein, d.h. Du könntest von heute auf morgen quasi direkt mit Brasil Telecom oder Telenor Myanmar sprechen. Abgesehen von den ganzen inländischen Zielen wie Behörden-Ruf oder die neuen Glasfaser-Betreiber, aber eben auch WLAN-Telefonie, VoLTE, … Du müsstest folglich täglich alle† Anruf-Szenarien mit allen Zielen (und Quellen) testen.

Ich bin mir nicht einmal sicher, ob die Deutsche Telekom geschweige denn AVM, Bintec-Elmeg oder LANCOM verstehen, was sie jetzt seit 15 Jahren da vor haben; vermutlich machen sie das selbst nicht einmal sondern nur rein stochastisch. Aber das als Einzel-Person-Maintainer stemmen zu wollen … kann man probieren und man hat ein neues Hobby. Daher zusätzlich mein Hinweis auf die von der Telekom Deutschland selbst vertriebenen Kaufboxen. Persönlich habe ich mich ganz anders herausgerettet: Ich habe meinen Asterisk/chan_sip und auf der Gegenseite einen PSTN-Provider ebenfalls mit Asterisk/chan_sip. Ehrlich? Mir auch schon zu kompliziert.

† Nur mal drei Beispiele was hier „alle“ bedeutet: Besetzt, Anruf-Abweisen, Anruf nicht annehmen, …
 

Meester Proper

Mitglied
Mitglied seit
24 Mai 2014
Beiträge
233
Punkte für Reaktionen
26
Punkte
28
Ganz so transparent sind IMS nicht, es gibt schon viele Black- und Whitelists von SIP-Headern und -Bodys, Syntaxüberprüfungen sowie Rufnummernnormalisierung durch Applikationsserver, die in der Regel als B2BUA agieren. Zumal stützt sich praktisch alles auf entsprechende RFCs...
 

abw1oim

Aktives Mitglied
Mitglied seit
26 Mrz 2007
Beiträge
957
Punkte für Reaktionen
4
Punkte
18
Zur Syntaxüberprüfung sind sie ja auch in ihrer Eigenschaft als SIP-Gateway / Mediator verpflichtet: Niemand will wirklich inkonsistente Signalisierungsdaten, die nicht RFC-konform sind. Spannender ist da in der Tat das Thema Blacklisting (oder auch: Headermanipulation) neben der Frage, welche der zahlreichen optionalen RFCs dann unterstützt sind (das ist leider das gleiche Drama wie weiland mit ISDN supplementary services).
Insoweit bleibt es auch auf Kundenseite immer spannend, die optimalen Settings für den Provider zu finden ...
 

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
1,537
Punkte für Reaktionen
143
Punkte
63
Also nur mal so zur Info, gibt auch Provider, die einfach so durchjagen. Anderes Thema. Mir ging es darum, dass der B2BUA vor Ort kein Moving-Target ist. Wenn mir ein Software-Update nicht gefällt, kann ich es erstmal zurückrollen. Labor aufziehen und das Update getrennt vom Live-System debuggen. Ich kann sogar vorher im Labor testen und erst dann die Updates ausrollen. Spielt allein mal mit dem Szenario „Anruf nicht annehmen“ bei den verschiedenen VoIP/SIP-Anbieter und jeweils mit verschiedenen Ziel-Netzen.
… stützt sich praktisch alles auf entsprechende RFCs.
Ja, aber dann müsste – nur als konkretes aber hier nicht passendes Beispiel – Asterisk/chan_sip mit seinem fehlenden SIP-UPDATE noch tun. Leider fehlt mir ein Anschluss von Telekom Deutschland, um dass vollständig zu debuggen. Auch deswegen empfiehlt gehtdoch, dass chan_sip veraltet sei und man doch bitte chan_pjsip nehmen solle.
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
172
Punkte für Reaktionen
12
Punkte
18
Mir ging es darum, dass der B2BUA vor Ort kein Moving-Target ist. Wenn mir ein Software-Update nicht gefällt, kann ich es erstmal zurückrollen. Labor aufziehen und das Update getrennt vom Live-System debuggen. Ich kann sogar vorher im Labor testen und erst dann die Updates ausrollen.
Wohl wahr - wenn die Bedingungen vorhanden sind - Mindestens 2 Leitungen und mindestens drei(!) Router (man will ja auch noch einen Backup für das Prod-System haben). Sicherlich ein eher seltenes Szenario für einen Privatanwender oder selbst für mehr oder weniger kleinere gewerbliche Betriebe.
Spielt allein mal mit dem Szenario „Anruf nicht annehmen“ bei den verschiedenen VoIP/SIP-Anbieter und jeweils mit verschiedenen Ziel-Netzen.Ja, aber dann müsste – nur als konkretes aber hier nicht passendes Beispiel – Asterisk/chan_sip mit seinem fehlenden SIP-UPDATE noch tun.
Das ist komplexer als Du es hier darstellst. chan_sip "funktioniert" ja auf den ersten Blick durchaus - hat aber Probleme im Einzelfall, z.B. was das Sessionhandling teilweise angeht. Die Telekom fährt das Sessionhandling per default via Update (wenn es vorhanden ist) und nicht via ReInvite. Letzteres ist daher offensichtlich ein Workaround, der funktionieren mag oder auch nicht (obwohl auf SIP-Ebene alles fehlerfrei läuft, wird die Session im Einzelfall trotzdem abgebrochen). Da bist Du alleine. Kenne ich auch von anderen Anlagen, die kein Update zur Verfügung stellen.
Manche kamen dann teilweise die Idee auf, dass die ReInvites authentifiziert laufen sollten. Hing vielleicht damit zusammen, dass Asterisk an den falschen Server ging (hier sind wir wieder beim Betriebskonzept der Telekom AllIP) - ich habe mich damit nicht weiter auseinandergesetzt, weil es bescheuert ist, einen toten Gaul zu reiten.

chan_sip ist seit 2013 im Status extended, das heißt, es findet keine Weiterentwicklung mehr statt durch Sangoma - alles, was noch folgte, kam von der Community und hat (teilweise bekannt) immer wieder Regressions verursacht. Das will man auf keinen Fall haben. Seit Asterisk 17 (2019) ist chan_sip deprecated. D.h., man muss sich darauf einstellen, dass chan_sip früher oder später komplett entfernt wird. Wie auch immer, chan_sip ist schon seit Jahren de facto tot - damit startet man schon seit Jahren nicht mehr.

Ob FreeSwitch die bessere Alternative zu Asterisk ist, würde ich zumindest bezweifeln. Bei Sangoma bekomme ich wenigstens noch eine europäische Adresse (UK), bei FreeSwitch habe ich überhaupt keine Adresse gefunden. Die IP-Adresse wird SignalWire zugeordnet (passt - die Firma hinter FreeSwitch) und nach Oklahoma verortet. Klingt für mich nicht nach besserem Support deutscher Verhältnisse als bei Asterisk.

Zur Variante, Asterisk hinter den Voice-Server irgendeiner Kaufbox zu verbannen: macht für mich, wie schon an anderer Stelle beschrieben, keinen Sinn. Ein weiterer Grund ist auch: warum setze ich überhaupt einen eigenen Voice-Server auf? Doch bestimmt nicht deshalb, weil ich mit der Schnittstelle in der Kaufbox glücklich bin, sondern deshalb, weil diese Stress macht oder einfach meine Anforderungen nicht erfüllt. Dann packe ich doch nicht genau diese Schnittstelle nochmal dazwischen und erbe wieder sämtliche Einschränkungen, Probleme, whatever und bekomme überdies noch neue dazu (eine Kette ist immer nur so stark wie ihr schwächstes Glied).