Opened 44 hours ago

Closed 17 hours ago

#460 closed баг (invalid)

Плата VE-02 (исполнение 2 ) отправляет BYE не с того IP-адреса

Reported by: roman_zhur Owned by: alx
Priority: средний Milestone: 1 очередь
Component: VE-02 Keywords:
Cc:

Description (last modified by roman_zhur)

Основной адрес платы VE-02-02 192.168.20.56/24, так же используется дополнительная подсеть (alias) с IP-адресом 192.168.30.1/24.
SIP-телефон (11@) имеет IP-адрес 192.168.30.10/24, подключен к плате VE-02-02 и зарегистрирован на ней.
В плату VE-02-02 установлен субмодуль FS01, к которому подключен аналоговый телефон (33@).

Звонок 11@ --> 33@, при отбое со стороны 33@ VE-02-02 отправляет BYE не с того интерфейса, с которого ожидается.

По пакетам видно, что SIP-телефон (192.168.30.10) отправляет пакеты на основной адрес платы (192.168.20.56) и получает от него ответы, кроме последнего BYE. Последний BYE почему-то приходит на SIP-телефон с адреса дополнительной подсети (192.168.30.1).


Attachments (3)

wireshark1.png (16.9 KB ) - added by roman_zhur 44 hours ago.
dump1.pcapng (6.6 KB ) - added by roman_zhur 44 hours ago.
tcpdump1.txt (12.6 KB ) - added by roman_zhur 44 hours ago.

Download all attachments as: .zip

Change History (15)

comment:1 by roman_zhur, 44 hours ago

Description: modified (diff)
Summary: Плата VE-02 (исполнение 2 ) отправляет BYE не в тот интерфейсПлата VE-02 (исполнение 2 ) отправляет BYE не с того IP-адреса

comment:2 by roman_zhur, 44 hours ago

Description: modified (diff)

comment:3 by roman_zhur, 44 hours ago

Description: modified (diff)

by roman_zhur, 44 hours ago

Attachment: wireshark1.png added

comment:4 by alx, 44 hours ago

Description: modified (diff)

Тип тикета установлен в "баг", но из описания тикета мне не совсем понятно, в чем по-твоему состоит баг. По заголовку тикета я могу предположить, что ожидалось, что адрес отправителя сообщения BYE будет другой. Если я догадался правильно, то поясни, пожалуйста, почему ты считаешь, что адрес должен быть другой (или, иными словами, почему ты считаешь, что прокси-сервер не должен был отправлять сообщение с адреса 192.168.30.1).

Напомню, что на главной странице есть рекомендации о том, как сделать хороший баг-рипорт.

by roman_zhur, 44 hours ago

Attachment: dump1.pcapng added

by roman_zhur, 44 hours ago

Attachment: tcpdump1.txt added

comment:5 by roman_zhur, 44 hours ago

Description: modified (diff)

comment:6 by alx, 44 hours ago

Описание в предыдущем комментарии изменил ненамеренно - я уже писал комментарий, когда roman_zhur внес изменение, поэтому изменение "откатилось". Возвращаю обратно...

comment:7 by san, 43 hours ago

или, иными словами, почему ты считаешь, что прокси-сервер не должен был отправлять сообщение с адреса 192.168.30.1

Я не Роман, но я тоже ожидал BYE с адреса 192.168.20.56, а не 192.168.30.1.
Т.к. предполагалось что 192.168.30.1, это только роутер и в SIP вмешиваться не должен.
В настройках телефона в качестве Sip сервера указан 192.168.20.56, а адрес 192.168.30.1 указан как шлюз.
Обмен Sip сообщениями идёт между 192.168.20.56 и 192.168.30.10, и только BYE неожиданно приходит от 192.168.30.1, телефон Yealink этот BYE игнорирует.

Если в телефоне дополнительно в настройку "Outbound proxy server внести" 192.168.30.1, в таком случае телефон примет BYE. Но, на мой взгляд, всё-равно странно что часть Sip сообщений в одном диалоге плата VE отправляет с одного адреса, а часть с другого.

in reply to:  7 comment:8 by alx, 38 hours ago

Replying to san:

телефон Yealink этот BYE игнорирует.

Откуда у тебя такая информация? Автор тикета ни о чем подобном не сообщал...

Но, на мой взгляд, всё-равно странно что часть Sip сообщений в одном диалоге плата VE отправляет с одного адреса, а часть с другого.

Во-первых, лично я ничего странного в наблюдаемом поведении не вижу. По-моему все вполне объяснимо и очевидно. Посмотри внимательно на приложенный лог. С адреса 192.168.20.56 передаются сообщения "407 Proxy Authentication Required", "180 Ringing" и "200 OK". Это ответные сообщения, которые передаются в транзакции INVITE, начатой телефоном. Телефон, инициируя транзакцию, отправил сообщение INVITE в то TCP соединение, которое он ранее установил с прокси-сервером (это видно по номерам портов). Ответы на запросы, полученные через connection-oriented транспорты (TCP, TLS), должны передаваться в том же соединении, в котором был получен запрос (кажется это есть где-то в RFC). Поэтому прокси-сервер передает ответы в то же самое соединение, из которого получил запрос, и это правильно. Так как, как ты сам отметил, в настройках телефона указан адрес прокси 192.168.20.56, то именно с этим адресом телефон устанавливал соединение, и поэтому именно этот адрес фигурирует во всех пакетах INVITE-транзакции.

