1

着信番号が応答した後、NOTIFY メッセージの長い文字列が発生します。約 20 ~ 30 秒後に 503 が発生し、通話は音声で正常に接続されます。Wireshark voip グラフの前半Wireshark voip グラフの後半すべての通知メッセージの後の最後の rtp を示す Wireshark voip グラフの最後のビット

4

1 に答える 1

2

そのトレースが単一の呼び出しの場合、それは非常に複雑なものです。少し時間をかけて調べたところ、単一の呼び出しではなく、いくつかの異なる呼び出しが混在していると思います。10.10.20.1 がバック ツー バック ユーザー エージェント (B2BUA) であり、さまざまなイベントに応答してオン コールを開始しているため、複雑です。

NOTIFY リクエストに関するご質問については、最初は 10.10.10.3 の UAC によって在席転送と思われるものの一部として生成されました。REFER 要求は、転送の開始です。NOTIFY 要求の一部である暗黙のサブスクリプションは、REFER トランザクション用に作成されます ( https://www.rfc-editor.org/rfc/rfc3515を参照し、 https://www.rfc-editorも参照してください。 org/rfc/rfc4488 (暗黙的なトランザクションの抑制を扱っています)。

在席転送の場合、NOTIFY 要求により、コール レッグ エンド ポイントは、転送が正常に処理されたことを示すことができます。この場合、10.10.10.3 のユーザー エージェントは、NOTIFY 要求への応答を受け取るまで転送を受け入れることに満足していないようです。通常、NOTIFY 要求はコール フローを制御しないイベントをエージェントに通知するためのものであるため、これは異常な動作です。10.10.10.3 がその NOTIFY 要求に対する 503 応答を取得すると、最終的に RTP を 10.10.20.4 に送信し始めます。503 はエラー状態であるため、応答が何であるかを気にする必要はありません。通常、失敗するのを待っていたものは何でも返されます。

于 2012-06-14T22:53:25.443 に答える