Hilfe für Grundeinstellung Asterisk/Telekom benötigt

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.
 
Ok. Du hast Recht und ich meinen Frieden.
 
[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, …
 
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...
 
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 ...
 
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.
 
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).
 
Hallo zusammen,

ich hänge mich mit meiner Frage hier mal dran, da es um das Thema Telekom (All-IP etc., kein Telekom-SIP-Trunk) mit PJSIP hinter NAT geht und das hier ganz gut rein passt, und ich gehofft hatte, die hier gezeigte Beispiel-Konfiguration würde das Problem lösen, was sie aber leider nicht tut.

Das Problem ist, dass die eingehende Telefonie mit sonst funktionierenden Einstellungen nicht funktioniert, solange nicht am Router der Port, der im PJSIP-Treiber als "port to listen on" angegeben ist, geöffnet wird. Bei SIP war dies nie nötig, da die INVITES immer über den Rück-Port, den Asterisk bei der Registrierung angegeben hat, rein kamen. Mit PJSIP kommt kein eingehendes Gespräch zustande, solange der Port (5061 in meinem Fall) nicht im router geöffnet wird. Für diese unschöne Lösung (aus Sicherheitsgründen) suche ich eine Alternative, und habe daher die Frage ob jemand Telekom->All-IP-PJSIP mit NAT ohne Portfreigabe am laufen hat. Bei den SIP-Trunks der Telekom habe ich dieses Problem nicht.

Leider habe ich trotz stundenlangem Probieren keine funktionierende Konfiguration gefunden, habe Optionen wie rport probiert, Registrierung mit- und ohne Port-Angabe, etc. - Angaben zum STUN-Server weggelassen oder wieder eingefügt, etc. - aber die INVITES werden offenbar einfach immer an den Port 5061 geschickt, den ich im SIP-Treiber als Listening-Port angegeben habe - oder ich habe einfach noch nie die richtige Kombination erwischt!?

Hat jemand eine Erklärung bzw. noch besser, eine Lösung dafür?

Besten Dank im Voraus!
 
Mit PJSIP kommt kein eingehendes Gespräch zustande
Was darf man genau darunter verstehen? Kommt der Invite bis zum Router, aber wird dort nicht weitergeleitet?

Wie auch immer, wenn Du mit TCP unterwegs sein solltest, wird im Rahmen des Registers eine TCP-Connection von Asterisk -> Telekom aufgemacht, die solange stehen bleibt, bis ein Unregister durchgeführt wird (ich gehe davon aus, dass der Register erfolgreich ist). Alle Requests werden exakt über diesen Kanal durchgeführt - egal ob von Asterisk zur Telekom oder umgekehrt. Daher kann es an dieser Stelle keine Probleme geben, weil der Port offen sein muss und das Paket durchgehen muss - sonst würde selbst eine 0815-http(s)-Anfrage eines Browsers zu einem Webserver nicht funktionieren. Da könnte es höchstens daran liegen, dass die Firewall im Router austimed. Den Timeout müsstest Du dann eben anpassen.

Oder kommt der Invite der Telekom bei Asterisk an und es liegt ein anderes Problem vor? Das müsstest Du dann aber auch konkret benennen.
 
INVITES werden offenbar einfach immer an den Port 5061 geschickt
Digium Asterisk hat die Krankheit (siehe ASTERISK-29190; und das Core-Asterisk Team kapiert es nicht), dass es im SIP-Header Contact nicht den dynamischen Port des TLS-Clients sondern den statischen Port des TLS-Server angibt. Leider habe ich hier kein Telekom Deutschland – normalerweise hätte ich erwartet, dass die Telekom auf dem dynamischen Port antwortet. Daher vermute ich etwas anderes: Kann es sein, dass Deine Firewall die TCP-Verbindung zu früh kappt? Welche Firewall nutzt Du genau? Ob das zutrifft kann Du schnell testen: Lass den Asterisk registrieren und rufe diese Nummer dann selbst (vom Handy aus an). Kommt das SIP INVITE nun über 5061 oder den dynamischen Port?

Du kannst die Firewall nicht umstellen? Dann kannst Du das in Digium Asterisk steuern, wie in der Anleitung in Post #5 beschrieben, über qualify_frequency=240. Das sind Sekunden. Wenn Du hier zum Test mal 25 Sekunden wählst, klappt es dann? Siehst Du überhaupt diese SIP OPTIONS rausgehend?
 
