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

[sunnyman]

Also meine öffentliche IP finde ich in keinem der Mitschnitte. Das geht alles immer von Telekom zur privaten IP.

Also die Telekom wird bestimmt keine Pakete an RFC1918-Adressen schicken. Kann es sein dass du beim Tracen auf dem falschen Interface sitzt?

 

[gehtdoch]

Du nutzt kein Progress Inband, richtig?

korrekt. inband_progress ist überall false.

Noch ergänzend zum Verständnis des Traces von mir weiter oben:
Die reInivte-Sequenz ab 18:51:57 ist "Nachkarten" seitens des TN A, welcher dediziert einen Codec sicherstellen will (zuvor wurde eine Liste ausgehandelt - der erste wird da normalerweise genommen - genau dieser "erste" wird da dediziert nachgekartet).

Die beiden reInvites um 18:52:32 und 18:52:40 waren von TN C (auf den von TN B weitergeleitet wurde) provoziert: TN C hat TN A auf halten gelegt und wieder aufgenommen. Dies war nicht deshalb, weil der RTP nicht funktioniert hätte, sondern einfach zu Demonstrationszwecken. Der Call hat von der ersten Sekunde an einwandfrei funktioniert.

 

[chrsto]

Also meine öffentliche IP finde ich in keinem der Mitschnitte. Das geht alles immer von Telekom zur privaten IP.

Also die Telekom wird bestimmt keine Pakete an RFC1918-Adressen schicken. Kann es sein dass du beim Tracen auf dem falschen Interface sitzt?

Das ist ein korrektes Verhalten der Telekom. Siehe deren technische Unterlage:

Dieser Mechanismus sucht nach vorhandenen IP-Bindungen zur TK-Anlage und ermittelt die vermutete IP-Adresse und den Transportport anhand des Registrierungskontextes, des Kontaktheaders aus SIP und der Medieninformationen aus SDP oder identifiziert die Quelle anhand der IP-Header-Informationen.
Durch diesen Mechanismus ist jeder NAT-Traversal-Mechanismus an der TK-Anlage überflüssig.

SIP UAs, die die öffentliche IP-Adresse und Informationen über den öffentlichen Port nicht kennen, senden eine private IP-Adresse
(RFC 1918) in VIA und CONTACT-Header. In diesem Fall aktiviert SIP-Trunk eine NAT-Traversal-Funktion und sendet SIP-
Nachrichten an den SIP UA mit dem gleichen Transportprotokoll auf der gleichen IP-Adresse und Portnummer wie vom Benutzer
empfangen.

 

[m3g4tr0n]

Hatte bisher auf dem FreePBX direkt gemessen, daher die IP. Im Anhang mal drei Mitschnitte über den Router.
router_progressOff_noSound
Inband Progress deaktiviert - kein Ton

router_progressOn_noRing
Inband Progress aktiviert - kein Ringback

router_progressOn_edit
Inband Progress aktiviert (mit geändeter chan_pjsip.so)

SIP UAs, die die öffentliche IP-Adresse und Informationen über den öffentlichen Port nicht kennen, senden eine private IP-Adresse
(RFC 1918) in VIA und CONTACT-Header. In diesem Fall aktiviert SIP-Trunk eine NAT-Traversal-Funktion und sendet SIP-
Nachrichten an den SIP UA mit dem gleichen Transportprotokoll auf der gleichen IP-Adresse und Portnummer wie vom Benutzer
empfangen.

Das ist ja dann das, was @gehtdoch durch sein Patch verändert hat und seitdem funktioniert, oder?

 

[gehtdoch]

Das ist ja dann das, was @gehtdoch durch sein Patch verändert hat und seitdem funktioniert, oder?

Wenn Du auf den Patch referenzierst in meinem NAT-Artikel: ja, der sorgt dafür, dass immer an allen Stellen in den SIP-Paketen tatsächlich die globale IP zu finden ist (und nicht noch teilweise die lokale) - so die dort beschrieben NAT Konfig / NAT Handling eingehalten wird.

Eine Frage zu Deinem Testszenario: da taucht ein RTP Stream zu NETZQUADRAT-MNT auf. Wie genau ist denn der Testcase? Call kommt von welchem Provider via Telekom zu Asterisk und wird dann von Asterisk via Telekom weitergeleitet zu Provider unbekannt?

