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

[sunnyman]

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. Das Asterisk baut daraufhin einen Ruf zum Umleitungsziel auf.

Abhängig von der Zielrufnummer funktioniert die Rufumleitung oder es ergibt sich folgendes Fehlerbild:
Signalisierungsseitig kommt der Ruf zustande (am rufenden Telefon wird der Ruf als angenommen angezeigt und die Gesprächszeit beginnt zu laufen), aber kein Audio.
Manchmal sendet das Asterisk dann auch nach einigen Sekunden von sich aus ein BYE.

Ich habe Paket-Mitschnitte von beiden Fällen und hier mal den Flow gegenübergestellt, wenn das Asterisk (0.0.0.0) den Ruf zum Umleitungsziel (Gateway Telekom: 217.0.27.32) aufbaut.

Umleitungsziele, bei denen der Ruf bspw. erfolgreich ist:

• ISDN-PtP vodafone
• Handy T-Mobile

Umleitungsziele, bei denen es bspw. nicht klappt:

• SIP-Trunk DTS
• Sipgate basic

Gibt es Tipps oder Dinge die ich mal genauer anschauen sollte?

 

[sonyKatze]

Gibt es Tipps oder Dinge die ich mal genauer anschauen sollte?

Der Asterisk ist direkt und bei der Telekom über VoIP/SIP registriert? Also nicht als IP-Telefon in der FRITZ!Box hinterlegt.

Ich würde in der FRITZ!Box einen Paket-Mitschnitt auf WAN (1. Internetverbindung) und LAN starten. Dann siehst Du, ob die RTP-Daten überhaupt bei der FRITZ!Box aufschlagen. Vielleicht routet die FRITZ!Box irgendwie falsch (Firewall oder deren interner SIP-Client).

Kommt gar kein RTP bei der Firewall an? Dann schau mal, ob Asterisk überhaupt irgendein RTP-Paket schickt und zwar an die richtige IP-Adresse. Auch schau Dir im SDP die Zeile „Connection-Information“ kurz c= an. Stehen dort ordentliche IP-Adressen?

Rufumleitungen schaltet

Auch fraglich – weil ich es nicht weiß –, ob die Telekom Deutschland überhaupt diese SIP-Status 30x unterstützt. Frag das mal im onlinekosten.de-Forum. Quark. Sehe gerade, Dein Digium Asterisk filtert die bereits raus und macht normale SIP-INVITE draus.

 

[sunnyman]

Der Asterisk ist direkt und bei der Telekom über VoIP/SIP registriert?

Ja.

Also nicht als IP-Telefon in der FRITZ!Box hinterlegt.

Korrekt.

Ich würde in der FRITZ!Box einen Paket-Mitschnitt auf WAN (1. Internetverbindung) und LAN starten. Dann siehst Du, ob die RTP-Daten überhaupt bei der FRITZ!Box aufschlagen.

Da tut sich nix. Habe ich auch mit beiden Fällen getestet. Also im Schlecht-Fall keine RTP-Pakete, im Gut-Fall erscheinen RTP-Pakete im Trace.

Vielleicht routet die FRITZ!Box irgendwie falsch (Firewall oder deren interner SIP-Client).

Kommt gar kein RTP bei der Firewall an?

Also ich habe ja getraced wie von dir vorgeschlagen in WAN und LAN. In beiden Traces kommen (im Schlecht-Fall) keine RTP-Pakete vor.

Auch schau Dir im SDP die Zeile „Connection-Information“ kurz c= an. Stehen dort ordentliche IP-Adressen?

Nein. Ist aber tatsächlich nie so, da steht die interne IPv4 des Asterisks. Das hat allerdings noch nie Probleme gemacht, und normale Telefonate mit den ganzen Gegenstellen klappen auch immer.
Ich habe es mal testweise mittels

external_media_address

hingebogen, hat keine Veränderung gebracht.

Dann schau mal, ob Asterisk überhaupt irgendein RTP-Paket schickt und zwar an die richtige IP-Adresse.

Auch hier habe ich mal beide Fälle getestet, und zwar indem ich

rtp set debug on

gesetzt habe. Im Schlecht-Fall wird offenbar nicht ein RTP Paket gesendet (oder empfangen), im funktionierenden Fall wird schön geloggt.

 

