[Problem] Telekom Magenta Zuhause - Rufumleitung kein Ton bzw. Ringback

[m3g4tr0n]

Moin,

seit geraumer Zeit habe ich die Einbindung meiner Telekom Rufnummern (Magenta Zuhause) in ein Asterisk geplant, welches ich nun mit FreePBX realisiert habe. Man kann behaupten etwas Overkill, allerdings hat mich das System interessiert und ich möchte etwas dazulernen.
Die Trunks sind soweit eingerichtet und funktionieren, ein- und ausgehende Gespräche werden zugestellt.

Nun zum Problem: Rufumleitung
Umgeleitet werden soll auf eine externe Rufnummer:

• Inbound Route auf Misc Destination:
  Anruf wird weitergeleitet, Ringback ist hörbar, kein Ton in beide Richtungen.
• Inbound Route auf Nebenstelle mit FollowMe:
  Anruf wird weitergeleitet, Ringback ist hörbar, kein Ton in beide Richtungen. Sobald der Anrufer das Gespräch "hält" und wieder freigibt hören sich beide Gesprächspartner.

Abhilfe dazu soll laut einiger Beiträge die Aktivierung des "Inband Progress" in den Trunks sein. Also aktiviert und:

• Inbound Route auf Misc Destination:
  Anruf wird weitergeleitet, kein Ringback beim Anrufer, Ton in beide Richtungen.
• Inbound Route auf Nebenstelle mit FollowMe:
  Anruf wird weitergeleitet, kein Ringback beim Anrufer, Ton in beide Richtungen.

---

Ein Problem welches bereits mehrfach im Internet (u. a. hier im Forum) thematisiert wurde, ich bisher jedoch keine Lösung finden konnte. Ein Workaround ist das Force Answer an der Inbound Route, was für mich aber keine Alternative darstellt. Erst mal geht für den Anrufenden der Kostenticker los (zugegeben, in der heutigen Zeit vermutlich vernachlässigbar), zudem wird signalisiert "Hey, du bist verbunden" was zu missverständnissen führen kann.

Im Anhang habe ich mal zwei Screenshots von sngrep beigelegt, ohne Rufumleitung.
Der Unterschied ist, dass ohne Inband Progress das 180 ringing geschickt wird, welches dem anrufenden Endgerät signalisiert "tute mal".
Mit Inband Progress wird stattdessen 183 SDP geschickt, welches in Zusammenhang mit early media das Ringback erzeugt, welches über Wireshark auch hörbar ist.
Wird das ggf. durch die Telekom blockiert?
Falls nein, muss ein P-Early-Media-Header mitgeliefert werden?
Falls ja, wie bekomme ich eine ordentliche Rufumleitung hin das alles funktioniert?
Evtl. hat jemand eine funktionierende Konfiguration?

Da das Them NAT sicherlich aufkommt: Habe alle möglichen Konstellationen durchprobiert. Direkte Portfreigaben für SIP und RTP, automatische und manuelles ausgehendes NAT, diverse Einstellungen. Wie auch immer realisiert, die Symptome bleiben dieselben. Kann mir (fast) nicht vorstellen, dass es an dem Thema liegt. Der FreePBX liegt an dem Telekom-Anschluss (IPv4/IPv6) hinter einer pfsense.

Weitere Infos gerne nach Bedarf, wollte den Post hier nicht komplett mit ggf. unnötigen Config/Logs zuhauen.

Dank euch schon mal im Voraus!

Gruß

 

[sunnyman]

Bei der Kombination Asterisk+Telekom+Rufumleitung klingelt's (harr harr harr) bei mir.
Schau mal hier:

[Erledigt] - Asterisk Rufumleitung: Sprache kommt nicht zustande bei bestimmten Zielen

Hallo zusammen, Gegeben: Asterisk 13.38.1 (PJSIP) hinter Fritzbox Telekom-PK-Tarif mit AllIP IP-Telefon (Snom D375), das am Asterisk angemeldet ist und Rufumleitungen schaltet Bei einem ankommenden Anruf, bei dem das Snom klingeln würde, signalisiert es die Umleitung mit SIP 302 zum Asterisk...

