Session-initiation-protocol-forking
SIP-フォーク
プロキシサーバーが単一のSIP呼び出しを複数のSIPエンドポイントに転送する場合があります。 このプロセスは分岐として知られています。 ここでは、1つのコールで多数のエンドポイントを同時に呼び出すことができます。
SIPフォークを使用すると、ソフトフォンまたはモバイルのSIP電話機と同時にデスクフォンを鳴らすことができ、どちらのデバイスからでも簡単に電話をかけることができます。
一般的に、オフィスでは、ボスが電話をかけたり外したりすることができないと仮定すると、SIP分岐により、秘書は内線に電話に応答できます。
ステートフルプロキシが使用可能な場合、受信する多数のプロキシから実行して応答する必要があるため、フォークが可能になります。
分岐には2種類あります-
- 並列分岐
- シーケンシャルフォーク
並列分岐
このシナリオでは、プロキシサーバーはINVITEを一度に2つのデバイス（UA2、UA3）に分岐します。 両方のデバイスが180の呼び出し音を生成し、コールを受信した人は200 OKを生成します。 最初にオリジネーターに到達する応答（UA2と想定）は、UA2とのセッションを確立します。 他の応答では、キャンセルがトリガーされます。
発信者が両方の応答を同時に受信した場合、q値に基づいて、応答を転送します。
シーケンシャルフォーク
このシナリオでは、プロキシサーバーはINVITEを1つのデバイス（UA2）に分岐します。 その時点でUA2が使用不可またはビジーである場合、プロキシは別のデバイス（UA3）にそれをフォークします。
ブランチ-IDおよびタグ
ブランチIDは、プロキシが分岐したリクエストへの応答を照合するのに役立ちます。 ブランチIDがなければ、プロキシサーバーは分岐した応答を理解できません。 Branch-idは、Viaヘッダーで使用できます。
UACは、タグを使用して、さまざまなUASからの複数の最終応答を区別します。 UASは、リクエストがフォークされたかどうかを解決できません。 したがって、タグを追加する必要があります。
プロキシは、最終応答を生成する場合にタグを追加することもできます。リクエストまたは転送する応答にタグを挿入することはありません。
単一のリクエストが複数のプロキシサーバーによって分岐される可能性もあります。 したがって、フォークするプロキシは、作成したブランチに独自の一意のIDを追加する必要があります。
コールレッグとコールID
コールレッグとは、2つのユーザーエージェント間の1対1のシグナリング関係を指します。 コールIDは、コールを参照するSIPメッセージで運ばれる一意の識別子です。 コールはコールレッグのコレクションです。
UACは、INVITEを送信することから始まります。 分岐により、異なるUAから複数の200 OKを受け取る場合があります。 それぞれが同じコール内の異なるコールレッグに対応します。
したがって、コールはコールレッグのグループです。 コールレッグは、UA間のエンドツーエンド接続を指します。
コールレッグの2方向のCSeqスペースは独立しています。 単一の方向内では、シーケンス番号はトランザクションごとに増分されます。
ボイスメール
ボイスメールは現在、エンタープライズユーザーにとって非常に一般的です。 電話アプリケーションです。 着信側が利用できない場合、またはコールを受信できない場合、PBXは発呼側に音声メッセージを残すように通知します。
ユーザーエージェントは、着信者の番号に到達できない場合、3xx応答を受け取るか、ボイスメールサーバーにリダイレクトします。 ただし、ボイスメールシステムに使用するメールボックス、つまり、再生するグリーティングと録音されたメッセージを保存する場所をボイスメールシステムに示すには、何らかの種類のSIP拡張が必要です。 これを達成するための2つの方法があります-
- SIPヘッダーフィールド拡張機能を使用して
- Request-URIを使用してこの情報を通知する
ユーザー* sip：Tom@finddevguides.com*のボイスメールシステムがsip：voicemail.finddevguides.comにあり、ボイスメールを提供しているとします。ボイスメールサーバーに転送されるINVITEのRequest-URIは次のようになります。
次の図は、Request-URIがメールボックス識別子と理由（ここでは486）をどのように運ぶかを示しています。
