Главная страница \ Статьи \ Метод проб и ошибок \ Локальные сети \ Panasonic NCP-500 и два SIP провайдера

Panasonic NCP-500 и два SIP провайдера

У нас в офисе установлена АТС Panasonic NCP-500, четыре входящих городских, восемь аналоговых, 8 SIP-транков и 32 SIP-абонента. Всё было хорошо, городские линии работали отлично, внутренние абоненты могли разговаривать друг с другом...

Понадобилось нам подключиться так сказать к общей телефонной сети. И вот тут начались "недокументированные" проблемы.

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

После этого все восемь SIP-транков были настроены на взаимодействие с общей сеть, первый транк - основным, остальные - дополнительными к основному каналами. Всё завелось.

Но, через какое-то время, офис был подключен к другому провайдеру телефонии, который эту самую телефонию раздаёт SIP-транком. И вот на этом месте начинается всё самое интересное. Первый три транка так и остались для внутренней телефонии, а оставшиеся пять были отданы внешнему провайдеру.

Для получения телефонии от провайдера, последний выдаёт нам белый IP-адрес, который должен смотреть в сторону нашей АТС. При этом, наша АТС должна ещё уметь работать с внутренней общей телефонией. Итого, в идеале, у АТС должно быть два адреса: 10.0.0.1 и 200.0.0.1. Только проблема в том, что у АТС предусмотрен только один IP адрес.

Благо - АТС подключена через маршрутизатор, который и обзавёлся белым адресом с безусловным пробросом всех портов на АТС. Только теперь встала другая проблема: односторонняя слышимость. Что говорят в офисе абонент, звонящий снаружи, слышит, а что он говорит - нет.

Начали разбираться... Дошли до перехвата пакетов соединения WireShark'ом, который показал, что АТС, само собой, провайдеру отдаёт свой внутренний IP 10.0.0.1, по которому АТС провайдера, естественно, никак не может достучаться до нашей АТС.

Что делать? Поменять IP нельзя, т.к. та же проблема произойдёт с внутренней сетью телефонии, которой будет отдаваться белый адрес.

Естественно, решение было найдено. Использовать STUN-сервера. Для соединений, который смотрят в сторону провайдера была установлена настройка STUN-сервера, который разрешает внутренний адрес во внешний и всё завелось!

Радость была не долгой, т.к. в течение недели выяснилось, что теперь все звонки, приходящие из внутренней сети телефонии проходят по маршруту распределения входящего вызова не внутреннего провайдера, а внешнего. Я подключился к SMDR консоли и стал наблюдать. Итак. Напомню, первый три транка смотрят в сторону внутренней телефонии, остальные пять - наружу. При этом, когда приходит звонок из внутренней сети, АТС, судя по логу SMDR, уверена, что он приходит строго с восьмого транка, т.е. с транка внешнего провайдера. И соответственно применяются правила распределения входящего вызова для восьмого транка. В итоге в офисе на все входящие из внутренней сети звонит один единственный телефон.

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

Пятничным вечером, от нечего делать, решил поиграться с АТС. Начал поочерёдно выключать транки АТС. Сначала сверху вниз - ничего не изменилось, звонит строго восьмой транк... А потом снизу вверх... И вот тут началось: при отключении восьмого транка, звонок "приходил" с седьмого, при отключении восьмого и седьмого - с шестого и так далее, пока не были выключены все транки внешнего провайдера и внутренняя телефония не заработала "как положено". При включении транков провайдера проблема снова вылезала: "звонящим" становился последний транк, с самым большим номером.

К сожалению, побороть эту проблему так и не удалось какими-либо настройками или перезагрузками системы. В итоге просто поменял местами провайдеров, что внутренний провайдер стал 6,7,8 транками, а внешний первыми пятью - и всё замечательно заработало.

Такая вот интересная особенность вылезла при настройке АТС Panasonic NCP-500 на работу с двумя SIP-провайдерами.

Вопросы? Предложения?

Spider [07.09.2015]
Однако, проблема с распределением звонков по номерам SIP-транков не решается только лишь настройкой маршрутизатора. АТС не знает - с какого из SIP-транков приходит конкретный звонок, поэтому кидает звонок либо на самый старший из доступных, либо на самый младший - это настраивается в АТС. Есть ещё настройка, при которой транк определяется по абонентскому номеру, закреплённому за данным SIP-транком. Для настройки данной системы требуется знания, получаемые от техподдержки производителя (Панасоника). Техподдержка доступна авторизованным установщиком (обучение-экзамен-доступ). Выход - пройти обучение, или найти авторизованного по IP-АТС специалиста, который знает, где крутить настройки. "Консультации с местными специалистами" говорят о низком уровне данных специалистов, либо о нежелании их работать. Далее должна быть реклама моей компании, которую я не привожу по этическим соображениям :) На самом деле, вам лучше найти ближайшего специалиста высокого уровня (уровень 4 - максимальный). Такой специалист обязан быть в АТЦ или РТЦ из списка http://rus.panasonic.ru/tc_pbx/
Если будут затруднения - можно воспользоваться нашими услугами, но у нас цены не самые низкие - соразмерно квалификации.
Webmcheck [12.02.2015]
Сейчас бьёмся с аналогичной проблемой с транками. По всей видимости придется проблемный транк тоже передвинуть "вниз".
BigXot [24.03.2013]
На самом деле все просто и АТС тут нисколько не причем. Проблема односторонней слышимости очевидна когда ты юзаешь нат, т.к. у тебя 5060 только сигналинг порт, соответственно ты либо полностью выкидываешь в статик нат, аля вот так на Cisco:
ip nat inside source static 10.0.0.1 xxx.xxx.xxx.xxx и разрешаешь весь входящий трафик от ip провайдера до твоего нат адреса. Либо врубаешь таки PAT, разрешаешь опять же весь входящий траффик от прова до твоего белого адреса и врубаешь CBAK. Это для кошки актуально, как обстаит дело с другими маршрутизаторами не могу сказать
Powered by Elise