Quelle serait la meilleure implémentation pour détecter les messages SIP répétés?

Question

J'ai écrit un UAC SIP, et j'ai essayé plusieurs façons de détecter et d'ignorer la répétition des messages entrants provenant de l'UAS, mais à chaque approche j'ai essayé, quelque chose s'est mal passé, mon problème est que tous les messages doivent faire avec le même appel a la même signature, et de comparer tout le texte du message est trop, donc je me demandais, quel paramètre composer un message dois-je regarder en essayant de détecter ces messages répétitifs.

MISE À JOUR:

J'ai eu un problème avec une des options entrant, que je manipulé avec l'envoi du serveur une réponse Ok vide. (Mise à jour: après un moment de test, j'ai remarqué que je reçois toujours de temps en temps une autre requête d'Options, quelques fois chaque seconde, donc j'essaye de répondre avec une Requête Bad, et maintenant je reçois seulement une fois la requête Options actuellement je répète des messages de SessionInPogress, et différents messages d'erreur tels que occupé ici, et indisponible, je reçois beaucoup de ceux-ci, et il gâche mon journal, je voudrais les filtrer.

une idée de comment y parvenir?

MISE À JOUR:

Je vais essayer votre Technics avant de poster en arrière, peut-être cela résoudrait mes problèmes

Voici ce que je, cela fonctionne bien:

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

Merci , Adam.

Answer 1

C'est un peu plus compliqué que la réponse de ChrisW. D'abord, la couche de transaction filtre la plupart des retransmissions. Il le fait en comparant, pour la plupart des choses, le message reçu à une liste de transactions en cours. Si une transaction est trouvée, cette transaction avalera la plupart des retransmissions selon les diagrammes au RFC 3261, section 17. Par exemple, une transaction UAC INVITE dans l'état Proceeding supprimera une INVITE retransmise différée.

La correspondance s'effectue de deux manières, en fonction de la pile distante. Si c'est une pile RFC 3261 (le paramètre de branche sur la plus haute Via commence par "z9hG4bK") alors les choses sont assez simples. Section 17.2.3 couvre tous les détails. En procédant comme ceci, les OPTIONS dupliquées/retransmises (que vous mentionnez comme étant un problème particulier) seront filtrées comme ceci.Les messages OPTIONS ne forment pas de boîtes de dialogue, donc regarder CSeq ne fonctionnera pas. En particulier, si l'UAS envoie cinq requêtes OPTIONS qui ne sont pas simplement des retransmissions, vous obtiendrez cinq requêtes OPTIONS (et cinq transactions de serveur non-INVITE).

Les réponses provisoires retransmises à une transaction non-INVITE sont transmises à la couche Transaction-User, ou core comme elle est parfois appelée, mais à l'exception de la première, les réponses finales ne le sont pas. (Encore une fois, vous obtenez ceci simplement en implémentant le FSM pour cette transaction - une réponse finale met une transaction UAC non-INVITE dans l'état Completed, qui laisse tomber d'autres réponses. recevoir plusieurs réponses pour les transactions INVITE

Il est parfaitement normal qu'un UAS envoie plusieurs 183s, au moins pour un INVITE, par exemple il peut envoyer immédiatement un 100 pour étancher vos retransmissions (sur des transports non fiables au moins), puis un quelques 183, un 180, peut-être un peu plus de 183, et enfin un 200 (ou plus, pour les transports non fiables)

Il est important que la couche de transaction mains toutes ces réponses car les mandataires et les agents utilisateurs gèrent les réponses différemment.

A ce niveau, les réponses ne sont pas, en quelque sorte, retransmises. Je devrais dire: un UAS n'utilise pas la logique de retransmission pour envoyer des charges de réponses provisoires (sauf s'il implémente RFC 3262). 200 OK aux INVITES sont renvoyés car ils détruisent la transaction UAC. Vous pouvez éviter leur retransmission en envoyant vos ACKs à temps.

Answer 2

Je pense qu'un message est double/identique, si son ...

• Cseq
• Call-ID
• et le nom de la méthode (par exemple "INVITER")

... les valeurs correspondent à celles d'un autre message.

Notez qu'un message de réponse a le même CSeq que la demande à laquelle il répond; et, qu'une seule requête vous donne plusieurs réponses provisoires mais non dupliquées (par exemple, RINGING suivi de OK).