Различный CID на транках — временное решение.

После объединения внутренних областных IP PBX транками для звонков между главками, осталась нерешенной одна задача. Это отдача правильного CID при звонке в другие области.

Согласно утвержденной схемы нумерации, абонентам присваивается 4-х значный номер. Звонок в другую область для всех однотипный, и выглядит 8-ХХ-YYYY. Где ХХ — код области, а YYYY — номер абонента. Схема работает, звонки ходят, вроде все хорошо, но… входящий звонок приходит с внутренним 4-х номером и абсолютно не понятно откуда он пришел. Открываем список пропущенных и видим, кто нам звонил, но с какой области непонятно. При такой схеме не будет работать кнопка redial.

Итак, посмотрим, что представляет собой схема объединения наших станций. Схема называется «звезда«.

звезда

Преимущество данной схемы — отправляй все на Киев, а там сами разберутся куда доставить звонок. А главный недостаток — в случае  «отказа»  центра — «ляжет» все.

Рассмотрим как в данный момент идет прохождение звонка из ГУ в ДСНС.

GUtoKIEV

Как видим, CID меняется при прохождении через ДСНС на полный номер с кодом 8151190. Все это делает правило на АТС ДСНС при условии, что звонок идет на номера ДСНС. В случае, если звонок проходит транзитом через ДСНС в другую область, то CID просто удаляется и абоненту отправляется Anonymous.

Дабы избежать такой схемы, необходимо администраторам АТС в ГУ самостоятельно контролировать уходящий CID, а не полагаться на ДСНС, что эту работу сделает кто то другой.

Понимая, что в ГУ нету необходимого уровня специалистов среди сотрудников, которые обслуживают Asterisk, и оплачивать сторонние организации тоже никто не будет, предлагаю самый простой способ контроля отправляемого CID.

 Итак, приступим.
1. В настройка extension есть поля Outbound CID и Emergency CID.

ext_cid

Для ведомственной маршрутизации будем использовать поле Emergency CID. Прописываем в нем нужный номер, т.е. к существующему номеру добавляем вначале «815″.

2. Настраиваем исходящую маршрутизацию. Выбираем необходимый роут.
out_route
addrouteОтмечаем опцию Emergency.
toDon

После чего, все звонки, идущие по этому правилу, будут брать CID из поля Emergency CID.
Вот так, достаточно просто можно решить эту проблему, но…

У нас остается нерешенная проблема транзитных звонков из старых ведомственных АТС, которые также подключены к Asterisk. Я думаю почти у всех похожая схема объединения АТС.
trankВ моем случае, абоненты звонящие из АТС SIEMENS (например с номера 1650 на номер 8008193) пройдут сквозь PBX ASTERISK через транк на ДСНС с не измененным CID.

Как обойти такой вариант, я не нашел легкого и простого способа, который можно использовать штатной веб мордой FreePBX. Если у Вас есть решение этой ситуации — поделитесь.

Конечно, было бы отлично, если бы в FreePBX существовала штатная опция изменения CID при выходе из транка — проблем бы не было, но пока ее нет-  выкручиваемся как можем.

Необходимо остановиться дополнительно на схеме объединении областных Asterisk. Звезда, с точки зрения отказоустойчивости, не годится. По этому, необходимо создать транки со всеми ГУ Украины. В настройках указать, что первым транком будет использоваться межобластной, а в случае его выхода — транк ДСНС.
rezrouteДанной схемой, мы всегда остаемся на связи, независимо от центрального узла, и не нагружаем центральный сервер.

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

Еще один нюанс (возможно у кого такое есть). Так сложилось, что наша ведомственная АТС SIEMENS имеет 4-х значные номера внутренних абонентов, но после того, как в Украине перешли на 3-х значные номера экстренных служб, АТСку пришлось перенастроить на 3-х значные номера. С этого момента CID абонентов SIEMENS не совпадает по разрядности с принятым стандартом. Настройщик SIEMENS сделал правило, которое внутри SIEMENS добавляет перед номером цифру «1» и для абонентов SIEMENS ничего не поменялось. Но, когда с SIEMENS звонят на IP Asterisk, то приходящий CID 3-х значный. Чтобы привести к нормальному виду необходимо сделать следующее:

1.  В файле extensions_custom.conf прописываем дополнительные правила обработки входящих.

[from-pstn-custom]
exten => _X.,1,ExecIF($[${VALID_EXTEN(16XX-cid,${CALLERID(num)})}]?Gosub(16XX-cid,${CALLERID(num)},1))

[16XX-cid]
exten => _6XX,1,Set(CALLERID(num)=1${CALLERID(num)})
exten => _6XX,n,Set(CALLERID(ANI-all)=${CALLERID(num)})
exten => _6XX,n,Return()

После чего, к нам уже приходит нормальный CID.


Уникальных посетителей темы: 54

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *