2

SIP UAC を作成し、UAS から繰り返し着信メッセージを検出して無視する方法をいくつか試しましたが、試したすべてのアプローチで何かがうまくいかず、私の問題は、同じ呼び出しには同じシグネチャがあり、すべてのメッセージ テキストを比較するには多すぎるため、これらの繰り返しメッセージを検出しようとするときに、メッセージを構成するどのパラメーターを調べればよいか疑問に思っていました。

アップデート:

着信オプションに問題があり、サーバーに空の Ok 応答を送信して処理しました。(更新:しばらくテストした後、私はまだ時々別のオプションリクエストを受け取り、数秒ごとに数回受け取ることに気づきました。そのため、悪いリクエストで応答しようとしましたが、今ではオプションリクエストを1回または2回しか受け取りません毎登録・再登録)

現在、SessionInPogress のメッセージが繰り返し表示され、ここでビジー、使用不可などのさまざまなエラー メッセージが表示されます。これらのメッセージが非常に多く、ログが乱れているため、フィルタリングしたいと思います。

それを達成する方法はありますか?

アップデート:

返信する前にあなたのテクニックを試してみます。おそらくこれで問題が解決するでしょう

これが私が使用したものです。うまく機能します:

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

ありがとう、アダム。

4

2 に答える 2

2

ChrisW の答えよりも少し複雑です。

まず、トランザクション層がほとんどの再送信を除外します。これは、ほとんどの場合、受信したメッセージを現在のトランザクションのリストと比較することによって行われます。トランザクションが見つかった場合、そのトランザクションは、RFC 3261 のセクション 17の図に従って再送信をほとんど飲み込みます。たとえば、Proceeding 状態の UAC INVITE トランザクションは、遅延再送信された INVITE を破棄します。

マッチングは、リモート スタックに応じて、2 つの方法のいずれかで行われます。それが RFC 3261 スタック (一番上の Via の branch パラメーターが "z9hG4bK" で始まる) の場合、物事はかなり単純です。詳細については、セクション 17.2.3を参照してください。

このようなマッチングは、重複/再送信された OPTIONS を除外します (これは特定の問題として言及されています)。OPTIONS メッセージはダイアログを形成しないため、CSeq を見ても機能しません。特に、UAS が単なる再送信ではない 5 つの OPTIONS 要求を送信する場合、5 つの OPTIONS 要求 (および 5 つの非 INVITE サーバー トランザクション) を取得します。

非 INVITE トランザクションへの再送信された暫定応答は、Transaction-User 層、またはコアと呼ばれることもありますが、最初のもの以外の最終応答は渡されません。(繰り返しますが、これは、そのトランザクションに FSM を実装するだけで取得できます。最終応答によって、UAC 非 INVITE トランザクションが完了状態になり、それ以降の応答は破棄されます。

その後、Transaction-User レイヤーは通常、INVITE トランザクションに対して複数の応答を受け取ります。

少なくとも INVITE の場合、UAS が複数の 183 を送信するのは完全に正常です。たとえば、すぐに 100 を送信して (少なくとも信頼性の低いトランスポートで) 再送信を抑制し、次に 183 を数回、180 を、場合によってはさらに 183 を送信し、最後に 200 (信頼性の低いトランスポートの場合はそれ以上) を送信します。

プロキシとユーザー エージェントは応答を異なる方法で処理するため、トランザクション層がこれらすべての応答を処理することが重要です。

このレベルでは、ある意味では、応答は再送信されません。つまり、UAS は大量の暫定応答を送信するために再送信ロジックを使用しません ( RFC 3262を実装していない限り)。UAC トランザクションを破棄するため、INVITE に対する 200 個の OK が再送信されます。ACK をタイムリーに送信することで、再送信を回避できます。

于 2010-07-01T16:18:00.273 に答える
0

メッセージが重複/同一であると思います...

  • Cseq
  • コール ID
  • およびメソッド名 (例: "INVITE")

... 値は別のメッセージの値と一致します。

応答メッセージには、応答先の要求と同じ CSeq があることに注意してください。そして、1 つの要求に対して、いくつかの暫定的ではあるが重複しない応答 (たとえば、RINGING の後に OK が続く) を受け取ること。

于 2010-07-01T11:08:29.640 に答える