Call Manager & Skype connect через CUBE

[@JDima]

Какая-то странная конфигурация дайл-пиров…
Входящую и исходящую ноги можно сделать на одном дайл-пире. Для этого одновременно делаем «destination-pattern» и «incoming called-number» на одинаковый паттерн. Например, для звонков в скайп достаточно (это сработает и входящей ногой для приема звонка от CCM):

dial-peer voice 30 voip
destination-pattern .T
incoming called-number .T
session protocol sipv2
session target dns:sip.skype.com
voice-class codec 1
dtmf-relay rtp-nte
no vad

и выкинуть 40.

Из короткого теста выяснилось, что звонки из skype доходят не все

Небось, 1ХХ не проходят за исключением тех, в вызываемом номере которых есть пара «8» на третьем с конца месте или раньше? Правильно в этих случаях: входящая нога — 10, а исходящая — 30, и у нас кольцо…
Так что для звонков от скайпа сделайте:

dial-peer voice 20 voip
destination-pattern ^[1,8]..$
incoming called-number ^[1,8]..$
session protocol sipv2
session target ipv4:ccm
voice-class codec 1
dtmf-relay rtp-nte
no vad

(если нужно ловить трехзначку, начинающуюся на 1 или 8 — я так и не понял, каким должен быть дайл-план)

Качество связи на 4.

Отключите торренты, или настройке QoS на канале в интернет :)

[@ufoton]

В диалпирах ошибка на копи — паст произошла. Исправил. По поводу количества пиров — мне так удобнее.

Звонки именно не доходят, нету пакетов.

По поводу качества это Ваши не подверждённые домыслы которые можно было опустить.

[@JDima]

Звонки именно не доходят, нету пакетов.

Уточню — нет INVITE на CUBE? Закономерность наблюдается?

По поводу качества это Ваши не подверждённые домыслы которые можно было опустить.

Наоборот — факт :) Вы представляете себе, какие кратковременные всплески способны давать сотни TCP соединений? Если не настроить исходящую приоритезацию или жесткие ограничения на торрент-клиенте — будет грустно. Еще и про входящую сторону стоит подумать, там то же самое. RTP пакеты неизбежно будут толкаться с TCP при скачке чего-либо, и даже при банальном браузинге.
И нет, эти пики невозможно зафиксировать средствами «show interface». Только сниффер.

Я на самом деле говорю об этом на основании личного опыта. Как дома, так и на работе в случае каналов до колл-центра. Пример: канал 30мб/с, средняя загрузка данными — 5мб/с, средняя загрузка голосом — 2мб/с, ощутимые потери голосового трафика по данным RTCP. Как только ставится приоритезация (или хотя бы полисер для TCP на 25мбит/с) — мгновенно потери пропадают.

[@ufoton]

Нет пакетов совсем от skype иногда. Без закономерностей.

Про QoS — поверьте не наш случай. Оценка 4 по моей шкале ценностей — это много. На этом предлагаю дискусию о qos закончить, а то придётся писать ещё одну статью.

[@JDima]

На этом предлагаю дискусию о qos закончить, а то придётся писать ещё одну статью.

Дык это же здорово!
На самом деле, QoS — важнейшая тема, когда мы говорим о голосе. Даже если голос этот приходит через интернет домой на единственную железку. Да и вообще, правильная настройка исходящего QoS позволяет запустить раздачу торрентов на десятке компьютеров через единственный 10мб/с канал, и при этом ни скайп, ни онлайн игрушки, ни HTTP закачка не будут страдать.