Какова будет лучшая реализация для обнаружения повторяющегося сообщения SIP? - PullRequest
Новая
       12

Какова будет лучшая реализация для обнаружения повторяющегося сообщения SIP?

2 голосов
/ 01 июля 2010

Я написал SIP UAC, и я попробовал несколько способов обнаружить и игнорировать повторяющиеся входящие сообщения от UAS, но с каждым попыткой подхода что-то пошло не так, моя проблема в том, что все сообщения, которые имеют делать с одним и тем же вызовом имеет одну и ту же сигнатуру, и сравнивать весь текст сообщения - слишком много, поэтому мне было интересно, какой параметр, составляющий сообщение, я должен смотреть при попытке обнаружить эти повторяющиеся сообщения.

UPDATE:

У меня была проблема с входящими опциями, которую я обработал, отправив серверу пустой ответ Ok. (Обновление: после некоторого времени тестирования я заметил, что время от времени я получаю еще один запрос параметров, несколько раз в несколько секунд, поэтому я пытаюсь ответить ошибочным запросом, и теперь я получаю запрос параметров только один / два раза каждая регистрация / перерегистрация)

В настоящее время у меня есть повторяющиеся сообщения SessionInPogress и различные сообщения об ошибках, такие как занятость здесь, и недоступность, я получаю очень много таких сообщений, и это портит мой журнал, я хотел бы отфильтровать их.

есть идеи, как этого добиться?

UPDATE:

Я попробую вашу технику, прежде чем отправлять обратно, возможно, это решит мои проблемы

Вот то, что я использовал, это прекрасно работает: 

private boolean compare(SIPMessage message1, SIPMessage message2) {
    if (message1.getClass() != message2.getClass())
        return false;
    if (message1.getCSeq().getSeqNumber() != message2.getCSeq().getSeqNumber())
        return false;
    if (!message1.getCSeq().getMethod().equals(message2.getCSeq().getMethod()))
        return false;
    if (!message1.getCallId().equals(message2.getCallId()))
        return false;
    if (message1.getClass()==SIPResponse.class)
        if(((SIPResponse)message1).getStatusCode()!=((SIPResponse)message2).getStatusCode())
            return false;
    return true;
}

Спасибо, Адам.

Ответы [ 2 ]

2 голосов
/ 01 июля 2010

Это немного сложнее, чем ответ ChrisW.

Во-первых, уровень транзакций отфильтровывает большинство повторных передач. Для этого он, в большинстве случаев, сравнивает полученное сообщение со списком текущих транзакций. Если транзакция обнаружена, эта транзакция будет в основном поглощать повторные передачи согласно диаграммам в RFC 3261, раздел 17 . Например, транзакция UAC INVITE в состоянии «Продолжение» отбрасывает задержанную ретранслируемую команду INVITE.

Сопоставление происходит одним из двух способов, в зависимости от удаленного стека. Если это стек RFC 3261 (параметр ответвления на верхнем Via начинается с "z9hG4bK"), то все довольно просто. Раздел 17.2.3 содержит полную информацию.

Подобное совпадение отфильтровывает дубликаты / ретранслируемые опции (которые вы упоминаете как особую проблему). Сообщения OPTIONS не образуют диалогов, поэтому просмотр CSeq не будет работать. В частности, если UAS отправляет пять запросов OPTIONS, которые не являются просто ретрансляциями, вы получите пять запросов OPTIONS (и пять транзакций сервера без INVITE).

Повторно переданные предварительные ответы на транзакцию, не являющуюся INVITE, передаются на уровень Transaction-User, или ядро, как его иногда называют, но, кроме первого, окончательные ответы - нет. (Опять же, вы получите это, просто внедрив FSM для этой транзакции - окончательный ответ переводит транзакцию UAC, не являющуюся INVITE, в состояние «Завершено», что исключает дальнейшие ответы.

После этого уровень Transaction-User обычно получает несколько ответов для транзакций INVITE.

Совершенно нормально, что UAS отправляет несколько 183-х, по крайней мере, для INVITE. Например, он может немедленно отправить 100, чтобы погасить ваши повторные передачи (по крайней мере, по ненадежным транспортам), затем несколько 183, 180, может быть, еще 183 и, наконец, 200 (или больше, для ненадежных транспортов).

Важно, чтобы уровень транзакций передавал все эти ответы, потому что прокси и пользовательские агенты обрабатывают ответы по-разному.

На этом уровне ответы, в некотором роде, не передаются повторно. Я должен сказать: UAS не использует логику повторной передачи для отправки множества предварительных ответов (если только он не реализует RFC 3262 ). Повторно отправляется 200 подтверждений «ПРИГЛАСИТЬ», потому что они уничтожают транзакцию UAC. Вы можете избежать их повторной передачи, своевременно отправляя свои ACK.

0 голосов
/ 01 июля 2010

Я думаю, что сообщение является дубликатом / идентичным, если его ...

  • Cseq
  • Call-ID
  • и имя метода (например, "INVITE"")

... значения совпадают со значениями другого сообщения.

Обратите внимание, что ответное сообщение имеет тот же CSeq, что и запрос, на который оно отвечает;и что за один запрос вы получите несколько предварительных, но не дублирующихся ответов (например, RINGING и OK).

...