Модифицировать поле TO в Sip-маршрутах

[san]

От двух разных пользователей мне недавно поступили просьбы(предложения) о модификации ПО платы VE-02. Пользователи просят добавить в маршрутах, кроме возможности модификации Request-URI, ещё и возможность модификации поля TO вызова.

Причина такой просьбы в том, что некоторые сторонние АТС оказались "чувствительны" к содержанию поля TO.
Примеры:
У пользователя1 АТС Протей в диалоге отправляет реинвайт, почему-то указывая в поле FROM uri взятый ей из поля TO исходного инвайта. Пользователю нужно модифицировать поле TO, чтобы FROM реинвайта содержал корректный домен.

У пользователя2 шлюз GoIP ищет абонента для передачи вызова не по Request-URI, а по "номерной части" содержимого поля TO вызова. Пользователю нужно убрать префикс из номера в поле TO, чтобы вызов попал в нужного абонента.

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

[mixyil1.1]

Replying to san:

По моему мнению возможность модификации поля TO может добавить больше проблем (ломаются все диалоги, если не вернуть поле to в исходное состояние при пересылке ответа), чем пользы.

У пользователя1 АТС Протей в диалоге отправляет реинвайт, почему-то указывая в поле FROM uri взятый ей из поля TO исходного инвайта. Пользователю нужно модифицировать поле TO, чтобы FROM реинвайта содержал корректный домен.

Это стандартное поведение при формирования запроса внутри диалога.
Как формируется запрос в диалоге (реинвайт от Протей).

12.2.1 UAC Behavior
12.2.1.1 Generating the Request
The URI in the To field of the request MUST be set to the remote URI from the dialog state.
The tag in the To header field of the request MUST be set to the remote tag of the dialog ID.
The From URI of the request MUST be set to the local URI from the dialog state.

В FROM URI ДОЛЖНО быть установленно значение local URI диалога.

Как формируется состояние диалога согласно RFC3261. Если INVITE поступает на АТС Протей в local URI должено быть записано значение TO URI из запроса.

12.1.1 UAS behavior
The remote URI MUST be set to the URI in the From field, and the
local URI MUST be set to the URI in the To field.

Если INVITE посылает АТС Протей в local URI должено быть записано
значение FROM URI из запроса.

12.1.2 UAC Behavior
The remote URI MUST be set to the URI in the To field, and the local
URI MUST be set to the URI in the From field.

Учитывая что пользователь хочет возможность изменять TO при маршрутизации запроса, можно предположить что первоначальный запрос INVITE идет в сторону Протей. В такой ситуации АТС Протей ведет себя коректно при формировании реинвайт запроса.

У пользователя2 шлюз GoIP ищет абонента для передачи вызова не по Request-URI, а по "номерной части" содержимого поля TO вызова. Пользователю нужно убрать префикс из номера в поле TO, чтобы вызов попал в нужного абонента.

Эта проблема скорее всего решается настройкой шлюза.

[alx]

Replying to san:

Причина такой просьбы в том, что некоторые сторонние АТС оказались "чувствительны" к содержанию поля TO.
У пользователя1 АТС Протей в диалоге отправляет реинвайт, почему-то указывая в поле FROM uri взятый ей из поля TO исходного инвайта.

Верно ли я понял, что под "чувствительностью к содержанию поля To", о которой ты писал выше, ты как раз и подразумевал то, что АТС помещает его содержимое в поле FROM при отправке re-INVITE? Кто был инициатором соединения (кто отправил первоначальный INVITE) - АТС или удаленная сторона? Если удаленная сторона, то это ИМХО нормально, что Протей в re-INVITE передает в поле From URI из поля To первоначального INVITE.

Пользователю нужно модифицировать поле TO, чтобы FROM реинвайта содержал корректный домен.

Выше ты писал, что Протей указывает в поле From URI, взятый из поля To первоначального INVITE. Следовательно, домен в поле To первоначального INVITE уже был некорректен. Почему пользователь1 обращается к нам с просьбой добавить функционал для борьбы со следствием проблемы вместо того чтобы устранить саму проблему (некорректный домен в URI исходного INVITE)? По-моему было бы логичнее и правильнее устранить саму проблему, чем бороться с ее последствиями. Обращался ли пользователь1 к администратору/владельцу UAC, отправляющему исходный INVITE с некорректным доменом?

