Ausgehender RTP-Datenstrom geht irgendwo "verloren"

[#1]

Anschlussart:

DeutschlandLAN IP Voice/Data

Netzaufbau:
IP-PBX Anlage => Digibox Smart => Glasfasermodem => [www]

Problem:
Ausgehend kein Ton hörbar, egal ob Ruf aufgebaut oder angenommen wird

Fehleranalyse:
KEIN Problem mit Portweiterleitungen / Firewall, ein PCPAP-Trace auf der WAN (PPP) Seite der Digibox zeigt ein- und ausgehende Audiodaten.

Screenshot dazu:

 

Diese Audiodaten kommen aber "bei mir" nicht mehr an.

PCPAP-trace im Anhang (Dateiendung von .png auf .pcapng ändern und mit Wireshark öffnen)

Störungsmeldungen:
261353067

Werden mit Kommentar "keine ankommenden RTP-Daten" geschlossen.

Das ist aber weder Ursache noch Lösung sondern genau das Problem. 

PS:

Momentan telefonieren wir mit Extrakosten über einen SIP-Trunk eines Konkurrenzanbieters, welcher in exakt der selben IP-PBX problemlos funktioniert.

[#2]

Zeigt denn ein PCAP auf der LAN Seite auch ein- und ausgehende Audiodaten?

Bei der Digibox kenne ich mich nicht gut aus, aber bei anderen Router liegt sowas gerne mal daran, dass der Router den Audiostream auf einem anderen UDP Port weiterreicht als von der Telefonanlage erwartet. 

[#3]

Hallo @AHBohr,

herzlich willkommen in unserer Community.

Damit ich schnell weiterhelfen kann, füllen Sie bitte in Ihren Benutzerdaten die Felder „Kundennummer“ und/oder „Telefonnummer“ aus. Über folgenden Link gelangen Sie sofort zur richtigen Stelle in Ihrem Profil.

Im Anschluss freue ich mich über eine kurze Rückmeldung.

Viele Grüße Heike Ha.

[#4]

@Heike Ha. Kontaktdaten sind Hinterlegt

@Stefan Ja auf der LAN Seite ebenfalls RTP in beide Richtungen, kann man sich mit Wireshark auch anhören

Den PCPAP Log kann ich hier gerne auch hochladen.

[#5]

Hallo @AHBohr ,

die DB läuft in der Betriebsart MGW?

Wenn ja, den Assistenten VoIP-PBX im Lan ausgeführt (ich hoffe den gibts in der neuen Oberfläche noch)?

Wenn nein, solltest du dir dieses Video ansehen:

https://www.youtube.com/watch?v=lrmCvywvGmA

[#6]

@AHBohr 

Die Netzwerk Mitschnitte wären interessant.

Würdest du die in eine Cloud kopieren und mir den Link als PN senden wollen?

[#7]

[#8]

@AHBohr 

Die Netzwerkmitschnitte sind nicht gleichzeitig erfolgt.

Die WAN-Seite sieht ganz "plausibel" aus.

Bei dem Netzwerkmitschnitt der LAN-Seite sehe ich zwei INVITES (217.0.21.129 und 217.0.28.33).

217.0.21.129:

INVITE -> SDP 217.0.5.246/18932

<- TRYING

... einige OPTIONS

CANCEL ->

<- 481 Call/Transaction does not exist

217.0.28.33:

INVITE -> SDP 217.0.6.246/26582

<- TRYING

<- RINGING

... einige OPTIONS

<- 200 OK SDP IPv4 DB/12908

Die RTP Daten, die ich im Netzwerkmitschnitt sehe sind ja totaler Blödsinn.

192.168.2.100/19664 -> 217.0.5.246/18932

Für das eigentliche Gespräch sendet die PBX nichts.

[#9]

Ok ich habe hier nochmal 2 Traces die gleichzeitig liefen (eben gerade):

https://1-wtp.no-ip.org:44500/d/f0c6863f45bc4513b348/

Mit meinem laienhaften wissen ist in beiden RTP ein- wie ausgehend (ich kanns mir anhören). Ich denke Ja dass irgendwas hinter der 217.0.4.197 die Daten "verschlampt".

[#10]

@AHBohr 

Ist es dir möglich bei einem Anruf einen gleichzeitigen Netzwerkmitschnitt von WAN und LAN zu erstellen?

Dann sollte man das Problem lösen können.

[#11]

Ok ich habe hier nochmal 2 Traces die gleichzeitig liefen (eben gerade):

https://1-wtp.no-ip.org:44500/d/f0c6863f45bc4513b348/

Mit meinem laienhaften wissen ist in beiden RTP ein- wie ausgehend (ich kanns mir anhören). Ich denke Ja dass irgendwas hinter der 217.0.4.197 die Daten "verschlampt".

Vielen Dank für deine Hilfe / Bemühungen.

[#12]

@AHBohr 

So wie ich das sehe, hat deine PBX das nicht im Griff.

Beim 180 Ringing wird schon munter an die 217.0.4.197 gesendet mit einem Source-Port von 15792.

Die DB macht daraus den Source-Port 53804, sollte sie eigentlich bei korrekter Einstellung nicht tun.

Dann beim eigentlichen 200 OK (Gesprächsannahme) benutzt und übermittelt deine PBX den Source-Port 16528.

Deswegen hörst du dein Fax auch nicht.

[#13]

@AHBohr 

Hat der Assistent eine ausgehende NAT-Regel in der DB angelegt?

[#14]

Ja hat er:

[#15]

@AHBohr 

Leider sehe ich im Bild die Schnittstelle nicht.

Welche Schnittstelle ist in den Regeln eingetragen?

[#16]

Da steht jeweils WAN_Telekom

[#17]

@AHBohr 

Die DB ist über den blauen LAN-Port mit dem Modem verbunden?

Wenn ja, solltest du den Eintrag VoIP-PBX im LAN löschen und mit en1-4 neu anlegen.

[#18]

Uff, ich war leider noch nicht vor Ort, aber es sieht tatsächlich für mich so aus als ob die am blauen Port hängt:

Ich probier das mal.

[#19]

Tatsächlich sieht es so aus:

[#20]

Hift allerdings nix:

[#21]

@AHBohr 

Du dürftest bei der Konfiguration VoIP-PBX im LAN, bei deiner Konfigurationsvariante, eigentlich gar kein en1-4 angezeigt bekommen.

Warum die DB den Quell-Port ändert verstehe ich nicht.

Müßte ich bei mir mal ausprobieren.

Das Problem mit dem falschen Quell-Port deiner PBX hast du immer noch.

Ich gehe davon aus, daß der Telekomserver diese Pakete einfach verwirft.

Daraus folgt, du als Anrufer hörst z.B. dein Fax nicht.

[#22]

@AHBohr 

Nutzt du in deiner PBX STUN?

Ich sehe gar keine STUN-Pakete.

Ich habe dein Szenario mal nachgebaut.

Ohne STUN funktionierts nicht.

In Ermangelung einer IP-PBX habe ich mit PhonerLite getestet.

[#23]

Nach allem was ich finden kann macht meine PBX (Starface Asterisk) kein STUN.

Nochmal für mein Verständnis.

1.: Ich werde angerufen, das Telekom "Dings" mit der IP 217.0.27.53 (1) lädt mich ein und sagt gleichzeitig ich möge mich doch mit einem zweiten "Dings" mit der IP 217.0.4.197 (2) unterhalten:

Dahin schickt meine PBX auch die Audiodaten (auf der WAN Seite kommt ausgehender Ton raus). Danach kommt ein "reinvite" vom "Dings" mit der IP 217.0.4.197 (3)mit der Aufforderung auf Port 16528 zu wechseln, welche meine PBX auch "acknowledged" (4). Das das klappt sehe ich daran dass die PBX mich ja hören kann (an der Lan seite kommt eingehender Ton raus)

Wie kommst du zu dem Schluss dass das Telekom "Dings" mit der 217.0.4.197 meinen RTP-Stream verwirft weil er den falschen Port hätte?

[#24]

@AHBohr 

- Dahin schickt meine PBX auch die Audiodaten (auf der WAN Seite kommt ausgehender Ton raus).

Nur weiß der Telekomserver von dem Source-Port nichts.

- Danach kommt ein "reinvite" vom "Dings" mit der IP 217.0.4.197 (3)mit der Aufforderung auf Port 16528 zu wechseln, welche meine PBX auch "acknowledged" (4). Das das klappt sehe ich daran dass die PBX mich ja hören kann (an der Lan seite kommt eingehender Ton raus)

Da kommt kein "reinvite".

Deine PBX nimmt das Gespräch mit 200 OK an und schreibt den Port 16528 in die SDP-Sektion.

Der Telekomserver erwartet die Audiodaten an 217.0.4.197 Port 46856.

Deine PBX sendet unmotiviert Audiodaten mit dem Source-Port 15792, den die DB auf Source-Port 53804 umsetzt.

Der Telekomserver verwirft jetzt diese Pakete, ist für mich auch logisch.

Jetzt nimmt deine PBX das Gespräch an (200 OK), der Port wird mit 16528 angegeben.

Deine PBX sendet aber weiter mit dem Source-Port 15792, den die DB wieder auf Source-Port 53804 umsetzt.

Von dem Port weiß der Telekom-Server nichts und verwirft die Pakete.

Deine PBX müßte STUN (Binding mit ihrem RTP-Port) machen, dann weiß sie welchen Port die DB ausgehend daraus macht, und den müßte sie in die SDP-Sektion eintragen.

[#25]

die Asterisk kann ohne Probleme STUN.

allerdings war das bisher bei mir noch nie nötig, nutze allerdings eine pfsense 

Dort musst nur Static Port angeklickt werden, das hat das remappen  des RTP Ports verhindert.

Das hat ich ganz am Anfang des Threads schon mal geschrieben,