IP-телефония в офисе: шлюз H.323 и приоритет голоса на коммутаторе

Когда клиент показал счёт от городской телефонной компании за межгород, разговор получился короткий: «сделайте что-нибудь». Счёт был внушительный - половина звонков уходила в другой город к партнёрам, и по обычным тарифам это накапало на серьёзную сумму. Мы предложили попробовать IP-транк через шлюз H.323. Провайдер, который давал им выделенку, как раз запустил такую услугу.

Что стоит на входе

Офисная АТС - небольшая Panasonic KX-TDA, аналоговые и цифровые порты, восемнадцать внутренних номеров. К ней через городскую линию подключены два городских номера. Всё работает годами, трогать не хочется - и не надо.

Идея простая: между АТС и интернетом ставим шлюз Cisco ATA 186. Этот маленький адаптер умеет брать аналоговый голос с одного конца и гнать его по H.323 с другого. АТС думает, что разговаривает с обычной телефонной линией. Провайдер думает, что принимает H.323-вызов. Шлюз переводит с языка на язык.

Регистрацию на гейткипере провайдера настроили по документации. Тут ничего хитрого - адрес гейткипера, логин, пароль, префиксы. Для исходящих межгородских вызовов на АТС прописали маршрут: номер начинается на 8-9хх - пускать через шлюз, а не через городскую линию. Городские вызовы идут как раньше.

Первый тестовый звонок прошёл. Качество - терпимое. Второй - хуже. Третий, когда сисадмин параллельно качал обновления по FTP, - уже откровенно плохой. Было понятно, что так дело не пойдёт.

Голос не терпит конкуренции

Голосовой трафик - штука требовательная. Ему не нужна большая полоса: один H.323-поток с кодеком G.711 занимает порядка 64-80 кбит/с в обе стороны. Проблема не в объёме, а во времени. Задержка пакета больше 150 миллисекунд - и собеседник слышит эхо или паузы. Потеря двух-трёх пакетов подряд - и в разговоре слышен характерный «глюк». Пока в сети тихо, всё в порядке. Стоит кому-то начать закачку - и пакеты с голосом стоят в той же очереди, что и большой файл.

Коммутатор на объекте стоял простой - неуправляемый D-Link на 24 порта. С ним сделать что-либо невозможно: он не понимает понятия «очередь» и «приоритет». Мы заменили его на управляемый - взяли Cisco Catalyst 2950. Недешёво, но без этого IP-телефония в такой сети просто не работает нормально.

На Catalyst 2950 настроили QoS. Смысл следующий.

Маркировка трафика. H.323-голос от шлюза Cisco ATA маркируется значением DSCP EF (Expedited Forwarding) - это специальный маркер, который говорит всему оборудованию на пути: этот пакет важный, пропусти вперёд.

Очередь приоритета. На выходном порту, который смотрит в сторону маршрутизатора и интернета, настроили очередь с приоритетом: трафик с меткой EF идёт вперёд всех. FTP-закачка подождёт, пока пройдут голосовые пакеты.

Ограничение полосы под голос. Чтобы голосовой поток не вытеснил всё остальное, задали потолок - не более двух параллельных вызовов через шлюз. Выше двух провайдер всё равно не давал, так что это скорее защита от аномалий.

После настройки QoS качество стало стабильным. Закачки шли, почта ходила, а голос не дрожал. Всё как надо.

Что не сработало сразу

Несколько вещей пришлось доделывать. АТС по умолчанию не знала, какие номера внутренние, а какие нужно слать через шлюз. Пришлось залезть в таблицы маршрутизации Panasonic и прописать диапазоны. Это не сложно, но документация у Panasonic написана так, что человек без привычки теряется страниц через двадцать.

Второй момент - NAT. Маршрутизатор у клиента делал трансляцию адресов, и H.323 с NAT исторически не дружат: протокол в теле пакета передаёт IP-адреса, и когда NAT их не подменяет, гейткипер провайдера видит приватный адрес и теряется. Пришлось включить H.323 ALG на маршрутизаторе - он умеет заглядывать внутрь протокола и подменять адреса правильно. После этого проблема ушла.

Третий момент - факс. Мы уже разбирались с IP-факсом раньше, и опыт пригодился: факсы через голосовой IP-транк ходят ненадёжно. G.711 с правильными настройками справляется, но гарантий нет. Факсовую линию оставили отдельно, через обычную аналоговую городскую - меньше проблем.

Итог

Выделенный канал с нормальным запасом полосы - необходимое условие, но не достаточное. Без управляемого коммутатора и QoS голос в общей сети ведёт себя непредсказуемо: то хорошо, то никак. Это не вопрос везения - это вопрос приоритетов в очередях, которые нужно явно задать.

Тем, кто думает о подобной интеграции АТС с IP-транком, стоит сразу закладывать в бюджет управляемый коммутатор. Экономия на железе здесь выходит боком - либо звонки плохие, либо разбираешься потом долго.

Клиент доволен. Счёт за межгород упал заметно. Правда, теперь звонят чаще - потому что дёшево.