Подключение к провайдеру телефонной связи: проблемы и решения

• 23.08.2013
• 1857

Автор
Сергей Калашников, CCIE
Технический директор

Статья опубликована в сентябрьском номере «Журнал сетевых решений/LAN».

• Протокол SIP для телефонии
• Цифровой поток E1
• Аналоговые линии телефонии
• ЗАКЛЮЧЕНИЕ

Переход на новые более современные системы телефонной связи отчасти представляет собой дань моде и прогрессу, а отчасти вызван моральным устареванием имеющихся у заказчиков АТС и поддержкой ведущими производителями новых коммуникационных технологий. При этом внедряемые системы по сути уже не являются АТС — это скорее платформы для унифицированных коммуникаций, благодаря которым к традиционной телефонной связи добавляются новые варианты взаимодействия: обмен мгновенными сообщениями, видеозвонки, конференции различного рода и другие способы осуществления контактов. Тем не менее при всем многообразии коммуникаций обычный голосовой вызов остается пока основным видом связи, хотя в будущем данная ситуация должна измениться.

Любое внедрение новой системы унифицированных коммуникаций сопряжено с множеством проблем, обусловленных внутренними и внешними факторами. Проблемы внутреннего характера возникают в процессе интеграции нового решения в существующую ИТ-инфраструктуру и миграции пользователей на новую систему, а также в ходе их последующего обучения и адаптации к новой среде. Внешние проблемы появляются при интеграции новой системы унифицированных коммуникаций в общее телефонное пространство и организации ее связи с АТС других компаний. Так, чтобы иметь возможность совершать обычные звонки, систему необходимо подключить к телефонной сети общего пользования. Эта задача существенно осложняется широким выбором провайдеров телефонной связи и разнообразием технических вариантов подключения (от традиционных аналоговых линий или цифровых потоков E1 до набирающего популярность подключения посредством протокола SIP).

В данной статье будут рассмотрены трудности, возникающие при настройке внешних телефонных линий, и определены наименее проблемные типы линий связи. Приведенные данные базируются на практическом опыте и знаниях инженеров компании CBS, внедривших большое количество систем унифицированных коммуникаций.

Протокол SIP для телефонии

Прежде всего рассмотрим возможные проблемы, с которыми приходится сталкиваться при подключении к провайдерам телефонной связи или другим АТС по протоколу SIP. Протокол установления сеанса (Session Initiation Protocol, SIP) регламентирует процесс установления и завершения сеанса при обмене мультимедийным содержимым (аудио, видео и пр.). Данный сигнальный протокол описан в RFC и является кросс-платформенным. При этом следует заметить, что его реализация у каждого производителя может отличаться, в особенности когда речь идет о дополнительных функциях (постановка вызова на удержание, перевод звонка и пр.).

Такое расхождение обусловлено как наличием различных методов реализации одной и той же функции в стандартах SIP, так и их некорректной реализацией на самом оборудовании. Из-за этого при сопряжении устройств разных марок возникает ряд проблем, которые в общем случае можно разделить на следующие классы:

• проблемы с конфигурацией оборудования;
• проблемы с функионированием кодеков и их согласованием;
• проблемы с реализацией дополнительных функций (постановка на удержание, переключение и пр.);
• проблемы с маршрутизацией голосового трафика (сюда можно включить также прохождение голосового трафика через фильтрующие устройства МСЭ и прочие особенности);
• другие проблемы (все, что не попало в предыдущие классы).

Все типы проблем, которые рассматриваются в данной статье, проиллюстрированы на примере сопряжения системы унифицированных коммуникаций Cisco с оборудованием других производителей (Dialogic, Avaya, D-Link, Mera и пр.).

