SIP прокси пытается отправить запрос на неправильный IP-адрес

[roman_zhur]

Что сделал:

1. настроил плату VE-02:

• изменил WAN IP-адрес платы с .0.124 (полученного по DHCP при загрузке платы) на .20.120;
• создал два URI, совершил звонок 11@ -> 22@.

2. сохранил конфигурацию блока дискеткой, скачал файл конфигурации.
3. очистил конфигурацию блока кнопкой "Очистить конфиг", перезапустил swd.
4. залил в блок файл конфигурации, полученный в пункте 2, перезапустил swd, попытался совершить звонок.

Что ожидалось: после загрузки конфиг файла в пункте 4 можно совершить звонок 11@ -> 22@ и поговорить.
Что происходит: при совершении звонка с 11@ на 22@ нельзя дозвониться, происходит отбой по таймауту.

судя по строчке из tcpdump'а:

05:58:44.480154 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 1190)

192.168.20.120.5060 > 192.168.0.124.5060: SIP, length: 1162

SIP прокси пытается перенаправить запрос с текущего IP-адреса на IP-адрес, который был до смены IP-адреса платы VE-02. Такого IP-адреса больше нет, соответственно, запрос никуда не попадает.

config-test-09-02-2026.xml - сохраненный файл конфигурации в пункте 2.
config-test-09-02-2026(1).xml - сохраненный файл конфигурации после пункта 4.
Оба файла конфигурации аналогичны.

11.txt - лог tcpdump'а с пункта 1.
22.txt - лог tcpdump'а с пункта 4 (первая попытка позвонить).
33.txt - лог tcpdump'а с пункта 4 (вторая попытка позвонить).

[roman_zhur]

лог с VE-02

[roman_zhur]

совсем забыл
Версия sw: 1.0-r2586
VE-02 ревизия прошивки 63

[alx]

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

Replying to roman_zhur:

судя по строчке из tcpdump'а:

05:58:44.480154 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 1190)

192.168.20.120.5060 > 192.168.0.124.5060: SIP, length: 1162

Судя по приложенному логу messages, проблемный вызов в пункте 4 был сделан в 09:18:37 и завершился в 09:19:09. Время вывода этой строчки даже близко не приближается к периоду совершения проблемного звонка...

11.txt - лог tcpdump'а с пункта 1.

Согласно приложенному логу messages, в пункте 1 звонок выполнялся с 09:17:42 по 09:17:49. В приложенном дампе 11.txt я не вижу ни одного пакета, попадающего в указанный интервал времени - все пакеты этого дампа проходили по сети на несколько часов (!!!) раньше, чем был сделан вызов в пункте 1...

22.txt - лог tcpdump'а с пункта 4 (первая попытка позвонить).

Судя по приложенному логу messages, проблемный вызов в пункте 4 был сделан в 09:18:37 и завершился в 09:19:09. В приложенном файле 22.txt я вижу пакеты, проходившие по сети в интервале с 09:06:20 по 09:06:53. То есть ни один из имеющихся там пакетов тоже не попадает в интервал времени, когда происходил проблемный вызов. Более того, все эти пакеты прошли еще до выполнения пункта 3 (судя по логу, пункт 3 был выполнен в 09:18:06)!

33.txt - лог tcpdump'а с пункта 4 (вторая попытка позвонить).

В приложенном логе messages нет второй попытки, там зафиксирована лишь одна попытка вызова после смены адреса платы обратно на 192.168.20.120...

Не мог бы ты прояснить ситуацию с этой путаницей во времени?

[roman_zhur]

Не мог бы ты прояснить ситуацию с этой путаницей во времени?

tcpdump и messages сделаны в разное время.
если это очень важно, могу попробовать записать всё в одно время.

я некоторое время экспериментировал с этим багом и записывал логи tcpdump'а, а файл message решил записать отдельно позже, чтобы там было меньше лишней информации

[alx]

Replying to roman_zhur:

Не мог бы ты прояснить ситуацию с этой путаницей во времени?

tcpdump и messages сделаны в разное время.

Понятно. :)

если это очень важно, могу попробовать записать всё в одно время.

Запиши, пожалуйста, если это не очень трудно. Просто на данный момент ничто из имеющейся в тикете информации не подтверждает утверждение о том, что SIP-прокси отправляет сообщения по неверному адресу...

Пока по существу вопроса могу сказать, что у прокси-сервера сокеты привязаны к адресам 0.0.0.0 (и ::), и, по идее, от смены адресов на каком-либо нтерфейсе его работа никак зависеть не должна. Единственное, что происходит с прокси при смене адреса на интерфейсе WAN - это старый адрес удаляется из списка доменов, за которые прокси отвечает, а новый туда добавляется. Это я уже проверил сегодня в коде sip_ua...