www.ip-phone-forum.de

#12 genügt zu lesen, des Rätsels Lösung war dafür zu sorgen dass in den SDP-Paketen meine öffentliche IP-Adresse erscheint.

Wenn ich Screenshots richtig interpretiere (sowas zu analysieren finde ich mit Wireshark übrigens deutlich komfortabler), hast du nur die INVITEs von extern gezeigt, die dann umgeleitet werden, richtig?
Interessant wäre zu wissen was das Asterisk beim Wählen des Umleitungsziels signalisiert, insb. beim Thema SDP.

 

[m3g4tr0n]

Danke für deine Antwort.

FreePBX setzt bereits external_media_address und external_signaling_address automatisch mit der von mir hinterlegten dyndns-Adresse. Habe testweise mal direkt die IP eingetragen, selbes Phänomen.
Die Anrufe werden bei mir ja auch in beiden Varianten durchgestellt und bleiben nach Annehmen des Gesprächs bestehen. Lediglich in "Variante 1" bricht die Verbindung nach 30 Sekunden wegen des RTP-Timeouts ab.

 

[m3g4tr0n]

Ich habe mir mal ein FusionPBX (FreeSWITCH) aufgesetzt um damit vergleichen zu können.
Scheinbar ist dort das Inband Progress standardmäßig aktiv, denn es wird direkt ein 183 inkl. RTP geschickt, folglich aber auch kein hörbares Ringback beim Anrufer.
Unter FreeSWITCH habe ich allerdings die Möglichkeit, das sogenannte ring_ready im Inbound zu setzen. Damit wird vor das 183 ein 180 gesetzt, womit der Anrufende sein *tuuut* hat und auch Weiterleitungen mit Sprache funktionieren.
Im Anhang habe ich mal einen Vergleich (oben "Standard", unten mit action ring_ready).

Es muss doch auch unter Asterisk möglich sein ein stinknormales 180 vor dem 183 zu schicken, oder nicht? In den Extensions habe ich bereits an verschiedenen Stellen ein Ringing() gesetzt, jedoch sorgt dieses nur für ein weiteres 183...

 

[sunnyman]

Was gut zu wissen wäre:
- Welches Asterisk läuft in der FreePBX?
- Wird chan_sip oder pjsip genutzt?

 

[m3g4tr0n]

Guter Einwand, habe ich völlig vergessen.
Es läuft ein Asterisk 18.10.0 mit pjsip. Zuvor mit der von FreePBX empfohlenen 16.24.0. Testweise hatte ich auch mal eine 19er laufen. Jeweils mit sauberen Neuinstallationen.
Das Verhalten ist allerdings in allen Versionen gleich.

 

[sonyKatze]

kein Ton in beide Richtungen

Die Frage ist eher, warum dies passiert und ob Du in diesem/n Ruf-Szenario(s) ein Ringing (180) oder Progress (183) hattest. Das klingt nämlich nach einem Software-Bug entweder in Digium Asterisk oder der Konfiguration.

Vor Jahren hatte ich mir das für den alten SIP-Channel-Driver chan_sip angeschaut … und es war von Digium Asterisk nicht schön gemacht. Dort hing Ringing vom Status des anderen Call-Legs – dem Weiterleitungsziel – ab. Mit dem neuen SIP-Channel-Driver chan_pjsip habe ich mir das noch nicht angeschaut. Allerdings bin ich gerade mal den Quell-Code durchgegangen. Ich fand zwei Stellen, mit denen ein 180 möglich wäre, beides in der Datei channels/chan_pjsip.c und dort dann in

• update_connected_line_information(…)
• chan_pjsip_indicate(…)

In einem Fall muss inband_progress = no und in dem anderen Fall müsste inband_progess = yes gesetzt sein. Ganz seltsam. Kann noch mehr Stellen geben, aber das waren zwei, die ich auf die Schnelle über eine Regular-Expression fand. Dort würde ich mal mit einem Debugger/Breakpoint hinspringen und dann den Zustand der ganzen Variablen drumherum anschauen. Weißt Du wie das geht? Ansonsten bastele ich eine kleine Anleitung.

