Выбор кодека Asterisk и VOIP телефонии. Расчет скорости интернета для телефонии

Самым приличным обычно считается кодек G.711 a-Law. Он позволяет добиться высокого качества звука, через него работают факсы.  

Информация о кодеке

Расчет пропускной способности

Codec & Bit Rate (Kbps)

Codec Sample Size (Bytes)

Codec Sample Interval (ms)

Mean Opinion Score (MOS)

Voice Payload Size (Bytes)

Voice Payload Size (ms)

Packets Per Second (PPS)

Bandwidth MP or FRF.12 (Kbps)

Bandwidth w/cRTP MP or FRF.12 (Kbps)

Bandwidth Ethernet (Kbps)

G.711 (64 Kbps)

80 Bytes

10 ms

4.1

160 Bytes

20 ms

50

82.8 Kbps

67.6 Kbps

87.2 Kbps

G.729 (8 Kbps)

10 Bytes

10 ms

3.92

20 Bytes

20 ms

50

26.8 Kbps

11.6 Kbps

31.2 Kbps

G.723.1 (6.3 Kbps)

24 Bytes

30 ms

3.9

24 Bytes

30 ms

33.3

18.9 Kbps

8.8 Kbps

21.9 Kbps

G.723.1 (5.3 Kbps)

20 Bytes

30 ms

3.8

20 Bytes

30 ms

33.3

17.9 Kbps

7.7 Kbps

20.8 Kbps

G.726 (32 Kbps)

20 Bytes

5 ms

3.85

80 Bytes

20 ms

50

50.8 Kbps

35.6 Kbps

55.2 Kbps

G.726 (24 Kbps)

15 Bytes

5 ms

 

60 Bytes

20 ms

50

42.8 Kbps

27.6 Kbps

47.2 Kbps

G.728 (16 Kbps)

10 Bytes

5 ms

3.61

60 Bytes

30 ms

33.3

28.5 Kbps

18.4 Kbps

31.5 Kbps

 

Как видно из таблицы, для гарантированной качественной связи, необходима пропускная способность канала в 87.2 Kbps x 2 = 174.4 Kbps. Также если оконечное оборудование sip телефонии работает в общей локальной сети, т.е. используется общий канал доступа в интернет sip телефонии c другими видами трафика, рекомендуется зарезервировать фиксированную полосу пропускания  канала, внутри локальной сети, для sip телефонии, либо (если нет возможности зарезервировать) выделить отдельный канал доступа, из расчета 174.4 Kbps x n (где n – количество телефонных каналов).

Данные о качестве звука и влиянии на него кодеков

Наиболее известной методикой оценки качества систем IP-телефонии яыляется MOS.  MOS (Mean Opinion Score или "усредненная субъективная оценка экспертов"), представляет собой численную оценку, характеризующую "качество" сети телефонии. Идея MOS очень проста: специально сформированной группе людей предоставляют возможность воспользоваться системой связи и просят поставить оценку от 1 (ужасно) до 5 (отлично). Усредненные данные такого исследования и называются MOS. Кроме того, для оценки качества речи также существуют и объективные методы, например, рекомендация ITU-T G.113 (измерение качества речи системы телефонии на основе искажений, вносимых каждым ее элементом), PSQM (оценка качества работы вокодеров), PESQ (развитие PSQM для оценки сетей телефонии). Не вдаваясь в детали методов оценки качества, давайте лучше рассмотрим основные параметры, оказывающие на него непосредственное влияние: 

 

 используемый кодек;
 наличие/отсутствие "эха";
 параметры каналов связи. 


 Все используемые на данный момент в IP-телефонии кодеки обеспечивают "сжатие с потерями". В зависимости от используемых алгоритмов эти "потери" могут быть по-разному различимы "на слух" именно в этом аспекте рассматривается влияние кодеков на качество речи.

 При ведении разговоров на больших расстояниях начинает проявляться эффект "эха". Существуют различные алгоритмы, призванные с этим бороться (G.165, G.168, G.168 2000, и др.), и в подавляющем большинстве устройств какой-нибудь из них обязательно должен присутствовать.

На качество систем телефонии оказывает воздействие три основных параметра канала связи:

 

