Маскарадинг во всех SIP сообщениях

[san]

К сожалению сделанного в #390 оказалось не достаточно для работы с "Sip транком" Hipath.
Выяснилось, что при вызове в сторону платы VE-01, удалённая сторона получив ответ 200, по непонятной причине отправляет ACK на IP адрес из поля Contact ответа 200 (127.0.0.1) в результате чего этот ACK не доходит до платы VE-01 что служит причиной разрыва разговора через 40 секунд видимо по инициативе VE-01.

Для попытки успешного взаимодействия конкретно с этим Sip-транком, при невозможности что-то поменять с удалённой стороны, нам требуется добавить ещё "костылей" - при включении опции маскарадинг, подменять поле контакт не только в сообщении инвайт, но и во всех остальных исходящих сообщениях.
Думаю что нужно сделать экспериментальную прошивку и посмотреть что из этого выйдет.

[alx]

Replying to san:

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

Верно ли я понял, что имеются в виду сообщения, отправляемые шлюзом платы VE-01?

[san]

В этом эксперименте да, речь о шлюзе.

[alx]

Экспериментальная прошивка отправлена san в telegram.

[san]

Приложил дамп проверки прошивки
Адрес платы 172.26.2.22
В сообщениях 180 и 200 в поле контакт по прежнему присутствует адрес 127.0.0.1

з.ы. Второй участник соединения - плата VE-02 без маскарадинга.

[alx]

Replying to san:

В сообщениях 180 и 200 в поле контакт по прежнему присутствует адрес 127.0.0.1

Так и должно быть. Согласно описанию нашей функции маскарадинга, адрес в поле Contact заменяется на адрес поля From только в случае, если домен в поле From принадлежит плате - присутствует в списке доменов, за которые ответственен прокси-сервер (см. #390). В список локальных доменов автоматически добавляются адреса интерфейса eth0.

Сообщения "180" и "200", о которых ты говоришь, исходят из платы с адресом 172.26.2.22. Однако в поле From этих сообщений находится URI sip:6012345@172.26.2.11. Домен этого URI (172.26.2.11) не является адресом платы, отправившей это сообщение. Таким образом, это сообщение не должно подвергаться маскарадингу.

[san]

Хм.. всё становится запутаннее. Условие маскарадинга было сформулировано для сообщений инвайт, а с другими сообщениями это условие всё портит...
Думаю что для экспериментальной прошивки нужно изменить условие.
Давай маскарадить все сообщения от шлюза не взирая на поле from, а по результатам эксперимента решим что делать дальше.

[alx]

Экспериментальная прошивка отправлена автору тикета в telegram.

[san]

Провёл эксперимент.
В сообщении 180 я ожидал в поле контакт увидеть внешний адрес своей платы .2.22, однако вижу там адрес .2.11 который является чужим адресом - адресом платы которая отправила инвайт.

[alx]

Replying to san:

В сообщении 180 я ожидал в поле контакт увидеть внешний адрес своей платы .2.22, однако вижу там адрес .2.11

Посмотрел приложенный дамп. Мой вывод: функция работает правильно, неверно ожидание адреса .2.22.

Для аргументации вывода - небольшой экскурс в историю. :) В один прекрасный (или ужасный) день выяснилось, что существуют АТС, которые ожидают, что домен в поле Contact сообщения INVITE непременно должен совпадать с доменом в поле From. И если домены в указанных полях не совпадают, АТС отказывается принимать такой вызов (см. #384).

Чтобы дать АТС то, что она ожидает, была реализована функция "Маскарадинг INVITE", которая в исходящих от шлюза платы VE-01 сообщениях INVITE устанавливает в URI поля Contact такой же домен, какой указан в URI поля From - то есть делает ровно то, что ожидает получить АТС.

Теперь посмотрим, что передается в сообщениях "180 Ringing" из последнего дампа:

	SIP/2.0 180 Ringing
	Via: SIP/2.0/UDP 172.26.2.11:5060;branch=z9hG4bK-524287-1---d5b5d94c063eea15;rport=5060
	Via: SIP/2.0/UDP 127.0.0.1:6060;rport=6060;branch=z9hG4bK1474871280
	Record-Route: <sip:172.26.2.22:5060;transport=udp;lr>
	Record-Route: <sip:172.26.2.11:5060;transport=udp;lr>
	Require: 100rel
	Contact: <sip:3333@172.26.2.11>
	To: <sip:3333@172.26.2.11>;tag=1409504167
	From: <sip:6012345@172.26.2.11>;tag=1091968783
	Call-ID: 225885614
	CSeq: 20 INVITE
	Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, INFO, UPDATE, PRACK
	Server: repro 1.12.0
	Supported: replaces, timer, 100rel
	User-Agent: eXosip/5.2.1
	RSeq: 100
	P-Asserted-Identity: <sip:3333@172.26.2.22>
	Content-Length: 0

Мы видим, что в поле From указан URI sip:6012345@172.26.2.11, а в поле Contact - sip:3333@172.26.2.11. Оба URI имеют один и тот же адрес - 172.26.2.11. Во всех остальных сообщениях "180 Ringing" я вижу то же самое. Таким образом, функция отработала правильно. Ожидание же адреса 172.26.2.22 было ошибочным, так как это не тот адрес, который присутствует в поле From.

[san]

Я забыл что применённое в #384 решение где мы брали для Маскарадинга внешний адрес платы мы заменили на #390, и теперь адрес берётся из поля From.
Придётся изменить тестовую прошивку - нужно для маскарадинга использовать внешний ipv4 адрес платы.

[alx]

А какой порт указывать в Contact?

[san]

Решили что 5060, т.к. это порт способный принимать сип сообщения на внешнем адресе

[alx]

Экспериментальная прошивка отправлена автору тикета в telegram.