Немного подробностей не помешает.
Уточните схему (Оператор-АТС-телефон), уточните откуда-куда исходящие и входящие и где именно сбрасывает.
Сделайте нормальный полный дамп вызова с помощью, например, sngrep (https://github.com/irontec/sngrep/wiki/Installing-... Запустите программу с ключом -с и выбрав пробелом нужное плечо сохраните дамп через F2. Покажите дамп тут.
Напишите, так же, что используется за оборудование/софт в роли АТС, то же не помешает.
Почему perl? Если вы хорошо разбираетесь в perl, почему бы вам самому не написать рабочий скрипт?
Если вам не принципиально, на каком языке будет написан скрипт, то уточните, пожалуйста:
-версия ОС (cat /etc/*-rel*)
-какой почтовый сервер вы хотите использовать для отправки?
gosha-z, я вас смешить не собирался, просто в том же найсе у банка топ3 России были пару кейсов по 8-14 месяцев отроду. Таки частный случай? С в опенсорсе в самых запущенных случаях -можно выйти из ситуации, ничего (например, изначальные инвестиции в сотни тысяч евро) не держит.
Мы очень уходим от темы, предлагаю не продолжать.
Евгений Намчук, прямо в законе нет запрета на автоматический обзвон. Единственное, что есть в плане регулирования, это что вам не могут автоматически дозвониться и "роботом" проиграть сообщение с рекламой. Это закон "О рекламе". Если рассматривать данный случай, то это клиенты таксопарка, это автоматическое уведомление клиента, а не автоматическая реклама услуг.
gosha-z, по поводу " в эьтом опенсорсе вариться и ждать годами помощи community," у вас, вероятно, не очень большой опыт общения с вендорами именно по ворсам устранения багов. Как раз таки кейсы у вендоров висят годами. Как у Авая, так и у того же Nice Perform. решить проблему с опенсорс- если совсем тяжелая задача -решается средствами нанятого разработчика за месяц -край.
К счастью, данная тема для обсуждения выходит за рамки Тостера...
SofroN, На вскидку, проблем с конфигом не вижу, но я не ас l2tp/pptp, ipsec ближе.
Почему, кстати, не используется ipsec?
По хорошему, нужно на каждом узле делать дамп и ловить проблему по факту.
Банально, попробуйте на Астериске включить запись разговора и убедиться, что голос при проблемном вызове на АТС приходит с двух сторон. Давайте так попробуем.
Запустите её без аргументов, на телефонном аппарате выключите и включите аккаунт, ловите пакеты на астериске.
Когда увидите REGISTER от искомого телефонного аппарата, пробелом выделите это сообщение и F2 сохраните его.
Покажите нам. Ну или скриншотов можете поделать с этого сообщения.
Так же, на Астериске, сделайте, пожалуйста:
iptables -L -v -n
и
grep localnet /etc/asterisk/*.conf
SofroN, адпак простой как две копейки, всё и тут правильно, на мой взгляд.
В первом вашем сообщении -это актуальный конифг, с которым не работает как раз?
SofroN, в последнем дампе smg голос в сторону адпака отдает. Но адпак не знает, что делать с голосом и на 192.168.1.151 не хочет данные отдавать. Обычно такое происходит, когда устройство или реально не отдает голос, потому что не знает сеть 192.168.1.151, или голос где то теряется "до" устройства сбора данных. Склоняюсь к первому варианту.
В вашем дампе обратите внимание на SDP, который отдает адпаку ваша SMG.
Видно, что адпак корректно указывает внутренний адрес для голоса, а от SMG приходит внешний 185.61.246.72 адрес.
Таким образом, вам нужно на вашем SMG сказать, что пир в лице адпака - не нужно натировать (корректировать SDP), что это локальный пользователь.
Во вторых, в дампе у вас должно быть два локальных пользователя, вы же впн построили, адресация должна быть приватной, а у вас со стороны SMG адрес для сигнализации указан внешний.
На микротике можете в сервисах отключить sip. Это вредил поможет, но думать мы об этом тут все перестанем :)