Сообщение же BYE инициирует новую транзакцию, и эта транзакция инициируется со стороны прокси. Проски использует для ее передачи другое соеинение TCP - то, которое установил с телефоном он сам (это опять-таки видно по номерам портов). При установке этого соединения ядро в качестве адреса отправителя выбрало тот (из двух имеющихся в его распоряжении) адрес, который находится в одной сети с сервером (и в этом есть свои логика и смысл). Поэтому, когда прокси отправляет в это соединение запрос BYE, адрес оказывается другой.

Во-вторых, для меня не важно, странно это или нет. Я - технический специалист, и понятием "странно" не оперирую. :) Для меня важно, правильно это или нет - насколько соответствует стандартам и спецификациям протоколов. Я не помню, чтобы встречал где-то в каких-то RFC требований, касающихся выбора локального адреса при установке TCP соединения. По-моему никаких требований на этот счет нет.

Лично для меня намного более странно то, что (с твоих слов, автор тикета ни о чем таком не писал!) телефон игнорирует корректное (well-formed) сообщение BYE, полученное им через правильный транспорт (он сам просил транспорт TCP). На мой взгляд, все это выглядит как баг телефона. Я не вижу ничего, в чем можно упрекнуть наши прокси или шлюз...

Поэтому я жду уточнений от автора тикета. Если он, например, покажет пункт RFC, требования которого данное поведение нарушает - я буду искать способ решить эту проблему.

in reply to:  7 comment:9 by alx, 38 hours ago

Replying to san:

Я не Роман, но я тоже ожидал BYE с адреса 192.168.20.56, а не 192.168.30.1.
Т.к. предполагалось что 192.168.30.1, это только роутер и в SIP вмешиваться не должен.

Забыл прокомментировать эту строчку. У нас в одном и том же хосте (я говорю про плату VE-02) есть много разных функций, связанных с IP - и маршрутизация, и SIP-proxy, и SIP-registrar, и SIP-gateway, и SNMP-agent, и DHCP-relay... Никто не обещал, что для каждой из этих функций будет использоваться свой выделенный адрес - так адресов не напасешься! :) Адрес вообще может быть только один (192.168.30.1 - это опциональный адрес, который нужен только для совместимости с более старыми версиями плат).

Поэтому написанные тобой выше предположение и ожидание ИМХО не обосновано.

Что ожидал roman_zhur, я не знаю, он этого не написал, а, в отличие от тебя, гадать я не хочу. :) Поэтому жду от него пояснений.

comment:10 by san, 22 hours ago

в отличие от тебя, гадать я не хочу

Я не гадал, я написал свою точку зрения.

Откуда у тебя такая информация

В случае если в настройках телефона не указать дополнительно Outbound proxy server = 192.168.30.1, то Sip-телефон игнорирует BYE, я наблюдал это в эксперименте Романа.

понятием "странно" не оперирую

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

in reply to:  10 comment:11 by alx, 17 hours ago

Replying to san:

в отличие от тебя, гадать я не хочу

Я не гадал, я написал свою точку зрения.

Прошу прощения, я неточно выразился. Я имел в виду, что ты предполагал что-то, о чем автор тикета не говорил (что из-за IP адреса удаленного конца TCP-соединения SIP-телефон не принимает сообщение BYE).

В случае если в настройках телефона не указать дополнительно Outbound proxy server = 192.168.30.1, то Sip-телефон игнорирует BYE, я наблюдал это в эксперименте Романа.

Понятно. Но, как бы то ни было, это выходит за рамки темы этого тикета. Атор тикета ничего не писал про игнорирование телефоном сообщения BYE. Автор написал (насколько смог понять), что, по его мнению, плата не должна была использовать адрес 192.168.30.1 в качестве своего адреса (адреса отправителя исходящих от нее пакетов). Я с его мнением не согласен, так как он сам указал, что данный адрес был назначен плате в конфигурации.

Я согласен, что придираться к опциональному адресу строго не стоит,

Во-первых, я так не говорил. :) Если такое поведение нарушает какой-либо пункт RFC, то его, конечно же, следует изменить (или по крайней мере попытаться) чтобы привести к требованиям RFC.

Во-вторых, тут дело не в опциональности адреса (у старых плат v8 он совсем не опциональный - это адрес второго интерфейса!), а в том, что плата просто не предназначена для такого включения. Предполагалось, что телефон будет работать не с платой, в которую он включен, а с сервером диспетчерской связи где-то далеко в сети. А плата VE-02 для него - всего лишь шлюз в эту общую сеть. Это уже потом мы экспериментировали и выяснили, что при некоторых хитрых настройках телефон с платой все-таки может работать. И был добавлен "костыль" для того чтобы перенаправлять RTP из MSP в CSP и затем во второй интерфейс (LAN)... Я, кстати, помню эти наши эксперименты (это было не в нашей комнате, а на производстве), и смутно припоминаю, что мы, действительно, задавали и Outbound proxy, и registrar... Хорошо помню, что "рабочая" настройка оказалась не такой уж простой и очевидной...

как минимум надо иметь в виду эту особенность, может быть потестить как другие телефоны относятся к сообщению от "неизвестного" IP.

Не возражаю. Но к данному тикету это IMO отношения не имеет...

comment:12 by roman_zhur, 17 hours ago

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.