檢測重複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消息的最佳實現是什麼？

回答

相關問題