Wenn ein Call von der Telekom kommt und via Telekom wieder rausgeht, darf kein RTP zu einem anderen Provider auftreten. Ich habe es zumindest bisher so verstanden, dass Asterisk einen Call von der Telekom bekommt und den dann wieder via Telekom zu einer anderen
Nummer weiterleitet.
In diesem Testcase terminiert Asterisk jeweils beide Calllegs und es gibt jeweils nur die RTP-Streams zwischen Telekom und Asterisk (insgesamt 4 - 2 pro Callleg).

 

[m3g4tr0n]

In dem Beispiel kommt der Anruf von T-Mobile an den Telekom-Anschluss und wird per Misc Destination an eine Sipgate-Nummer weitergeleitet.
Das Verhalten ist aber immer gleich, egal welche Anschlüsse/Provider an erster und letzter Stelle stehen.

 

[gehtdoch]

Vorweg: Dein Testcase ist recht komplex und alles andere als trivial für die beteiligten Stacks. Wenn die nicht alle absolut sauber konfiguriert sind, wirst Du da immer Probleme haben!


Zu Deinen 3 Traces:
Dass Du im dritten Fall kein Ringback hast, ist zwangsweise klar: da fehlt gleich am Anfang der 180 Ringing - media im 183 Session Progress wird (in der Regel nicht nur) von der Telekom geblockt (bevor der Call steht), weil Du damit ja schon Daten übermitteln könntest, bevor der Gebührenzähler läuft (early media wird daher unterbunden)! Außerdem fließen ja auch gar keine RTP-Daten - die müsstest Du ja ansonsten sehen. Werden die irgendwo weggeblockt?


Der 3. Trace (early media-Fall) im Detail, soweit möglich auf Basis der Daten: Du schreibst, dass der Call vom Handy via Telekom zu Sipgate via Telekom weitergeleitet wird. Was zunächst passt, ist, dass der Call von einem Handy kommt (wg. AMR im SDP). Den schiebt dann Asterisk weiter zur Telekom Richtung sipgate dann vermutlich. Dann kommt ein Call von sipgate rein (beginnend mit dem lila Part). Hast Du auch eine Nummer bei Sipgate in Asterisk registriert, so dass der Call dann schlussendlich bei Dir ankommt, nur eben über den "Umweg" (wg. Umleitung) sipgate? So verstehe ich das jetzt.

Der 2. Trace (ebenfalls early media) schickt zusätzlich zum 183 noch das 180 Ringing, was dann dafür verantwortlich ist, dass Du ein Ringback hast als Caller. Ebenso beim 1. Trace. Das 183 wird inhaltlich in Sachen media von der Telekom geblockt.

Der 1. Trace funktioniert zwar in Sachen Ringback (wg. dem 180), aber Ton (media) fehlt (vermutlich weil kein early media vorhanden ist, an dem sich der Router orientieren kann). Asterisk schickt zwar zu Sipgate RTP-Daten (im lila part), die kommen aber im orangenen Part nicht an (das ist der weitergeleitete Call von Dir zu Sipgate). Ob die wirklich nicht auf den Weg gebracht wurden oder vom Router geblockt werden, entzieht sich meiner Kenntnis. Ich vermute eher letzteres.

Warum "funktioniert" die zweite Variante? Es stellt sich für mich derzeit so dar, dass Dein (Kauf)Router die zusätzlichen SDP-Informationen aus den early media Paketen benötigt, um sämtliche relevante Ports (früh genug) zu aktivieren (wahrscheinlich schnüffelt der mit, um die relevanten Ports dynamisch zu aktivieren - Du bist ja ganz offensichtlich unverschlüsselt unterwegs). Konfiguriere den Router mal so, dass das NAT bzw. Forwarding für die entsprechenden Pakete statisch ist. Wird aber vermutlich nicht lustig werden - ich habe glücklicherweise einen eigenen Router, der exakt das macht, was ich will und dem ich genau das beibiegen kann, was SIP im Detail benötigt - ohne Orakelei und Schnüffelei und Interpretiererei - ist bei Einsatz von Verschlüsselung eh nicht möglich.
Was ich ja nicht sehen kann, ist, ob die IP-Adressen und Ports an allen Stellen im SIP-Paket immer korrekt und vollständig sind. Vielleicht passt ja auch da was nicht in den unterschiedlichen Fällen. Ist daher jetzt insgesamt Kaffesatzleserei und alles hochspekulativ.