Aber vorher würde ich dieses allererste Szenario anschauen, also wo Du während dem ganzen Anruf keinerlei Ton hattest. Das sollte ja unabhängig vom Ringing und Progress immer tun. Könnte also bereits das eigentliche Problem sein.

ich möchte etwas dazulernen.

Kleine Warnung: In VoIP/SIP etwas lernen, ist schwierig, weil das oft nur Detail-Wissen ist. Das ist Wissen, dass nicht übertragbar ist, also Dir nichts Weiteres erschließt, sondern nur dieses eine Problem löst. Ich nenne „Detail-Wissen“ auch immer gerne „unnützes Wissen“. Es kostet viel Zeit, es sich zu erschließen, aber gebrauchen tut man es vielleicht nur einmal, wenn man Glück hat zweimal. Auch ist Digium Asterisk (aber auch SignalWire FreeSWITCH) von der Software-Architektur her von dermaßen unerfahrenen Menschen zusammen geschustert, nein, gekleistert worden, dass Du auch wenig über Informatik im Allgemeinen oder VoIP/SIP im Speziellen lernen könntest. Anders formuliert: So hätte man das nie machen dürfen. Bitte nicht nachmachen.

Wenn Du ein wenig näher beschreibst, was Du lernen möchtest, vielleicht kann ich Dir dafür einen Tipp geben.

 

[m3g4tr0n]

Wenn ich Screenshots richtig interpretiere (sowas zu analysieren finde ich mit Wireshark übrigens deutlich komfortabler), hast du nur die INVITEs von extern gezeigt, die dann umgeleitet werden, richtig?
Interessant wäre zu wissen was das Asterisk beim Wählen des Umleitungsziels signalisiert, insb. beim Thema SDP.

Sry, den Absatz habe ich (vermutlich vor Euphorie der Lösung näher zu kommen ) völlig überlesen.
Das sind die Verbindungen von Extern zum Asterisk, genau. Quasi nur mit Ringback oder nicht. Ich habe noch mal Screenshots inkl. gesamter Weiterleitung und Gesprächsannahme/-beendigung in den Anhang gepackt. Ebenso von FreeSWITCH mit und ohne gesetztes ring_ready.

Für mich verhalten sich Asterisk und FreeSWITCH exakt gleich, nur mit dem Unterschied, dass ich unter FreeSWITCH eben ein zusätzliches 180 vorabschicken kann.

Die Frage ist eher, warum dies passiert und ob Du in diesem/n Ruf-Szenario(s) ein Ringing (180) oder Progress (183) hattest. Das klingt nämlich nach einem Software-Bug entweder in Digium Asterisk oder der Konfiguration.

Dazu auch die Anhänge, mal inkl. zustandekommender Gespräche (wenn auch teilweise ohne Ton).

Die chan_pjsip.c habe ich mir auch angschaut und auch einige Stellen zur Inband Progress-Abfrage gesehen. Kurz überlegt darüber mal ein 180 zu "erzwingen" und zu kompilieren. Aber... gibt's da keine bessere Lösung? Ich bin doch nicht der einzige der Telekom-SIP über Asterisk laufen lässt. Mit richtigen Telekom-Business-Trunkleitungen verhält sich das ggf. noch mal anders, aber...

Dort würde ich mal mit einem Debugger/Breakpoint hinspringen und dann den Zustand der ganzen Variablen drumherum anschauen. Weißt Du wie das geht? Ansonsten bastele ich eine kleine Anleitung.

Falls das relevant wird wäre eine kleine Anleitung super.

Aber vorher würde ich dieses allererste Szenario anschauen, also wo Du während dem ganzen Anruf keinerlei Ton hattest. Das sollte ja unabhängig vom Ringing und Progress immer tun. Könnte also bereits das eigentliche Problem sein.

Gerne, weiß aber nicht wo ich da noch tiefer ansetzen kann/sollte.

Kleine Warnung: In VoIP/SIP etwas lernen, ist schwierig, weil das oft nur Detail-Wissen ist. [...]

