Обычно так и есть. Порты закрыты от всех, кроме провайдера. Еще там nat практически всегда. Еще из простых причин: SIP ALG. В микроте это выглядит как ip-firewall-service ports. В некоторых случаях эта штука нужна, в других - вредит. Зависит от того что со стороны провайдера накручено. В инструкциях рекомендаций на этот счет не пишут, поэтому только методом проб и ошибок. Ну и, да, fpbx пишет крайне подробные логи. По любому звонку можно найти максимально детальные данные. Для этого сначала надо взять system id звонка из cdr, найти его в логах, после чего скопировать что-то типа trace-id и искать в логах уже его.
берешь tcpdump пишешь дамп, отрываешь в wireshark, читаешь сип, вот тут в сдп как раз описано как будет медиа ходить - ip и порт, в инвайте от одной стороны в 200ок, от другой (чаще всего) в процессе разговора если медиа сессия меняется приходит новый invite, это будет видно в дампе, там будут новые порты, так можно понять что что-то изменилось в процессе
Это в reports-cdr, по проблемному звонку в табличке есть. Если взять эти циферки, потом зайти в reports-asterisk logs и вбить их в поле поиска, получится найти несколько записей лога касательно этого звонка. Чтобы найти полный список сообщений лога, надо в найденных строках скопировать ID из квадратных скобок(выше, на screenshot_28 указано из каких именно). Потом уже его вбить в строку поиска. Если ничего не находится, надо выше строки поиска вставить число побольше, чем дефолтные 500.
Ещё добавлю, что сильно экономит время при дебаге - sngrep. Можно прямо на сервере с FreePBX поставить. Там прямо в процесс звонка много чего видно: диалог, параметры и т.д. Не надо самому цифры сверять