Искаженный VoIP через VPN, в основном на конференц-мостах
1791
Hennes
В моем офисе установлена большая Cisco UCM, и я работаю в основном удаленно с физическим телефоном Cisco 7940. Ранее я боролся с некоторыми проблемами с качеством, которые оказались плохим портом коммутатора. Но в основном мое качество было хорошо в течение нескольких месяцев. В последнее время люди жалуются на то, что мой голос прерывается, и они не могут меня понять. В настоящее время я использую кодек G.729, и все мои звонки имеют среднюю MOS LQK 3,68. Мой телефон сообщает об отсутствии RxLost, нет дрожания. Мой TxSize составляет 20 мс, но я не знаю, как это влияет на передачу звука. У меня никогда не было проблем с получением аудио.
Мое соединение с UCM осуществляется через IPSec VPN, который обрабатывается ASA5505 и ASA5580. ASA5505 подключается к моей домашней сети, а затем через мой домашний маршрутизатор подключается к Интернету. Мой телефон подключается к порту PoE ASA5505.
Во время разговоров один на один у меня редко возникали проблемы. Большинство людей никогда не знают, что я нахожусь на IP-телефоне. Однако из-за внутренних мостов для конференций мне недавно пришлось звонить с внешней линии, чтобы говорить. Я также испытывал эту проблему с внешними мостами в других компаниях, когда я звонил на их встречи, но реже. Я не могу найти никакой корреляции того, что может происходить, когда возникают проблемы с низким качеством. Трафик в моей домашней сети практически отсутствует. У меня есть другой SIP интернет-телефон, использующий такое же широкополосное соединение, но мои проблемы с качеством возникают независимо от того, используется ли этот телефон одновременно или нет.
Ранее я отслеживал трафик от ASA5505 и заметил, что он помечает инкапсулированный VoIP на внешнем сегменте как ускоренную пересылку с помощью DSCP 46 (я также удивился, что пакеты IPSec были помечены так, как это, но наш парень из VPN / Phone понятия не имел, что такое DSCP). Я могу расставить приоритеты (в настоящее время нет), но в прошлом это не помогло. Ниже приведен код конфигурации Vyatta для этого:
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" } }
Что я могу сказать группе, которая управляет телефоном и ASA, чтобы помочь им решить эту проблему? На данный момент они отказываются верить, что проблема на их стороне, только потому, что она проходит через мой домашний маршрутизатор, я виноват. Я предполагаю, что они предполагают, что у меня работает куча торрентов ...
Попробуйте позвонить кому-нибудь 1-к-1 и попросите его собрать информацию для разговора. Rx Jitter / RxLost имеет смысл с вашей точки зрения, потому что вы хорошо их слышите. Они, однако, должны показать некоторые потерянные на их стороне Rx, когда вы говорите. Самое главное, что вы хотите знать их RxLost, RxJitter (avg / max) и поле, в котором отображаются секунды с глушителем (я думаю, что это ErrSec), я не могу вспомнить. Поскольку это происходит только на исходящем, я бы сказал, что это может быть ваша широкополосная связь (потребительская широкополосная связь обычно имеет плохую загрузку по сравнению с загрузкой). Вы на DSL .. Кабель ...?
Sam 14 лет назад
0
Я на кабеле. 10 Мбит вниз, 1 Мбит вверх. Обычно я получаю эти скорости при тестировании, никогда не опускаясь ниже 900 кбит / с. Я думаю, что на моем телефоне это называется скрытые секунды. Мне нужно будет позвонить кому-нибудь завтра с VoIP-телефоном, чтобы получить эту информацию, но это имеет смысл. Я также включил QoS на своем домашнем маршрутизаторе для DSCP-46, но, как я уже сказал, это не помогло раньше.
14 лет назад
0
Любая причина, почему звонки 1-к-1 звучат хорошо, но мосты ужасны? Мосты находятся в основном в старой системе в том же здании, где находится UCM. Я предполагаю, что между ними есть какая-то аналоговая или цифровая магистраль.
14 лет назад
0
Загрузка 900 кбит должна быть более чем достаточной, даже если она застрянет, вы можете справиться с G.729. Вот еще кое-что, что я хотел бы сделать - посмотреть, сможете ли вы получить ограничение потока телефонных звонков как на конференц-мост, так и на другого человека. Идея будет состоять в том, чтобы сравнить базовый кодек, который согласован. WireShark должен правильно декодировать пакеты RTP-потока (если вы можете настроить порт монитора или мостовой компьютер, чтобы вы могли перехватывать эти пакеты). Я думаю, что с этой информацией кто-то здесь будет лучше помочь. И между прочим, это плохие новости о незнании того, что такое DSCP: /
Sam 14 лет назад
0
9 раз из 10 проблем с качеством звонков, которые возникают, как эта неожиданно, как правило, вызваны обновлениями пакета устройств или обновлениями IOS / firmware / DSP, которые не поддерживают кодеки. На этой ноте сравните ваши номера загрузки устройства / загрузки приложения с кем-то, у кого тоже нет проблем (но на телефоне той же модели). Это также может помочь определить это дальше. Если эти цифры не совпадают, возможно, ваш телефон не обновился. Вы также можете рассмотреть возможность восстановления заводских настроек, хотя я не уверен, что это хорошая идея, если вы не можете приступить к работе, если она что-то сломает.
Sam 14 лет назад
0
Проблема может быть связана с уменьшенным MTU VPN. Если между вами и конечной точкой, которая должным образом не поддерживает обнаружение mtu, есть что-то, возможно, он пытается отправить слишком большие пакеты. Проверьте способность маршрутизатора настроить параметр path-mtu.
Majenko 13 лет назад
0
1 ответ на вопрос
0
stonefoz
Единственное реальное отличие, которое я знаю о конференц-связи, - это синхронизация в АТС и эхоподавитель.
Предполагая, что АТС работает для всех остальных, у меня есть два предложения. Синхронизация может привести к пропаданию кадров, сбросу кодека и т. Д. Эхо может отключить ваш исходящий голос.
Попробуйте убедиться, что не пропуская тихие кадры, исправит проблемы с синхронизацией Это расточительно, но оно пытается эмулировать систему коммутации цепей. Пусть телефон отправит каждый кадр, беззвучный или нет.
Что касается эхоподавителя, ваша сторона не сможет иметь его «поезд» эхоподавителя. во время конференц-связи ваше эхо не будет отправлено обратно, в то время как другой канал делает голос. Отключите любые агрессивные настройки на вашей стороне, конференц-мост, вероятно, уже делает очень агрессивное подавление эха. На этой ноте вы используете громкую связь? Динамик-телефон также требует агрессивного эхоподавления.