Wenn Du ein wenig näher beschreibst, was Du lernen möchtest, vielleicht kann ich Dir dafür einen Tipp geben.

Es ging mir einfach um den Kontakt zu SIP und einem PBX um damit rumzuprobieren und die Software kennenzulernen. Detailiert in die SIP-Welt einzutauschen habe ich nicht vor, es sollte für meinen Zweck funktionieren und mein Interesse an "neuem" befriedigen.

Vielen Dank für eure Zeit.

 

[sonyKatze]

Dazu auch die Anhänge, mal inkl. zustandekommender Gespräche (wenn auch teilweise ohne Ton).

Sehe bzw. verstehe ich das richtig, dass Dein Weiterleitungsziel seine RTP-Pakete nicht über den Asterisk an die Telekom schickt, sondern direkt?

Ich bin doch nicht der einzige der Telekom-SIP über Asterisk laufen lässt.

Aus Spielerei und zum Verstehen, mache ich das auch. Aber ich rate jedem, wirklich jedem davon ab, mehr dazu ab diesem Post …

 

[m3g4tr0n]

Die RTP-Pakete haben, wenn ich das richtig sehe, immer ihren Ursprung am Asterisk bzw. gehen dort hin. 10.0.x.x ist mein Asterisk, das 217er Subnet die Telekom. Wobei ich von Telekom Mobil auf Telekom Festnetz (Asterisk) anrufe, um auf Sipgate weiterzuleiten. Das Verhalten ändert sich aber auch nicht wenn ich von anderen Providern anrufe/umleite.

Den verlinkten Beitrag habe ich im vorhinein auch schon gelesen, verstehe auch den Hintergrund deiner Warnung. Dennoch kickt mein Ehrgeiz da jetzt etwas rein das angefangene auch irgendwie zufriedenstellend abzuschließen.

 

[sonyKatze]

das 217er Subnet die Telekom.

Aber es geht an zwei verschiedene IPs in dem Subnet. Müsste es nicht zu einer IP gehen? Ich frage wirklich so blöd, weil ich das aus der Darstellung nicht ablesen kann. Das könnte nämlich genau der Fehler sein, den ich in dem anderen Thread beschrieben hatte – Dein Ziel schickt die RTP-Pakete an Asterisk vorbei und versucht selbst irgendwie wohin zu schicken. Daher dann kein Audio, weil die Firewall dort bei der Telekom das gar nicht erwartet.

das angefangene auch irgendwie zufriedenstellend abzuschließen

Eine IMS ist nicht nur ein Moving-Target – was bezüglich der Interoperabilität immer nur eine Moment-Aufnahme ergäbe –, es sind unendliche viele Moving-Targets – was ein einzelner Mensch schlicht nicht testen/leisten kann. Daher ist das nie „abgeschlossen“.

 

[m3g4tr0n]

Aber es geht an zwei verschiedene IPs in dem Subnet.

Ich verstehe was du meinst. Kann ich jetzt auch nicht 100 %ig erklären, jedoch sind das auch die Verbindungen mit Inband Progress, sprich Audio funktioniert aber kein Ringback.

Daher ist das nie „abgeschlossen“.

Schon klar, ein funktionierender Anschluss mit Rufweiterleitung wär aber schon mal ein guter Anfang


Nebenbei hab ich mal Asterisk compiled und versuche es gerade mal ohne FreePBX einzurichten. Wenn das klappt kann ich mal mit verschiedenen chan_pjsip.c rumprobieren. Allerdings entfernt mich das irgendwie alles weiter vom Ziel.

Warum bekommt es Asterisk ohne Inband Progress nicht hin die Verbindung zum Weiterleitungsziel entsprechend aufzubauen? Wenn ich ein ankommendes Gespräch annehme und weiterleite funktioniert es ja auch.
Mit Inband Progress leitet die Telekom das Early Media scheinbar nicht weiter. Es wird ja vom Asterisk erzeugt und verschickt.

 

[m3g4tr0n]

