检测重复SIP消息的最佳实现是什么？

我已经写了一个SIP UAC，并且我尝试了几种方法来检测并忽略来自UAS的重复传入消息，但是我尝试了每种方法，出错了，我的问题是所有必须用相同的调用做相同的签名，并且比较所有的消息文本太多了，所以我想知道，当我试图检测这些重复消息时，我应该看到组成消息的参数。检测重复SIP消息的最佳实现是什么？

UPDATE：

我有一个问题与传入选项，这是我与向服务器发送一个空的OK应答处理。（更新：经过一段时间的测试后，我注意到，我仍然每隔几秒钟就会收到一次Options请求，因此我尝试用一个Bad请求进行响应，现在我只收到一次/两次Options请求每个注册/重新注册）

当前我有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; 
}

谢谢，亚当。

来源

2010-07-01 TacB0sS

什么类型的消息？临时回应？最终答复？你使用UDP吗？你在和RFC 2543 UAS还是RFC 3261 UAS交谈？ – 2010-07-01 09:04:01

如果是回应或请求，它真的很重要吗？临时还是最终？所有消息的通用性都不低，我可以识别重复的消息吗？ – TacB0sS 2010-07-01 09:42:06

嗯，它有助于回答问题:)请求/响应重传处理方式不同。 – 2010-07-01 10:17:02

这比ChrisW的答案稍微复杂一些。

首先，事务层过滤掉大部分重传。对于大多数情况，这是通过将接收到的消息与当前事务列表进行比较来实现的。如果发现交易，那么该交易将主要依据RFC 3261, section 17中的图表进行重传。例如，处于“正在处理”状态的UAC INVITE事务将删除延迟重发的INVITE。

匹配发生在两种方式之一，具体取决于远程堆栈。如果它是一个RFC 3261堆栈（最顶端的Via上的分支参数以“z9hG4bK”开头），那么事情相当简单。 Section 17.2.3涵盖了全部细节。

这样匹配会过滤掉重复/重发的OPTIONS（你提到这是一个特殊的问题）。OPTIONS消息不形成对话框，因此查看CSeq将不起作用。特别是，如果UAS发出5个OPTIONS请求，不仅仅是重传，你将得到5个OPTIONS请求（和5个非INVITE服务器事务）。

重传对非INVITE事务的临时响应被传递到事务用户层或核心，因为它有时被调用，但除第一个之外，最终的响应不是。（同样，通过简单地通过实现该事务的FSM得到这个 - 最终响应将UAC非INVITE事务置于完成状态，这将丢弃任何进一步的响应。

之后，事务 - 用户层通常接收INVITE事务的多个响应

对于一个UAS来说，发送多个183s至少对于一个INVITE来说是非常正常的，例如它可能立即发送一个100来终止你的重发（至少通过不可靠的传输）少数183个，180个，也许多个183个，最后200个（或更多，对于不可靠的传输）。完成所有这些响应，因为代理和用户代理处理响应的方式不同。

在这个级别上，答复不是以某种方式重新发送。我应该说：UAS不使用重传逻辑来发送大量的临时响应（除非它实现了RFC 3262）。因为它们破坏了UAC事务，因此INVITE的200 OK被重新发送。您可以通过及时发送您的ACK来避免重传。

来源

2010-07-01 16:18:00

在收到错误响应后，我用UAC和UAS之间的几条消息更新了我的问题，对于我得到的4xx和5xx也是如此。 – TacB0sS 2010-07-01 16:48:52

我已经开始实施使用你的解释，它工作得很好，谢谢！ – TacB0sS 2010-07-02 23:49:15

我认为，一个消息是重复/相同的，如果...

Cseq的
的Call-ID
和方法的名称（例如 “邀请”）

...值与另一个消息的值相匹配。

请注意，响应消息具有与其所响应的请求相同的CSeq;并且，一个请求可以得到几个临时但不重复的响应（例如，RINGING，然后是OK）。

来源

2010-07-01 11:08:29 ChrisW

这是重复消息的唯一标准...？索引和方法，那么Call ID不应该是一个因素吗？ – TacB0sS 2010-07-01 11:11:47

@ TacB0sS根据http://www.ietf.org/rfc/rfc3261.txt的第36至38页，CSeq在对话框中是唯一的，Call-ID标识一组消息（或对话框）。 – ChrisW 2010-07-01 11:24:43

比这更复杂;我会得到RSN的答案。 – 2010-07-01 15:14:35

检测重复SIP消息的最佳实现是什么？

回答

相关问题