代码之家  ›  专栏  ›  技术社区  ›  TacB0sS

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

  •  2
  • TacB0sS  · 技术社区  · 15 年前

    我写了一个SIP UAC,我尝试了几种方法来检测和忽略来自UAS的重复传入消息,但是我尝试的每种方法都出了问题,我的问题是所有与同一个呼叫相关的消息都有相同的签名,要比较所有的消息文本太多了,所以我想知道,在尝试检测这些重复消息时,应该查看构成消息的参数。

    更新:

    目前我有SessionInPogress的重复消息,以及不同的错误消息,如busy here和unavailable,我收到了很多这样的消息,这会扰乱我的日志,我想过滤它们。

    更新:

    在发回之前我会试试你的技术,也许这能解决我的问题

    这是我用过的,效果很好:

    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 回复  |  直到 15 年前
        1
  •  2
  •   Frank Shearar    15 年前

    首先,事务层过滤掉大部分重传。在大多数情况下,它通过将收到的消息与当前事务列表进行比较来实现这一点。如果找到一个事务,则该事务将根据中的图表大部分吞下重传 RFC 3261, section 17 . 例如,处于进行中状态的UAC INVITE事务将丢弃延迟的重新传输的INVITE。

    匹配以两种方式之一进行,具体取决于远程堆栈。如果是rfc3261堆栈(最上面的Via上的branch参数以“z9hG4bK”开头),那么事情就相当简单了。 Section 17.2.3 包括全部细节。

    这样的匹配将过滤掉重复/重新传输的选项(您提到的这是一个特殊的问题)。选项消息不会形成对话框,因此查看CSeq将不起作用。特别是,如果UAS发出5个OPTIONS请求,而不仅仅是重传,那么您将得到5个OPTIONS请求(和5个非INVITE服务器事务)。

    对非INVITE事务的重新传输的临时响应被传递到事务用户层,或者有时被称为core,但是除了第一个响应之外,最终响应不是(同样,您只需为该事务实现FSM就可以实现这一点—最终响应将UAC non INVITE事务置于已完成状态,这将丢弃任何进一步的响应。

    之后,事务用户层通常会收到多个INVITE事务的响应。

    UAS发送多个183是完全正常的,至少是一个邀请。例如,它可能会立即发送一个100来终止您的重传(至少在不可靠的传输上),然后发送几个183,一个180,也许更多的183,最后是200(或者更多,对于不可靠的传输)。

    在这个级别上,响应在某种程度上不会被重新传输。我应该说:UAS不使用重传逻辑来发送临时响应(除非它实现了 RFC 3262 ). 对邀请的200个ok被重新发送,因为它们破坏了UAC事务。您可以通过及时发送ack来避免它们的重新传输。

        2
  •  0
  •   ChrisW    15 年前

    我认为信息是重复的/相同的,如果它是。。。

    • 命令序列
    • 呼叫ID

    ... 值与另一条消息的值匹配。

    注意,响应消息与它所响应的请求具有相同的CSeq;而且,一个请求您会得到几个临时的、但不重复的响应(例如,响铃后接“确定”)。