Kurze Zwischeninfo:
In der chan_pjsip.c sorgt der case AST_CONTROL_RINGING in der chan_pjsip_indicate (Zeile 1741) für das Senden des 183 mit eingeschaltetem Inband Progress. Ändere ich diesen in 180 wird (wie sollte man es anders erwarten) kein 183 geschickt, sondern ein 180. Damit allerdings auch wieder das oben beschriebene Problem: Keine Übermittlung von Ton.

Ich schaue mal ob ich es hinbekomme in dem Case zusätzlich ein 180 davor zu senden. Allerdings übersteigt das glaube langsam meine Kompetenz.

Edit:
Okay, war doch gar nicht so schwer, zumindest gepfuscht. Jetzt wird ein 180 und 183 gesendet, Ringback und Ton klappen auch. Bild im Anhang.
Dennoch nicht so ganz die Lösung die ich für sinnvoll erachte

 

[sonyKatze]

jedoch sind das auch die Verbindungen mit Inband Progress, sprich Audio funktioniert aber kein Ringback.

OK. Dann habe ich jetzt wirklich den Überblick verloren: Was ist mit den Verbindungen mit Klingeln aber ohne Audio? Deren RTP-Verkehr, zu welchen IP-Adressen geht der?

Telekom das Early Media scheinbar nicht weiter.

Du musst schauen, ob davon Ziel-Port schon offen ist, also ob die Telekom auf dem Port überhaupt schon erwartet etwas zu bekommen.

ein funktionierender Anschluss mit Rufweiterleitung wär aber schon mal ein guter Anfang

Kann sein, dass das vom Ziel abhängt. Kann sogar sein, dass das vom Proxy dazwischen abhängt. Du also (aus Deiner Sicht zufällig) ein anderes Verhalten bekommst. Du änderst etwas, aber zufällig ändert sich auch der Weg dorthin. Sieht hier in diesem Szenario nicht so aus, aber hatte ich auch schon. Ich verändere etwas. Dachte, es hätte eine Auswirkung. Dabei hat sich die andere Seite geändert, ohne dass ich darauf Einfluss nahm/nehmen konnte. Dadurch dass die Telekom Deutschland ein nicht-transparentes Load-Balancing hat, kann das sogar auf Deiner Seite passieren. Das hast Du bereits im Griff und Asterisk sieht immer nur den selben DNS-A?

zusätzlich ein 180 davor zu senden

Was genau hast Du geändert?
Hast Du auch mal das andere 180 oben geändert? Oder kommt/käme jener Repsonse-Code erst danach, also 183 180?
Jener Response-Code scheint den Konfigurationsparameter rpid_immediate = yes zu benötigen. Und dazu steht auch was Interessantes im Asterisk Wiki … hilft das irgendwie? Danach wäre das ein Ding des Dialplans. Kann das sein?

ennoch nicht so ganz die Lösung die ich für sinnvoll erachte

Erstmal nur ein Workaround, ja. Aber solche Ansätze helfen Asterisk zu verstehen.
Der nächste Schritt wäre jetzt wirklich die Englisch-sprachige Asterisk Community, im Web oder E-Mail.

Falls das relevant wird wäre eine kleine Anleitung super.

Erstmal den gebauten Binaries wieder löschen:

make clean​

dann aktivierst Du die Debugging-Symbole:

make menuselect → Compiler Options → DONT_OPTIMIZE und BETTER_BACKTRACES​

danach wieder Asterisk bauen:

make​

sudo make install​

dann öffnest Du Asterisk im Debugger:

sudo gdb /usr/sbin/asterisk​

Jetzt bist Du erstmal im Debugger mit seinen Befehlen. Über

break channels/chan_pjsip.c:1456​

setzt Du einen Breakpoint. Die Zahl ist die Zeile an der Du die Zustände wissen willst. Nun startest Du Asterisk im Debugger

run -gc​

Wenn der Debugger dann in den Breakpoint ausführt, kannst Du über

print​

jede Variable anschauen. Ab hier dann irgendein Tutorial zu GDB aus dem Web nehmen.

 

[m3g4tr0n]

OK. Dann habe ich jetzt wirklich den Überblick verloren: Was ist mit den Verbindungen mit Klingeln aber ohne Audio? Deren RTP-Verkehr, zu welchen IP-Adressen geht der?