[sonyKatze]

Um den Asterisk zu kontrollieren, nimm bitte den Paket-Mitschnitt LAN oder ein Switch mit Port-Mirroring. Ich traue dem Asterisk Command-Line-Interface (CLI) nicht immer. Noch ein Tipp: In Wireshark filtere bitte nicht sofort auf „rtp“ sondern erstmal nach „udp“. Manchmal erkennt Wireshark den RTP-Verkehr nicht automatisch und lässt das als reine UDP-Pakete. Die Frage ist nämlich, warum Dein Asterisk keinerlei RTP sendet. Vielleicht warten diese Gegenstellen darauf, dass Du das erste RTP-Paket schickst. Ist in dem kommenden SDP die IP-Adresse in Header c= plausibel und erreichbar?

 

[sunnyman]

Um den Asterisk zu kontrollieren, nimm bitte den Paket-Mitschnitt LAN oder ein Switch mit Port-Mirroring. Ich traue dem Asterisk Command-Line-Interface (CLI) nicht immer. Noch ein Tipp: In Wireshark filtere bitte nicht sofort auf „rtp“ sondern erstmal nach „udp“.

OK, da ist aber auch nix, leider.

Ist in dem kommenden SDP die IP-Adresse in Header c= plausibel und erreichbar?

Ja, ist in beiden Fällen sogar dieselbe IP-Adresse.

Ich habe auch das Gefühl, dass es sich um einen "programmlogisches" Problem handelt.

Ich habe mal mitgeschrieben, was das Asterisk so an Logmeldungen ausspuckt, ich hoffe ich kann das verständlich genug rüberbringen:

Im Gut-Fall passiert folgendes:

Channel PJSIP/AbgehenderRuf joined 'simple_bridge' basic-bridge <EINS>
Channel Local/Umleitungsziel;2 joined 'simple_bridge' basic-bridge <EINS>

Channel Local/Umleitungsziel;1 joined 'simple_bridge' basic-bridge <ZWEI>
Channel PJSIP/AnkommernderRuf joined 'simple_bridge' basic-bridge <ZWEI>

> Strict RTP switching to RTP target address (...) as source
> Move-swap optimizing Local/Umleitungsziel;2 <-- PJSIP/AnkommenderRuf

Channel PJSIP/AnkommenderRuf left 'simple_bridge' basic-bridge <ZWEI>
Channel Local/UmleitungsZiel;2 left 'simple_bridge' basic-bridge <EINS>
Channel PJSIP/AnkommenderRuf swapped with Local/Umleitungsziel;2 into 'simple_bridge' basic-bridge <EINS>
Channel Local/Umleitungsziel;1 left 'simple_bridge' basic-bridge <ZWEI>

Es kommen also Ankommend und Umleitungsziel sowie Abgehend und Umleitungsziel in zwei Bridges. Asterisk optimiert das dann und schaltet PJSIP/AnkommenderRuf und PJSIP/AbgehenderRuf in einer Bridge zusammen.

Genau das passiert im Schlecht-Fall jedoch nicht:

Channel PJSIP/AbgehenderRuf joined 'simple_bridge' basic-bridge <EINS>
Channel Local/Umleitungsziel;2 joined 'simple_bridge' basic-bridge <EINS>
Channel Local/Umleitungsziel;1 joined 'simple_bridge' basic-bridge <ZWEI>
Channel PJSIP/AnkommenderRuf joined 'simple_bridge' basic-bridge <ZWEI>

Und dann ist Schluss.
Die Frage ist allerdings, ob das die Ursache ist oder auch nur ein Symptom.

 

[sonyKatze]

Meine Vermutung wäre, das mit den Bridges ist ein Symptom. Schalte bitte in der Konfigurationsdatei rtp.conf (nur zum Test): strictrtp=no