[roman_zhur]

добавил файлы messages.2 и tcpdump.zip. tcpdump записал полностью одним файлом с шага 1 по шаг 4. запись лога и дампа были в одно время.

[roman_zhur]

добавил еще файлы messages3, dump1 и dump2. отдельно записал tcpdump во время выполнения шага 1 (dump1) и шага 4 (dump2). запись лога и дампа были в одно время.

[alx]

Replying to roman_zhur:

добавил файлы messages.2 и tcpdump.zip.

Спасибо. Теперь ситуация прояснилась.

Для начала напомню, какую функцию несет URI канального окончания, а точнее, его домен. В числе прочего, домен канального окончания определяет, должно оно регистрироваться на сервере или нет: если канальному окончанию в качестве домена установлен собственный адрес платы (127.0.0.1 или адрес WAN), канальное окончание не регистрируется. Если же ему задан "чужой" домен (не адрес платы), канальное окончание регистрируется.

Теперь что происходило в ходе эксперимента. Пункты 1 и 2 я пропускаю - там все было ожидаемо.

• В 05:11:21 плата получила дефолтную настройку IP, в которой плата получает сетевые настройки по DHCP. Был запущен DHCP клиент.
• В 05:11:22 DHCP клиент получил адрес 192.168.0.124 и установил его интерфейсу WAN (eth0).
• В 05:11:23 процесс sip_ua обнаружил изменение адреса и уведомил об этом канальные окончания. Так как домен (192.168.20.120) канальных окончаний не являлся адресом платы, канальные окончания отправили прокси-серверу запрос на регистрацию на сервере 192.168.20.120, при этом в поле Contact указали sip:11@192.168.0.124 и sip:22@192.168.0.124.
• Прокси-сервер начал попытки доставки сообщения на адрес 192.168.20.120, но так как такого хоста в сети нет, не получал ответа.
• В 05:11:43 плата получила статические настройки сети и установила интерфейсу WAN адрес 192.168.20.120.
• Прокси-сервер, делая очередную попытку отправки запросов регистрации на адрес 192.168.20.120, наконец-то успешно доставил их самому себе и, таким образом, зарегистрировал канальные окончания платы.
• В 05:12:32 канальное окончание 11@192.168.20.120 направило прокси-серверу вызов канального окончания 22@192.168.20.120. Прокси-сервер, обнаружив, что 22@192.168.20.120 зарегистрирован в его сервере регистрации с контактом 22@192.168.0.124, перенаправил сообщение на адрес 192.168.0.124.
• Так как хост 192.168.0.124 в сети отсутствовал, прокси-сервер не получил никакого ответа и в 05:12:24 ответил вызывающему канальному окончанию "408 Request Timeout".

Строго говоря, ни в работе прокси, ни в работе шлюза ошибок нет, они работают как и задумано. Причина неуспешного вызова - стечение нескольких разных обстоятельств. Во-первых, оператор установил канальным окончаниям домен 192.168.20.120, не ожидая, что в какой то момент у платы может оказаться другой адрес, и канальные окончания будут пытаться зарегистрироваться на этом адресе как чужом. Во-вторых, канальное окончание при регистрации указывает в контакте не 127.0.0.1, а внешний IP адрес платы (это осталось "в наследство" от старых версий ПО, в которых не было прокси-сервера, и шлюз обменивался сообщениями с внешними хостами непосредственно).

Чтобы избежать подобных ситуаций рекомендую канальным окончаниям, регистрация которых не предполагается, устанавливать в "SIP URI" домен 127.0.0.1 (то есть в данном случае 11@127.0.0.1 и 22@127.0.0.1) - это гарантирует, что канальное окончание не будет пытаться нигде зарегистрироваться (если, конечно, не установить другой адрес регистратора). Также можно адрес регистратора установить в 127.0.0.1 - эффект будет тот же.

Что касается шлюза, можно при регистрации в поле Contact указывать адрес 127.0.0.1, тогда даже если он зарегистрируется, сообщения все равно, по идее, должны возвращаться ему.

[alx]

Replying to alx:

Что касается шлюза, можно при регистрации в поле Contact указывать адрес 127.0.0.1, тогда даже если он зарегистрируется, сообщения все равно, по идее, должны возвращаться ему.

Провел эксперимент. При регистрации с доменом 127.0.0.1 SIP сообщения, как и ожидалось, успешно доставляются шлюзу.

[alx]

In 2673/sip_ua:

При регистрации канального окончания на сервере
в поле Contact указывается домен 127.0.0.1.
А порт не указывается. Closes #473.