Обрабатывать заголовок P-Asserted-Identity

[alx]

При наличии заголовка P-Asserted-Identity опционально брать имя/номер вызывающего абонента из него, а не из заголовка From.

Дополнительно можно обрабатывать поле Remote-Party-ID.

[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.