Opened 10 years ago
Closed 5 years ago
#11 closed улучшение (fixed)
Формировать и обрабатывать заголовок Remote-Party-ID
| Reported by: | alx | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | any | Keywords: | |
| Cc: |
Description (last modified by )
Для улучшения совместимости с существующим оборудованием/софтом предлагается добавить глобальную настройку, определяющую, куда шлюз помещает информацию о вызывающем абоненте (например 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.
Change History (7)
comment:1 by , 10 years ago
| Priority: | низкий → средний |
|---|
comment:2 by , 5 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | Обрабатывать заголовок Remote-Caller-ID → Обрабатывать заголовок Remote-Party-ID |
Добавил в описание тикета поле 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 с именем аутентификации.
comment:3 by , 5 years ago
| Milestone: | → 1 очередь |
|---|
comment:4 by , 5 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | Обрабатывать заголовок Remote-Party-ID → Обрабатывать заголовок P-Asserted-Identity |
Так как P-Asserted-Identity - стандарт, а Remote-Party-ID - draft, основным вариантом принят P-Asserted-Identity.
comment:5 by , 5 years ago
Хм... Так просто достичь желаемого не получается: при получении входящего вызова от внешнего SIP-пользователя repro заменяет P-Asserted-Identity на URI аутентифицированного пользователя, в данном случае шлюза. Таким образом, caller-id теряется...
Попробуем применить Remote-Party-ID...
comment:6 by , 5 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | Обрабатывать заголовок P-Asserted-Identity → Формировать и обрабатывать заголовок Remote-Party-ID |
Эксперименты показали, что Remote-Party-ID успешно решает проблему, описанную в #324: прокси успешно аутентифицирует клиента, так как имя в поле From не меняется, при этом телефоны отображают реальные имя/номер вызывающего абонента, помещенные в поле Remote-Party-ID. Описание тикета очередной раз скорректировано.
Также опционально при трансляции вызова из соединительной линии в SIP помещать имя/номер вызывающего абонента не в поле From:, а в Remote-Caller-ID:, оставляя в поле From: URL шлюза.