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

Reply to CUBE будет обрабатывать два заголовка перенаправления с SIP-профилем on Wed, 18 Feb 2026 21:10:12 GMT

yellomello — Wed, 18 Feb 2026 21:10:12 GMT

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

Reply to CUBE будет обрабатывать два заголовка перенаправления с SIP-профилем on Wed, 18 Feb 2026 21:10:11 GMT

Roger Kallberg — Wed, 18 Feb 2026 21:10:11 GMT

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

Reply to CUBE будет обрабатывать два заголовка перенаправления с SIP-профилем on Wed, 18 Feb 2026 21:10:10 GMT

yellomello — Wed, 18 Feb 2026 21:10:10 GMT

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

Reply to CUBE будет обрабатывать два заголовка перенаправления с SIP-профилем on Wed, 18 Feb 2026 21:10:09 GMT

b.winter — Wed, 18 Feb 2026 21:10:09 GMT

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

Reply to CUBE будет обрабатывать два заголовка перенаправления с SIP-профилем on Wed, 18 Feb 2026 21:10:08 GMT

Roger Kallberg — Wed, 18 Feb 2026 21:10:08 GMT

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

Reply to CUBE будет обрабатывать два заголовка перенаправления с SIP-профилем on Wed, 18 Feb 2026 21:10:07 GMT

b.winter — Wed, 18 Feb 2026 21:10:07 GMT

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

Reply to CUBE будет обрабатывать два заголовка перенаправления с SIP-профилем on Wed, 18 Feb 2026 21:10:06 GMT

Roger Kallberg — Wed, 18 Feb 2026 21:10:06 GMT

Возможно, это не имеет прямого отношения к вашему вопросу о двух заголовках 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]@(.)>

Reply to CUBE будет обрабатывать два заголовка перенаправления с SIP-профилем on Wed, 18 Feb 2026 21:10:05 GMT

yellomello — Wed, 18 Feb 2026 21:10:05 GMT

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