Ich kann das obige Problem nicht nachvollziehen. Ich setze für einen Telekom ALL-IP Endpunkt force_rport und für die Mediendaten rtp_symmetric auf wahr. Ich benötige auch keine kurzen OPTIONS (qualify) Intervalle. Ich habe sogar Verbindungen, wo ich auf OPTIONS ganz verzichte, aber die Tests für einen Telekom ALL-IP Anschluss stehen noch aus.

Ich verwende aber nur Router, die es mir erlauben explizite rausgehende NAT Regeln zu setzen (OPNSense, pfSense, ...). Mit den sich nicht ändernden Ports an allen beteiligten Stellen ist die Fehlersuche auch etwas einfacher. Abgesehen davon würde ich von vorne herein auch immer gleich noch einen Homer Server an Asterisk dranhängen. Die Anbindung geradezu trivial.

Zumindest bis Asterisk 18.2 muss man die DNS-Auflösung von Asterisk für den ALL-IP Anschluss (nicht für den SIP-Trunk) etwas ändern, oder anderweitig tricksen... Das wäre aber ein anderes Problem.
 
Hallo zusammen,

vielen Dank erstmal für die vielen Reaktionen und Rückmeldungen.

Ich habe mir das Problem Vorgestern, Gestern und Heute nochmal etwas genauer angeschaut, weil ich auch an einem Telekom-SIP-Trunk plötzlich ein ähnliches Problem hatte, mit dem Unterschied, dass dort die Anrufe garnicht mehr ankamen, auch nicht mit Portweiterleitung. Das Problem konnte ich lösen und den Lösungsansatz habe ich dann für die ALL-IP-Anschluss-Problematik auch nochmal probiert. Das Problem ist folgendes:

Ich habe mir mit Wireshark die Daten angesehen. Es ist so, dass im REGISTER von Asterisk an die Telekom im VIA und CONTACT Header immer der der Port an die IP angehängt wird, der im PJSIP-Treiber für das binding angegeben ist. Lässt man ihn leer fügt er einfach den Port 5060 an. Es ist dabei egal, ob die Optionen rport und/oder rewrite contact aktiv sind oder nicht. Das eigenartige ist, dass der Router die Antworten zur Registrierung durchlässt, aber die Invites nicht. Ich bin schon mit dem Router-Hersteller in Klärung, ob die eine Idee dazu haben - aber ich glaube eigentlich fast nicht, dass es ein Problem des Routers ist! ALG-Modus ist im Router deaktiviert, KeepAlive steht auf 90 sek. und liegt somit unter dem Timeout des Routers, bis der den Port wieder schließt. Ich kann mir einfach keinen Reim aus der Sache machen. Falls hierzu noch jemand eine Idee hat, bin ich für jeden Tipp oder Ansatz dankbar!

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Vollzitat von darüber gemäß Boardregeln entfernt
Deswegen nutzen wir PJSIP, da mit SIP die SRV-Lookups nicht richtig funktionieren sollen und die Telekom ja eigentlich zum 28.2. die klassische DNS-Auflösung abschalten wollte, dies aber wohl bis 31.3. verschoben hat - so die Aussage der Hotlin vor ein, zwei Wochen..

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Vollzitat von darüber gemäß Boardregeln entfernt
keep_alive steht auf 90 sekunden, der Router macht erst ab 190 Sekunden oder so dicht - das hatte ich schon gecheckt. Ein Register-Paket mit einem dynamischen Port konnte ich Asterisk tatsächlich nicht abringen! Wie gesagt, wenn ich die Port-Angabe beim Binding leer lass, steht im Contact-header nachher 5060 drin. Trage ich 5061 ein, schickt Asterisk die Pakete auch von diesem Port raus und die Telekom versucht auch dort hin wieder durch zu stellen, nur dass das Paket halt vom Router nicht durchgereicht wird - warum auch immer.
 
Zuletzt bearbeitet von einem Moderator:
Deswegen nutzen wir PJSIP, da mit SIP die SRV-Lookups nicht richtig funktionieren sollen und die Telekom ja eigentlich zum 28.2. die klassische DNS-Auflösung abschalten wollte, dies aber wohl bis 31.3. verschoben hat - so die Aussage der Hotlin vor ein, zwei Wochen..
Ich verwende auch nur PJSIP und Asterisk priorisiert eh SRV-Lookups.
 