У пользователя2 шлюз GoIP ищет абонента для передачи вызова не по Request-URI, а по "номерной части" содержимого поля TO вызова.

IMHO это очевидно неправильное поведение, как минимум, потому что оно "ломает" переадресованные вызовы. Предполагаю, что этот GoIP либо неправильно настроен, либо "сломан" (неверно работает в принципе). Опять же, почему пользователь2 обращается к нам с просьбой разработать и реализовать специальный механизм обхода существующей проблемы вместо того чтобы устранить саму проблему? По-моему ему следует обратиться к администратору/владельцу GoIP с просьбой изменить настройки/прошивку (или что там у него внутри определяет поведение) так, чтобы цель вычислялась на основе Request-URI, а не поля To.

Пользователю нужно убрать префикс из номера в поле TO, чтобы вызов попал в нужного абонента.
Тех.поддержки от производителей стороннего оборудования пользователи не получили,

Подожди... В первом примере источником проблемы является некорректный домен в сообщении, отправляемым каким-то UAC. При чем тут производитель? Домен же задается где-то в настройках, невозможно представить, что производитель устройства "забил гвоздями" в прошивке какой-то домен, и не дал никакой возможности его изменить. Насколько я понимаю, этот домен вписал не производитель, а администратор/пользователь UA.

поэтому просят нас помочь

Мне не нравится предложение пользователей, так как они предлагают компенсировать "кривость" чужого изделия намеренным введением "кривости" в наше изделие. Я не хочу намеренно вводить кривость в свою разработку, даже опционально. Кривых (тем или иным образом) устройств на свете наверное существует великое множество. Если следовать этому паттерну и реализовывать в нашей плате "костыль" всякий раз, когда владелец платы сталкивается с подобным "кривым" устройством, наша плата вся с ног до головы обрастет этими костылями. Я бы этого не хотел. Это какой-то неправильный подход.

[mixyil1.1]

Небольшое замечание.

Нам, пока, только в одном случае приходилось напрямую манипулировать заголовками в sip сообщении (To, From) - при подключении к SIP транку оператора связи. Требования оператора - в Uri этих заголовков должны быть номера в международном формате,иначе вызов не состоится. (Еще были нюансы с кодами ответа, но в контексте данной задачи это не так важно)

Если действительно нужно как-то "специфически" взаимодействовать с заголовками в SIP сообщении, когда по другому не получается решить проблему, можно посоветовать использовать для этих целей плату MC-03.

[san]

По проблеме пользователя2:
Replying to alx:

IMHO это очевидно неправильное поведение, как минимум, потому что оно "ломает" переадресованные вызовы Предполагаю, что этот GoIP либо неправильно настроен, либо "сломан" (неверно работает в принципе).

Replying to mixyil1.1:

Эта проблема скорее всего решается настройкой шлюза.

Replying to mixyil1.1:

По моему мнению возможность модификации поля TO может добавить больше проблем (ломаются все диалоги, если не вернуть поле to в исходное состояние при пересылке ответа), чем пользы.

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

---

Replying to alx:

Если следовать этому паттерну и реализовывать в нашей плате "костыль" всякий раз, когда владелец платы сталкивается с подобным "кривым" устройством, наша плата вся с ног до головы обрастет этими костылями. Я бы этого не хотел. Это какой-то неправильный подход.

В целом я согласен, но бывают случаи когда "нестандартная" настройка может сделать нашу плату полезнее для пользователей.

---

По проблеме пользователя1:

Replying to alx:

это ИМХО нормально, что Протей в re-INVITE передает в поле From URI из поля To первоначального INVITE.

Replying to mixyil1.1:

Это стандартное поведение при формирования запроса внутри диалога.

Ага, значит Протей ведёт себя здесь корректно. Миша, спасибо за подробный разбор. Тогда давайте, я сейчас весь контекст проблемы предоставлю, чтобы понять, что происходит, кто виноват и что делать...

[alx]

Replying to mixyil1.1:

Нам, пока, только в одном случае приходилось напрямую манипулировать заголовками в sip сообщении (To, From) - при подключении к SIP транку оператора связи. Требования оператора - в Uri этих заголовков должны быть номера в международном формате,иначе вызов не состоится.

Кстати, в VE-01 (VE-02) можно манипулировать номером вызываемого, задавая регулярные выражения набора с заменой. В этом случае в поле To будет уже измененный номер. Это так, небольшое напоминание. :)

