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

Question

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

UPDATE:

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

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

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

UPDATE:

Попробую свой Technics, прежде чем отправлять обратно, возможно, это будет решать мои проблемы

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

• CSeq
• Вызов-ID
имя
• и метод (например, "INVITE")

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

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