Für Fragen oder Diskussionen ist hier der Link zum entsprechenden Thema im Forum.
Hier ist das Video zum Blog-Beitrag
Was wird benötigt?
- Die vorbereitete und gestartete FreePBX / Asterisk wie in Teil 1 beschrieben
- Die Zugangsdaten für den Telekom SIP-Trunk
- PuTTY installieren
- WinSCP installieren
- Script from-pstn-pciheader (914 Downloads) downloaden
Asterisk SIP-Settings
Aufruf der FreePBX-Verwaltungsoberfläche durch Eingabe der IP-Adresse der FreePBX/Asterisk in der Adresszeile des Browsers und klicken auf “FreePBX-Verwaltung.
Im folgenden Login-Dialog die im Teil 1 festgelegten Daten für den Admin User eingeben und anmelden.
Als Nächstes Im Menü “Einstellungen” den Unterpunkt “Asterisk SIP Settings” auswählen.
Im Reiter “Allgemeine SIP EInstellungen den Parameter “Allow SIP Guets auf “Nein” setzen.
Ganz wichtig sind die NAT-Settings. Für den Telekom DeutschlandLAN SIP-Trunk wird zwingend eine statische IP odetr DynDNS benötigt.
Um hier nichts falsch zu machen, schlage ich folgende Vorgehensweise vor:
Zuerst auf den Button “Netzwerkeinstellungen erkennen” klicken. Dadurch wir die externe IP des Routers und das interne Netzwerk in die entsprechenden Felder eingetragen.
Ist die externe IP keine statische IP, sondern es soll DynDNS verwendet werden, dann die DynDNS-Adresse anschließend in das Feld “Externe Adresse” eintragen.
Die Codecs durch verschieben mit der Maus in die gleiche Reihenfolge bringen und mit dem Häkchen aktivieren.
Anschließend unten rechts auf “Absenden” und oben rechts auf “Apply Config” klicken.
Weiter geht’s im Reiter “SIP Settings (chan_pjsip)”
Dort zunächst den Parameter “Show Advanced Settings” auf “Ja” setzen, dann Unten rechts auf den Button “Submit” und oben rechts dann auf “Apply Config” klicken.
Im Abschnitt TLS/SSL/SRTP in die gekennzeichneten Felder sie angegebenen Werte eintragen:
Im Abschnitt “Transports” muss das TCP-Protokoll aktiviert werden. Anschließend wieder auf “Submit” und “Apply Config” klicken.
Anschließend wieder auf den 2. Reiter “SIP-Settings (chan_pjsip) klicken, ganz nach unten fahren und den Port für TCP auf 5061 ändern.
Anschließend wieder auf “Submit” und “Apply Config” klicken. Die im nachfolgenden Bild angezeigte Nachricht einfach mit “OK” bestätigen.
Als Nächstes im Hauptmenü den Punkt “Connectivity” und darin den Unterpunkt “Hauptleitungen” aufrufen.
Im nächsten Bildschirm dann auf den Button “Amtsleitungen” klicken und die erste Option “SIP (cjan_pjsip)-Amtsleitung hinzufügen” auswählen.
Die folgenden Felder wie folgt ausfüllen:
- Trunk Name: Frei wählbar
- Outbound CallerID: Die Rufnummer, die standardmäßig bei Ihrem Gesprächspartner angezeigt werden soll in spitzen Klammern.
Beispiel: Die Rufnummer Ihrer Zentrale ist 0123-45678-0. Dann tragen Sie in dieses Feld folgendes ein: <0123456780>. - Maximum Channels: Das ist die Anzahl Ihrer Sprachkanäle die Ihnen Ihr Provider zur Verfügung stellt. Bei einem Standardanschluss sind das 2 Kanäle. Wer mehr Kanäle gebucht hat trägt die entsprechende Anzahl dort ein.
Anschließend auf den Reiter “pjsip Einstellungen” klicken und im Reiter “General” die gekennzeichneten Felder wie folgt ausfüllen:
Username: Ihr Telefonie-Benutzername (siehe Telekom-Zugangsdaten)
Passwort: ihr Telefonie-Passwort (siehe Telekom-Zugangsdaten)
SIP Server: sip-trunk.telekom.de
SIP Server Port: 5061
Transport: 0.0.0.0-tcp
Dann auf den Reiter “Erweitert” klicken und die markierten Felder wie im Bild gezeigt ausfüllen:
Beschreibung der im Bild verdeckten Felder:
Contact User: Ihre Stammnummer mit Vorwahl, führender Null und der Null am Ende (z. B. 04578123450 für 0 4578 12345-0)
Client URI: sip:+494578123450@sip-trunk.telekom.de
Dann nach unten scrollen bis zum Feld “Match (Permit)”
In den gekennzeichneten Feldern dann die entsprechenden Einträge vornehmen.
Anschließend PuTTY öffnen und “fwconsole restart” eingeben um FreePBX neu zu starten und mit ENTER bestätigen.
Jetzt das Command Line Interface des Asterisk öffnen durch Eingabe des Befehls “asterisk -rvvvv”.
Dann, im CLI den Befehl “pjsip show registrations” eingeben und mit ENTER bestätigen.
Dann sollten Sie diese Anzeige erhalten:
Wichtig dabei ist, dass als Status “Registered” ausgewiesen ist. Dieser Status bestätigt, dass die FreePBX/Asterisk am SIP-Trunk der Telekom erfolgreich registriert ist.
Ein kleines Problem müssen wir aber noch lösen:
Leider kommen die angewählten Nummern der externen Anrufer im “Standard-to-Header” nicht einheitlich formatiert an. Dieser Header wird von allen Telefonanlagen standardmäßig ausgelesen. Mögliche Formate ein und derselben Nummer sind z. B.
- +49 5555 12345
- 0049 5555 12345
- 0 5555 12345
- oder wenn der Anruf aus dem Ortsnetz kommt auch nur 12345
Das ist immer die selbe Nummer nur in einem anderen Format.
Anhand der Nummer wird aber in den Inbound-Routen (siehe Teil 3) entschieden, wohin die FreePBX diesen Anruf weiterleitet. Das heißt, unter diesen Bedingungen müsste man wegen der vielen verschiedenen Formate für ein und die selbe Nummer mehrere Inbound-Routen anlegen. Genauer gesagt für jedes Format eine Inbound-Route.
Im P-Called-Party-Identity-Header übergibt die Telekom die Nummer aber auch noch mal sauber formatiert im Format +4955512345.
Um die Nummer aus diesem Header auszulesen müssen wir jetzt noch ein kleines Script installieren.
Das muss unter dem folgenden Link das Script”from-pstn-pciheader” heruntergeladen und in die Datei “/etc/asterisk/extensions_custom.conf” kopiert werden.
Dazu den WinSCP öffnen, in das Verzeichnis gehen, die Datei “extensions_custom.conf” öffnen, das Script hinein kopieren und speichern.
Anschließend muss dieses Script bzw. dieser Context noch in die Konfiguration des Trunks eingetragen werden. Dazu wie folgt vorgehen:
In der FreePBX-Verwaltungsoberfläche unter dem Menüpunkt “Connectivity” auf “Hauptleitungen” klicken und dann die Konfiguration des Trunks öffnen.
Dort auf den Reiter “pjsip Einstellungen” und auf den Unterreiter “General” klicken und im vorletzten Feld mit der Bezeichnung “Context” den Namen des Scriptes “from-pstn-pciheader” eintragen.
Anschließend unten rechts auf “Absenden” und oben rechts auf “Apply Config” klicken.
Das war’s. Weiter gehts mit Teil 3-Konfiguration der Nebenstellen.
Hallo,
über die Daten:
Username: Ihr Telefonie-Nummer 0611231234
Passwort: * (nur sternchen als Platzhalter)
SIP Server: tel.t-online.de
SIP Server Port: 5060
Transport UDP
kann ich unter:
pjsip show registrations
auch erfolgreich registrieren, was ist daran falsch?
Hallo,
für’s Erste sehe ich erst mal 2 Fehler.
1. Da Sie tel.t-online.de als SIP Server verwenden sind Sie im falschen Beitrag. In diesem Beitrag geht es um SIP-Trunk. Für Sie trifft Teil 2.2. zu.
2. In das Passwort gehören keine Sternchen. Beim IP-Anschluss bleibt das leer.
VG
Jörg Griebsch
Ich habe die FreePBX nach Ihrem Video versucht am Telekom SIP Trunk anzumelden ohne Erfolg. Die Registrierung wurde abgelehnt (rejected). Auch der Versuch mit einem zweiten FreePBX-Server funktionierte nicht trotz mehrmaligen durcharbeiten der einzelnen Schritte.
Wenn ich eine Verbindung mit dem vorhandenen Lancom Router zum Telekom SIP Trunk herstelle, registriert sich der Router sofort.
Woran kann es liegen? Oder ist es einstweilen auch nicht mehr möglich einen Telekom SIP Trunk an der FreePBX anzumelden wie es beim Company Flex Anschluss wohl der Fall ist?!
Hallo,
das wird wohl am Lancom Router liegen. Im Lancom sämtliche Telefonfunktionen deaktivieren und die Weiterleitung der Ports 5060 UDP und 10000-20000 UDP auf die FreePBX einrichten. Dann könnte es klappen. Mehr kann ich aus der Ferne leider nicht dazu sagen.
Grüße
Hallo Herr Griebsch,
auch meine FreePBX befindet sich hinter einem Lancom Router. Die Registrierung hat mit Ihrer Anleitung auf Anhieb geklappt. Der Ruf kam durch aber ich hatte keinen Ton. Mit der Weiterleitung der Portrange 10000 bis 20000 auf die FreePBX hat es dann geklappt.
Vielen Dank!
R. Halbach
Konnte das Problem gelöst werden?
Nachdem ich noch zusätzlich Port 5061 weitergeleitet und tls aktiviert habe, funktioniert es.
Hallo, vielen Dank für die tolle Anleitung,
da wir mit dem alten sip Treiber keine Rufweiterleitung auf Handy´s einrichten konnten mussten wir auf pjsip umstellen, nun klappt das Feature endlich!
Allerdings funktionierte der custom context mit “from-pstn-pciheader” nicht, da gab es immer Fehlermeldungen im log das die entsprechende Nebenstelle nicht in diesem Context wäre…
Abhilfe schaffte der bereits vorhandene Context “from-pstn-toheader”.
Hallo,
Der Context from-pstn-toheader liefert bei eingehenden Anrufen kein einheitliches Nummernformat. Dadurch wird es immer wieder Anrufer geben, welche Sie nicht erreichen werden. Sie benötigen zwingend den Context from-pstn-pciheader oder Sie müssen für jede Nummer und jedes Nummernformat je eine Inbound-Route anlegen. Wenn der Context from-pstn-pciheader nicht funktioniert, liegt das meist an einer falschen Zeichenkonvertierung. Das passiert oft, wenn die Datei unter Windows im Editor geöffnet wurde.
Grüsse
Hallo Andreas,
Hast du eine korrekte Konfiguration welche du mit uns teilen kannst?
Nachdem ich bisher auf Chan_SIP-Trunk jahrelang gelaufen bin, hat das hier bei mir auf Anhieb geklappt. Router ist ein Fritzbox, in der gar nix weitergeleitet ist. Es ist übrigens für die Registrierung des Trunks ziemlich egal, was bei den Einstellungen / PJSIP-settings für Port-Nummern eingestellt sind. Vorsichtige Menschen, die ihre freePBX frei (ohne Router mir Firewall vorne dran) in einer Cloud im Internet stehen haben, nehmen da statt 5060 oder 5061 lieber irgendwelche hohen Ports (z.B: 63800 und 63801). Das ist erst dann wichtig, wenn sich Telefonapparate mit der Anlage verbinden möchten. Die müssen sich dann auf diesen Ports verbinden. Hintergrund: Alle Hacker dieser Welt suchen nach offenen Ports 5060, weil sie da ein SIP dahinter vermuten und auf fremder Leuts’ Kosten telefonieren wollen. Sobald so eine Anlage online ist, laufen sofort Angriffsversuche auf diese Ports los. Bei hohen Ports ist das eher mal Zufall, wenn sich jemand unberechtigt anmelden mag.
Und die Codecs können auch im Trunk eingeschränkt werden. Das muss nicht unbedingt in den SIP-settings passieren.
Wen’s interessiert, für den habe ich übrigens noch ein Pfund Dial-Pattern. Damit werden in der Outbound Route Gespräche auf Europäische Länder eingeschränkt. Für den unwahrscheinlichen Fall eines Hacks kann der Hacker damit zumindest nicht mehr stundenlang Ziele in der Karibik anrufen.
Wenn man eine Anlage (FreePBX) für einen Provider (Deutsche Telekom SIP-Trunk) konfiguriert,
sollte man sich auch dessen Spezifikationen durchlesen. 😉
Siehe 1TR118, Seite 22, Abschnitt 2.13 Callee Identity in Incoming Calls (to the SIP-PBX).
Bei eingehenden Anrufern wird die vom Anrufer gewählte Rufnummer NICHT im to-header übermittelt,
sondern im R-URI User part bzw. in der P-Called-Party-ID.
Der to-header sollte nicht ausgewertet werden, denn:
Leitet eine Mobilfunknummer einen ankommenden Anruf zum SIP-Trunk/FreePBX um,
so steht im to-header die Mobilrufnummer, da diese ja ursprünglich gewählt wurde.
Das Nutzen des to-headers funktioniert somit nur eingeschränkt und ist KEINE korrekte Konfiguration
für den DeutschlandLAN SIP-Trunk der Deutschen Telekom.
Hallo Andreas,
Hast du eine korrekte Konfiguration welche du mit uns teilen kannst?
Leider (noch) nicht, ich kämpfe noch mit den Grundeinstellungen und zahlreichen
Macken der FreePBX.
Ich finde die FreePBX alles andere als übersichtlich/anwenderfreundlich,
aber das gehört hier nicht hin. 😉
Sollte ich eine korrekte Konfig hinbekommen, werde ich das hier berichten. 🙂
In einem anderen Beitrag hier las ich was von Portweiterleitung (5060, 5061).
Den Sinn kann ich nicht nachvollziehen, normalerweise baut doch der UA (User Agent=TK-Anlage)
eine TCP-Verbindung von innen nach aussen durch den Router auf.
Diese TCP-Verbindung sollte “unendlich lange” bestehen bleiben. Ggf. den TCP-Keepalive-Timer
im Router hochsetzen oder von der Anlage regelmäßig OPTIONS zum SIP-Proxy senden lassen.
Über diese TCP-Verbindung kommen die externen Anrufe rein und der Router sollte diese
dann auch annehmen und zur Anlage weiterleiten, da er ja weiß, dass die Anlage diese TCP-
Verbindung eröffnet hat.
Leitet man dagegen pauschal Port 5060 zur Anlage, so kann jeder Angreifer darüber zur Anlage
gelangen.
Manche Provider kommunizieren wohl auch über andere Proxys mit der Anlage, an denen sie
sich nicht zuvor registriert hat. Der SIP-Trunk der Deutschen Telekom ist da aber ganz “pingelig”,
die SIP-Pakete kommen grundsätzlich immer von dem Server, an dem sich die Anlage zuvor registrierte.
Eine Weiterleitung ist daher nicht nötig.
Ebenso wird kein STUN benötigt, da die Telekom-Proxys erkennen, wenn im SIP-Header eine
interne IP-Adresse übermittelt wird und dann die Adresse aus dem TCP-header nehmen.
Gleiches beim RTP: Der Telekom-Proxy wartet auf drei RTP-Pakete von der Anlage,
um Port und IP-Adresse des RTP-Streams zu erkennen und dorthin seine Pakete zu senden.
Noch ein Hinweis zur SIcherheit:
Beim Telekom SIP-Trunk wird web digest (MD5) zur Authentifizierung verwendet.
Zu dessen Sicherheit einfach mal google bemühen.
Ich empfehle daher immer, zusätzlich TLS zu nutzen.
Hallo,
Ich möchte mal versuchen durch ein paar Überlegungen welche ich hier teilen möchte, vielleicht einen kleinen Beitrag zur Lösung des Problems zu leisten.
1. Die Konfiguration in meinem Video funktioniert. Ich habe vor etwa 2 Monaten den letzten DeutschlandLAN-SIP-Trunk mit diesen Einstellungen konfiguriert. Wenn das nicht so wäre, dann hätten sich meine anderen Kunden längst gemeldet.
2. Voraussetzung, damit das auch genau so wie im Video funktioniert, ist natürlich, dass auch die Netzwerkumgebung exakt der Umgebung in meinen Video entspricht. Also FreePBX —> FritzBox —> Internet —Provider. Gelegentlich haben Zuschauer meiner Videos zwischen FreePBX und Router aber noch eine Firewall und wundern sich sich, dass die FreePBX irgndwie nicht funktioniert. Weil die Firewall bisher aber auch Ihren Dienst im Netzwerk getan hat, wird oft die falsche Schlussfolgerung daraus gezogen, dass es an der Firewall nicht liegen kann und der Fehler wird in der FreePBX oder beim Provider, also an der falschen Stelle gesucht und deshalb auch nicht gefunden. Meine Erfahrung ist: Wenn es in meinen fast 200 Installationen irgend ein Problem gab und es war eine Firewall im Spiel, lag es in fast allen Fällen an der Firewall-Konfiguration. Deshalb empfehle ich bei vorhandener Firewall als erste Maßnahme beim Troubleshooting die Firewall testweise zu umgehen und wenn es dann funktioniert die Firewall wieder reinzunehmen.
3. Die Telekom verändert gerade Ihre Serverlandschaft. Dieser Prozess findet schrittweise regional statt und wird wohl noch bis Ende 2023 andauern. Dabei sollte es nicht zu Störungen kommen. Ausschließen kann man es aber nicht.Tatsächlich sind mir solche Störungen in Einzelfällen auch schon berichtet worden. In diesem Fall könnte man testweise mal folgende Einstellungen varieren:
3.1. In der Trunk-Konfiguration mal den den SIP Server Port rauslöschen. Einfach das Feld leer lassen.
3.2. In der FreePBX-Verwaltungsoberfläche, im Menü “Einstellungen” unter dem Punkt “SIP-Settings” auf dem Reiter “Allgemeine Einstellungen” im Abschnitt “NAT-Settings” mal die externe IP-Adresse rauslöschen und das lokale Netzwerk eintragen. Am besten auf den Button “Netzwerkeinstellungen erkennen” klicken und anschließend die externe Adresse wieder rauslöschen.
Die Punkte 3.1. und 3.2. mal einzeln und in Kombination testen.
Konkreter kann ich hier leider nicht werden. Ohne die technische Umgebung genauer zu kennen wäre alles Weitere rein spekulativ. Sollten diese Hinweise nicht helfen, eine Lösung aber unbedingt erforderlich sein, biete ich gern meine Dienstleistungen an.
Ich hoffe ich konnte helfen.
Grüße
Hallo,
seit einer Weile funktioniert das Telefonieren mit der FreePBX nicht mehr richtig. Ich kann den Anrufer deutlich verstehen. Der Anrufer versteht mich aber nur schlecht (leise, abgehackt, …) oder gar nicht. Woran kann dies liegen? Hat jemand eine Lösung dafür?
Freundliche Grüße
Nach meinen bisherigen Verdachts-Ideen mit (seltenen) ähnlichen Vorkommnissen ist da zuviel Netwerk-Traffic im LAN/WlAN. Nachdem die FreePBX zwar eine eigene Firewall hat, aber keinen eigenen Session-Boarder-Controller vorne dran, hatte ich vor einiger Zeit die Empfehlung bekommen Telefonie und "normalen" Netzwerk-Traffic nicht im selben Netz laufen zu lassen. Aber wer hat schon 2 gleichzeitige DSL-Anschlüsse. Ob einzelne Geräte im Router oder POE-Switch priorisierbar sind, hängt u.A. von der eigenen Infrastruktur ab. Und ob's dann auch wirklich priorisiert wird? Ich würde auf jeden Fall mal die PBX neu booten bzw fwconsole restart (nicht nur reload) und die PBX direkt an den Router anstecken, und mal in der GUI die Prozessor-und Netzwerk Auslastung anschauen auf Zeitraum 1 Tag / oder länger.
Im Übrigen hast du doch einen LANCOM. Ganz ehrlich, ich würde den Lancom die Verbindung zur Telekom aufbauen lassen (der hat einen Session-Boarder-Controller bzw. Telefonie-Gateway eingebaut – und ein paar Trunks zwischen LANCOM und FreePBX basteln. Dann auch keine Ports aufmachen! Oder forwarden. Auf TLS innerhalb des eigenen private LAN kannst du gern verzichten.
Mich stört "Gegenüber hört mich leise".
Die Lautstärke ist nicht abhängig von der verfügbaren Bandbreite, das scheint mir eher ein Problem der FreePBX zu sein.
Aber per Wireshark-Trace sollte sich das doch schnell herausfinden lassen. 😉
Für das Bandbreitenproblem gibt es QoS (Quality of Service).
Sofern die FreePBX die Pakete entsprechend markiert und der LANCOM korrekt konfiguriert ist,
sollte das also ebenfalls kein Problem sein – sofern der Acces/DSL fehlerfrei ist. Es wäre ja möglich, dass der Upstream massiv gestört ist. Das sollte der Provider aber zweifelsfrei feststellen können.
Aber woher weiß guenni, das Stefan einen LANCOM hat? Das steht doch nicht in seiner Anfrage?
Hat er mal weiter oben in den Kommentaren geschrieben.
Guten Morgen,
ich hatte auch immer wieder Probleme mit Sporadische Registrierungsfehler oder fehlende Ton Übertragung egal ob ein oder ausgehend, geholfen hatte in der Vergangenheit ein Neustart der Freepbx, nach etlicher suche über Google gab es viele Einstellungsmöglichkeiten wie "QOS" und "Bandbreite" etc. aber letztendlich war für mich die Beste Lösung meinen Lancom Router gegen eine Simple FritzBox 7560 auszutauschen, dort habe ich die Hauptleitungen Konfiguriert und seitdem läuft es einfach Zuverlässig.
Sehr seltsam – bei mir lief Telekom SIP Trunk mit FreePBX über PJSIP jetzt seit Jahren relativ gut, und gestern (6.6.2023) hatte ich das erste mal Probleme.
Das meiste funktioniert, aber bei Anrufen von intern auf Telekom-Mobilfunk habe ich One-Way-Audio. Reproduzierbar.
Hier hat seit Ende 2022 niemand geschrieben, und auf einmal am 6.6. gleich 4 Posts?
Liegt es vielleicht daran, dass doch die Telekom gebastelt hat?
Hallo,
wie Herr Griebsch oben schon erwähnt, ich denke das hängt mit der Telekom zusammen, die sind noch beim umstellen wohl bis Ende 2023.
Unseren Lancom Router habe ich vor ca. 2 – 3 Monaten gegen die FritzBox getauscht, weil gar nichts mehr ging, ein ähnliches verhalten tauchte bei einem Kunden von mir auf wo am nächsten Tag ohne irgendeine Veränderung unsererseits kein Telefonieren mehr möglich war, erst als ich die Hauptleitung in die FritzBox eingetragen hatte, läuft es jetzt seit Monaten Stabil.
Auch die Tipps (oben) von Herrn Griebsch bezüglich das Entfernen des Ports und der öffentlichen Adresse (3.1 / 3.2) waren sehr Hilfreich aber leider keine Dauerlösung, wirklich geholfen hatte letztendlich nur die FritzBox mit den Hauptleitungen.
Also eine Fritz!Box ist bei uns vorhanden, sogar 2 (Kabel-Internet und Vectoring). Daher wollen wir natürlich den SIP-Trunk _nicht_ auf einer Fritz!Box laufen lassen sondern aus Redundanzgründen umschalten können. Außerdem glaube ich nicht, dass eine Fritz!Box 100 Endgeräte verwalten kann (ohne das jetzt überprüft zu haben).
Oder was ist gemeint mit "wirklich geholfen hatte letztendlich nur die FritzBox mit den Hauptleitungen."
Mir ist neulich mal bei einer FritzBox aufgefallen, dass die mit tcp port 5061 TLS connected ist. Kann aber sein, dass das schon lange so ist, und ich nur nicht darauf geachtet hatte. Ansonsten sind mir in letzter Zeit nicht ganz seltene volle Verbindungsabbrüche bei Telekom-Gegsprächen aufgefallen, wo auch ein LANCOM beteiligt ist (allerdings hinten dran eine old.styled ISDN/IP Siemens Hybrid TK) mit ein paar wenigen IP-Telefonen dran, die über VPN dort dran verbunden sind. Echte ISDN/ISDN-Gespräche sind aber ohne Abbrüche.
Hallo,
in der FritzBox habe ich nur die Hauptleitungen eingetragen.
BG
Jason.
Hallo,
ich verstehe nicht, was gemeint ist. Die Trunk-Einstellungen, die in FreePBX gemacht wurden, bleiben ganz normal bestehen und zusätzlich richtet man den SIP-Trunk nochmal in der Fritz!Box ein? Gibt es dafür eine Anleitung, oder eine Skizze wo das erklärt wird? Was genau macht in dem Fall dann die Fritz!Box und was FreePBX? Aktuell ist unsere Fritz!Box ein einfacher Router, der von dem ganzen VoIP-Kram eigentlich nichts mitbekommt (außer IP-Pakete weiterzuleiten).
Außerdem ist mir auch aufgefallen, dass mittlerweile die Sprachpakete zwischen Fritz!Box und FreePBX verschlüsselt zu sein scheinen. Früher konnte man da mit Wireshark gut debuggen, jetzt höre ich nur noch rauschen. Evtl. liegt es daran? Ich wüsste nicht, wann ich das mal aktiviert habe.
Hallo die Hauptleitung sind in der FritzBox, weiter wird für jede Leitung ein LAN Teilnehmer eingerichtet, Herr Griebsch hat da eine Tolle Anleitung irgendwo 😉
Zu One-Way-Audio (einseitige Verständigung) zu T-Mobile:
Im SIP-Trace seht ihr (hoffentlich), dass ihr zweimal SIP 183 erhaltet. Die sind unterschiedlich!
Im SDP sind unterschiedliche RTP-Ports und IP-Adressen.
Gab´s vor einigen Jahren schon mal bei T-Mobile (Multidialog, damals per UPDATE realisiert),
damit kamen diverse Anlagen nicht klar.
Die FreePBX sendet vermutlich (!! Ich hab´s nicht getraced) ihr RTP zur IP/Port des ersten SIP 183,
daher kommt am Handy nichts an. Ich meine, in den 183er Meldungen sind auch unterschiedliche to-tags drin.
Wäre somit ein Fehler der FreePBX.
Also ja, ich sehe 2x SIP 183 (Telefonnummern und meine IP habe ich verändert):
—————————————-
SIP/2.0 183 Session Progress
Via: SIP/2.0/TLS 80.123.123.123:5061;rport=43673;branch=z9hG4bKPj8a4fc5d7-57d4-4c44-ad8d-3b83907f857e;alias
Record-Route:
To: ;tag=af818f68
From: ;tag=04563e0d-4ba5-4655-9b39-e5f125a8b2b3
Call-ID: f7633ddb-01c1-4fb0-93f7-a4248eda3bb3
Contact:
CSeq: 9592 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE
Require: 100rel
Server: Google – Pixel6 – TQ2A.230505.002
RSeq: 1
History-Info: ;index=1, ;index=1.1
Reason: TSSI;cause=0
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 332
v=0
o=- 30118188124255 30118188124255 IN IP4 217.0.26.246
s=on transit
c=IN IP4 217.0.132.209
t=0 0
m=audio 22956 RTP/SAVP 9 101
a=sendrecv
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:40
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:xFomO4JAfJBWFRIwUOI5V/mHL13INO/DS9EKmahG
———————
SIP/2.0 183 Session Progress
Via: SIP/2.0/TLS 80.123.123.123:5061;rport=43673;branch=z9hG4bKPj8a4fc5d7-57d4-4c44-ad8d-3b83907f857e;alias
Record-Route:
To: ;tag=8e08c9c8
From: ;tag=04563e0d-4ba5-4655-9b39-e5f125a8b2b3
Call-ID: f7633ddb-01c1-4fb0-93f7-a4248eda3bb3
Contact:
Supported: 100rel,precondition,timer
Session-Expires: 1800;refresher=uas
CSeq: 9592 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REGISTER, UPDATE
Require: 100rel,timer
Server: DC-SIP/2.0
RSeq: 1
History-Info: ;index=1, ;index=1.1;mp=1
Reason: TSSI;cause=1830010
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 360
v=0
o=- 78440207 78440207 IN IP4 217.0.26.246
s=on transit
c=IN IP4 217.0.133.179
b=AS:80
t=0 0
m=audio 24444 RTP/SAVP 9 101
b=AS:80
b=RR:0
b=RS:0
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32,36
a=maxptime:40
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:rQeaU6xLJbmAQtJDSzNXnP3taftpKFp2sm48gGh1
———————————–
Es sieht aber so aus, als wenn FreePBX das berücksichtigen würde und dann Pakete an die richtige Adresse schickt:
No. AbsTime Time Source Destination SPort DPort Protocol Length Info
896 13:18:00,121242 9.196980 sip.vectoring.geheim.de 217.0.132.209 30230 22956 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24388, Time=2980844512
897 13:18:00,141149 9.216887 sip.vectoring.geheim.de 217.0.132.209 30230 22956 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24389, Time=2980844672
898 13:18:00,161142 9.236880 sip.vectoring.geheim.de 217.0.132.209 30230 22956 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24390, Time=2980844832
899 13:18:00,181154 9.256892 sip.vectoring.geheim.de 217.0.132.209 30230 22956 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24391, Time=2980844992
900 13:18:00,201186 9.276924 sip.vectoring.geheim.de 217.0.132.209 30230 22956 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24392, Time=2980845152
901 13:18:00,221115 9.296853 sip.vectoring.geheim.de 217.0.132.209 30230 22956 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24393, Time=2980845312
902 13:18:00,241152 9.316890 sip.vectoring.geheim.de 217.0.132.209 30230 22956 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24394, Time=2980845472
906 13:18:00,261138 9.336876 sip.vectoring.geheim.de 217.0.132.209 30230 22956 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24395, Time=2980845632
908 13:18:00,281109 9.356847 sip.vectoring.geheim.de 217.0.132.209 30230 22956 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24396, Time=2980845792
912 13:18:00,296602 9.372340 217.0.133.179 sip.vectoring.geheim.de 24444 30230 RTP 224 PT=ITU-T G.722, SSRC=0x741FC049, Seq=3269, Time=2072349192
913 13:18:00,301145 9.376883 sip.vectoring.geheim.de 217.0.133.179 30230 24444 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24397, Time=2980845952
915 13:18:00,315397 9.391135 217.0.133.179 sip.vectoring.geheim.de 24444 30230 RTP 224 PT=ITU-T G.722, SSRC=0x741FC049, Seq=3270, Time=2072349352
916 13:18:00,321111 9.396849 sip.vectoring.geheim.de 217.0.133.179 30230 24444 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24398, Time=2980846112
917 13:18:00,335621 9.411359 217.0.133.179 sip.vectoring.geheim.de 24444 30230 RTP 224 PT=ITU-T G.722, SSRC=0x741FC049, Seq=3271, Time=2072349512
918 13:18:00,341168 9.416906 sip.vectoring.geheim.de 217.0.133.179 30230 24444 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24399, Time=2980846272
920 13:18:00,355406 9.431144 217.0.133.179 sip.vectoring.geheim.de 24444 30230 RTP 224 PT=ITU-T G.722, SSRC=0x741FC049, Seq=3272, Time=2072349672
921 13:18:00,361099 9.436837 sip.vectoring.geheim.de 217.0.133.179 30230 24444 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24400, Time=2980846432
922 13:18:00,375404 9.451142 217.0.133.179 sip.vectoring.geheim.de 24444 30230 RTP 224 PT=ITU-T G.722, SSRC=0x741FC049, Seq=3273, Time=2072349832
923 13:18:00,381102 9.456840 sip.vectoring.geheim.de 217.0.133.179 30230 24444 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24401, Time=2980846592
924 13:18:00,395394 9.471132 217.0.133.179 sip.vectoring.geheim.de 24444 30230 RTP 224 PT=ITU-T G.722, SSRC=0x741FC049, Seq=3274, Time=2072349992
925 13:18:00,401087 9.476825 sip.vectoring.geheim.de 217.0.133.179 30230 24444 RTP 224 PT=ITU-T G.722, SSRC=0x38D0D867, Seq=24402, Time=2980846752
926 13:18:00,415395 9.491133 217.0.133.179 sip.vectoring.geheim.de 24444 30230 RTP 224 PT=ITU-T G.722, SSRC=0x741FC049, Seq=3275, Time=2072350152
Stimmt, das sieht korrekt aus. Dann muss ich passen. Wird spannend, berichte gerne, was die Ursache war!
Hallo Andreas,
Du hast vollkommen Recht mit Deiner Analyse. Ich hatte gestern noch mal Kontakt mit der Telekom und sie hat es bestätigt. Es wurde eine technische Änderung beim telefonieren ins Telekom Mobilfunknetz eingeführt. Und zwar handelt es sich um die schon von Dir erwähnten multiplen SDP-Dialoge. Diese sind die Ursache für die 2 x 183 welche empfangen werden. Der Asterisk, zumindest Asterisk 16.xx. kann im Standard damit nicht richtig umgehen und das führt zu den beobachteten Erscheinungen.
Ich habe 2 Lösungsansätze für Euch und bitte euch diese zu testen. Sollte einer oder beide funktionieren werde ich das für alle anderen veröffentlichen.
1. Lösungsansatz (Asterisk 16.xx)
in /etc/astersik/pjsip.registration_custom_post.conf folgenden Eintrag hinzufügen:
[NAME_DES_TELEKOM_TRUNKS](+)
100rel=no
"NAME_DES_TELEKOM_TRUNKS" müsst Ihr natürlich durch den von Euch in der Trunk-Konfiguration festgelegten Namen des Trunks ersetzen (Nur zur Sicherheit um Missverständnisse zu vermeiden).
Anschließend an der Konsole "fwconsole reload" eingeben und mit ENTER bestätigen
Und dann noch mal testen.
2. Lösungsansatz
Umswitchen auf Asterisk 19. Das geht ganz einfach mit dem Asterisk Version Switch
An der Konsole "asterisk-version-switch" eingeben.
Dann bekommt Ihr alle auf dem System verfügbaren Asterisk-Versionen angezeigt. Da könnt Ihr dann die entsprechende Ziffer auswählen und mit ENTER bestätigen.
Das Umswitchen dauert nur wenige Sekunden. Ihr könnt die Version auf die gleiche Weise auch jederzeit wieder zurückstellen.
Da ich über keinen DeutschlandLAN SIP-Trunk mehr verfüge, bitte ich Euch das mal zu testen und mich zu informieren, ob es geklappt hat.
Sollte sich das Problem nicht lösen lassen, hat ein Fachmann von der Telekom mir seine Mitarbeit bei der Problemlösung angeboten. Allerdings wird das frühestens in 3 Wochen sein, da er vorher nicht verfügbar ist.
Grüße
ich hab mal die Lösung 1 mit dem (+) eingetragen. Was bedeutet das + in der Klammer? Und warte einfach mal ab, ob irgend etwas unschönes passiert.
Das (+) bedeutet, dass diese Parameter der bestehenden Konfiguration hinzugefügt werden.
Hab jetzt noch auf meine Test-Cloud-FreePBX den Version-Switch von 16.3 auf 19.8 laufen lassen.
Es kommen ein paar Fehlermeldungen wegen "locale" default nicht gesetzt. Scheint aber nicht zu stören. Die 19er Version ist dort ebenso wie die 16er als "end-of-life" gekennzeichnet. Aktuelle LTS-Version scheint wohl 20.x zu sein. Hab ich jetzt aber nicht genommen. So mutig war ich nicht.
Zu Lösungsvorschlag 1:
Wenn die FreePBX kein 100rel mehr kann, also kein PRACK senden kann,
sollte die Gegenseite kein 183 mehr mit SDP senden, das SDP wäre dann im finalen 200 OK ("Abheben"),
wenn ich das korrekt verstanden habe. Problem dürfte also nicht mehr auftreten. 🙂
Aber würde das dann nicht automatisch bedeuten, dass die FreePBX dann auch kein EarlyMedia von der
Gegenseite empfangen kann, da sie das SDP ja nicht "PRACKen kann"??
Bzgl. Freiton per EarlyMedia ist das zwar kein Problem (eher ein Segen, wenn die Zielnummer sowas
wie "musikalischen Freiton" mit einem Wolfgang Petry-Lied nutzt), sofern die Anlage korrekt arbeitet,
aber was, wenn das Ziel eine Wartemusik/-Ansage per EarlyMedia übertragen will?
Wäre es denkbar, dass die Verbindung dann nicht zustande kommt, weil das Ziel "require: 100rel"
voraussetzt?
Kann hier jemand was dazu sagen?
*Grübel*
Ich frage mich, ob und wie die conf-Dateien verarbeitet werden. Vielleicht bin ich in ein paar Wochen, nachdem ich meine 2 neuen Asterisk-Bücher gelesen habe, schlauer.
Möglicherweise hat der 100rel-Eintrag in der ….post.conf eine besondere Bedeutung.
Es gäbe ja ansonsten noch eine Menge andere pjsip.*.conf-Dateien.
Im Übrigen ist – zumindest bei mir – in der pjsip.conf der include für pjsip.registration_custom_post.conf auskommentiert.
Und auch in der pjsip.registration.conf Würde also gar nicht durchlaufen bei einem reload.
Du bist mein Held!
Ich habe keine Ahnung, was das 100rel bedeutet. ABER: Der Fehler war bis eben stabil da, dann habe ich Deine Änderung gemacht, und das Problem ist verschwunden.
Vielen Dank!
Vielen Dank für die Rückmeldung.
Grüße
Ich weiß was! 😉
Ist nicht ganz einfach, aber offensichtlich RFC-konform:
Die Anlage muss RTP nicht IMMER zum Server aus dem SDP des zweiten 183 senden!
Hier kommt nämlich Multidialog zum Einsatz, die beiden Dialoge kann man am to-tag unterscheiden!
Die beiden 183er haben also nicht nur unterschiedliche connection-Information im SDP (Ziel-IP- Adresse und Ziel-Port, zu der die Anlage RTP senden muss), sondern auch unterschiedliche to-tags!
Im 200 OK ("Abheben am Ziel") wird ebenfalls ein to-tag vom Provider gesendet.
DAS ist die korrekte Verbindung, zu der die Anlage RTP senden muss.
Die Daten (IP-Adresse & Port) erfährt sie aus dem SDP des 183, welches den gleichen t-tag hat!
Kannst Du das vielleicht auch nochmal für Normalsterbliche formulieren?
Ich habe mal Rücksprache mit der Telekom gehalten. Am DeutschlandLAN SIP-Trunk wurden keine technischen Veränderungen vorgenommen. Wichtig ist vor allem, dass im Outbound Proxy sip:reg.sip-trunk.telekom.de eingetragen ist, da sonst die Adressauflösung nicht funktioniert.
Sollten die Störungen trotzdem und ohne dass die Konfiguration der FreePBX oder des Routers oder einer anderen beteiligten lokalen Netzwerkkomponente geändert wurde auftreten, empfehle ich eine Störungsmeldung an die Telekom abzusetzen.
Der Hinweis von jgrieb mit dem OutboundProxy und der Adressauflösung bezieht sich vermutlich
auf eines der anderen Fehlerbilder (von guenni, Plows oder Stefan), weil das ja nichts mit dem
"One-Way-Audio" zu tun hat.
Bei "einseitiger Verständigung zu T-Mobile" empfehle ich, erstmal einen lokalen Trace durchzuführen,
um damit ein Anlagenproblem bzgl. Multidialog auszuschließen.
@guenni
Nimms mir nicht übel, aber dann müsste ich hier einen halben Roman tippen.
Wer SIP versteht, wird mit meiner Erklärung zurechtkommen.
No problem. Ist auch nicht mein eigentliches business.
Vielleicht hättest Du einen Tip auf Verdacht (nix genaues weiss ich nicht):
Meine 3 IP Telefone (neben den ISDN-Telefonen) hängen als Nebenstellen an einer OpenStage Hybrid-TK über FritzBox VPN-Tunnel. Die Hauptleitung kommt von einem LANCOM über ISDN an die OpenStage.
Den LANCOM hat die Telekom eingerichtet, da hab ich keinen User und kein PW. Die IP-Telefone haben oft Verbindungsabbrüche bzw. one- oder noway audio. Das kam die letzten Jahre nie vor, und tritt seit ein paar Monaten auf, ohne dass an der konfig jemals was geändert wurde, auf. Der Tunnel mit fixen IPs erscheint stabil.
Sollte ich die Telefone lieber direkt an den LANcom hängen? Oder lieber die Telekom herzauseln für ein update des LANCOM?
Ähhhhh….ist der Aufbau bei Dir so:
DSL——-> LANCOM——-S0——->OpenStage—–>Fritz!Box—–VPN—-> IP-Telefone
????
Falls ja: Was soll das? Ist ja sehr wild. 😉
Warum sind die IP-Telefone nicht direkt am LANCOM?
Oder die Fritz!Box ganz nach vorne packen und die Telefone dort anschliessen.
Spart Geld (LANCOM-Miete bzw. -Service), allerdings hast Du dann auch nur einen Privatkundenrouter
statt einem Businessrouter. Kommt halt drauf an, was man braucht bzw. damit machen will.
Jedenfalls würden beide Alternativen die Fehlersuche erheblich (!) vereinfachen!
Da sich der LANCOM anscheinend bei der Telekom registriert, ist er erstmal der "Hauptverdächtige". 😉
Leider weiß ich nicht, welche FW drauf ist und welches Modell Du hast.
Ggf. einfach mal nett bei der Telekom anrufen, die können die FW-Version sofort erkennen und ein Blick
auf der LANCOM-Seite zeigt dann, welche aktuell ist sowie sehr ausführliche ReleaseNotes.
Wenn die Fritz!Box per TLS (Port 5061) verbunden ist, dann ja anscheinend intern.
Kann man machen, muss man aber nicht, sofern man seinem eigenen Netz vertraut. 😉
Nachteil bei dem Konstrukt: Du kannst nicht mal eben tracen, weil ja der gesamte SIP-Verkehr
verschlüsselt ist.
Ja, Infrastruktur ist wohl etwas wild. Liegt aber an der räumlichen Trennung:
location1: DSL / SIP– LANCOM– ISDN–OpenScape — ISDN Telefone
location1 DSL — FritzBox —LAN2 — OpenScape –POE-Switch
location2: DSL– Fritzbox –IP-Telefon –im FritzBox-VPN mit POE-Switch zu location1
Damit bekommt die location2 eigene Nebenstellen-Nummern von der location1. Man kann auch intern über den VPN-Tunnel telefonieren und weiterleiten.
Ist aber alles "business"-Telekom und traffic ist möglicherweise ein eigenes Siemens-Protokoll über den Tunnel. Deshalb kann ich leider nicht die FritzBox der location2 als "IP-Telefon" an der location1 registrieren..
In den LANCOM sehe ich nicht rein. Deshalb FW fraglich. Allerdings macht die Telefonie an der loc1 selbst keine Probleme. Nur die loc2 ärgert mich.
Ich hab´s immer noch nicht ganz kapiert.
Wenn an der Fritz!Box ein Switch hängt, der mit location1 verbunden ist, dann läuft die
Telefonie von loaction2 doch gar nicht über den DSL von location 2, sondern komplett intern im LAN.
Der Provider (sowohl SIP als auch DSL) von beiden locations wäre dann ja "raus".
Und warum ist das IP-Telefon dann nicht direkt per LAN am LANCOM von location1 angeschlossen?
Wenn das Telefon an location2 kein SIP kann, dann halt das Telefon tauschen. 😉
Man könnte auf/in dem LANCOM tracen, woher die Abbrüche stammen, also welche Seite/Gerät diese
verursacht. Aber wie erwähnt würde ich zuerst die FW aktualisieren.
Achja, mir fällt nochwas ein:
Hast Du in der Fritz!Box "Paketbeschleunigung" aktiv? Der Mist macht gerne mal Probleme bei VPN
und ist nach jedem Stromausfall/Neustart automatisch wieder aktiv, auch wenn man ihn deaktiviert hat.
Kommt auf die Fritz!Box und Firmware an, ob Du diese Einstellung hast. Findet man über "Inhalt/ Fritz!BoxSupport/ "
Ggf. macht hier ein CompanyFlex/CloudPBX Sinn, dann würden sich die Endgeräte direkt beim
SIP-Provider registrieren – aber ich weiss nicht, ob die Fritz!Box inzwischen eine Freigabe für den
CompanyFlex hat.
Also location1 hat einen Durchwahlanschluss (Lancom), der geht per S0 auf die TK
location1 hat auch einen Mehrgeräte-Anschluss (FritzBox), der geht auch per S0 auf die TK
Location2 hat IP-Telefone und einen Mehrgeräte-Anschluss (FritzBox). Die Rufnummer wird extern auf eine Nebenstelle der location1 (Lancom-> S0 -> TK) umgeleitet. Ich verwende noch die alten Begriffe, obwohl das inzwischen ja alles SIP-Trunk whaterver heißt.
Die TK an location1 kann auch IP, und hängt zusätzlich im FritzBox-Lan.
VPN ist FritzBox FritzBox.
Wenn ich FritzBox Lancom VPN haben wollte, müsste ich auf die neue VPN-Technologie von AVM umstellen. (Habe aber ohnehin leider keinen Zugang zum Lancom)
Und ja, eine CloudPBX würde sicher Sinn machen. Da ist mir eine FreePBX sogar sympatischer als Company-Flex. Würde aber neue Telefone für location1 bedeuten, und einen passenden Hoster für die FreePBX hab ich auch noch nicht entdecken können. Sangoma ist zu teuer. IONOS funktioniert im Test ganz prima. Kann ich auch sehr gut gegen externe Angriffe bisher abschotten. Nur die Mehrgeräte-Nummer funktionieren halt nicht. Die sind nomadisch nur von Telekom-Anschlüssen aus registrierbar und eben gerade nicht von einem IONOS-Cloud-Server.
Durchwahl-Anschluss funktioniert da wie erwartet ohne Probleme.
Leider gibt es wohl keine Cloud-Server für 10 € /Monat bei der Telekom zu mieten, auf die FreePBX installiert werden könnte. Wer will sich schon selbst Konkurrenz machen.
Die Paketbeschleunigungen hau ich über mittag jetzt gleich mal auf beiden Seiten raus. Da könnte wohl ein reboot dran hängen. Hab sowieso 50 MBit extern. Da muss nix beschleunigt werden.
Hat das ansonsten irgendwelche negative Folgen?
Bildliche Erklärung:
Jemand registriert per Fritz!Box seine Rufnummer 12345 über seinen DSL, also von zuhause aus.
GLEICHZEITIG registriert er diese Rufnummer per Smartphone mittels VOIP-Client ("Telefonie-App").
Sowas geht nicht beim DeutschlandLAN SIP-Trunk, aber bei anderen SIP-Anbietern.
Ruft man die Nummer an, klingelt es sowohl am Smartphone als auch am Festnetz zuhause.
Der Anrufer erhält also ZWEI "Antworten", jeweils mit unterschiedlichen IP-Adressen & Ports.
Nämlich einmal das Festnetzziel, einmal das Mobilfunknetz.
An einem Anschluss wird nun abgehoben, mal ist es das Smartphone, mal die Fritz!Box.
Der Anrufer erhält also EINE "Abhebe-Bestätigung".
Woher weiss er, wer abgehoben hat, also wohin er Sprache senden muss?
Da kommen die to-tags der Zielseiten ins Spiel und mein vorher geschriebenes.
Ignoriert der Anrufer (dessen Anlage) das, so sendet er seine Sprache zum falschen Gegenüber,
wo niemand abgehoben hat und die Sprache entgegennimmt.
Bzw. die Anlage des Anrufers nimmt die empfangegen Sprachpakete nicht an, weil sie nicht von
der erwarteten IP-Adresse stammen (die zuletzt per 183 oder 100 gemeldet wurde).
Ich hoffe, das ist verständlicher.
Hallo Andreas,
müsste das Problem nicht eigentlich bei allen Telekom-Trunks auftreten? (also auch den alten Mehrgeräte Anschlüssen wie auch bei den Durchwahlanschlüssen)…wenn Gespräche mit Telekom-Mobil-Anschlüssen laufen.
Und könnte es zudem sein, das die Sprachpakete erst mal (zufällig) richtig laufen, und später abbrechen, wenn die "falsche" Gegenstelle nach xxx-Sekunden den re-register macht?
Ich würde natürlich lieber auf allen meinen FreePBXn den Asterisk Version-Change laufen lassen statt den 100rel-Eintrag machen, wenn das Problem damit behoben ist. Frage ist halt, ob damit noch x andere Änderungen notwendig werden.
Das ganz dürfte wohl insgesamt recht mühseelig nachzuverfolgen sein, weil halt leider oft auch Gespräche von Freepbx zu mobil gern mal aus ganz anderen Gründen nicht zustande kommen oder unterwegs abstürzen.
Die Deutsche Telekom betreibt unterschiedliche Plattformen/Server:
Der CompanyFlex und die Mehrgeräteanschlüsse sind auf der einen Plattform (IMS=IP Multimedia Subsystem),
der "alte" SIP-Trunk läuft aber auf der TAS (Telephony Application Server).
Daher "funktionieren" sie auch unterschiedlich, bzw. werden unterschiedlich konfiguriert.
Es ist also durchaus denkbar, dass das Multidialog-Problem nur bei den alten SIP-Trunks auftaucht.
Mit Sicherheit sagen kann ich das jedoch aktuell nicht.
Ein Re-REGISTER der Gegenstelle sollte keinerlei Auswirkungen haben, da die RTP-Verbindung ja
unverändert bleibt, also IP-Adresse und UDP-Port der Gegenseite.
Ein (korrektes) Re-REGISTER hat ja auch im "normalen" Telefonverkehr, also auch ohne Multidialog/T-Mobile keinerlei Auswirkungen.
Zum "mühseligen nachverfolgen": Ohne Trace/Paketmitschnitt ist alles nur Kaffeesatzlesen. 😉
Das ist ausschliesslich ein Problem des Asterisk. Der Asterisk hat Probleme mit dem multiplen SDP-Dialog. Einige wenige andere Anlagen wohl auch. Die Masse aber nicht. An welchen Telekom-Anschlüssen dieses Problem auftaucht ist daher für die Lösung dieses Problems unerheblich. Das umswitchen auf Version 19 geht auf jeden Fall ohne Probleme, wenn FreePBX 16 verwendet wird. Falls noch FreePBX 15 im Einsatz ist sollte vorher ein Upgrade auf FreePBX 16 erfolgen. Und bitte micht vergessen mir zu schreiben ob und welche meiner vorgeschlagenen Lösungen funktioniert.
Grüsse
Puh.
Der Wechsel von FreePBX 15 auf 16 ist ein nicht ganz so trivialer Ratschlag.
Hier ein paar Zeilen aus der Sangoma Newsgroup dazu:
So, to make your experience better, here is how I would run the upgrade from FreePBX 15 to 16
Login with your non-root user. Because you never allow root to log in over ssh right?
Update the system
sudo yum upgrade -y
Remove ioncube if you already have it installed (most people will not), not required if your version upgrade versions is 15.0.19 or later.
sudo yum remove ioncube-loader-56
Upgrade the current modules.
sudo fwconsole ma upgradeall
Fix permissions
sudo fwconsole chown
Reload
sudo fwconsole reload
Reboot
sudo reboot
Log back in and then switch to root.
sudo su –
Download the versionupgrade module
fwconsole ma downloadinstall versionupgrade
Fix permissions again
fwconsole chown
Reload
fwconsole reload
Run the version upgrade check and use fwconsole ma delete MODULENAME to remove any depreciated modules. If you do this, also make sure to fwconsole reload.
fwconsole versionupgrade –check
It should be clean, so upgrade. If you have issues, before you revert your snapshot, download the freepbx16_upgrade.log file from /root in order to look at what went wrong.
fwconsole versionupgrade –upgrade | tee -a freepbx16_upgrade.log
Fix any issues you may have. I had a broken restapi, likely left over from when this system was FreePBX 13.
fwconsole ma delete restapi
fwconsole reload
Once everything looks good, reboot and see if it all comes up again normally.
reboot
Was ich aber noch gefunden habe, um ggf. das Problem mit dem rel100 zu lösen:
Es gibt wohl eine Einstellung rtp_symetric=YES, dabei muss direct_media unbedingt auf NO sein.
Das wird auch call comedia genannt. Dabei verlässt sich der Trunk nicht auf die Adresse aus dem SDP-header, sondern verwendet die Adresse, von wo das erste RTP-Paket herkommt.
Vielleicht kann das noch jemand kommentieren?
Noch ein kleiner Hinweis in eigener Sache. Diese Seite wird immer mal wieder von Spam-Bots attackiert. Deshalb lasse ich Kommentare ab sofort nur für registrierte und angemeldete Benutzer zu. Also vor dem nächsten Kommentar bitte registrieren oder anmelden. Ich bitte um Euer Verständnis.
Grüße