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