Вначале рассмотрим проблемы с конфигурацией (первый класс проблем). В голосовые шлюзы компании Cisco, начиная с IOS версии 15.0, по умолчанию включена функция Toll Fraud Protection для предотвращения их использования с целью совершения несанкционированных звонков. Данная функция была внедрена ввиду участившихся случаев взломов системы унифицированных коммуникаций, когда злоумышленник совершает через нее звонки на платные номера других стран через обнаруженные им открытые порты на телефонной станции. Чтобы функция Toll Fraud Protection работала, для всех соединений SIP необходимо предварительно указать адреса, с которых эти соединения можно инициировать. Проблема лишь в том, что многие об этом забывают и потом долго пытаются выяснить, почему блокируется входящая через SIP-транк связь.

Проблема согласования кодеков передачи голоса (второй класс проблем) возникает наиболее часто при сопряжении двух систем, причем она не зависит от используемого оборудования и проявляется, даже когда настраивается оборудование одного производителя. Это проявляется следующим образом: после прохождения запроса на установление соединения связь разрывается. Причина проста: каждая из сторон предлагает свой набор кодеков (G711 U-law или A-law, G729b, G729 и многие другие), которые могут полностью не совпадать. Согласование кодеков обычно происходит при обмене начальными сообщениями INVITE и OK протокола SIP (в зависимости от того, какой метод используется — SIP Early-Offer или SIP Delayed-Offer). Данная проблема решается либо установкой на обеих сторонах одинаковых кодеков, если это возможно, либо включением транскодирования (функции преобразования голосового потока из одного кодека в другой; ее можно реализовать, например, при помощи аппаратных процессоров DSP на маршрутизаторе).

Следует заметить, что эта проблема проявляется на различных стадиях настройки системы: во-первых, при инициировании звонка; во-вторых, при использовании автосекретаря, когда звуковой файл записывается в другом кодеке; и в-третьих, если систем несколько и звонок переводится из одной в другую. В последнем случае абонент дозванивается до удаленной стороны и получает сообщение о переводе звонка, но при нажатии ответившим абонентом на кнопку перевода (transfer) происходит разрыв соединения. Для диагностики достаточно запустить детальную трассировку сообщений SIP, из которых можно узнать как набор предлагаемых кодеков, так и причину разрыва соединения (в сообщении BYE).

Распространенной проблемой при объединении систем различных производителей является несовместимость некоторых дополнительных функций (третий класс проблем). Как уже упоминалось, протокол SIP пока не предусматривает строгого стандарта на реализацию некоторых из них, поэтому системы различных производителей зачастую «общаются на разных языках». Чаще всего это касается функций, выполняемых уже после установления соединения (перехват, удержание, перевод звонка — mid-call signaling). К примеру, при постановке вызова на удержание IP-АТС SIP-провайдера изменяет атрибут звонка с sendrecv на sendonly или inactive, в то время как IP-АТС компании использует атрибут адреса со значением 0.0.0.0.

Обе технологии описаны и разрешены в RFC. Однако любой входящий звонок, который секретарь пытается перевести на сотрудника, в результате обрывается, так как системы «не понимают» друг друга. Данный класс проблем решен в голосовом шлюзе Cisco UBE, начиная с IOS версии 15.2.1. Соответствующая функция получила название Mid-call Re-INVITE Consumption, она позволяет блокировать все сообщения о промежуточных состояниях звонка. Теперь IP-АТС провайдера просто «не информирует» об изменениях состояния звонка, а все операции выполняются корпоративной IP-АТС. Данная функциональность чрезвычайно полезна и зачастую является последним способом «подружить» разные системы. К сожалению, рассматриваемый релиз операционной системы Cisco IOS доступен для маршрутизаторов, начиная с серии 29xx.