Verständlich, da das eigentliche Problem (Umleitung funktioniert nicht) ggf. mehrere/unterschiedliche Ursachen und Lösungswege mit sich bringt...
Es werden bei der Variante gar keine RTP-Pakete verschickt.

Noch mal kürzer zur Übersicht:
Inband Progress: deaktiviert
Ringback ist hörbar, kein Ton in beide Richtungen.

Inband Progress: aktiviert
Ringback nicht hörbar, Ton in beide Richtungen.

Du musst schauen, ob davon Ziel-Port schon offen ist, also ob die Telekom auf dem Port überhaupt schon erwartet etwas zu bekommen.

Wie bekomm ich das mit? Steht das in einer Antwort eines Requests? Im Internet habe ich zu Early Media und Telekom auch die unterschiedlichsten Sachen gelesen. Einige schreiben es werde nicht unterstützt (Link, Nachtrag 7.12.2018), andere sagen es muss ein P-Early-Media-Header gesetzt werden, was mir aber für eingehende Gespräche bisher nicht geglückt ist. Grundlegend ist diese Thematik aber nichts neues und wird schon jahrelang immer mal wieder diskutiert. Nur eine Lösung scheint es nicht zu geben.

Das hast Du bereits im Griff und Asterisk sieht immer nur den selben DNS-A?

Das habe ich noch nicht überprüft, jedoch ist das Fehlerbild dauerhaft dasselbe. Auch bei anderen Zielen oder aus anderen Netzen.

Was genau hast Du geändert?
Hast Du auch mal das andere 180 oben geändert? Oder kommt/käme jener Repsonse-Code erst danach, also 183 180?
Jener Response-Code scheint den Konfigurationsparameter rpid_immediate = yes zu benötigen. Und dazu steht auch was Interessantes im Asterisk Wiki … hilft das irgendwie? Danach wäre das ein Ding des Dialplans. Kann das sein?

Erstmal nur ein Workaround, ja. Aber solche Ansätze helfen Asterisk zu verstehen.
Der nächste Schritt wäre jetzt wirklich die Englisch-sprachige Asterisk Community, im Web oder E-Mail.

Den Status in der erwähnten Zeile habe ich zu einem 180 gezwungen, das wird auch gesendet jedoch dann kein Inband Progess mehr durchgeführt. Dadurch ist das Verhalten dasselbe wie ohne Inband Progress.
rpid_immediate bewirkt überhaupt keine Änderung.

Aktuell habe ich folgende Änderung um Zeile 1820 vorgenommen:

if (response_code) {
        struct indicate_data *ind_data = indicate_data_alloc(channel->session, condition, response_code, data, datalen);
      
        // workaround for missing ringback if using inband_progress
        if (response_code == 183) {
            ast_sip_push_task(channel->session->serializer, indicate, indicate_data_alloc(channel->session, condition, 180, data, datalen));
        }
      
        if (!ind_data) {
            SCOPE_EXIT_LOG_RTN_VALUE(-1, LOG_ERROR, "%s: Couldn't alloc indicate data\n", ast_channel_name(ast));
        }

        if (ast_sip_push_task(channel->session->serializer, indicate, ind_data)) {
            ast_log(LOG_ERROR, "%s: Cannot send response code %d to endpoint %s. Could not queue task properly\n",
                    ast_channel_name(ast), response_code, ast_sorcery_object_get_id(channel->session->endpoint));
            ao2_cleanup(ind_data);
            res = -1;
        }
    }

Nicht schön, aber so wird vor jedem 183 ein 180 gesendet. Eines zwischen 100 Trying und dem ersten 183 würde wohl genügen, das bekomme ich aber nicht hin.
Dazu wende ich mich wohl wirklich mal an die Community, ggf. kann eine Option eingefügt werden, welche das besser macht. Wissen ob es bei der Telekom so nötig ist tue ich dennoch nicht, aber es funktioniert vorerst.

Das Debuggen habe ich auf die schnelle mal ausprobiert, klappte nicht so ganz. Schau ich mir in Ruhe noch mal an.

 