Wenn Du wirklich sicher sein willst, dass Dein Router da nicht reinspuckt, dann aktiviere wenigstens für alle Trunks (SIP) Verschlüsselung (ja, ist bei der Telekom nicht so einfach, wg. mediasec - aber ich habe ja auch dafür einen Patch geliefert - wobei der für 18.11.x an einer Stelle deutlich angepasst werden muss).

 

[m3g4tr0n]

Komplex? Das ist doch eine ganz normale Situation. Jemand ruft von irgendwo an und ich lasse das weiterleiten. Oder verstehe ich was falsch?

Dass Du im dritten Fall kein Ringback hast, ist zwangsweise klar: da fehlt gleich am Anfang der 180 Ringing - media im 183 Session Progress wird (in der Regel nicht nur) von der Telekom geblockt (bevor der Call steht), weil Du damit ja schon Daten übermitteln könntest, bevor der Gebührenzähler läuft (early media wird daher unterbunden)! Außerdem fließen ja auch gar keine RTP-Daten - die müsstest Du ja ansonsten sehen. Werden die irgendwo weggeblockt?

Das ist ja genau der Grund warum ich die pjsip verändert habe, damit eben ein 180 vorher geschickt wird. Dass das Early Media von der Telekom allerdings blockiert wird liest man im Internet halt mal so mal so. Eine wirkliche Bestätigung gibt es nicht, selbst in irgendwelchen Dokumenten der Telekom habe ich schon gelesen das es unterstützt wird... Ist eben alles sehr undurchsichtig.
Ein generierte Ringback und auch das ausgehende Audio sind im Mitschnitt dabei und kann ich mir anhören.

So verstehe ich das jetzt.

Die Sipgate Nummer habe ich auf meinem PC laufen, ist daher evtl. für den Mitschnitt jetzt etwas irreführend, da das ja auf dieselbe IP geht
Verhält sich aber genauso wenn das in irgendein anderes Netz geht.

ich habe glücklicherweise einen eigenen Router, der exakt das macht, was ich will und dem ich genau das beibiegen kann, was SIP im Detail benötigt
[...]
Wenn Du wirklich sicher sein willst, dass Dein Router da nicht reinspuckt, dann aktiviere wenigstens für alle Trunks (SIP) Verschlüsselung

Welche Einstellungen meinst du denn damit? Auch im Router/Firewall (es läuft eine pfsense) hab ich, wie im ersten Beitrag beschrieben, schon diverse Optionen ausprobiert.
Die Trunks liefen zeitweise auch alle schon mit TLS (allerdings ohne SRTP), selbes Verhalten in allen fällen. Habe ich jetzt nur für die Mitschnitte wieder umgestellt.

 

[gehtdoch]

Dass das Early Media von der Telekom allerdings blockiert wird liest man im Internet halt mal so mal so. Eine wirkliche Bestätigung gibt es nicht, selbst in irgendwelchen Dokumenten der Telekom habe ich schon gelesen das es unterstützt wird... Ist eben alles sehr undurchsichtig.

Im Zusammenhang mit einem PSTN-Client als callee wahrscheinlich - da ist das nötig - aber nicht bei SIP-Clients als callee. Die Telekom (und nicht nur die) unterstützt das sicher nicht bei VoIP-Clients (vielleicht im Ausnahmefall in bestimmten Fällen, die dann abgestimmt sind) in der Breite, weil das ansonsten missbraucht werden könnte. Lediglich die Telekom selbst generiert derartige Ansagen - dann ist aber auch klar, dass das nicht missbraucht werden kann (dann kommt es ja nicht vom callee).

Ein generierte Ringback und auch das ausgehende Audio sind im Mitschnitt dabei und kann ich mir anhören.

Im trace ist es jedenfalls am Messpunkt nicht zu sehen - und damit auch nicht vorhanden. Die anderen RTP-Streams werden ja angezeigt - warum sollte ausgerechnet der nicht angezeigt werden, obwohl er vorhanden ist - das wäre nur dann der Fall, wenn er vor dem Messpunkt irgendwo weggeblockt wurde. Kann ich aber nicht beurteilen, weil ich die Deine Umgebung im Detail unmöglich kennen kann. Ist aber am Ende sowieso egal, weil der Datenstrom sowieso von der Telekom geblockt wird - egal, ob Du ihn jetzt wegschickst oder nicht.

