Ответы, не представленные sip-сервлету, когда proxyTo используется более одного раза
У меня возникли проблемы при разработке приложения SIP-прокси, которое должно передавать запрос нескольким адресатам.
Таким образом, при получении звонков он должен:
- прокси для Боба. Если звонящий отменяет, отмените прокси.
- если Боб не отвечает в течение X секунд, отмените прокси для Боба и перенаправьте запрос Алисе.
- если Боб ответил в течение X секунд, установите вызов
главная проблема, которую я вижу, это после второго прокси (Алисе). Для первого прокси мое приложение получает вызовы doCancel, и вызовы устанавливаются правильно, если на них ответили в течение тайм-аута. Тем не менее, для второй операции прокси я вижу:
- входящие сообщения CANCEL не приводят к вызову doCancel в моем приложении
- входящие 200 OK от Алисы не приводят к тому, что doSuccessResponse вызывается в моем приложении
создается впечатление, что контейнер не может найти подходящие сеансы для обработки каких-либо сообщений после повторной отправки запроса.
Я считаю, что это должно работать нормально с использованием Proxy API. Кто-нибудь сделал что-нибудь подобное? какие-либо предложения о том, как решить эту проблему дальше?
Это использует restcomm-sip-servlets-4.0.119-apache-tomcat-8.0.26.
Для вопроса 1, например, я вижу:
2017-09-04 12: 54: 05,599 DEBUG [DialogFilter] (pool-AffinityJAIN-thread-2) Получен ОТМЕНА, InviteServerTx = gov.nist.javax.sip.stack.SIPServerTransactionImpl@b15db597 отменить Tx ID сервера = gov.nist.javax.sip.stack.SIPServerTransactionImpl @ a131bdbd isMapped = false
2017-09-04 12: 54: 05,599 DEBUG [DialogFilter] (pool-AffinityJAIN-thread-2) Слишком поздно для отмены транзакции
похоже, что ответ 487, завершающий первую прокси-транзакцию, заставляет контейнер поверить, что вторые сеансы / транзакции прокси уже завершены?
Для выпуска 2 я вижу:
2017-09-04 12: 54: 45096 ОТЛАДКА [ResponseDispatcher] (пул-AffinityJAIN-нить-13) Пытаясь найти сеанс с последующим сеансового ключа (06a432a1aa2e71e39e59a283fb00; 01e82f1aa2e71f49e59a283fb00; 06a432a1aa2e71e49e59a283fb00; d3ea5ab3; SipProxy)
2017-09-04 12: 54: 45096 ОТЛАДКА [ResponseDispatcher] (пул-AffinityJAIN-нить-13) Пытаясь найти сеанс с последующим сеансового ключа (01e82f1aa2e71f49e59a283fb00; 06a432a1aa2e71e39e59a283fb00; 06a432a1aa2e71e49e59a283fb00; d3ea5ab3; SipProxy)
2017-09-04 12:54:45,096 Обнаружен сеанс DEBUG [ResponseDispatcher] (pool-AffinityJAIN-thread-13)
2017-09-04 12:54:45,096 DEBUG [SipManagerDelegate] (pool-AffinityJAIN-thread-13) sip-сессии, присутствующие в менеджере сеансов
2017-09-04 12:54:45,096 DEBUG [ResponseDispatcher] (pool-AffinityJAIN-thread-13) Отбрасывание ответа, так как для него не найдено активного сеанса SIP: SIP/2.0 200 OK
так что опять похоже, что контейнер неправильно разделяет сеансы / транзакции первой прокси-операции с сеансами / транзакциями второй прокси-операции?
Просто чтобы уточнить, я не звоню
proxy.proxyTo (Боб, Алиса)
вместо этого я делаю:
proxy.proxyTo (Bob)
затем в ответ на ошибку (либо потому, что Боб ответил, либо контейнер выдал 487 из-за отмены приложения), я использую снова:
proxy.proxyTo (Алиса)
Я не могу использовать proxyTo (Боб, Алиса), потому что в конечном итоге Боб будет иметь N параллельных адресатов, поэтому снова мне нужно будет сначала прокси-сервер для N адресатов, а затем прокси-сервер позже для M адресатов, если первый набор из N адресатов не ответил OK в течение тайм-аут.
Кто-нибудь есть какие-либо предложения о том, как добиться такого поведения?