[gehtdoch]

Nun zum Problem: Rufumleitung
Umgeleitet werden soll auf eine externe Rufnummer:

• Inbound Route auf Misc Destination:
  Anruf wird weitergeleitet, Ringback ist hörbar, kein Ton in beide Richtungen.
• Inbound Route auf Nebenstelle mit FollowMe:
  Anruf wird weitergeleitet, Ringback ist hörbar, kein Ton in beide Richtungen. Sobald der Anrufer das Gespräch "hält" und wieder freigibt hören sich beide Gesprächspartner.

Letzteres habe ich schon seit Ewigkeiten völlig problemlos in Einsatz. Auch Ringback ist kein Problem. Allerdings muss man bei den NAT-Einstellungen via iptables einige Details beachten - v.a. nicht das SIP-Module verwenden, sondern die Einstellungen grundsätzlich statisch vornehmen. U.U. gibt es ja auch Probleme mit der im SDP gesendeten IP-Adresse - aber die Telekom machte, als ich die Probleme vor längerer Zeit durch einen Patch angegangen habe, den Call in diesem Fall ganz dicht. Von daher glaube ich nicht, dass das Dein Problem ist.

Asterisk selbst hat da zumindest kein grundsätzliches Problem - sonst hätte ich da ja auch schon längst draufstoßen müssen.

Deine SIP-Traces sehen auch ganz ok aus. Sind bei mir identisch. 180 genügt vollkommen. So wie Du das beschreibst, ist das aus meiner Sicht definitiv ein FW-Problem hinsichtlich der NAT-Einstellung. Hat sich bei mir damals unter bestimmten Bedingungen (gerade Rufumleitung) auch so geäußert - der Portfilter in Sachen SIP-Module kam da einfach nicht unter allen Bedingungen mit klar.

Unabhängig davon habe ich auch noch einen eigenen Patch drin, der alle eingehenden 183er ohne SDP als 180 weitergibt (da gab es lange Zeit Probleme mit fehlenden 180er bei der Telekom).

 

[m3g4tr0n]

Kann jetzt bei mir kein NAT-Problem ausschließen, da ich auch nicht exakt weiß wie wer was wo erwartet. In deinem Fall hat man ja auch einiges neben der Standardinstallation zu tun, da hab ich mit meinem kleinen Workaround ja fast weniger Aufwand
Verschiedene Einstellungen habe ich dann auch mit und ohne diverse Portfreigaben getestet, allerdings ohne auf der FreePBX-Maschine direkt zu NATten. Die Firewall darauf ist auch ausgeschaltet.

Geplant war das ganze mal unter IPv6 auszuprobieren, allerdings geht das mit FreePBX wohl noch nicht wirklich und über tel.t-online.de bekomm ich auch keine 6er Adressen.

 

[gehtdoch]

Telekom (AllIP zumindest) bietet keine Telefonie via IPv6 an.

Hier noch ein Beispiel für einen SIP-Trace bei einer Weiterleitung auf ein Handy.



Man beachte: das Ringback wird von Asterisk schon geschickt bevor er überhaupt den ersten Schritt in Richtung TN C macht.

 

[sonyKatze]

Wie bekomm ich das mit? Steht das in einer Antwort eines Requests?

Schau mal in die Nachrichten, die Du an das Weiterleitungsziel sendest. Ist dort bereits SDP enthalten? Ist im SDP eine IP-Adresse drin? Das müsste Deine öffentliche IP-Adresse sein (und keine private IP-Adresse und keine Telkom IP-Adresse).

 

[m3g4tr0n]

Telekom (AllIP zumindest) bietet keine Telefonie via IPv6 an.

Ja, bei dir wird scheinbar einiges weitergeleitet was bei mir nur zwischen erstem Endpunkt und Asterisk ausgehandelt wird...
Du nutzt kein Progress Inband, richtig?

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]
Also meine öffentliche IP finde ich in keinem der Mitschnitte. Das geht alles immer von Telekom zur privaten IP.

Wenn ich die nächsten Tage Zeit finde probier ich die NAT-Konfiguration von gehtdoch mal aus.