Wenn auch das nicht hilft, Asterisk in einem Debugger starten und im Gutfall den backtrace anschauen, also wann/warum Asterisk anfängt RTP zu senden (Englisch: call stack). Wenn Du das nicht kannst, würde ich in einem der englisch-sprachigen Foren wie der Mailing-List oder dem Web-Forum fragen, was genau Asterisk dazu verleitet, RTP zu senden. Meine wilde Spekulation: Die andere Seite wartet, bis Du das erste RTP-Paket schickst. Deren Annahmen: „weil erst so Deine lokale Firewall geöffnet wurde“. Aber Dein Asterisk schickt kein RTP, weil es ebenfalls darauf wartet, dass die andere Seite den ersten Schritt macht. Du könntest das als Frage, als Arbeitshypothese in den genannten Foren stellen.

Ich nutze hier kein PJSIP (und auch kein Telekom Deutschland), daher weiß ich nicht, ob das was ausmacht.

 

[sunnyman]

Meine Vermutung wäre, das mit den Bridges ist ein Symptom. Schalte bitte in der Konfigurationsdatei rtp.conf (nur zum Test): strictrtp=no

Nein, das ändert nichts am Verhalten. Auf der Konsole spuckt Asterisk dann eben nichts in Bezug auf "strict RTP learning" aus, aber das swapping mit den Bridges im Gut-Fall, und im Schlechtfall nicht.

Wenn auch das nicht hilft, Asterisk in einem Debugger starten und im Gutfall den backtrace anschauen, also wann/warum Asterisk anfängt RTP zu senden (Englisch: call stack). Wenn Du das nicht kannst, würde ich in einem der englisch-sprachigen Foren wie der Mailing-List oder dem Web-Forum fragen, was genau Asterisk dazu verleitet, RTP zu senden. Meine wilde Spekulation: Die andere Seite wartet, bis Du das erste RTP-Paket schickst. Deren Annahmen: „weil erst so Deine lokale Firewall geöffnet wurde“. Aber Dein Asterisk schickt kein RTP, weil es ebenfalls darauf wartet, dass die andere Seite den ersten Schritt macht. Du könntest das als Frage, als Arbeitshypothese in den genannten Foren stellen.

Ich nutze hier kein PJSIP (und auch kein Telekom Deutschland), daher weiß ich nicht, ob das was ausmacht.

Das Asterisk ist selbst kompiliert, das könnte ich natürlich auch mal mit den Debugger-Symbolen bauen. Aber bevor ich da sozusagen ans Eingemachte gehe, frag' ich vielleicht vorher doch eher in der Asterisk Community nach. Und vielleeeeeicht hat ja zwischenzeitlich hier im Forum ein anderer User noch einen Geistesblitz.

 

[sonyKatze]

Oder Du probierst eine komplett andere Konfiguration … mittels MediaSec …

 

[IEEE]

Ehrlich gesagt kenne ich dieses Problem, kein Audio bei Weiterleitung auf Mobilgeräte, seit bald 15 Jahren durchgängig durch diverse asterisk Versionen. Auch dass manche (was jetzt das Weiterleitungsziel angeht) Mobilfunkprovider betroffen sind und andere nicht, kann ich soweit bestätigen.
Ich habe schon lange aufgegeben hier eine Schulbuch-Lösung zu finden. Ich mache es stattdessen jetzt immer so, dass ich für die Handys auf die weitergeleitet wird, eigene extensions zum Rauswählen anlege, bei denen ich vor dem Dial ein Answer mache. Dieses Answer reicht aus, dass der Medienstrom anschließend fließt.

Mir ist klar dass diese Lösung bedingt elegant ist und Nachteile hat. Einerseits weil für den Anrufenden die Gesprächszeit gleich zu laufen beginnt (obwohl vielleicht gar niemand erreichbar ist), andererseits weil dieses Answer natürlich dafür sorgt dass der Call beantwortet ist und sich somit keine Parallelanrufe realisieren lassen. Also wenn ich zum Beispiel eine Weiterleitung auf mehrere Bereitschaftstechniker Handys realisieren soll, hab ich ein Problem weil natürlich in der ersten Millisekunde wo ein Answer zieht, der Call beantwortet ist und sich andere Dials erübrigen.
Aber immerhin konnte ich so das Problem halbwegs zufriedenstellend erschlagen und monatelanges Fehlersuchen beenden.

 

[sunnyman]

