Mobicents Обработка ответов об ошибках SIP - каков правильный способ повторного прокси-сервера?

Question

Контейнер сервлета Mobicents SIP, по-видимому, обрабатывает ответы об ошибках по-разному с другими контейнерами SIP, которые я использовал. Ситуация такова, что:

• При получении ПРИГЛАШЕНИЕ, приложение ручки и прокси-серверов (контролируемой) вниз по течению (так что он может получить ответы на приглашение).

• При получении ответа об ошибке от начальной цели прокси-приложения к новому месту назначения (неконтролируемым способом).

Это должно предотвратить распространение первоначальной ошибки в восходящем потоке (поскольку транзакция имеет новую цель). Однако, с контейнером Mobicents, даже несмотря на то, что INVITE действительно проксирован в новое место назначения, первоначально принятый ответ об ошибке по-прежнему распространяется вверх по потоку. Я считаю, что это ошибка в реализации Mobicents, но как это работает?

Код:

public void doInvite(SipServletRequest req) { 
    req.getProxy().proxyTo(req.getRequestURI()); 
} 

public void doError(SipServletResponse res) { 
    Proxy p = res.getProxy(); 
    p.setSupervised(false); 
    p.proxyTo(...); 
    // request is proxied, but the error response still passes 
    // upstream - the retargeting of the transaction (through 
    // proxying to a new destination ought to prevent that). 
} 

Answer 1

Какие другие контейнеры SIP вы миграции приложения из? Вы выполняете последовательное или параллельное проксирование? Какой ответ на ошибку вы получаете? Какую версию контейнера сервлетов Mobicents SIP вы используете? У вас есть полный журнал, доступный на gist.github.com или pastebin.com?

Answer 2

В качестве чистого прокси-решения Mobicents выполняет правильное поведение пересылки ответа об ошибке обратно инициатору вызова, и, следовательно, логика последовательного форкирования [на основе кода ошибки] должна быть обработана на стороне вызывающего абонента.

Но если вы хотите, чтобы это поведение было связано с мобильными устройствами, вам необходимо запустить режим B2BUA для мобильных устройств, которые должны дать вам более подробный контроль над выбором поведения, независимым от двух вызовов (вход/выход).

Оригинатор получает 183-ход вызова для INVITE [входной ножки], в то время как последовательные повторы могут обрабатываться на выходе, без риска начальных тайм-аутов, происходящих на Ingress.