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

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

ОБНОВЛЕНИЕ:

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

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

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

ОБНОВЛЕНИЕ:

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

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

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;
}

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


person TacB0sS    schedule 01.07.2010    source источник
comment
Какие сообщения? Предварительные ответы? Окончательные ответы? Вы используете UDP? Вы говорите с UAS RFC 2543 или UAS RFC 3261?   -  person Frank Shearar    schedule 01.07.2010
comment
Имеет ли значение, ответ это или запрос? предварительный или окончательный? Разве не существует более низкой общности для всех сообщений, что я могу идентифицировать повторяющиеся сообщения?   -  person TacB0sS    schedule 01.07.2010
comment
Что ж, это помогает ответить на вопрос :) Повторные передачи запросов / ответов обрабатываются по-разному.   -  person Frank Shearar    schedule 01.07.2010
comment
@Frank Shearar Я думаю, он спрашивает, как обнаружить / распознать, что сообщение повторяется (не спрашивая, как с ним обращаться после того, как он его обнаружит).   -  person ChrisW    schedule 01.07.2010
comment
Вы правы, и я уточнил свой вопрос. Спасибо вам.   -  person TacB0sS    schedule 01.07.2010


Ответы (2)


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

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

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

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

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

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

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

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

На этом уровне ответы каким-то образом не передаются повторно. Я должен сказать: UAS не использует логику повторной передачи для отправки множества предварительных ответов (если он не реализует RFC 3262). 200 OK на INVITE отправляются повторно, потому что они уничтожают транзакцию UAC. Вы можете избежать их повторной передачи, своевременно отправляя свои ACK.

person Frank Shearar    schedule 01.07.2010
comment
Я обновил свой вопрос несколькими сообщениями между UAC и UAS после получения ответа об ошибке, то же самое касается 4xx и 5xx, которые я получил. - person TacB0sS; 01.07.2010
comment
Я начал реализовывать, используя ваше объяснение, оно отлично работает, спасибо! - person TacB0sS; 03.07.2010

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

  • Cseq
  • Call-ID
  • и название метода (например, "ПРИГЛАСИТЬ")

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

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

person ChrisW    schedule 01.07.2010
comment
Это единственный критерий повторения сообщений ...? Индекс и метод, как насчет идентификатора вызова, не должно ли это быть фактором? - person TacB0sS; 01.07.2010
comment
@ TacB0sS Согласно страницам с 36 по 38 документа ietf.org/rfc/rfc3261.txt CSeq уникален в пределах диалога, а Call-ID идентифицирует группу сообщений (или диалог). - person ChrisW; 01.07.2010
comment
Это более сложно, чем это; Я получу ответ по RSN. - person Frank Shearar; 01.07.2010