アプリケーションサーバでのenableDelayQuickReinviteの設定

はじめに

このドキュメントでは、アプリケーションサーバ(AS)がACKの後でre-INVITEを送信しすぎるのを防ぐためにenableDelayQuickReinviteを設定する方法について説明します。

前提条件

• Session Initiation Protocol(SIP)の基礎知識
• 基本的なASの知識
• BroadWorks bwcliの基礎知識

要件

• AS bwcliとadminユーザを使用できること
• AS XSLogsを確認できるようにする

使用するコンポーネント

• Cisco BWのAS

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

一部のコールシナリオでは、ASは再接続を開始する必要があり、これを行うために、両端にre-INVITEを送信します。 これが発生する一般的なケースは、「コールセンター」、「ハントグループ」、または「クリックツーダイヤル」や「コールレコード」に関連するコールで、一般的にセッションが確立された後にASで再接続をトリガーする必要がある場合があります。

同じダイアログでACKが送信された後にASがre-INVITEを送信する必要がある場合、ASは通常ACKと同時にre-INVITEを送信するため、リモートデバイスでACKとre-INVITEが順不同で受信される可能性があります。

この場合、保留中のACKの前にre-INVITEを受信したデバイスは、通常は500エラーコードでre-INVITEを拒否できます（ただし、これはリモートデバイスの実装によって異なる場合があります）。

設定

この機能の設定に使用するパラメータは2つあり、どちらもbwcli(AS_CLI/Interface/SIP>)にあります。

• enableDelayQuickReInviteは、この機能をオンまたはオフにするメインスイッチです。指定できる値はtrueとfalseです
• delayQuickReInviteMillisecondsは、ACKの後に追加される遅延の値（ミリ秒）です。値の範囲は100ミリ秒 ～ 10000ミリ秒です。

この機能を設定するには、AS bwcliを開き、Adminユーザとしてログインし、AS_CLI/Interface/SIP>に移動します。

AS_CLI> cd /Interface/SIP
AS_CLI/Interface/SIP>

最初にgetコマンドを実行して、両方のパラメータの現在の値を確認します。デフォルトでは、enableDelayQuickReInviteは無効(false)であり、delayQuickReInviteMillisecondsのデフォルト値は1000（1000ミリ秒、または1秒）です。

getコマンド出力の一部は、読みやすさを向上するために省略されています。

AS_CLI/Interface/SIP> get
...
enableDelayQuickReInvite = false
delayQuickReInviteMilliseconds = 1000
...

次に、delayQuickReInviteMillisecondsパラメータを設定します。デフォルト値をそのまま使用することも、環境に最も適した値を使用することもできます。再コマンドは可能な限り低い値を使用するため、100 msの値から始めて、問題の解決に十分でない場合に備えて値を増やすことをお勧めします。

AS_CLI/Interface/SIP> set delayQuickReInviteMilliseconds 100
...Done

delayQuickReInviteMillisecondsの値を設定したら、enableDelayQuickReInviteを有効にすることができます。

AS_CLI/Interface/SIP> set enableDelayQuickReInvite true
...Done

確認

設定が完了したら、コールシナリオを再度実行して、ASがACKとre-INVITEの間に遅延を追加することを確認します。たとえば、ASが100ミリ秒を追加するように設定されている場合、遅延は少なくとも100ミリ秒になると予測できますが、数ミリ秒以上遅延が発生する可能性があります。

通常は100ミリ秒でACKとre-INVITEが誤った順序で受信されることはありません。ただし、ネットワーク環境やシグナリングパスに含まれるSIPエンティティによっては、この値の方が高くなる場合があります。

トラブルシュート

デバイスが依然として500エラーコードで応答し、ACKとre-INVITEが正しい順序で配信されている場合は、デバイスの詳細な調査が必要です。

AS上のXSLogsを使用して、ASに遅延が設定どおりに追加されたことを確認します。また、パケットキャプチャまたはデバイスログを使用して、メッセージが正しい順序で配信されるために十分な遅延であったことを確認します。

これは、ASがACKを送信した直後にre-INVITEを送信した場合にのみ機能しますが、ASがACKを受信し、そのためにASがre-INVITEを送信する場合には機能しません。