Welche Einstellungen meinst du denn damit? Auch im Router/Firewall (es läuft eine pfsense) hab ich, wie im ersten Beitrag beschrieben, schon diverse Optionen ausprobiert.

Sorry - habe ich überlesen. Wer terminiert die pppoe-Session? Macht das die pfsense? Sprich, danach kommt nichts mehr?
Was ich meine, ist, dass Du, wie in meinem NAT-Artikel beschrieben, die iptables-Regeln statisch einrichten musst (für jedes RTP-Ziel-Netz - vor allem in und evtl. auch outbound - falls das nicht sowieso offen ist). Dynamisch wird nie sauber funktionieren - Du hast genau einen solchen use case jetzt ausgegraben, wo das nicht funktioniert. Kenne ich zur genüge - ich weiß aus Erfahrung, wovon ich rede.

Von dynamisch gibt es zwei Varianten, die beide nur eingeschränkt funktionieren (in den einfachsten Fällen eben - dies gilt auch in Kombination beider Varianten).
Variante a): Mit Hilfe des sip helpers lauscht iptables mit und versucht rauszubekommen, welche Ports in welche Richtung geöffnet werden müssen.
Variante b): Ohne sip helper, aber auf connection tracking Basis, sprich, ein eingehender Datenstrom wird erlaubt, wenn vorher ein ausgehender Datenstrom erkannt wurde. Diese Reihenfolge ist bei weitem nicht bei jedem Call (von Anfang an) gegeben.

Daher ist es eminent wichtig, dass Du die Regeln statisch einträgst (ohne connection tracking und ohne sip helper - einfach statisch - sip helper macht bei Verschlüsselung z.B. sowieso keinen Sinn). Wenn Du das machst, so wie ich es im NAT-Artikel geschrieben habe, wird das auch in jedem Fall funktionieren - auch im komplexesten (falls alle IP-Einträge und Ports in allen SIP-Paketen korrekt sind). Auch ohne Deinen zusätzlichen Patch.
In wie weit das pfsense unterstützt in der GUI - keine Ahnung, die nutze ich nicht. Ich habe mir meine iptables-Regeln komplett selbst gebaut (via script). Da weiß ich exakt, was ich habe (weil ich es selbst geschrieben habe).

 

[IEEE]

Ich riskier jetzt mal dass ich einen sinnlosen Tipp gebe, weil das vielleicht eh schon probiert wurde oder das vorliegende Problem anders gelagert ist. Zumindest konnte ich nicht entdecken dass nachfolgendes hier in diesem Thread mal erwähnt wurde. Sorry falls trotzdem umsonst.

Jedenfalls hab ich das Problem ja auch immer wieder seit über 10 Jahren (mit allen möglichen Providern) und hab mich halt immer irgendwie durchgerettet mit unschönen Lösungen wie einem Answer auf dem Zielchannel vor dem Dial, abspielen eines kurzen Soundfiles, der "r" Option beim Dial etc.

Kürzlich bin ich endlich, nachdem ich es mir seit Jahren vornehme, die Umstellung auf pjsip angegangen. Unmittelbar nach der Migration bestand das Problem wie gewohnt weiterhin. Also kein Ringback (allerhöchstens mit "r" oder mit Ringing()) und auch kein Audio bzw. Audio eher Glücksfall oder einseitig. Diverse Versuche mit rtp_symetric, force_rport etc. haben nichts geändert. Kein Unterschied zu chan_sip vorher.

Dann habe ich die Endpoint Option rtp_keepalive entdeckt und sie gemäß diversen Tipps gleich mal auf 1 gestellt. Also rtp_keepalive=1.
Durch diese Zeile war das Thema sofort vom Tisch. Alles funktioniert nun wie geplant, Ringback, Audio, alles super. Und das obwohl mein Asterisk hinter einem durchaus restriktiven NAT (ohne Portforwardings) steht und keinerlei Idee über die öffentliche IP hat und diese auch in keine Pakete schreibt.