2

Mobicents SIP サーブレット コンテナーは、私が使用した他の SIP コンテナーとは異なる方法でエラー応答を処理するようです。状況は次のとおりです。

  • INVITE を受信すると、アプリはダウンストリーム (監視対象) を処理およびプロキシします (そのため、招待への応答を受け取ることができます)。

  • 最初のターゲットからエラー応答を受信すると、アプリは新しい宛先に (監視されていない方法で) プロキシします。

これにより、最初のエラー応答が上流に伝播するのを防ぐ必要があります (トランザクションに新しいターゲットがあるため)。ただし、Mobicents コンテナーを使用すると、INVITE が実際に新しい宛先にプロキシされても、最初に受信したエラー応答が上流に伝搬されます。これは Mobicents 実装のバグだと思いますが、どうすればこれを回避できますか?

コード：

public void doInvite(SipServletRequest req) {
  req.getProxy().proxyTo(req.getRequestURI());
}

public void doError(SipServletResponse res) {
    Proxy p = res.getProxy();
    p.setSupervised(false);
    p.proxyTo(...);
    // request is proxied, but the error response still passes
    // upstream - the retargeting of the transaction (through
    // proxying to a new destination ought to prevent that).
}
4

2 に答える 2

0

純粋なプロキシ ソリューションとして、Mobicents はエラー応答を呼び出し元に転送するという正しい動作を行っているため、[エラー コードに基づく] シーケンシャル フォークのロジックは呼び出し側で処理する必要があります。

ただし、モビセントによるこの動作が必要な場合は、モビセントに対して B2BUA モードを実行する必要があります。これにより、2 つのコール レッグ [イングレス/エグレス] に依存しない動作をより細かく制御できるようになります。

発信者は INVITE [イングレス レッグ] の 183 コール プログレスを取得しますが、シーケンシャル リトライはイーグレス レッグで処理でき、イングレスで初期タイムアウトが発生するリスクはありません。

于 2015-06-01T05:03:51.220 に答える