Verstümmeltes VoIP über VPN, hauptsächlich auf Konferenzbrücken

1992
Hennes

Mein Büro verfügt über ein umfangreiches Cisco UCM-Setup. Ich arbeite hauptsächlich mit einem physischen Cisco 7940-Telefon entfernt. Ich habe schon einige Qualitätsprobleme gekämpft, was sich als schlechter Switch-Port herausstellte. Aber meistens ist meine Qualität seit Monaten in Ordnung. Kürzlich beklagen sich die Leute, dass meine Stimme ein und aus geht und sie mich nicht verstehen können. Ich verwende derzeit den G.729-Codec und alle meine Anrufe haben einen durchschnittlichen MOS-LQK von 3,68. Mein Telefon meldet kein RxLost, kein Jitter. Mein TxSize ist 20 ms, aber ich weiß nicht, wie sich dies auf die Audioübertragung auswirkt. Ich hatte noch nie Probleme mit dem Empfang von Audio.

Meine Verbindung zum UCM erfolgt über ein IPSec-VPN, das von einem ASA5505 zu einem ASA5580 gehandhabt wird. Der ASA5505 wird in mein Heimnetzwerk eingesteckt und dann über meinen Heimrouter auf das Internet zugegriffen. Mein Telefon wird an einen ASA5505-PoE-Port angeschlossen.

Bei Einzelgesprächen habe ich selten, wenn überhaupt, ein Problem gehabt. Die meisten Leute wissen nie, dass ich ein IP-Telefon habe. Bei internen Konferenzbrücken muss ich jedoch kürzlich von einer externen Leitung anrufen, um zu sprechen. Ich habe dieses Problem auch mit externen Brücken bei anderen Unternehmen erlebt, wenn ich ihre Besprechungen anrufe, aber seltener. Ich kann keine Korrelation finden, was passiert, wenn Probleme mit schlechter Qualität auftreten. Der Verkehr in meinem Heimnetzwerk ist fast nicht vorhanden. Ich habe ein anderes SIP-Internettelefon, das dieselbe Breitbandverbindung verwendet, aber meine Qualitätsprobleme treten unabhängig davon auf, ob das Telefon zur gleichen Zeit verwendet wird oder nicht.

Zuvor habe ich den Datenverkehr des ASA5505 überwacht und festgestellt, dass gekapseltes VoIP im Außensegment als Expedited Forwarding mit DSCP 46 gekennzeichnet wird (ich war überrascht, dass die IPSec-Pakete als solche gekennzeichnet wurden, aber unser VPN / Phone-Mitarbeiter hatte keine Ahnung, was DSCP war). Ich kann dies priorisieren (derzeit bin ich nicht), aber in der Vergangenheit hat es nicht geholfen. Hier ist der Vyatta-Konfigurationscode dafür:

qos-policy { traffic-shaper EXTERNAL_QOS { bandwidth 1mbit class 10 { bandwidth 90% description "Match VoIP traffic" match VOIP { ip { dscp 46 } } } default { bandwidth 5% } description "External bandwidth QoS Policy" } }

Kann ich der Gruppe, die das Telefon und den ASA verwaltet, etwas mitteilen, um sie bei der Lösung dieses Problems zu unterstützen? Bis jetzt weigern sie sich zu glauben, dass das Problem auf ihrer Seite liegt, nur dass, da es durch meinen Heimrouter läuft, ich schuld bin. Ich nehme an, sie gehen davon aus, dass ich ein paar Torrents laufen habe ...