Задержка (latency). При передаче голоса или видео существуют определенные требования к максимально допустимой задержке. Различные исследования показывают, что для ведения нормального диалога необходимо, чтобы "двойная задержка" при передаче голоса не превышала 250-300 мс (бюджет задержки). При превышении этого порога участники начинают испытывать дискомфорт и стремятся закончить разговор. Таким образом, для ведения комфортного разговора односторонняя задержка не должна превышать 150 мс (задержка канала + алгоритмическая задержка кодека), что совпадает с рекомендацией ITU-T G.114. Для уменьшения задержки, вносимой сетью, необходимо использовать QoS (Quality of Service)  
Джиттер (jitter). Ethernet является сетью с коммутацией пакетов. В общем случае это означает, что пакеты могут быть получены клиентом не в том порядке, в каком они были ему отправлены (для доставки пакетов могли использоваться различные маршруты). Что в таком случае делать декодеру? Для решения таких проблем используются специальные "jitter buffers" (сглаживающий буфер). Задачей этих буферов является предварительное накопление пакетов перед их дальнейшей передачей декодеру. Очевидно, что буфер дрожания также вносит некоторую задержку в процесс передачи голоса, поэтому желательным является использование такого размера буфера дрожания, которое, с одной стороны, обеспечивает приемлемое качество речи, а с другой – минимизирует общее значение бюджета двусторонней задержки до значения 300 мс.  
Потеря пакетов. Как известно, в сетях Ethernet допускается потеря пакетов. Влияние потери пакетов на качество речи определяется размером пакета, а также используемым алгоритмом сжатия речи. Речевая информация в большей степени устойчива к пропаже одиночных пакетов, нежели целых серий. В любом случае, согласно рекомендации ITU-T, для нормальной работы систем IP-телефонии допускается потеря не более 1% пакетов, в противном случае ухудшение качества речи будет заметно. Для улучшения качества в условиях загруженных сетей можно использовать QoS либо, если пакеты теряются из-за природы самой сети (например, беспроводная сеть), то для улучшения качества можно использовать более помехоустойчивый кодек или уменьшать размер кодируемого кадра.

 

Замечания по передаче факсов

(по материалам базы знаний asterisk.ru)

 

Передача факсов через VoIP-сети не работает. Иногда у вас получится достичь достаточно высокого процента успешных передач факсов. Может случиться, что вы создадите такую установку, которая будет работать на 100% всё время своего существования. Это редкие, неповторимые установки. Вам необходимо использовать правильный протокол FAX over IP, такой, как например Т.38, чтобы достичь постоянного, надёжного результата передачи факсов через IP-сети.

 

Для скептиков


Вы не верите, что передача факсов через VoIP-протоколы не работает? Вы слышали, что всё прекрасно работает если использовать кодеки рекомендации G.711? Читайте далее, если вы хотите понять, почему всё намного сложнее, и проблематичнее, чем этот подход.

 

Пытаясь ужиться с передачей факсов через VoIP-сети…


Передача факсов через VoIP-сети обычно заканчивается неудачей. В природе человека – искать простые объяснения этому, и простые решения. В реальности же, всегда есть много причин, и полное отсутствие простых универсальных решений. VoIP-сети были разработаны чтобы отлично работать с голосом. Передача любого другого звука, отличного от речи, не является главным требованием к системе VoIP-связи. Естественно, не надо удивляться, что такие передачи работают из рук вон плохо.

Не получится налить кварту в пинту


Наиболее распространённая проблема при передачи факсов через VoIP-сети – это самая простая из решаемых. Речевые кодеки с низкой скоростью передачи данных не могут передавать быстрые модемные сигналы без грубейшего их искажения. Неужели вы ожидаете, что G.729 8 кбит/с кодек сможет без искажений передать сигнал модема факса скорости 9.6 кбит/с? Если да, то, скорее всего, вы верите в вечный двигатель, и так далее. Я бы смог вам предложить неплохую сделку по этому поводу, если вы согласитесь купить Лондонский мост (London Bridge – прим. перевод.). Единственные широко поддерживаемые кодеки, которые могут адекватно сохранить сигналы модема факса до 14,4 бод (V.17) – это G.711 u-закон и A-закон. Полная версия G.726 кодека также будет работать с сигналом факса до 9,6 бод. Хотя не все устройства, которые рекламируются с поддержкой G.726, будет действительно поддерживать эту спецификацию. Несколько быстрых переходов в коде программы кодека могут значительно сократить вычислительные издержки, и всего лишь небольшому числу людей нужна полная поддержка G.726. Поэтому результаты на разных устройствах могут отличаться. Как бы то ни было, G.726 кодек был специально разработан для передачи среднескоростных сигналов модемов, таких как протокол V.29 на котором работает факс.

Совсем недавно стали популярными факс-аппараты с поддержкой скорости передачи до 33,6 кбит/с (V.34bis). Эта скорость передачи вряд ли будет надёжно работать через любое VoIP-соединение, даже если используются кодеки G.711 A-закон или u-закон. Кодеки смогут обеспечить требуемое качество сигнала, но задержки в VoIP-канале, даже если они будут стабильными, не дадут эхокомпенсаторам в любом факс-модеме возможности обучиться до нужного предела. Более медленные модемы факсов – V.27ter, V.29 и V.17 не используют эхокомпенсации, поэтому данной проблемы с ними не возникает.

Низкоскоростные кодеки имеют нулевой шанс нормально передать любое стандартное факс-сообщение. Некоторые кодеки без проблем передадут через канал контрольные сообщения факса в 300 бит/с (V.21). Но они не смогут передать быстрые сигналы модемов, непосредственно несущие информацию о передаваемом сообщении.

 

Модемам не нравится относительность


