Achtung! Dieser Beitrag ist nicht mehr aktuell. Die aktuellen Beiträge zu diesem Thema findet Ihr hier oder in der Youtube-Playlist für die neue Themenreihe:
Hier geht’ zum Forum
Hier eine Anleitung wie man FreePBX/Asterisk am SIP-Trunk der Telekom registriert:
Bevor mit der eigentlichen Konfiguration begonnen werden kann, muss das TCP-Protokoll aktiviert werden, da die Telekom VOIP-Anschlüsse nur über TCP und nicht über UDP kommunizieren. Dazu wie folgt vorgehen:
Aktivieren des TCP-Protokolls
In FreePBX unter Einstellungen/Asterisk SIP-Einstellungen unter dem Punkt “Transporte”, Unterpunk “tcp” das TCP-Protokoll wie im nachfolgenden Screenshot gezeigt aktivieren:
Das TCP-Protokoll muss dann auch in der Konfiguratiin des SIP-Trunk aktiviert werden.
Einrichten des SIP-Trunk
Auf dem Telekom-Schreiben mit den Zugangsdaten findet man unter Punkt 3-Telefonie einrichten folgende Daten:
Telefonie-Benutzername: 550123456789
Telefonie-Passwort: geheim
Outbound-Proxy: reg.sip-trunk.telekom.de
Registrar: sip-trunk.telekom.de
Wir gehen in diesem Beispiel von folgender Telefonnummer aus:
Vorwahl: 05555
Stammnummer: 12345
Zentrale Durchwahl: 0
Diese Daten müssen im FreePBX exakt wie folgt eingetragen werden:
Hauptleitung (Trunk)
Achtung! Im Feld “Transport” muss das tcp-Protokoll eingestellt sein.
In Feld “Context” muss stehen: from-pstn-pciheader
Dann den folgenden Context in die extensions_custom.conf eintragen:
[from-pstn-pciheader]
; einheitliche Nummer im internationalen Format wird im Telekom SIP Trunk im Header P-Called-Party-ID übergeben
; im To-Header kommt die Nummer in unterschiedlichen Formaten
; Dieser Context muss im Trunk angegeben werden
exten => _.,1,NoOp(Attempting to extract DID from SIP PCI header)
exten => _.,n,NoOp(SIP From: ${PJSIP_HEADER(read,From)})
exten => _.,n,NoOp(SIP To : ${PJSIP_HEADER(read,To)})
exten => _.,n,NoOp(SIP P-Called-Party-ID : ${PJSIP_HEADER(read,P-Called-Party-ID)})
exten => _.,n,NoOp(SIP PAI : ${PJSIP_HEADER(read,P-Asserted-Identity)})
exten => _.,n,NoOp(SIP PPI : ${PJSIP_HEADER(read,P-Preferred-Identity)})
exten => _.,n,NoOp(SIP Via : ${PJSIP_HEADER(read,Via)})
exten => _.,n,NoOp(SIP Call-ID : ${PJSIP_HEADER(read,Call-ID)})
exten => _.,n,NoOp(SIP Subject : ${PJSIP_HEADER(read,Subject)})
exten => _.,n,gotoif($[“${CHANNEL(channeltype)}”=”SIP”]?SIP)
exten => _.,n,gotoif($[“${CHANNEL(channeltype)}”=”PJSIP”]?PJSIP)
exten => _.,n,NoOp(Unable to determine SIP channel type)
exten => _.,n,goto(from-pstn,${EXTEN},1)
exten => _.,n(SIP),Goto(from-pstn,${CUT(CUT(SIP_HEADER(P-Called-Party-ID),@,1),:,2)},1)
exten => _.,n(PJSIP),Goto(from-pstn,${CUT(CUT(PJSIP_HEADER(read,P-Called-Party-ID),@,1),:,2)},1)
Hier ist noch mal der Download des Scriptes als Textdatei
Erläuterung: Die Telekom macht da etwas anders als die anderen Provider. Im Normalfall wird die angerufene Nummer im “to” Feld des Headers übergeben. Das macht die Telekom zwar, aber leider nicht im einheitlichen Format. Meistens kommt die Nummer im Format +4912345… an. Manchmal aber auch als 012345 oder 004912345. Will man die angerufene Nummer dann über eine Inbound-Route an eine Nebenstelle oder Rufgruppe weiterleiten müsste man für jeder Nebenstellennummer und jedes mögliche Format eine Inbound-Route anlegen. Das kann man aber umgehen. Im SIP-Header-Feld “P-Called-Party-ID” wird die angerufene Nummer einheitlich im internationalen Format gesendet. Der Context [from-pstn-pciheader] liest dieses Feld anstelle des “To”-Feldes aus. So spart man sich mehrere Inbound-Routen für die selbe Nebenstelle oder Rufgruppe.
Achtung Fehlerteufel im Feld “Server URI”. Muss heißen: sip:sip-trunk.telekom.de
Und die Reihenfolge der Codecs wie folgt einstellen:
Achtung! Nochmal der Fehlerteufel. Der Codec g722 muss an erster Stelle stehen. Also mit der Maus einfach dahin verschieben und falls das Häkchen beim verschieben rausgeht, anschließend wieder reinklicken.
Inbound Route
In der Inbound Route muss die Telefonnummer wie folgt angegeben werden, damit die Weiterleitung über diese Route erfolgt.
Also: +49555123450 für die Zentrale, Z. B. +49555512345100, +49555512345200 usw. für die anderen Nebenstellen oder Rufgruppen.
Für jede Nebenstelle oder Rufgruppe die per Durchwahl direkt von außen erreichbar sein soll, muss jeweils eine Inbound Route angelegt werden
Hier geht’ zum Forum
Hallo,
was für ein Router hängt in der Anleitung vor der FreePBX?
Viele Grüße
Norbert
Das ist eine FB 7590. Ist bei dieser Konfiguration aber egal, weil der Router lediglich die Internetverbindung bereit stellt. Die Freepbx registriert ja direkt am SIP-Trunk der Telekom.
Wissen Sie, was ich bei der Inbound Route als DID angeben muss, um +4912345 als auch 012345 in die gleiche Nebenstelle weiterzuleiten. Kann man das mit einem Pattern abfangen? Aktuell habe ich für jede Nebenstelle 2 Inbound Routes angelegt. das geht doch sicherlich schöner.
Die Telekom reicht die DID unterschiedlich durch. Übers Handy als +4912345, als Ortsgespräch mit 012345.
Viele Grüße Thomas
Hallo,
ich denke ich habe dafür eine Möglichkeit gefunden. Habe den Blog-Beitrag entsprechend ergänzt.
Grüße
Danke für die schnelle Antwort.
die Zeile “[from-pstn-custom]”, muss die genau so heißen, oder ist das der Name des Contextes des trunks “[from-pstn-toheaqder]”?
Normalerweise müsste es so funktionieren wie von mir angegeben, da [from-pstn-custom] eigentlich in jedem Fall abgearbeitet wird.
Das Wort custom sagt ja auch, dass es genau für solche nutzerspezifischen Anpassungen gedacht ist.
Aber wie gesagt: ich hab’s nicht getestet. Aber es spricht ja nichts dagegen, wenn [from-pstn-custom] nicht funktioniert, es mal mit [from-pstn-toheader] zu probieren.
Hallo,
ich habe das alles so nachvollzogen wie angegeben. Allerdings wird der Trunk nicht registriert (rejected). Bei meinem Recherchen bin ich auf einen Forumsbeitrag bei community.freebox.org gestoßen, in dem Sie wohl dort auch diese Frage gestellt haben.
Leider ergibt sich aus dem Beitrag keine Lösung.
Ich nehme an dass Sie das Problem lösen konnten – können Sie mir einen Hinweis geben wo bei einem PJ-SIP Trunk der srvlookup eingetragen werden muss.
Ich weiter gefunden, dass bei Asterisk (ohne freepbx) hier der sip.conf eingetragen werden soll, aber wird nicht diese Datei bei Updates von freepbx überschrieben?
Sollte das dann in die sip_custom.conf eingetragen werden? Oder welche der *_custom.conf Dateien soll verwendet werden?
Viele Grüße
Norbert Zosig
Hallo,
ich habe gerade in den letzten 10 Tagen wieder 3 Installationen mit Registrierung am Telekom SIP-Trunk durchgeführt. Das hat geklappt ohne Probleme und extra Aktivierung eines SRV-Lookup.
Bei mir hat der allererste Versuch am SIP-Trunk zu registrieren auch nicht geklappt und da habe ich auch im Web recherchiert. Da bin ich auf einen Beitrag gestoßen, dass es am SRV-Lookup liegen würde. War aber ein Beitrag über die Konfiguration von Chan-Sip. Für PJSIP hat das nicht zugetroffen.
Tatsächlich habe ich Problem dann dadurch gelöst, in dem ich die Zugangsdaten zum SIP-Trunk in unterschiedlichen Varianten und in unterschiedliche Felder in der SIP-TRUNK-Konfiguration der FreePBX eingetragen habe.
Also sollte das Problem recht einfach lösbar sein. Ich versuche Dir noch mal ein paar wichtige Hinweise zu geben, woran es liegen könnte.
1. Die von mir beschriebene Konfiguration habe ich mit FreePBX14 / Asterisk 13 durchgeführt. Habs auch schon mit FreePBX 14 / Asterisk 15 probiert. Da hat die Registrierung auch geklappt aber da gibts noch einige Bugs. Also noch nicht empfehlenswert.
2. Du musst die Anleitung 100%ig befolgen. Wirklich 100%ig. Ein klassischer Fehler ist zum Beispiel die Angabe des Trunk-Namen (das erste Feld im Reiter “General” der Trunk-Konfiguration). In meiner Anleitung steht da “550123456789”. Normalerweise ist der Trunk-Name frei wählbar. Nicht aber beim Telekom SIP-Trunk. Beim Telekom SIP-Trunk muss in das Feld “Trunk Name” zwingend der “Telefonie-Benutzername” aus Deinen Telefonie-Zugangsdaten rein. Das rauszufinden hat mich Tage gekostet.
3. Was ich im Beitrag im Screenshot zwar gezeigt, aber nicht extra erwähnt habe ist die Verwendung des TCP-Protokolls. Die Telekom VOIP’s kommunizieren ausschließlich über TCP. Ich habe den Beitrag entsprechend ergänzt. Schau ihn bitte noch mal an.
4. In meiner Anleitung, in dem Screenshot zum Reiter “erweitert” in der SIP-Trunk Konfiguration der FreePBX steht in dem Feld “Server-URI” ein falscher Wert. Der richtige Wert steht unterhalb des Screenschots hinter der Bemerkung “Achtung Fehlerteufel!”.
5. Eins fällt mir noch ein. Die Telekom bietet ja 2 Typen von VOIP-Anschlüssen an. Zum einen den Telekom ALL-IP Anschluss als Ersatz für den früheren ISDN-Mehrgeräte-Anschluss (Da hatte man meistens 3 MSN’s) und den Telekom DeutschlandLAN SIP-Trunk als Ersatz für früheren ISDN-Anlagenanschluss (Das war der Anschluss mit den Durchwahlnummern). Meine Anleitung bezieht sich auf den Telekom DeutschlandLAN SIP-Trunk. Beim ALL-IP Anschluss wird eine andere Konfiguration erforderlich sein.
Wenn Du also FreePBX 14 / Asterisk 13 verwendest und die Anleitung und meine Hinweise genau befolgst dann muss das auch klappen.
Ich hoffe die Hinweise helfen. Gib mal ‘ne Info ob’s geklappt hat.
Schönes Osterfest
Hallo,
danke für die schnelle Antwort. Ich habe den Unterschied erkannt. Ich verwende Asterisk 15 weil ich irgendwo gelesen habe dass es da angeblich keine Probleme gibt. Ich setze jetzt mal genau die gleiche Version auf und versuche es erneut.
Ich melde mich dann wieder.
Danke, schöne Ostern und Grüße aus Franken.
Norbert
Hallo,
ich habe es nicht ausgehalten und es gleich probiert. Asterisk 14 war die Lösung! Endlich war die Registrierung erfolgreich!
Vielen, vielen Dank für die tolle Anleitung und die fast schon lebensrettenden Hinweise.
Ich bin ja erst seit Juli 2018 drüber.
Viele Grüße
Norbert Zosig
Zunächst nochmal Dankeschön für dieses Tutorial! Es hat mir sehr geholfen, den SIP-Trunk überhaupt zum Laufen zu bekommen. Ein Feedback möchte ich jedoch noch geben:
Zitat:
1. Die von mir beschriebene Konfiguration habe ich mit FreePBX14 / Asterisk 13 durchgeführt. Habs auch schon mit FreePBX 14 / Asterisk 15 probiert. Da hat die Registrierung auch geklappt aber da gibts noch einige Bugs. Also noch nicht empfehlenswert.
Meine Erfahrung dazu:
Mit Asterisk 16 hatte ich immer wieder folgende Fehler:
[2019-11-07 05:08:06] VERBOSE[4845] res_pjsip/pjsip_configuration.c: Endpoint Telekom-Sip-Trunk is now Unreachable
[2019-11-07 05:08:06] VERBOSE[4845] res_pjsip/pjsip_options.c: Contact Telekom-Sip-Trunk/sip:+49xxxxxxxx@sip-trunk.telekom.de is now Unreachable. RTT: 0.000 msec
[2019-11-07 05:10:03] VERBOSE[4845] res_pjsip/pjsip_configuration.c: Endpoint Telekom-Sip-Trunk is now Reachable
[2019-11-07 05:10:03] VERBOSE[4845] res_pjsip/pjsip_options.c: Contact Telekom-Sip-Trunk/sip:+49xxxxxxxxxx@sip-trunk.telekom.de is now Reachable. RTT: 45.537 msec
Das kam unregelmäßig alle paar Stunden, mit dem Ergebnis, dass man in der Zeit nicht raustelefonieren konnte. Ich habe an allen möglichen Hebeln und Schaltern gedreht, der Fehler war nicht wegzubekommen. Im Wireshark-Trace war zu sehen, dass die TCP-SIP-Session mit der Telekom die ganze Zeit sauber bestand und eigentlich gar kein Problem da war.
Ich habe dann den Trunk nochmal neu aufgesetzt, und diesmal die Einstellungen von https://community.asterisk.org/t/pjsip-settings-for-two-german-telekom-products/79293 manuell in FreePBX eingepflegt. Dasselbe Ergebnis. Trunk is now Unreachable alle paar Stunden mal.
Dann habe ich von Asterisk 16 auf Asterisk 13 gedowngraded, und bisher sieht es gut aus. Ich halte Euch auf dem Laufenden.
Zitat:
2. Du musst die Anleitung 100%ig befolgen. Wirklich 100%ig. Ein klassischer Fehler ist zum Beispiel die Angabe des Trunk-Namen (das erste Feld im Reiter “General” der Trunk-Konfiguration). In meiner Anleitung steht da “550123456789”. Normalerweise ist der Trunk-Name frei wählbar. Nicht aber beim Telekom SIP-Trunk. Beim Telekom SIP-Trunk muss in das Feld “Trunk Name” zwingend der “Telefonie-Benutzername” aus Deinen Telefonie-Zugangsdaten rein. Das rauszufinden hat mich Tage gekostet.
Das kann ich nicht bestätigen, und ich fände es auch unlogisch wenn es so wäre. Der Trunk-Name ist doch ein rein symbolischer Name, der sich im Wireshark-Capture auch nirgends finden lässt. Bei mir heißt der Trunk jetzt "Telekom-Sip-Trunk" und funktioniert genauso gut/schlecht wie vorher mit der Benutzerkennung.
Hat hier jemand eine Idee, w arum es mit Asterisk 16 nicht geht? Man findet generell zu dem "no Reachable" bei Trunks wenig Info, und wenn, dann liegt es fast immer am UDP/NAT – was ja hier wohl kaum der Fall sein kann. Vielleicht hilft "qualify_frequency = 0"? Ich habe aber zu wenig Ahnung von SIP um zu überblicken, ob man das will oder nicht will.
Hi Danke für die wirklich gute Themenreihe! Leider funktionierte. Der Custom Extension Context bei uns nicht, da die Abfrage ob PJSIP oder normal SIP in deinem Beispiel nicht funktionierte. Da der Trunk eh von uns als PJSIP Trunk konfiguriert wurde ist die Abfrage eh hinfällig, sodass wir mit -.,n,Goto(from-pstn,${CUT(CUT(PJSIP_HEADER(read,P-Called-Party-ID),@,1),:,2)},1)
Ohne das (PJSIP) in den Klammern wunderbar hinkommen 🙂
Und warum hast du den g722 Codec erst an dritte Stelle und nicht an erster Stelle gesetzt? Das führt dazu, dass HD-Voice Anrufe nicht funktionieren weil die Telekom wohl dem Client den Vortritt bei der Wahl des Codecs lässt, obwohl beide Teilnehmer eines Anrufs HD-Voice fähig sind.
Wollte meine Erfahrungen hier mal kund tun damit auch andere davon etwas haben 🙂
Hallo, danke das Du Deine Erfahrungen mit uns teilst. Warum der Context nicht funktionieren soll ist mir nicht ganz klar. Den Code habe ich aus meiner eigenen Konfiguration kopiert. Da funktioniert er. Aber da PJSIP eh moderner ist, kann man mit Deinem Workaround erst mal leben. Der Codec G722 gehört tatsächlich an die erste Stelle. Das habe ich bei der Dokumentation einfach übersehen. Diese Anleitung habe ich einstmals für eine Anfrage eines Interessenten förmlich zusammengeschossen weil ich unbedingt und schnell helfen wollte. Und da haben sich eben leider einige Fehler eingeschlichen. Soll man eben nicht machen. Einige habe ich selbst bereits korrigiert. Einen hast Du jetzt noch gefunden. Das werde ich gleich einbauen. Ich habe ohnehin seit längerer Zeit vor diese ganze Themenreihe mal auf den aktuellen Stand zu bringen. Da wird dieser Beitrag auch vollständig überarbeitet werden.
Hi,
ich habe die Anleitung Schritt für Schritt befolgt, allerdings funktioniert bei mir das Rein-Telefonieren nur, wenn ich bei der Inbound Route statt +49 die 0 nehme, soweit in Ordnung.
Allerdings kann ich von den Telefonen aus nicht nach draußen telefonieren, woran könnte das liegen? Habe schon versucht, eine Outbound Route wie in Teil 2 beschrieben anzulegen, funktioniert allerdings nicht.
Weiterhin hätte ich die Frage, ob ich die beschriebene Änderung in der extensions_custom.conf irgendwie über die Weboberfläche machen kann. Bin leider ein Neuling in der Sache.
Vielen Dank im Voraus
Hast Du denn in der Outbound-Route auch die entsprechende Hauptleitung eingestellt? Falls Du Wählmuster (Patterns) in der Route angegeben hast, dann nimm sie zum Test mal alle raus und probiere dann.
Die ectensions_custom.conf kannst Du auch ändern in der Weboberfläche im Menü Administrator/Config Edit.
Grüße
Hi,
vielen Dank für deine schnelle Antwort! Die Outbound-Route habe ich tatsächlich schon mit allen möglichen Wählmustern versucht, überall einen Punkt “.”, alles einmal ausgefüllt mit “.”, oder tatsächlich keine. Mittlerweile hab ich folgende Fehlermeldung im Log gefunden:
[2019-08-13 14:00:56] WARNING[2241] res_pjsip_outbound_registration.c: No response received from ‘sip:sip-trunk.telekom.de’ on registration attempt to ‘sip:+495xxxxx7770@sip-trunk.telekom.de’, retrying in ’60’
Die “x” in der Nummer sind natürlich Ziffern…
Ich denke mal, das wird damit zusammenhängen. Könnte es sein, dass die Outbound registration aufgrund von unpassenden Daten nicht funktioniert?
Vielen Dank
Vorweg eine kurze Erläuterung. Es gibt keine Outbound-Registrierung. Man registriert eine Hauptleitung beim Provider und schafft damit eine Verbindung zwischen FreePBX/Asterisk und dem Provider. Über diese Verbindung werden dann ausgehende und eingehende Gespräche geführt. Mit den Outbound- und Inbound-Routen wird nur der Weg beschrieben, den das Gespräch zwischen der Nebenstelle und der Hauptleitung nimmt. Da ist der Log-Eintrag etwas verwirrend. Ohne die Situation genau zu kennen, kann ich nur raten: Wenn Du bei eingehenden Gesprächen eine 0 statt einer +49 nehmen musst, vermute ich, dass Du als Anschluss keinen Telekom DeutschlandLAN SIP-Trunk sondern einen Telekom DeutschlansLAN IP-Anschluss hast. Wenn das so ist, dann bist Du im vollkommen falschen Beitrag. Du musst dann die Registrierung nach Teil 4 meiner Themenreihe durchführen.
Diese Anleitungen sind Nachbauanleitungen. Wenn Du die selben Programmversionen und die richtigen Beiträge verwendest wird es auch funktionieren.
Hallo,
erstmal vielen Dank für die ausführliche Anleitung.
Allerdings habe ich ein Problem bei der extensions_custom.conf.
Wenn ich die auswähle tut sich da nix.
Auf was muss ich denn die Inbound Routes auswerten?
Auf +49123456789 oder auf 0123456789.
Konfiguriert ist der SIP-Trunk als pjsip.
Nehme ich “from-pstn-toheader” kommen zumindest die Gespräche für +49123456789 an.
Die Telekom gibt die angerufene über den to-Header so weiter, wie sie ankommt. Die Nummer wird also nicht in ein einheitliches Format umgewandelt. Wird die Nummer mit +49… oder mit 0049… oder mit 0… oder mit 00… angewählt, dann kommt sie auch so im Standard-Header bei dir an. Das musst Du nun irgendwie abfangen.
Variante 1:
In meinem Beitrag habe ich das über den benutzerdefinierten Context from-pstn-pciheader gelöst. Der SIP-Standard hat nämlich mehrere Headereinträge definiert und die Telekom gibt die Nummer über den PCI-Header auch noch nochmal einheitlich formatiert im +49…-Format weiter. Wenn Du an extensions_custom.conf nicht ran kommst, hast Du wahrscheinlich das falsche Programm im Einsatz.
Übrigens ist die Datei leer. Das heißt, wenn Du die anklickst und ein weißes Fenster siehst in welches Du schreiben kannst, dann ist alles in Ordnung.
Variante 2:
Du legst für jedes mögliche Nummernformat für jeder Deiner Nummern die aus dem öffentlichen Netz erreichbar sein sollen eine eigene Inbound-Route an. Das kann bei mehreren Nummern aber schnell unübersichtlich werden.
Ich habe die Zeilen komplett reinkopiert. Nur dann tut sich garnichts mehr.
Die Inbounds habe ich mit +49……. angelegt.
Aus deinem Script werde ich noch nicht richtig schlau, aber ist in der Zeile
exten => _.,n,goto(from-pstn,${EXTEN},1))
evtl. eine Klammer zuviel?
Dann bekomme ich über den Inbound 0xxx xxxxxxx wenigstens alle Anrufe, aber nur an der Zentrale.
Ja, die letzte Klammer muss weg. Hätte aber auch so funktionieren müssen, da diese Zeile nur der Notausstieg aus dem Context ist, falls nicht ermittelt werden kann ob es sich um chan_sip oder pjsip handelt. Ein anderer Leser hat das auch schon mal gehabt und den Context entsprechend geändert um den Fehler zu umgehen. Schau mal ein paar Kommentare weiter oben.
Ich hatte denselben Fehler, und weiß auch, woran es liegt:
wenn man den Code aus der Webseite rauskopiert, sind die Anführungszeichen “spezielle” Anführungszeichen und nicht die normalen ASCII-Zeichen. Daher passt der Match nicht und mal kommt in den Fallthrough part. Vielleicht kann man das in der Anleitung irgendwie korrigieren?
Ich habe das Script noch mal gelöscht und als unformatierten Text in den Beitrag kopiert. Zusätzlich habe ich noch einen Link zum Download als Textdatei eingefügt.
Sollte es immer noch Probleme geben, dann bitte noch mal melden.
Grüße
Der Download als Textdatei funktioniert korrekt; der Code in der Webseite wird wohl vom Blog-System “verschönert” und dabei werden die Anführungszeichen nach wie vor verfälscht.
Vielen Dank für die Anleitung, hat mir sehr geholfen, nachdem es neulich das Netzteil unserer eigentlichen Telefonanlage nirvanisiert hat.
Habe es auch geschafft, eine Nummer per “Sonstiges Ziel” auf eine externe umzuleiten. Wenn ich das richtig sehe, ist das aber eine interne Umleitung. Schöner wäre es, wenn das per SIP 302 redirection über den Provider laufen könnte, aber wie richte ich das ein?
FreePBX selbst bietet dafür keine Konfigurationsoption über die Weboberfläche. Das geht nur über Einträge direkt in die Asterisk-Konfigurationsdateien. Ich habe mich mit dieser Problematik noch nicht weiter beschäftigt. Während diese “Umleitung im Amt” ein Standard-Leistungsmerkmal von ISDN-Anschlüssen war, wird es bei VoIP längst nicht mehr von allen Providern angeboten. Ich habe auf die Schnelle mal zwei Links herausgesucht in denen das Problem besprochen und Lösungsansätze aufgezeigt werden. Getestet habe ich es allerdings nicht.
Hier die Links:
https://community.freepbx.org/t/forward-call-via-trunk/35990
https://www.ip-phone-forum.de/threads/freepbx-did-telekom-deutschlandlan-sip-trunk.300561/
Mehr kann ich im Moment leider nicht tun, sorry.
Wenn Du’s damit hinbekommen solltest, wäre es nett, wenn Du die Lösung hier mal posten würdest, damit sie auch den anderen Lesern zur Verfügung steht.
Grüße
Ok, danke für die Info. Die Links hatte ich auch schon gefunden, nur habe ich keine Ahnung, wie ich die Skripte einbinden kann. Die FreePBX habe ich nur mal “auf die Schnelle” aufgesetzt, damit wir zu mehreren wieder telefonieren können, denn unsere eigentliche Telefonanlage ist ausgefallen und die Ersatzteilbeschaffung wohl etwas schwierig (ist halt nicht das neueste Modell).
Die Umleitung per SIP 302 funktioniert bei allen SIP-Trunks der Telekom (https://telekomhilft.telekom.de/t5/All-IP-das-digitale-Netz/Weiterleitung-mit-Rufnummernuebermittlung-bei-SIP-Trunk-Anschluss/m-p/2630177#M4631) und wohl auch bei DeutschlandLAN-Anschlüssen (zumindest meinem privaten).
Hat jemand dieses Setup erfolgreich und ohne Gesprächsabbrüche am Laufen?
Ich habe jetzt am Wochenende extra mit dieser Anleitung von CHAN_SIP auf PJSIP gewechselt, und Anrufe vom Vodafone-Mobilfunk (VoLTE/VoWIFI) brechen regemäßig ab, insbesondere wenn sie von der Zentrale auf andere Sprechstellen weitergeleitet werden.
Das Problem ist bekannt. Das habe ich auch seit ca. 8-9 Monaten bei eingehenden Gesprächen aus dem Vodafone-Netz. Vorher hat alles einwandfrei funktioniert. Das liegt definitiv an Telekom/Vodafone. Ich habe mir zum Test noch einen anderen Provider (Sipgate) eingerichtet. Wenn die Vodafone-Anrufe über Sipgate reinkommen klappt alles. Wenn es an der Anlage liegen würde dürfte das auch über Sipgate nicht funktionieren. An der Telekom-Trunk-Konfiguration kann es auch nicht liegen, sonst könnte man gar nicht telefonieren. Außerdem hat es früher ja funktioniert. Ich habe auch schon mehrere Tickets bei der Telekom aufgemacht. Aktuell habe ich auch wieder eins laufen. Irgendwie kriegen die das nicht in den Griff. Die kannten das Problem aber schon von anderen Störungsmeldungen. Am besten macht Du auch ein Ticket bei der Störungsstelle auf. Vielleicht erhöhen mehrere Tickets zum gleichen Problem die Priorität und wir kommen so schneller zu einer Lösung. Sobald ich von der Telekom Nachricht habe, werde ich die Info hier posten. Ich bitte alle mit dem selben Problem das auch zu tun.
Noch eine Frage: Hat das mit Chan_SIP bei dir definitiv funktioniert?
Grüße
Hallo,
es gibt Neues bzgl. der Gesprächsabbrüche bei Anrufen aus dem Vodafone D2-Netz. Ich hatte im letzten halben Jahr mehrere Störungsmeldungen bei der Telekom abgesetzt. Heute erhielt ich einen Anruf, dass das ein Patch eingespielt wurde und das Problem damit beseitigt wäre. Ich habe es grad mal mit einem Anrufer getestet, bei dem die Gespräche sonst immer abgebrochen wurden und hat hat funktioniert.
Grüße
Hallo,
Seit dem letzten Update funktioniert der Kontext [from-pstn-pciheader] bei mir nicht mehr, es kann niemand rein telefonieren.
Dazu kann ich nicht allzu viel sagen. Ich habe 3 Installationen von FreePBX. Dort sind alle Updates installiert und die funktionieren auch. Auch aus meinem Kundenkreis gibt es bisher keine weiteren Fehlermeldungen.
Eventuell ist bei dem Update etwas schief gelaufen. Das hatte ich zwar bisher auch noch nicht, kann aber theoretisch passieren. Da würde dann nur ein Restore aus einem zuvor angefertigten Backup helfen. Oder dein Problem mit dem Context und das Update sind zwei getrennte Ereignisse, die lediglich relativ zeitnah aufgetreten sind aber ursächlich miteinander nichts zu tun haben. Dann müsste man sich das mal genauer anschauen.
Eine Lösung kann ich so dafür leider nicht anbieten, da ich vorher erst mal die Ursache ermitteln müsste. Wenn meine Unterstützung benötigt wird, kann ich sie gern in Form eines Dienstleistungsauftrages anbieten.
Grüße
So, ich habe aus Ermanglung eines passenden Patches die Einstellungen nochmal kontrolliert.
Auch den Kontext habe ich nochmal neu kopiert und siehe da, es geht wieder! 😀
Danke für das Angebot, komme gerne drauf zurück, wenn es mal arg klemmen sollte.
Freut mich, dass alles wieder läuft.
Grüsse
Hallo, ich habe das Problem wenn ich für eine Nebenstelle oder mehre Nebenstellen die Inbound Route erstellt habe und reinwähle bekomme ich immer Z.B. von einem Handy die Rufnummer in meiner Abwesenheitsliste +49 172XXXXXXXX angezeigt und sobald ich dann in der Liste für nicht entgegengenomme Anrufe an meinem SNOM 370 Phone zurückrufen möchte funktioniert das nicht. Woran liegt das ?
Hallo,
scheint so, als hättest Du in der Outbound Route den Dial Patterns Eintrag +XXXX. vergessen.
Hallo Herrr Grieb,
ich habe folgende:
+XXX.
XXX.
match pattern
Ist das Falsch ?
Was müsste ich ändern ?
Vg
Andreas
Ohne das selbst analysiert zu haben, kann ich da auch nur raten. Hier noch ein paar Tipps.
Also diese Patterns lassen alles durch. Lösche alle anderen Outbound-Routes. Entferne in der verbleibenden Route in den Dial Patterns jegliche Einträge im Feld Anruferkennung. Bei diesen Dial Patterns dürfen Deine Nebenstellen nur 2-stellig sein. Bei 3-stelligen Nebenstellen muss ein X mehr in die Patterns. Jetzt noch mal testen. Wenn’s nicht funktioniert, dann folgende Schritte:
1. Versuche mal die Nummer im +49-Format mit Hand vom selben Gerät zu wählen. Wenn das funktioniert, die Wahl aus den Anrufspeicher aber nicht, hast Du ein Problem mit dem Telefon.
2. Zieh den Stecker an Deinem Telefon. Richte auf einem PC ein Phoner Lite Softphone ein und registriere es an der Nebenstelle des abgekemmten Telefons. Versuche die Wahl im +49er Format von diesem Softphone aus. Funktioniert das, hast Du ebenfalls ein Problem mit Deinem Telefon. Funktioniert das auch nicht, vermute ich, dass Dein Provider dieses Format ablehnt. Obwohl ich mir das nicht vorstellen kann. Deshalb zum nächsten Punkt.
3. Wähle die Nummer im 0049-Format. Wenn das funktioniert, liegt es wohl doch am Provider. Dann musst Du die Nummer umformatieren. Das machst Du im Trunk im Reiter Dial Number Manipulation Rules. Da müssen 2 Zeilen rein.
1. Zeile: prepend=00, prefix=+, Match Pattern=+XXX.
2. Zeile: Match Patterns=XXX., Alles andere leer.
Kannst Du das Problem mit diesen Hinweisen nicht lösen und Du möchtest, dass ich das Problem für Dich löse, dann müsstest Du mir einen Dienstleistungsauftrag erteilen, denn für weitere Unterstützung müsste ich mir die Konfiguration selber anschauen.
Schreib mal, obs funktioniert hat.
Grüsse