Формировать и обрабатывать заголовок Remote-Party-ID

[alx]

Для улучшения совместимости с существующим оборудованием/софтом предлагается добавить глобальную настройку, определяющую, куда шлюз помещает информацию о вызывающем абоненте (например Caller-ID, принятый канальным окончанием FXO из абонентской линии) при исходящем вызове в сторону сети IP. В настройке должно быть (для начала) два варианта:

• в поле From - вариант по умолчанию, как все работает в настоящий момент;
• в поле Remote-Party-ID - имя/номер вызывающего помещается в поле Remote-Party-ID, при этом в поле From должен быть URI, указанный в конфигурации канального окончания.

Позже выбор может быть дополнен другими вариантами (например P-Asserted-Identity).

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

• RPID-PAI-FROM: поле Remote-Party-ID, если нет, то поле P-Asserted-Identity, если нет то поле From. Вариант по умолчанию.
• PAI-RPID-FROM: поле P-Asserted-Identity, если нет, то поле Remote-Party-ID, если нет то поле From.
• RPID-FROM: поле Remote-Party-ID, если нет то поле From.
• PAI-FROM: поле P-Asserted-Identity, если нет то поле From.
• FROM: только из поля From.

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

• использовать глобальную настройку (вариант по умолчанию);
• поле From;
• поле Remote-Party-ID;
• поле P-Asserted-Identity.

[alx]

Также опционально при трансляции вызова из соединительной линии в SIP помещать имя/номер вызывающего абонента не в поле From:, а в Remote-Caller-ID:, оставляя в поле From: URL шлюза.

[alx]

Добавил в описание тикета поле P-Asserted-Identity как потенциальный источник Caller-ID. Сейчас оно используется при получении ответа на вызов, позволяя в CDR видеть, кто реально ответил на вызов (при сложных сценариях вызова, когда вызывается сразу группа абонентов или выполняется переадресация).

Предлагается добавить настройку, определяющую, из какого поля брать caller-id со следующими вариантами:

• From;
• P-Asserted-Identity, From;
• Remote-Party-ID, From;
• P-Asserted-Identity, Remote-Party-ID, From;
• Remote-Party-ID, P-Asserted-Identity, From.

Не знаю пока, где такую настройку сделать. Вариант сделать глобальную настройку мне не очень нравится, так как не позволяет сделать разные настройки разным канальным окончаниям. В случае же настройки в каждом канальном окончании возникает вопрос, как быть с CDR, ибо на момент обработки SIP-сообщений и формирования CDR еще неизвестно, какое канальное окончание получит сообщение (и вообще получит ли его шлюз)... Так что пока склоняюсь к глобальной настройке.

Также канальным окончаниям предлагается сделать настройку, определяющую способ передачи Caller-ID при вызове в направлении сети IP:

• From;
• P-Asserted-Identity;
• Remote-Party-ID.

Использование P-Asserted-Identity или Remote-Party-ID позволит при формировании INVITE оставлять поле Fromn таким, какие оно сконфигурировано, избежав таким образом проблем типа #324, когда сервер требует совпадения имени пользователя в поле From с именем аутентификации.

[alx]

Так как P-Asserted-Identity - стандарт, а Remote-Party-ID - draft, основным вариантом принят P-Asserted-Identity.

[alx]

Хм... Так просто достичь желаемого не получается: при получении входящего вызова от внешнего SIP-пользователя repro заменяет P-Asserted-Identity на URI аутентифицированного пользователя, в данном случае шлюза. Таким образом, caller-id теряется...

Попробуем применить Remote-Party-ID...

[alx]

Эксперименты показали, что Remote-Party-ID успешно решает проблему, описанную в #324: прокси успешно аутентифицирует клиента, так как имя в поле From не меняется, при этом телефоны отображают реальные имя/номер вызывающего абонента, помещенные в поле Remote-Party-ID. Описание тикета очередной раз скорректировано.