[san]

Итак, проблема пользователя1.

При вызове по схеме 1 и 2, после поднятия трубки абонентом Б, вместо ожидаемого успешного разговора, абонент А слышит короткие гудки. В схеме 3 вызов проходит корректно.
От техподдержки Протей пользователь не смог получить комментариев по этой проблеме, надо попробовать разобраться самим.
По успешному эксперименту 3 попробуем понять, алгоритм вызова:

• Si3000 отправляет инвайт на Протей
• При поднятии трубки абонентом Б, Протей отправляет ре-инвайт (ну видимо так у них принято, не знаю зачем)
• Разговор начинается абоненты слышат друг друга, всё хорошо.

Теперь посмотрим на эксперименты 1 и 2

• VE-02 отправляет инвайт на Протей
• При поднятии трубки абонентом Б, Протей отправляет ре-инвайт, в поле FROM реинвайта содержится домен платы VE-02, который предположительно был взят из поля TO исходного инвайта
• VE-02 видит в ре-инвайте в поле FROM свой домен
• Т.к. пользователь свой, то VE-02 отправляет 407 Proxy Authentication Required
• После этого Протей присылает BYE (подозреваю. что она не ожидала увидеть требование аутентификации в диалоге и таким образом "аварийно" завершает диалог)

И вот тут мне не понятно как должно быть правильно, ведь фактически абонент Б, это не абонент платы VE-02 и аутентификацию мы у него просить не можем, он ведь чужой.

IP Si3000 - 172.16.100.70
IP VE-02 - 172.16.110.11
IP Протей - 172.16.200.70

Схема 1
A-> Si3000 -SIP-> VE-02 -SIP-> Протей ->Б
Номер абонента A - 31189
Номер абонента Б - 36901
Дамп1​

Схема 2
A ->...-ISDN.PRI-> VE-02 -SIP-> Протей ->Б
Номер абонента A - 35277
Номер абонента Б - 36901
Дамп2​

Схема 3
A-> Si3000 -SIP-> Протей ->Б
Номер абонента A - 31189
Номер абонента Б - 36901
Дамп3​

[mixyil1.1]

схема 1

[mixyil1.1]

схема 2

[mixyil1.1]

Схема 1 наглядно. Все выглядит, вроде, нормально.
Есть подозрение, что в настройках платы VE стоит галочка "Аутентифицировать запросы из чужих доменов" - INVITE 06

Схема 1 наглядно. Все тоже выглядит, нормально.

Проверить параметр "Аутентифицировать запросы из чужих доменов"

[mixyil1.1]

Replying to alx:

Кстати, в VE-01 (VE-02) можно манипулировать номером вызываемого, задавая регулярные выражения набора с заменой. В этом случае в поле To будет уже измененный номер. Это так, небольшое напоминание. :)

Знаем\помним про эту возможность. В данном случае сложность была еще и в том, что есть список коротких номеров 101, 102..... (порядка 30 номеров), которые тоже должны транслироваться в полный номер в международном формате. И вот для этого списка нет прямого соответствия 101 -> +XXXXXXXX101.

[san]

Replying to mixyil1.1:

Есть подозрение, что в настройках платы VE стоит галочка "Аутентифицировать запросы из чужих доменов"

Так в этом и хитрость что домен в поле From ре-инвайта не чужой. Как мне объяснил alx, у платы VE-02 критерием для определения своих служит наличие своего домена в поле From.

[alx]

Replying to mixyil1.1:

Есть подозрение, что в настройках платы VE стоит галочка "Аутентифицировать запросы из чужих доменов"

В данном случае эта настройка не имеет значения, так как домен не чужой, а свой (172.16.110.11).

[alx]

Replying to san:

И вот тут мне не понятно как должно быть правильно, ведь фактически абонент Б, это не абонент платы VE-02 и аутентификацию мы у него просить не можем, он ведь чужой.

На этот счет по-моему никаких специальных правил нет, то есть в каждой конкретной сети администраторы сами решают, как это в ней будет работать. Самым простым мне видится такой вариант: в плате VE-02 для АТС создается учетная запись SIP, а АТС просят на VE-02 регистрироваться, и дают логин/пароль. Собственно, регистрироваться не обязательно, главное чтобы у АТС были логин/пароль для VE-02. Тогда при получении ответа 407 она сможет отправить re-INVITE с нужной аутентификацией.