Digium Asterisk hat die Krankheit (siehe ASTERISK-29190; und das Core-Asterisk Team kapiert es nicht), dass es im SIP-Header Contact nicht den dynamischen Port des TLS-Clients sondern den statischen Port des TLS-Server angibt.
Fix siehe hier.
Leider habe ich hier kein Telekom Deutschland – normalerweise hätte ich erwartet, dass die Telekom auf dem dynamischen Port antwortet.
Die Telekom - zumindest All-IP interessiert das schlicht und ergreifend nicht. Easybell auch nicht - geht alles über die Verbindung, die beim Register aufgemacht wurde. Ist auch definitiv sicher, weil der Port 5060/61 hier eingehend gesperrt ist.
Daher vermute ich etwas anderes: Kann es sein, dass Deine Firewall die TCP-Verbindung zu früh kappt? Welche Firewall nutzt Du genau? Ob das zutrifft kann Du schnell testen: Lass den Asterisk registrieren und rufe diese Nummer dann selbst (vom Handy aus an). Kommt das SIP INVITE nun über 5061 oder den dynamischen Port?
Es geht alles über die vom Client (= Asterisk) geöffnete Verbindung.

Hier habe ich das transport-Handling von Asterisk pjsip beschrieben und wie man Probleme damit speziell im Zusammenhang mit All-IP der Telekom in den Griff bekommen kann, wenn man mehr als eine Nummer registriert.
 
Zuletzt bearbeitet:
gehtdoch, verstehe leider kein Wort von Deiner Antwort. Meine Vermutung war/ist, dass die TCP-Verbindung bei ATO warum auch immer gekappt ist. Die Telekom weicht daraufhin auf den Port im Contact-Header aus. Die Frage ist, warum die TCP-Verbindung früher gekappt wird, als die lokale Firewall zu macht.
nur dass das Paket halt vom Router nicht durchgereicht wird - warum auch immer.
Das heißt, Du siehst im Router-Log oder in einem Paket-Mitschnitt, dass das Paket bei Deiner Firewall aufschlägt. Richtig? Auf welchem Port schlägt das TCP-Paket auf? Ausschließlich auf 5061? Dann müsstest Du eine Port-Weiterleitung dieses Ports auf den Asterisk machen. Problem ist dann, dass Du auch den TLS-Server auf Deinem Asterisk starten musst. Problem ist dann, dass die Telekom vielleicht Dein Server-Zertifikat nicht mag. Aber, aber, die eigentliche Frage bleibt warum die TCP-Verbindung zu ist. Siehst Du, dass Dein Asterisk wirklich die Keep-Alives macht? Was passiert, wenn Du das Keep-Alive bis auf 25 Sekunden runtersetzt?
 
gehtdoch, verstehe leider kein Wort von Deiner Antwort.
Ok, ich versuche eine Langversion:
Es geht hier um das Signaling und nicht um das RTP. Im Rahmen des Registers wird einmalig eine Verbindung vom Client zum Server der Telekom aufgebaut. Die Verbindung besteht auf der lokalen Seite aus IP-Adresse und einem ephemeral Port und auf der Serverseite aus der IP-Adresse des Servers und des angesprochenen Ports 5060 oder 5061. Also $lokaleIP:$irgendeinPort > 1024 <-> $serverIP:5060 oder 5061. Diese Verbindung gilt bis zum nächsten ReRegister (900s) und wird dann aufgefrischt und gilt die nächsten 900s und so weiter. Falls kein ReRegister mehr stattfindet, ist der Client weg und der Telekomserver kennt Dich nicht mehr und kann Dir keine Calls mehr zuweisen und der Client kann auch keine Calls mehr absetzen.
Über diese einzige Verbindung gehen alle Calls usw. - egal ob ein- oder ausgehend. Die Telekom (und nicht nur die macht das so), macht nie eine Verbindung von ihrem Server zu Dir auf (daher benötigst Du zumindest für diesen Zweck auch keinen Listenerport 5060/5061).

Bei der NAT-Thematik kommt nun u.a. die Firewall ins Spiel, die von einer nicht Internet-IP in die jeweils aktuelle globale IP übersetzen muss. Hier greifen u.U. Timeouts, die zu dem führen, was Du (und ich) vermuten: die Firewall macht dicht.

Ich habe Dich nun so verstanden, dass die Firewall via deep packet inspection mitbekommen soll, welche Ports und IP-Adressen jeweils für die Verbindung relevant sind, um so ein automatisiertes Masquerading auf die Reihe zu bekommen. Weil Asterisk in allen derzeit produktiven Versionen einen Fake-Port einträgt im Contact und Via header, kann es im Zusammenhang mit deep packet inspection zu Problemen führen. Dafür gibt es aber den von mir oben genannten Patch, der dafür sorgt, dass korrekte Ports im Contact und Via enthalten sind.

Des weiteren wird seitens Asterisk kein TCP-KeepAlive gesendet, welches das Masquerading der FW offen halten könnte. Allerdings kann man Qualify einstellen (dann werden alle 240 s Options-Pakete verschickt), die dann die FW offen halten sollte (d.h., der Timeout in der FW müsste dann etwas länger als 240 Sekunden sein).