2
Versuchen Sie, jemanden 1: 1 anzurufen, und lassen Sie ihn seine Informationen für den Anruf anzeigen. Der Rx Jitter / RxLost macht aus Ihrem PoV Sinn, weil Sie sie gut hören. Sie sollten jedoch etwas verloren auf ihrer Empfangsseite zeigen, wenn Sie sprechen. Am wichtigsten ist jedoch, dass Sie deren RxLost, RxJitter (avg / max) und das Feld, das die verstummten Sekunden anzeigt (ich denke, es ist ErrSec), an die ich mich nicht erinnern kann. Da dies nur bei Ihrem Outgoing geschieht, wage ich zu behaupten, es könnte Ihr Breitband sein (Consumer Broadband hat im Vergleich zum Download normalerweise einen schlechten Upload). Bist du auf DSL..Kabel ...? Sam vor 14 Jahren 0
Ich bin am Kabel. 10 MBit runter, 1 MBit hoch. Normalerweise bekomme ich diese Geschwindigkeiten, wenn ich einen Test mache, niemals unter 900kbps. Ich glaube auf meinem Telefon heißt es verborgene Sekunden. Ich muss morgen mit einem VoIP-Telefon jemanden anrufen, um diese Informationen zu erhalten, aber es macht Sinn. Ich habe auch QoS auf meinem Heimrouter für DSCP-46 aktiviert, aber wie gesagt, das hat vorher nicht geholfen. vor 14 Jahren 0
Gibt es Gründe, warum 1-zu-1-Anrufe gut klingen, aber Brücken sind schrecklich? Die Brücken befinden sich hauptsächlich auf einem älteren System in demselben Gebäude, in dem sich UCM befindet. Ich gehe davon aus, dass zwischen beiden eine analoge oder digitale Amtsleitung ist. vor 14 Jahren 0
Das Hochladen mit 900kBit sollte mehr als ausreichend sein, selbst wenn es festgefahren ist, können Sie mit G.729 umgehen. Hier ist etwas anderes, was ich tun würde - schauen Sie nach, ob Sie eine Stream-Obergrenze eines Anrufs sowohl an eine Konferenzbrücke als auch an eine andere Person erhalten können. Die Idee ist, den zugrunde liegenden Codec zu vergleichen, der ausgehandelt wird. WireShark sollte die RTP-Stream-Pakete gut decodieren (wenn Sie einen Monitor-Port oder einen Bridging-Computer einrichten können, um diese Pakete abzufangen). Ich denke, mit dieser Information wird jemand hier besser helfen. Und übrigens, das ist eine schlechte Nachricht, nicht zu wissen, was DSCP ist: / Sam vor 14 Jahren 0
9 von 10 Problemen mit der Anrufqualität, die wie aus dem Nichts auftauchen, werden in der Regel durch Geräte-Pack-Upgrades oder IOS / Firmware / DSP-Upgrades verursacht, die keine Codecs unterstützen. Vergleichen Sie in diesem Fall Ihre Geräteladen- / AppLoad-Nummern mit einer anderen Person, die ebenfalls keine Probleme hat (aber auf demselben Modelltelefon ist). Dies könnte auch dazu beitragen, es genauer zu bestimmen. Wenn diese Nummern nicht übereinstimmen, ist es möglich, dass Ihr Telefon nicht aktualisiert wurde. Sie können auch einen Werksreset in Betracht ziehen, obwohl ich nicht sicher bin, ob dies eine gute Idee ist, wenn Sie nicht arbeiten können, wenn etwas kaputt geht. Sam vor 14 Jahren 0
Das Problem kann auf die reduzierte MTU des VPN zurückzuführen sein. Wenn sich etwas zwischen Ihnen und dem Endpunkt befindet, der die mtu-Erkennung nicht ordnungsgemäß unterstützt, versucht er möglicherweise, zu große Pakete zu senden. Überprüfen Sie die Fähigkeit des Routers, die Pfad-mtu-Einstellung anzupassen. Majenko vor 13 Jahren 0

1 Antwort auf die Frage

0
stonefoz

Der einzige wirkliche Unterschied, den ich bei Konferenzgesprächen kenne, sind das Timing in der PBX und der Echounterdrücker.

Angenommen, die PBX funktioniert für alle anderen, habe ich zwei Vorschläge. Das Timing führt dazu, dass Frames fallen gelassen werden, Codec-Resets usw. zurückgesetzt werden. Echo kann Ihre abgehende Stimme stummschalten.

Versuchen Sie zu sehen, ob das Löschen von stillen Frames Timing-Probleme beheben kann. Es ist verschwenderisch, aber es versucht, ein Schaltkreissystem zu emulieren. Lassen Sie das Telefon jeden Frame senden, stumm oder nicht.

Was den Echo-Unterdrücker angeht, können Sie den Echo-Unterdrücker "train" nicht haben. Während eines Konferenzgesprächs wird Ihr Echo nicht zurückgesendet, während ein anderer Schaltkreis eine Stimme sendet. Deaktivieren Sie alle aggressiven Einstellungen auf Ihrer Seite. Die Konferenzbrücke führt wahrscheinlich bereits eine sehr aggressive Echokompensation durch. Verwenden Sie in diesem Zusammenhang das Freisprech-Telefon? Freisprechen erfordert auch eine aggressive Echokompensation.

Verwandte Probleme