Я когда-то, кажется, решал обратную задачу (там у VE-01 кто-то требовал аутентифицироваться) именно так: добавил канальное окончание (на самом деле не нужное), которое регистрировалось на нужной АТС, и в нем прописал логин/пароль.

[alx]

Разглядывая дамп3, я заметил, что Si3000 не просит вызывающего аутентифицироваться. Если для пользователей VE-02 это приемлемый вариант (обычно нет, так как в этом случае любой желающий может воспользоваться услугами связи), то можно в плате VE-02 в файле /etc/repro.conf изменить DisableAuth = false на DisableAuth = true. Но следует учитывать, что при обновлении прошивки платы это изменение пропадет.

[alx]

Я заметил еще одну странность в Дамп3: если я правильно понял, хосты 172.16.100.70 и 172.16.200.70 имеют один и тот же MAC адрес (00:d0:50:66:66:66). =8-() Непонятно, как они в таком случае вообще могут коммуницировать друг с другом. Хотя к теме тикета это вряд ли имеет прямое отношение...

[mixyil1.1]

Протей посылает реинвайт потому что меняет параметры сесии было c=IN IP4 172.16.200.70 - стало c=IN IP4 172.29.100.21. Первое вероятно нужно для early-media, по второму уже пойдет голос. Еще как вариант можно попробовать изменять настройки Протей, например запретить early-media для этого направления, и смотреть будет ли в 200 OK в таком случае окончательное описание сессии, без необходимости слать реинвайт. Но не факт что так сработает.

[alx]

Replying to alx:

Самым простым мне видится такой вариант:

Еще один вариант - настроить SI3000 так, чтобы при отправке первоначального вызова указывала в поле To другой домен (отличный от адреса VE-02). Это решение наверное будет даже проще чем то, что я писал в comment:11.

[mixyil1.1]

Replying to alx:

Еще один вариант - настроить SI3000 так, чтобы при отправке первоначального вызова указывала в поле To другой домен (отличный от адреса VE-02). Это решение наверное будет даже проще чем то, что я писал в comment:11.

Это решает проблемы схемы 1, но не схемы 2

[san]

Replying to alx:

Еще один вариант - настроить SI3000 так, чтобы при отправке первоначального вызова указывала в поле To другой домен (отличный от адреса VE-02). Это решение наверное будет даже проще чем то, что я писал в comment:11.

Этот вариант я уже предлагал пользователю, он не смог настроить это в Si3000

[san]

Теперь мне более-менее понятно, что происходит, всем спасибо за обсуждение.
Попробуем один из методов решения применить у пользователя.

[alx]

Replying to mixyil1.1:

Это решает проблемы схемы 1, но не схемы 2

Я, честно говоря, схему 2 вообще не смотрел. :) Сейчас посмотрю...

Посмотрел. Насколько я понимаю, окончанию PRI в плате VE-02 не назначен параметр "To домен", поэтому при создании INVITE в поле To помещается домен из его собственного URI (который совпадает с адресом платы). Для решения этой проблемы можно прописать адрес АТС Протей либо в параметр "To домен", либо в URI окончания PRI. В последнем случае окончание будет (пытаться) регистрироваться на АТС.

[alx]

По просьбе @san я попытался провести эксперимент по сценарию из Дамп1. Результат оказался неожиданным - плата VE-02 не требует аутентификации re-INVITE! :-/

Дамп​ эксперимента прилагаю для информации. Схема эксперимента:

Абонент А (111@192.168.1.67) ---- VE-02 (192.168.0.182) ----- Абонент Б (505@192.168.0.91)

В плате VE-02 установлен маршрут, который вызов 222@192.168.0.182 форвардит на 505@192.168.0.91.

Ход эксперимента:

• Абонент А вызывает номер 222;
• Абонент Б отвечает;
• Абонент Б ставит абонента А на холд (отправляет re-INVITE);
• Абонент Б снимает абонента А с холда;
• Абонент Б кладет трубку.

Постановка на холд была в 12:47:56. Как видно из дампа, плата VE-02 не отправляла ответ 407, а сразу, без всяких вопросов, отфорвардила INVITE абоненту Б. И вот мне теперь непонятно, в чем принципиальное отличие моего эксперимента от эксперимента 1. Буду пытаться выяснить это позже (завтра)...