CUBE будет обрабатывать два заголовка перенаправления с SIP-профилем

[yellomello]

Всем привет! Сценарий следующий: ITSP > CUBE > CUCM > Телефон A Переадресация вызова на телефон B > Переадресация вызова с телефона B на мобильный телефон > CUCM > CUBE > ITSP В рамках вышеуказанного сценария CUCM отправляет два заголовка Diversion в рамках INVITE, отправляемого в CUBE. Получено:
INVITE sip:destinationnumber@address:5060 SIP/2.0
Diversion: «Телефон 3» sip:numberphoneB@ip-address;reason=unconditional;privacy=off;screen=yes
Переадресация: «Телефон 2» sip:numberphoneA@ip-address;reason=unconditional;privacy=off;screen=yes
P-Preferred-Identity: sip:number-of-initial-caller@ip-address Вот важные части конфигурации: класс голоса sip-copylist 1000
sip-header P-Preferred-Identity
sip-header Diversion
!
dial-peer voice 1001 voip
description ### Из CUCM ###
класс голоса sip copy-list 1000
! класс голоса sip-profiles 2051
правило 1 запрос INVITE peer-header sip P-Preferred-Identity копировать «sip:(.)@» u01
правило 2 запрос INVITE peer-header sip Diversion копировать «sip:(.)@» u01
правило 3 запрос INVITE sip-header P-Preferred-Identity изменить «sip:.*@(.*)" "sip:\u01@provider.com"
!
dial-peer voice 2051 voip
description ### К поставщику услуг ###
voice-class sip profiles 2051
!
SIP-профиль работает нормально, когда есть один заголовок Diversion, но не работает с двумя заголовками Diversion, потому что в этом случае CUBE выполняет следующие действия с исходящим INVITE к ITSP. Отправлено:
INVITE sip:destination-number@provider.com:5060 SIP/2.0
P-Preferred-Identity: sip:numberPhoneB@ip-address;reason=unconditional;privacy=off;screen=yes,"Phone 2" sip:numberphoneA@provider.com И, конечно же, провайдер не может обработать это и отклоняет вызов. Есть ли какие-либо идеи, почему CUCM отправляет два заголовка Diversion, как я могу этого избежать или как CUBE может обработать два заголовка Diversion с данным SIP-профилем? Заранее большое
спасибо, Майкл

[yellomello]

Обновление:
для устранения этой проблемы необходимо изменить правило 2 следующим образом: правило 2 запрос INVITE peer-header sip Diversion copy "sip:([^@>]+)@.*" u01 С помощью этого регулярного выражения CUBE останавливается на символе «@» первого заголовка перенаправления, а не второго.

[Roger Kallberg]

Возможно, это не имеет прямого отношения к вашему вопросу о двух заголовках Diversion, но вы не можете использовать одну
и ту же
переменную в вашем SIP-профиле для двух операторов copy. voice class sip-profiles 2051
rule 1 request INVITE peer-header sip P-Preferred-Identity copy "sip:(.)@"
u01
rule 2 request INVITE peer-header sip Diversion copy "sip:(.)@"
u01
rule 3 request INVITE sip-header P-Preferred-Identity modify "sip:.*@(.*)" "sip:\u01@provider.com" Попробуйте вместо этого voice class sip-profiles 2051
rule 1 request INVITE sip-header P-Preferred-Identity copy "sip:(.)@" u01
rule 2 request INVITE peer-header sip Diversion copy "sip:(.)@" u02
rule 3 request INVITE sip-header P-Preferred-Identity modify "
<
sip:
.@(.)
>
" "
<
sip:
\u01@provider.com
>
" Согласно тестеру профилей SIP, который теперь снова доступен по этой ссылке
https://cway.cisco.com/csa-new/#/sipprofiletest,
он, похоже, берет скопированное значение из Preferred Identity в правиле 1 и использует его в правиле 3. ![image.png] ![Response Signature]</sip:\u01@provider.com></sip:.@(.)>

[b.winter]

Привет, Майкл,
я сомневаюсь, что CUCM добавляет второй заголовок Diversion. Скорее всего, SIP-сообщение уже поступает в CUCM извне с двумя заголовками. В большинстве случаев, когда у меня возникала эта «проблема», входящий вызов от SIP-провайдера уже содержал заголовок Div, потому что провайдеры не «очищают» свои сообщения (они часто говорят мне, что это «не их дело»).
Поэтому, возможно, стоит проверить такие звонки, откуда они поступают, а затем «очистить» ваше сообщение уже в первой точке входа.
Например, вы можете добавить профиль входящего SIP, чтобы удалить заголовок перенаправления, когда звонок поступает из PSTN. Он удалит заголовок, если он есть, а если заголовка нет, то просто ничего не сделает. @Roger Kallberg
:
Да, вы можете использовать ту же переменную в качестве временного хранилища. Она просто перезаписывается.

[Roger Kallberg]

@b.winter
Конечно, вы можете это сделать, но какой в этом смысл, если вы сможете использовать только значение последнего оператора copy? ![Response Signature]

[b.winter]

В Германии существует более или менее стандартный «шаблон» с этими тремя правилами, согласно которому PAI или PPI заполняются номером, принадлежащим диапазону номеров SIP-транка, для «аутентификации» вызовов (обычных исходящих и перенаправленных внешних вызовов). Если это исходящий вызов, правило 2 не может быть выполнено, и вы скопируете PAI/PPI из входящего сообщения (из CUCM) в исходящее сообщение (в PSTN). Если это перенаправленный вызов, поступающий извне, PAI / PPI будет внешним номером, и поэтому вызов не будет выполнен.
Поэтому вы перезаписываете PAI / PPI номером заголовка перенаправления (который может быть только внутренним номером).

[yellomello]

Привет, Роджер, спасибо за информацию. Копирование заявлений имеет конкретную причину. Если в INVITE нет заголовка Diversion, то будет использоваться PPI, отправленный Call Manager, поскольку это действительный PPI, так как вызов инициирован собственным телефоном компании, поэтому номер стационарного телефона правильный и соответствует номеру, предоставленному ITSP. Но если в INVITE присутствует заголовок переадресации, то PPI будет перезаписан значением заголовка переадресации, поскольку PPI, отправленный CUCM, является номером первоначального вызывающего абонента (в данном случае внешнего). На самом деле это очень действительный сценарий конфигурации, который, конечно же, проверен во многих клиентских средах. Проблема здесь действительно заключается в двух заголовках Diversion Headers от CUCM, которые вызывают эту проблему. Если есть один заголовок Diversion Header, все работает как ожидается, но не с двумя заголовками Diversion Headers. Правило SIP-профиля должно останавливаться на первом знаке @, но оно проходит до второго знака @ во втором заголовке Diversion Headers и вызывает проблему. Я уже пробовал добавить IP-адрес (для лучшего соответствия), но это не помогло, потому что он одинаков для обоих.

[Roger Kallberg]

@yellomello
Спасибо за разъяснение вашего случая использования, все понятно. ![Response Signature]

[yellomello]

На данный момент я нашел временное решение, которое может подойти для конкретного случая использования у клиента, но оно может иметь некоторые проблемы. Я изменил правило 2 на следующее:
правило 2 запрос INVITE peer-header sip Diversion copy "<sip:(+...............)@" u01 Я взял это из этого поста:
[Копирование]
[SIP-профиля с двумя @ в заголовке History-Info — Cisco Community] Статическое сопоставление на основе номера пока работает, но это определенно не динамическое решение.