Insgesamt ist der deep packet inspection - Ansatz aber ziemlich kaputt, weil er eine unverschlüsselte Verbindung voraussetzt - was aus Datenschutzgründen ein nogo ist. Daher ist der (so oder so) bessere Ansatz: entweder auf NAT verzichten oder die Timeouts in der FW so hoch ansetzen, dass es grundsätzlich zu keinen Problemen kommen kann. Im Falle der Telekom also wenigstens 15,5 Minuten (sicherheitshalber). Irgendwie musst Du ja auch noch den RTP-Strom ermöglichen. Auch da muss ja die Firewall irgendwie mitspielen ... . Ja, ich weiß, es gibt Wege, um Löcher in die Firewall zu schießen - welchen Sinn macht die dann noch? Ich will das nicht haben! Andere dürfen gerne anderer Meinung sein.
 
die Firewall [soll] via deep packet inspection mitbekommen
Nö. Die Hypothese ist erstmal, dass bei ATO die TCP-Verbindung gekappt ist. Meine zweite Hypothese war dann, dass die Pakete auf dem falschen Port aufschlagen. Jetzt ist ATO dran, uns zu sagen, auf welchem Port genau die INVITEs der Telekom aufschlagen. Dann müssen wir schauen, wie wir die Firewall offen halten. Dazu braucht der Router/Firewall den Inhalt (Datenteil) der Pakete nicht anschauen. Normalerweise reicht Datenverkehr, also im Falle von Digium Asterisk die OPTIONs rechtzeitig zu schicken. Nun meint ATO aber, dass er das schon so eingestellt hat. Wir überprüfen das jetzt nochmals gemeinsam, indem er uns sagt, auf welchem Port seine INVITEs aufschlagen. Schön wäre noch, wenn uns ATO verrät, welche Firewall er genau verwendet. Dann können wir vielleicht gezielter helfen. Aber ich befürchte, er hat in seinem Aufbau zwei Firewalls (Mobilfunk?, Router-Kaskade?).
über diese einzige Verbindung […] und nicht nur die [Telekom Deutschland] macht das so
Offtopic, nur zur Ergänzung: Leider nicht alle.
Zum Beispiel Digium Asterisk chan_pjsip selbst und daher auch Sangoma FreePBX chan_pjsip aber auch SignalWire FreeSWITCH machen das von Haus aus nicht so. Für VoIP/SIP-Anbieter mit jener Software muss dann entweder (a) der tatsächliche Port im SIP stehen, (b) die Firewall auf 5060/tcp bzw. 5061/tcp auf sein und auch ein TCP/TLS-Server lokal laufen oder (c) Du musst als Nutzer Deinen VoIP/SIP-Anbieter überzeugen, jene optional Einstellung einzuschalten (welche, siehe Ticket). AVM hatte in seinem VoIP-Client den selben Fehler in FRITZ!OS 7.20 und hat dies dankenswerten mit FRITZ!OS 7.25 repariert. Daher hilft ASTERISK-29241 bei ASTERISK-29190 nicht = es ist kein Fix dafür.
 
Zum Beispiel Digium Asterisk chan_pjsip selbst und daher auch Sangoma FreePBX chan_pjsip aber auch SignalWire FreeSWITCH machen das von Haus aus nicht so.
Doch - macht Asterisk so (zumindest die aktuellen Versionen 16 und 18 auf Basis pjsip), falls das Paket auf Basis der Vorgaben von Sangoma und dem gebundelten pjsip kompiliert wurde - vielleicht nicht, wenn es anders kompiilert wurde. Wird gemäß diesem RFC umgesetzt. Bereits im REGISTER seitens Asterisk ist der alias-Parameter im Via enthalten und wird auch von der Telekom explizit bestätigt. Aber auch selbst, wenn kein alias gesetzt wird (bei internen Devices, angebunden via TCP z.B. hier) wird für alle Requests, völlig egal, welche Richtung, die exakt gleiche Verbindung verwendet, welche vom registrierenden Client aufgebaut wurde. Der Neuaufbau einer TCP oder gar TLS-Session für einen Request würde viel zu viel Zeit in Anspruch nehmen. Die TCP-Verbindung von Asterisk zu den internen Telefonen z.B. ist hier bedingunglos und komplett geblockt (wäre ja auch nochmal so schön, wenn das überhaupt nötig wäre) über die globale FW-Policy DROP - ebenso wie der Zugriff vom Internet auf Port 5060/61.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.