При интеграции IP-АТС на базе Cisco Unified Communication Manager (CUCM) с программной АТС мы наблюдали еще одно проявление такого рода проблем. Внутренние вызовы между двумя АТС проходили, проблема же возникала при попытке перевести внешний звонок на пользователя программной АТС с установленной в ней платой Dialogic. Детальная трассировка вызова показала, что после поступления очередного сообщения INVITE, который отправлял CUCM после нажатия пользователем кнопки transfer для выполнения перевода вызова, программная АТС не отвечала и CUCM завершал вызов по тайм-ауту. В сообщении SIP предлагалось соединить внешний вызов с вызовом программной АТС, то есть осуществить перевод звонка и передать данные о новом IP-адресе и порте, с которого будет происходить передача голосовых пакетов.

Из-за невозможности проведения детальной диагностики на стороне программной АТС определить, почему Dialogic игнорировал определенные сообщения от CUCM, не удалось. Поэтому было реализовано обходное решение, суть которого заключалась в настройке единой точки терминирования голосового трафика (Media Termination Point, MTP) для данного направления вызовов. В этом случае переадресованные звонки осуществлялись через CUCM, то есть последний работал как некий посредник (proxy) для вызовов. Включение MTP решило проблему с переводом вызовов между системами.

Четвертый класс проблем чаще всего проявляется в виде односторонней слышимости при совершении звонка, то есть только один абонент слышит другого. Причин тому несколько. Во-первых, могут отсутствовать маршруты к определенным подсетям. В этой связи стоит отметить, что различные системы нередко передают голосовой трафик по-разному. В общем случае он идет напрямую от абонента к абоненту (например, при использовании IP-телефонов), а в остальных случаях (что справедливо, например, для системы CUCMe при совершении звонков за ее пределы) проходит через IP-АТС. Поскольку в распределенных системах IP-телефоны могут находиться в различных сетях, проверить прямую маршрутизацию голосового трафика между всеми телефонами достаточно сложно.

Второй причиной может быть отсутствие разрешающих правил на межсетевом экране (МСЭ), через который проходит голосовой трафик. Помимо этого, на голосовых шлюзах Cisco может быть неправильно выбран исходящий интерфейс для сигнального и голосового трафика. Производитель оборудования настойчиво рекомендует вручную указывать интерфейсы, с которых будет отправляться голосовой трафик (настроить так называемый bind). Причем если в старых версиях программного обеспечения маршрутизаторов Cisco это можно было сделать только для всех звонков сразу, что не всегда было удобно, то в новых появилась возможность указать интерфейс для каждого направления вызова.

Цифровой поток E1

Цифровой поток E1 представляет еще один тип внешних линий, через которые можно осуществить сопряжение двух разных систем. Многие заказчики воспринимают данный тип связи как некий эталон: по одному кабелю можно организовать до 30 соединений одновременно, при этом качество связи не зависит от интернет-канала, в отличие от SIP-транков. Вместе с тем пропускная способность интернет-каналов, особенно в крупных городах, стала вполне достаточной, поэтому сопряжение через SIP-транки по качеству звука не уступает, а иногда и превосходит цифровые линии E1. Поскольку цифровой поток E1 используется уже на протяжении долгих лет, многие ранее встречавшиеся трудности при сопряжении оборудования уже неактуальны и настройка данного типа соединений проходит, как правило, без особых сложностей. Но иногда «заминки» все же случаются, и на их решение приходится тратить немало времени и сил.

При настройке E1 у одного из заказчиков возникла следующая интересная ситуация. Исходящие вызовы через порт E1 работали, а входящие — нет: для последних соединение устанавливалось, но абоненты друг друга не слышали. Такая ситуация типична скорее для соединений SIP, нежели для E1. После проведения детальной диагностики удалось выяснить, что проблема кроется в аппаратной части и связана с процессорами DSP, которые как раз и отвечают за обработку голоса. Поэтому было принято решение извлечь и заново установить модуль E1 в маршрутизатор Cisco, чтобы полностью «обнулить» ресурсы DSP, выделенные данному модулю. Перезагрузка маршрутизатора в таком случае не помогает, так как переопределения выделенных ресурсов DSP не происходит. После повторной установки модуля двусторонняя слышимость появилась.

