проблема с удержанием Cisco в SIP-транке

[Eng Mohamed Saber]

Здравствуйте, уважаемые коллеги, У меня возникла проблема с настройкой нового CUBE: когда пользователь совершает исходящий звонок с IP-телефона Cisco и ставит его на удержание, все работает нормально, и он может успешно снять удержание. Но когда тот же IP-телефон Cisco принимает входящий звонок и пытается поставить его на удержание, он зависает и не может возобновить разговор. Если он пытается сделать это со старого голосового шлюза, все работает нормально. Я проверил MRGL, и все выглядит нормально. Поток вызовов следующий: (ITSP >> CUBE >>> CUCM >>> IP-телефон). Также при переадресации входящего вызова возникает та же проблема. Есть ли какие-нибудь идеи?

[M02@rt37]

Здравствуйте
[, @Eng Mohamed Saber] Когда IP-телефон пытается отменить удержание или перевести входящий вызов, CUBE облегчает обмен сигналами между CUCM и ITSP. Проблемы могут возникнуть, если CUBE неправильно обрабатывает сообщения SIP REFER или re-INVITE, которые часто используются в таких сценариях. Вы должны включить отладку SIP на CUBE с помощью
сообщений debug ccsip,
чтобы наблюдать за потоком сигналов. Обратите внимание на неожиданные ответы, такие как
488 Not Acceptable Here
или
500 Internal Server Error,
при попытке приостановить/возобновить удержание или перевести вызов. Эти ошибки могут указывать на неправильную настройку обработки CUBE сигналов во время вызова. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

[Eng Mohamed Saber]

Здравствуйте, уважаемые коллеги! Проблема была решена после перемещения Sip Tenant в входящий Dial Peer. Большое спасибо

[Eng Mohamed Saber]

Здравствуйте, Да, я уже сделал это, и вдруг, после попытки поставить на удержание, провайдер выдал нам ошибку «401 unauthorized» Скриншот приведен ниже. ![EngMohamedSaber_0-1733580915073.png]

[Roger Kallberg]

Поскольку это исходит от вашего поставщика услуг, вы спросили у них, почему они так отвечают? ![Response Signature]

[Eng Mohamed Saber]

Здравствуйте, Роджер, Я думаю, что понял, в чем проблема. Проверив рабочий исходящий поток в режиме удержания и входящий поток, я обнаружил, что повторный вызов для рабочего звонка имеет аутентификацию SIP, а звонок имеет проблему, не содержащую аутентификацию SIP. Я проверил наборные пары и обнаружил, что SIP-арендатор выходит только на исходящей наборной паре. Но входящий наборный пир не имеет SIP-арендатора. Поэтому я добавлю SIP-арендатора к входящему набору номера и надеюсь, что это сработает. Мой последний вопрос: повторный вызов использует тот же SIP-арендатор входящего набора номера или он может преобразоваться в исходящий набор номера? Я внесу это изменение и обновлю информацию здесь, если это решит проблему.

[M02@rt37]

@Eng Mohamed Saber SIP re-INVITE обычно использует тот же диалоговый пир, который был сопоставлен во время первоначальной настройки вызова; для входящих вызовов это будет входящий диалоговый пир. Однако, если есть несоответствие в конфигурации, например, отсутствующие настройки SIP-арендатора, несоответствие кодеков или изменения в сигнализации, re-INVITE может завершиться сбоем или попытаться сопоставить другой диалоговый пир. В вашем случае добавление конфигурации SIP-арендатора к входящему набору номера должно решить проблему, обеспечив правильную обработку SIP-сигнализации для удержания/отмены удержания и перевода входящих вызовов. Убедитесь, что входящие и исходящие наборы номера последовательно настроены для кодеков, SIP-арендатора и транспортных протоколов, чтобы избежать несоответствий... Это должно позволить re-INVITE функционировать правильно без преобразования в исходящий набор номера. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените .ı|ı.ı|ı.

[Eng Mohamed Saber]

Большое спасибо за ваш отзыв, я протестирую его и обновлю дело.