Как прервать звонок из Kamailio в случае тайм-аута медиа - PullRequest
0 голосов
/ 27 апреля 2020

Я использую Kamailio версии 5.3.3 и rtpengine версии 8.4.0. И Kamailio, и Rtp-Engine работают на одной машине с Ubuntu. Значение «timeout» в конфигурационном файле rtpengine установлено на 60 секунд.

Я установил sh вызов между двумя SIP-клиентами, зарегистрированными в Kamailio, и передача мультимедиа через rtp-механизм - это прекрасно работает

Чтобы проверить время ожидания мультимедиа rtp, я заблокировал трафик UDP c от клиентов SIP к rtpengine, и по истечении указанного периода я вижу следующий журнал от rtpengine, который, кажется, указывает, что он обнаружил таймаут

rtpengine[2127]: INFO: [R-RVm58r4SUY7Cz6GW-D5w..]: Closing call due to timeout

Однако даже после этого звонок прерывается. Итак, мой вопрос:

Как заставить Kamailio завершить вызов, когда rtp-движок обнаруживает тайм-аут медиа. Какие изменения (если они есть) в kamailio cfg необходимы для этого?

ОБНОВЛЕНИЕ

Прикрепили текущие файлы kamailio.cfg и rtpengine.conf после маскировки IP-адресов

В основном мое требование заключается в том, что если один ( или оба) из SIP-клиентов в вызове либо погибают, либо теряют сеть, либо прекращают отправку мультимедиа - должен быть способ идентифицировать это в Kamailio и завершить вызов.

Конфигурация Kamailio: https://pastebin.com/s4akZSfa Rtpengine config: https://pastebin.com/7xzejiYW

Я отлаживал эту проблему дальше, и у меня есть две отдельные проблемы:

Первый выпуск :

Проблема, о которой я упоминал ранее - когда я блокирую трафик RTP c от обоих клиентов SIP до RTPEngine, механизм RTP обнаруживает тайм-ауты, как видно из журнала, упомянутого выше, но вызов не завершается. При дальнейшей отладке, насколько я понимаю, rtpengine должен сделать RP C вызов Kamailio, чтобы сказать ему, чтобы завершить диалог - я попытался использовать параметры конфигурации "b2b-url" и "xmlrp c -format" в Для этого, однако, мне не ясно следующее:

a. Какой порт должен быть установлен в конфигурации "b2b-url" в rtpengine? Я пробовал с 80 и 5060, но продолжаю получать отказ в соединении, когда rtpengine пытается сделать запрос скручивания по тайм-ауту носителя

b. Какой модуль Kamailio должен быть загружен для этого - есть модуль XMLRP C, модуль XHTTP RP C и модуль JSONRPCS - какой нужен для этого?

Второй выпуск Вторая проблема заключается в том, что если вместо того, чтобы RTP traffi c блокировался на обоих устройствах, он блокировался только на одном из этих устройств - тогда похоже, что rtpengine даже не может определить время ожидания мультимедиа, то есть я не см. журнал Closing call due to timeout в системном журнале, который я видел, когда трафик c с обоих устройств был заблокирован. Я предполагаю, что должен быть способ обнаружить это - чтобы справиться со случаем, когда одно устройство, скажем, теряет сеть или прекращает отправку мультимедиа - как я могу обнаружить и предпринять действия, основанные на этом?

1 Ответ

0 голосов
/ 28 апреля 2020

Хорошо, поэтому я, скорее всего, выяснил Первый выпуск - Когда обе стороны RTP traffi c отключены, и rtpengine может обнаружить тайм-аут, но вызов не заканчивается.

Было две проблемы с моей конфигурацией:

  1. Из rtpengine я отправлял запрос RP C на 127.0.0.1:5060, но в kamailio.cfg он прослушивал локальный IP-адрес (10.xxx) - когда я изменил его на 0.0.0.0 в kamailio.cfg, rtpengine смог установить sh connection

  2. Из rtpengine значение xmlrp c -format должно быть 2 вместо 1, кажется (не очень уверен в этом) - 1 означает команду teardown , тогда как 2 означает команду dlg.terminate_dlg . Также диалоговый модуль не был загружен в kamailio.cfg. После загрузки диалогового модуля в kamailio и установки значения xmlrp c -format в 2 в rtpengine.conf - теперь, когда RTP traffi c с обеих сторон заблокирован, Kamailio завершает чистый вызов.

Однако я все еще не смог выяснить Второй выпуск , упомянутый выше - почему rtpengine не может обнаружить тайм-аут носителя, если остановлен только один из сторон RTP-трафика c

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...