Если там уже провайдер(ы) через этот проброс работают, - не ручаюсь за результат

Профит в том, что TCP при переподключении всегда меняет порт отправителя, и для NAT это будет уже новым соединением.
Полезно в ситуации, когда меняется IP, предоставляемый провайдером, или SIP-трафик начинает идти через другого провайдера (UDP-"соединение" продолжает натироваться старым IP).

@ovoshlook , Anton спасибо вам огромнейшее за помощь! завтра будем проверять

Так профита от этого все равно не будет так как SIP UA исходящие запросы будет слать на данные которые лежат в пакете а не на новый сетевой адрес

Едиственный вариант профта -если SIP сервер будет мапить новую точку назначения к сущесвующему диалогу - но тут нет гарантии что это везде будет работать
не помню как конкртено с астериск и chan_sip но PJSIP на сколко я помню работает правильно и такое с ним не прокатит просто так
при переподкючении точки UAC и его диалоги должны будут смапиться на новый адрес и должен будет произойти новый обмен пакетами
иначе reivite и тому подобное уйдет по адресу который был опубликован ранее через SIP заголовки

Начнёт слать на новый адрес, как только пройдёт регистрация с него. По UDP новая регистрация не пройдёт без посторонней помощи (удаление соединения на роутере).

почему не пройдет?
адрес новый будет

Потому что по UDP пакеты будут уходить, натированные неправильным адресом. Они до SIP UA никогда не дойдут.

даже если пройдет регистрация - где гарантия что SIP сервер обновит адрес точки для существующих диалогов?
в RFC этой гарантии нет
точки уже обменялись адресами
UAC пока не пришлет новый адрес в indialog - диалог не обновит состояние и UAS когда решит отправить indialog - будет слать на старый адрес все равно

не будут
пришел REINVITE он UAC с нового адреса - для роутера это новое соединение
в пакете - новый адрес
Так же как и с TCP адреса - поменялся исходящий адрес ( не важно что - порт или ip ) это уже новое соединение
Мы мбо разных вещах говорим?

Я думаю пользователь перезвонит, нестрашно, если существующие диалоги упадут. Я-то про подключение IP-телефонов из-за случайных домашних роутеров.

Ну подключили вы телефон по TCP с домашнего роутера
поменялся IP нечаянно
пока телефон не пошлет регу новое соединение с сервером не произойдет

По UDP то же самое
В чем профит то?

Я даже не про SIP, а про UDP-пакеты. Для роутера это соединение и оно заносится в таблицу соединений. После того, как соединение проходит NAT, информация об этом тоже заносится в таблицу соединений (причём информация о NAT на соединении не меняется потом).

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

Ну вы тут сами себе противоречите
Вы вот пишите что определяется конечными адресами
адрес- это ip+port
соовтетсвенно если даже у точки остался тот же порт для UDP
то IP поменятся  -  на ротутере таблица адресации перестраивается

Господа, первый раз дебажу RTP. Плавающая проблема. Входящий звонок, далее идёт Playback, если аудио файл нормально воспроизводится, то RTP debug выглядит так -
Got  RTP packet from
Got  RTP packet from
Got  RTP packet from
Got  RTP packet from и так далее
Воторой вариант когда происходит реально не понятное - идёт один гудок, в cli показывается, что должен пойти Playback, но играет какая то не понятная музыка 3 секунды(я такой и не разу не слышал в библиотеках) и RTP идёт вот так -
Got  RTP packet from
Sent RTP packet to
Got  RTP packet from
Sent RTP packet to
и падает в конце ессено

Точка находится за NAT, - не поменяется её IP

И что что за нат?
роутер видит IP роутера провайдера как IP источника
а не IP точки которая за NAT
Это один из методов nat traverse
откройте TCPdump и посмотрите какие адреса стоят

Поздравляю Вас с победой, у меня больше нет времени.

SRC как раз за натом находится в данном пакете
но как видите IP внешний

У меня все

помогите советом