Сделайте файл Supout.rif сразу после ребута зависшего микротика.
Потом прочитайте его содержимое в личном кабинете на mikrotik.com.
Может быть там будет что-то полезное.
Попробуйте жестко указать IP-адрес в sip.conf (параметр bind или что-то типа этого), или IP-адрес транспорта в pjsip.conf. Тогда при появлении новых IP-адресов Asterisk их будет игнорировать.
У Вас файл скачался в nginx_signing.key.2, а Вы добавляете nginx_signing.key, и не понятно что там в нем. Сделайте cat nginx_signing.key и результат приложите.
1) Попросить провайдера МАРК поменять схему вызова с "ЗВОНИТЬ ВСЕМ" на "ЗВОНИТЬ ПО ОЧЕРЕДИ";
2) Можно сделать через группы:
exten => _X.,1,Set(GROUP()=${CALLERID(num)}${EXTEN})
same => n,GotoIf($[${GROUP_COUNT(${CALLERID(num)}${EXTEN})}>1]?drop)
same => n,Dial(SIP/xxx/xxx)
same => n(drop),Congestion
voice vlan на коммутаторах нигде не настроен? А то, может быть, вместо запаковки в S-VLAN срабатывает что-то другое? По SIP с софтового клиента (а-ля Zoiper) связь есть?
Вы уверены что это именно модуль?
Я к тому, что модуль Asterisk - это so-файл, который лежит в /usr/lib/asterisk/modules. Пишется на Си, требует достаточно высокого уровня подготовки.
А Ваша задача может быть решена, например, внешним AGI или FastAGI скриптом. Пишется много на чем, значит и уровень подготовки ниже, и количество потенциальных исполнителей больше.
Возможно, что RouterBoard (конкретно ваша модель) во время перезагрузки становится простым свичом.
Столкнулся с этим на RB1100AHx2. Он двумя портами уходит в один коммутатор. Во время перезагрузки запетлевал одним VLAN-ом, коммутатор петлю не поймал (причину не помню).
Задал вопрос "знатоку" микротиков Saab95 на forum.nag.ru, ответа не получил.
Думаю, Вам стоит проверить эту версию экспериментом.
Классиков Вам уже посоветовали, а вот запустить Wireshark на компьютере и своими глазами заглянуть внутрь IP-пакетов еще не успели.
Думаю, это самый удобный способ: далеко ходить не надо (есть "интернет", значит есть обмен данными по сети), виден весь IP-стек, все прокомментировано (кратко, но достаточно для понимания). Рекомендую!
Нужно, чтобы * биндил для разных транков разные IP-адреса.
Если речь про SIP, то:
- модуль chan_sip биндит адрес глобально и указать конкретный IP для конкретного транка не получится.
- модуль chan_pjsip гораздо гибче - там в каждом транке указывается транспорт, и в транспорте можно указывать и разные протоколы (udp,tcp,tls), и IP-адреса, и source-порты. Вопрос с RTP-трафиком должен решаться также - транспорт имеет возможность указать параметр external_media_address - "внешний" адрес для передачи медиа.
Скорее всего по DHCP получаете адрес от кого-то из "соседей" по сети и через него работаете. А когда пытаетесь поднять PPTP/PPOE/L2TP/или_что_там_у_Вас - BRAS оператора Вас не авторизует.
Третий вариант - взять номер по SIP без функционала ВАТС, приземлить на свою IP АТС (Asterisk и т.д.)
Тот факт, что у Вас самописная CRM означает, что готовых решений по интеграции с ней не будет ни у кого, а значит всё придется делать самим. В этом случае все-таки удобней когда всё под вашим контролем - и IP АТС, и CRM.
Можете работать с Asterisk через AMI и не зависеть от API сторонних сервисов.
> или софтфон вообще сам не выполняет запросов на определение ip
Софтфон должен знать свой IP. Если не считать IP-адреса в заголовке IP-пакета, то еще он встречается в заголовке Contact и в SDP. Что касается IP-пакета, тут все просто - пакет идет с тем source ip, какой висит на исходящем интерфейсе в сторону сервера регистрации, если жестко не задан другой адрес. Адрес в Contact - тут сложней. В справочнике сказано - "Агент пользователя не должен передавать новых сообщений регистрации (запросов, содержащих новых сообщений в заголовке Contact), пока не получит окончательный ответ от сервера регистрации на предыдущий запрос...". Еще: "Запрос Register может включать в себя заголовок Contact, содержащий ноль или более контактых адресов.".
Какие тут могут быть варианты:
1) SIP-клиент шлет несколько REGISTER-пакетов с разными адресами в Contact, пока не пройдет регистрация.
2) SIP-клиент шлет один REGISTER-пакет с несколькими адресами в заголовке Contact.
Видимо, зависит от реализации клиента.
Если на пути между клиентом и сервером стоит NAT с функционалом SIP ALG, то заголовок Contact будет подвержен изменению в соответствии с логикой работы этого самого SIP ALG.
Для определения адреса за NAT (а также тип NAT) SIP-клиент может использовать STUN-сервер (SIP ALG в этом случае уже не нужен и даже может мешать). В этом случае заголовок Contact будет сформирован без локального адреса, а сразу с публичным IP-адресом и портом.
Греться должен, но не сильно. Возможно, что у Вас КЗ по TX.
Может быть поэтому и не удается ввести tpl - все что вы вводите не доходит до железки.
Оставьте только RX и посмотрите что поменяется - будет ли греться, отвалится ли ttyUSB0.
Наверное, Вам нужен firmware mod kit.
В составе есть binwalk, который по сигнатурам найдет что есть что, и куча разные версий "экстракторов" для разных ФС. Сам распакует всё что сможет (обычно - rootfs), сам запакует (после ваших изменений), если захотите.
Такое разделение чревато. Если разделять по портам удаленного сервера, то запрос на 80ый порт может придти с одного IP (через первый канал), а на 443 - с другого (второй канал). Если брать локальные порты - аналогично, с одного локального ПК может быть установлено две TCP-сессии с одним и тем же сервером, но с разных адресов. Что-то может пойти не так, особенно, если cookie на сайте привязываются к IP-адресам.
Альтернативные варианты - разделить "весь интернет" (0.0.0.0/0) на две почти равные части - 0.0.0.0/1 и 128.0.0.0/1, и смаршрутизировать их через разных провайдеров.