Клиент за NAT - коннектится, есть гудок, голоса нет. Заменяет в голосовых пакетах белый ip внутренним ip клиента.

Перерыто пол-инета, пробовали кучу рецептов. Видимо решение во второй половине.
Ситуация такая: у всех клиентов, спрятанных за натом, авторизация происходит. Звонок коммутируется. Гудок слышно.
В это время дебаг выглядит так: Здесь 82.82.82.82 - типа реальный ip астериска.
46.233.213.29 - реальный ip роутера, за которым прячется клиент.

Как только снимаем трубку - звук пропадает. Напрочь, в обе стороны. Пакеты выглядят так: Выплывает ip 10.10.0.103, который является внутренним ip клиента за роутером.
Получается, что на этот адрес ничего дойти не может, астериск не найдет его в интернете.
Или мы неправильно поняли ситуацию?
Пробовали на разных клиентах за разными натами/роутерами. Одинаковая ситуация. Когда клиент устанавливается на компе с белым ip - звук проходит.
Как с этим бороться?

в sip.conf ГЛОБАЛЬНО
nat=yes
canreinvite=no
вопрос неоднократно обсуждался, поиск сломался или не знали в какую конкретно уже существующую тему вписаться? непонятно для чего плодить снова и снова одно и тоже

И то, и другое есть.
Мы уже поняли, что на форуме за вопросы ругают, поэтому сначала пользуемся гуглем и поиском на форуме, пробуем, все что нашлось и что предлагают, а только потом спрашиваем:)
Вдруг найдется дока, который по виду дебага сходу назовет причину:)

Added after 12 minutes:

конфиги такие:
sip.conf: В настройках пиров также nat=yes

Посмотрите внимательнее настройки программы x-lite, которая, судя по заголовкам, используется. Скорее всего она ставит в контакт внутренний ip.

Наблюдаем не только на X-lite, на других клиентах и провайдерах тоже.
Мы немного продвинулись - астериск у нас работает через железку-файрвол, в инет через него ходит. Пускаем напрямую - звук появляется, пакеты ходят на нормальный адрес.
Садим обратно - звука нет, адрес снова становится 10.10.0.103 в пакетах.
Админ железки-файрвола уверяет, что с его стороны проблем быть не может.
Думаем в сторону того, что в своей подсети, которая через файрвол ходит в инет, астериск неправильно определяет адресацию в самой подсети.

Так Asterisk за натом или на реальнике?

На реальном ip. В большой сети с реальными ip.
Железка с файрволом натом не является, только проверяет проходящий через нее трафик.
На ней безусловно открыт сигнальный порт SIP, а диапазон UDP открывается автоматически, только нужные порты, когда этого требует приложение, работающее в данный момент по порту 5060.
Первая мысль - что файрвол по каким-то причинам диапазон UDP не открывает.
Но не стоит забывать, что клиенты без ната звонят нормально, со звуком. И визуально проблема в том, что астериск откуда-то берет адрес 10.10.0.103 (адрес клиента в подсети за натом) и начинает кидать пакеты на него. При этом пакеты tcp по порту 5060 ходят по правильному адресу 46.233.213.29, а одновременно с ними бегают UDP пакеты на адрес 10.10.0.103. Как такое может быть одновременно - непонятно.

Еще тонкость - две недели назад все работало, и вдруг отвалилось. Сеть и железо обслуживают несколько практически не связанных администраторов, у каждого своя зона ответственности, возможно кто-то что-то перенастроил и забыл. Сейчас не можем найти следов.

попробуйте поставить nat=comedia
и указать externaddr

Поигрались с nat=comedia и force_rport с явным указанием внешнего ip в разных вариациях - не помогает:( В смысле клиенты не могут зарегистрироваться.

Странная ситуация когда звонок идет а голос нет, то это врядли вина астериска, посмотрите tcpdump`ом на какие адреса астериск отправляет голосоывае пакеты, если на реалйный адрес (на которм нат и за которым клиент) то надо колупать нат + клиент

Может быть железка-firewall несколько умнее, чем просто firewall, была у меня схожая проблема с софт-firewall она умела обрабатывать sip пакеты, может быть и тут также.

Посмотрите по кодекам, долго парился почему голоса нет, оказалось проблема была в выборе кодека, как только прописал g729&alaw&ulaw вместо alaw&ulaw&g729 голос полетел.
посмотрите потоковый tshark (без записи капчуринка)
типа
tshark host ip - этого достаточно, и посмотрите с каким кодеком вы отправляете пакеты и с каким кодеком реально устанавливается связь.

Проблема решена.
Была вина Cisco, там админ включил опцию SIP INSPECT.
Эта опция лезет в пакеты SIP, проверяет, что это действительно SIP протокол, и ищет в пакете, какой порт UDP надо открыть для установления соединения.
Так вот этот SIP INSPECT работает правильно, когда клиент не за натом. Порты открывает.
А когда за натом - не может, то есть фактически UDP 10000:20000 для голоса получаются закрыты. Голоса нет. И астериск почему-то начинает пытаться кидать пакеты не на внешний адрес ната клиента, а на внутренний адрес самого клиента за натом - 10.10.0.Х, ну или там 192.168.0.Х, естественно, что в интернете и в своей подсети таких клиентов нет и пакеты улетают вникуда.
Такая система работы и сбила с толку в диагностике - если бы он пытался слать пакеты на правильный адрес, нашли бы быстрее пакеты. А так админ циски ругался на астериск, что это он путает подсети.

Решили проблему отключением инспекта в Циско и прямым открытием диапазона 10000:20000.

Спасибо всем за советы!

П.С.: кстати, с инспектом была еще одна интересная проблема - когда китайцы пытались перебирать пароли с частотой 40000 обращений в минуту, то fail2ban срабатывал, а вот Cisco все равно получала пакеты и лезла в них, в итоге вообще висла - перегружался процессор от такого объема работы. Решилось прописыванием в Cisco правила отправлять пакеты на регистрацию не чаще одного в секунду с одного ip. Помогло, задержек в регистрации абонентов не заметно, разве что на секунды две дольше.

Тссс...! разве можно такое про Cisco...