В мире ТфОП, коммутированная сеть имеет конечное значение задержки для каждого конкретного звонка. Скорость, с которой данные попадают в сеть, всегда равна скорости, с которой они её покидают. Задержка между концами канала не имеет дрожаний фаз (jitter – прим. перевод.), и не изменяется пошагово в любой из своих характеристик, за исключением вынужденных обстоятельств (например переход на обходные маршруты, если часть канала, до этого проходившая через оптоволокно, вдруг оборвалась). Эти характеристики каналов требуются модемам, они были разработаны для них. В IP-сетях дрожания это просто факт, от которого никуда не уйти. Дрожание можно свести до допустимого предела, используя приоритезацию (QoS) трафика, поддерживаемую большинством IP-оборудования, но только если вы можете контролировать сеть от начала и до конца. Если же звонок проходит через публичную часть сети Internet, там нет QoS-а. С трудом можно представить себе бизнес-модель оператора связи, который бы ввёл бы QoS на публичной части сети. Поэтому, при первом приближении, временные характеристики голоса, входящего в VoIP-сеть, такие же, как на выходе, но при детальном рассмотрении они могут быть очень и очень разными.

Если VoIP-сеть работает через локальную сеть или через WAN-соединение с включенным QoS-ом, вы можете достичь близкую к нулю вероятность потери пакетов, и очень, очень низкое значение дрожаний. Далее, многие полагают, что буфер на приёмном конце канала будет смягчать влияния средних по величине дрожаний, поэтому сигнал на выходе VoIP-канала будет прекрасно восстанавливаться в оригинальный. Чаще всего, эти люди будут правы. Но никаких гарантий. Есть много различных конструкций буфера дрожаний. Много современных вариантов динамически адаптируют длину буфера тем или иным способом, тем или иным алгоритмом. Если дрожание невелико, динамическая буферизация отключается, и вся система работает хорошо. Если динамическое управление буфером нельзя отключить, его поведение может, в общем-то, значительно ухудшить качество восстановления сигнала модема. Различные алгоритмы будут:

Гарантированно терять пакеты, настраивая буферизацию до такого предела, когда некоторый постоянный процент пакетов не будут считаться поздними, и будут отбрасываться. Потеря пакетов обычно встраивается в такие алгоритмы, и результаты могут быть вполне приемлемыми для голоса. Это вполне резонный обмен: терять небольшое количество пакетов, и взамен иметь нечто менее подверженное задержкам.
Регулировать периоды тишины во всех отсчётах пакетов (обычно по 20 мс). В спецификации факса, некоторые периоды тишины определены значениями 75+-20мс. Периоды в 20мс могут сбить их с толку.
Постоянно регулировать временные характеристики вне периодов тишины, используя техники наложения краёв и смешения. Этот подход считается произведением искусства для речевых буферов, и при этом – полной катастрофой для модема факса…

По закону подлости, самое простое оборудование будет почти наверняка хорошо работать, а более новые и более сложные разработки почти наверняка доставят кучу хлопот. 

 

Модемы не любят подавление тишины


В зависимости от реализации в том или ином оборудовании, подавление тишины может полностью уничтожить звонок с факсом. Если подавление тишины включено, детектор голоса постоянно проверяет звонок, пытаясь обнаружить наличие голоса – т.е. сигналов модема. Некоторые из них были разработаны таким образом, чтобы фокусироваться на речевом сигнале, и отбрасывать все посторонние шумы – в нашем случае тоны модема факса. Поэтому, эти детекторы могут недоброкачественно включать и выключать аудио-нагрузку когда модем факса начинает и заканчивает передачу. И если даже они качественно переключаются, алгоритмы подавления тишины обычно сильно искажают сигналы уровни которых находятся около пороговых отметок.

Во время периодов тишины, в аудио-нагрузку постоянно вносится "комфортный шум", который симулирует нормальную обстановку, которую вы слышите во время привычного звонка через ТфОП. Это означает, что период, который обычно будет полон тишины (факсы передают сгенерированные сигналы, то есть нет внешних шумов), будут сильно зашумлены. Модем на приёмной стороне может не увидеть достаточно чёткой "тишины" чтобы корректно определять границы сигналов модема передающего факса.

 

Модемы любят полное общение


Модемам требуется полноценный канал аудио. Если внести в него потерю пакетов, последствия будут суровыми, но реальный эффект будет зависеть в основном от оборудования, которое вы используете. Предположим, пакет в 20мс теряется в середине страницы факса. Понятно, что эта потеря приведёт к утрате какой-то части передаваемого изображения, но будет ли это влиять на передачу небольшого отрезка, или всего остатка страницы? Если приёмная сторона VoIP-канала вставляет 20 мс тишины, приёмный модем факса почти наверняка воспримет эти 20 мс как конце страницы. Если приёмная сторона вставляет 20 мс какого-то шума или звука, приёмный модем факса наверняка сможет перейти через разрыв в приёме. Всё зависит от конкретного оборудования. Если приёмная сторожа вставляет больше или меньше чем 20 мс какого-то шума, понятно, что остаток страницы будет принят с искажениями.

данные с сайта http://sip-melt.ru/trafik_i_kodeki/

+ Нет комментариев

Добавить свой