При интеграции IP-АТС с существующими телефонными системами нередко возникает необходимость в сложной маршрутизации звонков через несколько голосовых шлюзов — к примеру, из E1 в SIP или H.323 и затем обратно в E1. В процессе перекодирования часть сообщений из потока E1 в другой протокол может исказиться, что приводит к сбоям в работе некоторых функций. По этой причине передачу сообщений E1 рекомендуется настроить таким образом, чтобы они не преобразовывались внутри голосового сигнального протокола SIP или H.323.

Некорректное функционирование потока E1 также может быть связано с отсутствием заземления оборудования. Каждый производитель в своей документации настоятельно рекомендует выполнять данную процедуру, но на практике это делается далеко не всегда. Тем не менее полная или частичная неработоспособность E1 (периодическое отсутствие соединения) может быть связана именно с заземлением. Поэтому, если после всех проверок выяснится, что та или иная проблема все еще имеет место, стоит попробовать провести заземление оборудования.

Аналоговые линии телефонии

Несмотря на распространение цифровых технологий, до сих пор подключение к провайдеру телефонной связи нередко осуществляется по обычным аналоговым линиям. Такой вариант актуален хотя бы потому, что многие компании используют их с давних времен и не хотят отказываться от привычного городского номера при смене АТС.

Какие же проблемы характерны для данных типов линий? Типичная проблема — «зависание» аналоговой линии. Она проявляется в том, что телекоммуникационная система не может определить момент, когда абонент на удаленной стороне «повесил» трубку, и поэтому считает, что аналоговая линия занята. Чаще всего данная ситуация возникает, когда на портах АТС настроены различные региональные параметры акустических и вызывных сигналов (тона, звонка и пр.): например, с одной стороны настроены параметры для России, а с другой — для Америки.

Данную проблему можно попытаться решить двумя способами: установкой отбойников и более тонкой настройкой различных параметров на аналоговом порту. К сожалению, оба варианта не гарантируют решения проблемы. При этом реализация второго варианта достаточно трудоемка, так как предполагает поочередное варьирование различных настроек порта (тип сигнализации и настройки тональных сигналов) до тех пор, пока проблема не исчезнет. Как показывает практика, провайдер может в лучшем случае лишь сообщить, какой регион указан в его настройках. Кроме того, данная проблема часто встречается, когда автосекретарь обрабатывает вызов, входящий с порта FXO.

Помимо «зависания» приходилось сталкиваться и с проблемой передачи сигналов DTMF через аналоговую линию. DTMF — это метод передачи дополнительных цифр внутри установленного голосового соединения. Обычно он используется в автосекретарях, когда требуется донабрать внутренний номер. Решить данную проблему можно, варьируя параметры передачи сигналов DTMF. Однако в случае, с которым столкнулись специалисты CBS, потребовалось заменить оборудование, так как исходное оказалось несовместимым.

Как это ни удивительно, но проблемы сопряжения возникали и при соединении двух устройств Cisco через аналоговые порты. С обеих сторон находились маршрутизаторы Cisco с аналоговыми портами FXO и FXS, но после их подключения установить голосовое соединение не удавалось. С учетом того что в различных версиях программного обеспечения возможна различная реализация той или иной технологии, было принято решение выравнять версии операционных систем на обоих устройствах. После обновления одной из операционных систем все заработало. Тем не менее, этот инцидент показывает, что связность по аналоговым линиям не гарантируется даже при использовании оборудования от одного производителя.

ЗАКЛЮЧЕНИЕ

Следует отметить, что проблемы могут возникать на любых типах линий, даже при аналоговом подключении. Однако в случае использования протокола SIP неполадок, как правило, больше, чем при подключении через E1. При возникновении той или иной трудности следует в первую очередь выявить функцию, которая не работает, и провести в ее отношении детальную диагностику.

1. Implementing Cisco Unified Communications Manager, Part 1
2. Implementing Cisco Unified Communications Manager, Part 2