Danke für deine Infos. Tatsächlich ist es ja aber so, dass Umleitung aufs Handy einer von den funktionierenden Fällen ist. Im Nicht-Funktionierenden Fall ein Answer() in den ausgehenden Ruf zu machen funktioniert tatsächlich, ist aber aus den von dir genannten Gründen problembehaftet. Zudem müsste ich für eine solche Sonderbehandlung die problematischen Umleitungsziele ja im Vorhinein alle kennen.

 

[IEEE]

Sorry bezüglich des Irrtums meinerseits, da hab ich Deinen Post wohl zu schnell gelesen und mich zu rasch darin wieder gefunden.
In meinem Fall sind es halt quasi immer Mobilfunkprovider als Weiterleitungsziel mit denen das Problem auftritt. Aber eben auch nicht alle.
In jedem Fall schonmal interessant, dass das Answer bei Dir auch funktioniert.
Wie gesagt, mit den Nachteilen dieser Lösung habe ich mich abgefunden.

Zudem müsste ich für eine solche Sonderbehandlung die problematischen Umleitungsziele ja im Vorhinein alle kennen.

Was das angeht, so löse ich das üblicherweise auf zwei Arten: Bei Kleinstinstallationen weiß man in aller Regel auf welche Ziele so üblicherweise umgeleitet wird (meistens liegt das fixfertig auf Telefontasten), da pflege ich diese Ziele halt dann im Dialplan ein.
Dort wo das nicht geht, arbeite ich mit Prefixe. Also ich bitte die User dann die Weiterleitung nicht auf 01234567 einzurichten, sondern zum Beispiel auf **01234567. Das ** Prefix arbeite ich dann im Dialplan entsprechend ab, dass hier das Answer gemacht wird.

Wie gesagt, Mega-Uncool diese Lösung, aber es ist zumindest eine Lösung. Die Suche nach der Ursache hat mich hier damals echt zermürbt, ich musste das irgendwann aufgeben, sonst wär mir das Hirn sauer geworden

 

[sunnyman]

So,

mittlerweile bin ich schlauer.
Im Prinzip war @sonyKatze schon auf der richtigen Spur: Schuld sind in meinem Fall tatsächlich die kaputten Pakete. Die SDP-Nachrichten enthalten meine private IP-Adresse, die SIP-Nachrichten aber auch komplett -- kann auch nicht anders sein, weil ich im Asterisk aktuell nichts dazu eingestellt habe. War auch schlicht nie nötig, es gab ja nie Probleme, und Asterisk verlässlich und stabil die wechselnde öffentliche IP beizubringen ist ja auch kein ganz einfaches Unterfangen.

Nun ist es so, dass zumindest in dem Fall des weitergeleiteten Anrufs - abhängig von der Zielrufnummer - unter derselben Telekom-IP unterschiedliche Systeme mit mir sprechen.
Das mache ich daran fest, dass im einen Fall die SDP-Session seitens des Telekom-Servers "-" genannt wird, im anderen fall "TELES-SBC".
Nun ist es wohl so, dass eines dieser Systeme "connection oriented media" macht, also erkennt dass ich nur RFC1918-Adressen signalisiere und schlicht dorthin sendet von wo die Pakete kommen.

Im Fehlerfall ist es übrigens nicht das Asterisk, dass den Ruf ursächlich terminiert, sondern es ist das Telekom-Gateway für den eingehenden Ruf.

Nun zur Lösung:
ich habe nicht nur die

external_media_address

mit meiner öffentlichen IP bestückt sondern auch die

external_signaling_address

. Nun klappt's!

Allerdings gibts nun ein Problem, das nach einem IP-Adresswechsel die PJSIP-Registrierungen nicht invalidiert werden, aber dafür mache ich mal lieber einen neuen Thread auf, es ist ja eine neue/andere Fragestellung:

[Problem] - PJSIP: keine Neu-Registrierung nach Wechsel d. öffentlichen IP

Hallo zusammen, gegeben: Telekom AllIP-PK Anschluss (DSL+VoIP) Fritzbox Asterisk 13 mit PJSIP Ich hatte das Problem, dass bei Rufumleitungen teilweise keine Sprache zustande kam: Asterisk Rufumleitung: Sprache kommt nicht zustande bei bestimmten Zielen Dieses Problem habe ich gelöst, indem...

www.ip-phone-forum.de