Session-initiation-protocol-quick-guide

提供：Dev Guides
移動先:案内、検索

セッション開始プロトコル-はじめに

セッション開始プロトコル（SIP）は、VoIPテクノロジで使用される最も一般的なプロトコルの1つです。 これは、インターネット上のマルチメディア通信セッションを制御するために他のアプリケーション層プロトコルと連携して機能するアプリケーション層プロトコルです。

VoIPテクノロジー

先へ進む前に、まずVoIPに関するいくつかのポイントを理解しましょう。

  • VOIPは、インターネット上で音声およびマルチメディア（ビデオ、写真）コンテンツを配信できるようにする技術です。 これは、インターネットの可用性を利用して、いつでもどこでも通信する最も安価な方法の1つです。
  • VOIPのいくつかの利点が含まれます-
  • 低価格
  • 移植性
  • 追加ケーブルなし
  • 柔軟性
  • ビデオ会議
  • VOIPコールの場合、必要なものはインターネット接続が可能なコンピューター/ラップトップ/モバイルだけです。 次の図は、VoIPコールがどのように行われるかを示しています。

VoIP

これが非常に基本的なため、SIPに戻りましょう。

SIP –概要

以下に、SIPに関する注意点をいくつか示します-

  • SIPは、インターネットプロトコルを介してマルチメディアセッションを作成、変更、および終了するために使用されるシグナリングプロトコルです。 セッションは、2つのエンドポイント間の単純な呼び出しにすぎません。 エンドポイントは、スマートフォン、ラップトップ、またはインターネット経由でマルチメディアコンテンツを送受信できる任意のデバイスです。 SIPは、IETF（Internet Engineering Task Force）標準で定義されているアプリケーション層プロトコルです。 RFC 3261 *で定義されています。
  • SIPは、クライアント/サーバーアーキテクチャと、 HTTP のURLとURI、 SMTP のテキストエンコーディングスキームとヘッダースタイルの使用を具体化します。
  • SIPは、セッションを記述するSDP（セッション記述プロトコル）と、IPネットワークを介した音声およびビデオの配信に使用されるRTP（リアルタイム転送プロトコル）の助けを借ります。
  • SIPは、2パーティ（ユニキャスト）またはマルチパーティ（マルチキャスト）セッションに使用できます。
  • 他のSIPアプリケーションには、ファイル転送、インスタントメッセージング、ビデオ会議、オンラインゲーム、ストリーミングマルチメディア配信などがあります。

SIPはどこに収まりますか？

基本的に、SIPはアプリケーション層プロトコルです。 これは、1人以上の参加者とのセッションを作成および終了するためのシンプルなネットワークシグナリングプロトコルです。 SIPプロトコルは、基盤となるトランスポートプロトコルに依存しないように設計されているため、SIPアプリケーションはTCP、UDP、またはその他の下位層のネットワークプロトコルで実行できます。

次の図は、物事の一般的なスキームでSIPが適合する場所を示しています-

SIPレイヤー

通常、SIPプロトコルは、2つ以上のエンドポイント間のインターネットテレフォニーおよびマルチメディア配信に使用されます。 たとえば、ある人がSIPを使用して別の人に電話をかけたり、誰かが多くの参加者との電話会議を作成したりできます。

SIPプロトコルは、限られたコマンドセットで非常にシンプルになるように設計されました。 また、テキストベースであるため、誰でもSIPセッションのエンドポイント間で渡されるSIPメッセージを読むことができます。

SIP-ネットワーク要素

SIPがネットワークを作成する際に役立つエンティティがいくつかあります。 SIPでは、すべてのネットワーク要素はアドレスのような SIP URI （Uniform Resource Identifier）で識別されます。 以下は、ネットワーク要素です-

  • ユーザーエージェント
  • プロキシサーバー
  • レジストラサーバー
  • リダイレクトサーバー
  • ロケーションサーバー

ユーザーエージェント

これはエンドポイントであり、SIPネットワークの最も重要なネットワーク要素の1つです。 エンドポイントは、セッションを開始、変更、または終了できます。 ユーザーエージェントは、SIPネットワークの最もインテリジェントなデバイスまたはネットワーク要素です。 ソフトフォン、モバイル、またはラップトップの場合があります。

ユーザーエージェントは論理的に2つの部分に分かれています-

  • ユーザーエージェントクライアント（UAC）-要求を送信し、応答を受信するエンティティ。
  • ユーザーエージェントサーバー（UAS）-要求を受信し、応答を送信するエンティティ。

SIPは、呼び出し元の電話が呼び出しを開始するクライアントとして機能し、呼び出し先の電話が呼び出しに応答するサーバーとして機能するクライアントサーバーアーキテクチャに基づいています。

プロキシサーバー

ユーザーエージェントから要求を取得し、それを別のユーザーに転送するのはネットワーク要素です。

  • 基本的に、プロキシサーバーの役割はルーターのようなものです。
  • SIPリクエストを理解し、URIの助けを借りて送信するためのインテリジェンスがあります。
  • プロキシサーバーは2つのユーザーエージェントの間に位置します。
  • 送信元と宛先の間に最大70のプロキシサーバーが存在できます。

プロキシサーバーには2種類あります-

  • ステートレスプロキシサーバー-受信したメッセージを単に転送します。 このタイプのサーバーは、呼び出しまたはトランザクションの情報を保存しません。
  • ステートフルプロキシサーバー-このタイプのプロキシサーバーは、受信したすべての要求と応答を追跡し、必要に応じて将来使用できます。 時間内に反対側からの応答がない場合、要求を再送信できます。

レジストラサーバー

レジストラサーバーは、ユーザーエージェントからの登録要求を受け入れます。 ユーザーがネットワーク内で自分自身を認証するのに役立ちます。 URIとユーザーの場所をデータベースに保存して、同じドメイン内の他のSIPサーバーを支援します。

SIP登録のプロセスを示す次の例を見てください。

SIP登録の例

ここで、呼び出し元はTMCドメインに登録したいと考えています。 そのため、TMCのレジストラーサーバーにREGISTER要求を送信し、サーバーはクライアントを承認したときに200 OK応答を返します。

リダイレクトサーバー

リダイレクトサーバーは要求を受信し、レジストラによって作成されたロケーションデータベースで要求の目的の受信者を検索します。

リダイレクトサーバーはデータベースを使用して位置情報を取得し、ユーザーに3xx（リダイレクト応答）で応答します。 応答コードについては、このチュートリアルの後半で説明します。

ロケーションサーバー

ロケーションサーバーは、発信者の可能な場所に関する情報をリダイレクトサーバーとプロキシサーバーに提供します。

プロキシサーバーまたはリダイレクトサーバーのみがロケーションサーバーに接続できます。

次の図は、セッションを確立する際に各ネットワーク要素が果たす役割を示しています。

ロケーションサーバー

SIP –システムアーキテクチャ

SIPは階層化プロトコルとして構造化されています。つまり、SIPの動作は、各ステージ間の疎結合のみを含むかなり独立した一連の処理ステージの観点から説明されます。

システムアーキテクチャ

  • SIPの最下層は、構文とエンコーディング*です。 そのエンコーディングは、拡張された Backus-Naur Form文法*（BNF）を使用して指定されます。
  • 2番目のレベルは*トランスポート層*です。 クライアントが要求を送信して応答を受信する方法と、サーバーがネットワーク経由で要求を受信して​​応答を送信する方法を定義します。 すべてのSIP要素にはトランスポート層が含まれます。
  • 次は*トランザクション層*です。 トランザクションは、クライアントトランザクションから（トランスポートレイヤーを使用して）サーバートランザクションに送信される要求であり、サーバートランザクションからクライアントに送信されるその要求へのすべての応答と共に送信されます。 ユーザーエージェントクライアント（UAC）が実行するタスクは、一連のトランザクションを使用して実行されます。 *ステートレスプロキシ*にはトランザクションレイヤーが含まれていません。
  • *トランザクションレイヤー*の上のレイヤーは、トランザクションユーザーと呼ばれます。 *ステートレスプロキシ*を除く各SIPエンティティは、トランザクションユーザーです。

SIP-基本的なコールフロー

次の図は、SIPセッションの基本的なコールフローを示しています。

SIPコールフロー

以下は、上記のコールフローの段階的な説明です-

  • プロキシサーバーに送信されるINVITE要求は、セッションの開始を担当します。
  • プロキシサーバーは、呼び出し側（アリス）に 100 Trying 応答をすぐに送信して、INVITE要求の再送信を停止します。
  • プロキシサーバーは、ロケーションサーバーでボブのアドレスを検索します。 アドレスを取得した後、INVITE要求をさらに転送します。
  • その後、ボブによって生成された 180 Ringing （暫定応答）がアリスに返されます。
  • ボブが電話を拾った直後に 200 OK 応答が生成されます。
  • Bobは 200 OK を取得すると、Aliceから ACK を受け取ります。
  • 同時に、セッションが確立され、RTPパケット（会話）が両端から流れ始めます。
  • 会話の後、参加者（アリスまたはボブ）は、セッションを終了するために BYE リクエストを送信できます。
  • BYE は、プロキシサーバーをバイパスしてアリスからボブに直接到達します。
  • 最後に、Bobは 200 OK 応答を送信してBYEを確認し、セッションは終了します。
  • 上記の基本的なコールフローでは、3つの*トランザクション*（1、2、3としてマーク）が利用可能です。

完全な呼び出し（INVITEから200 OKまで）は Dialog と呼ばれます。

SIP台形

プロキシは、あるユーザーを別のユーザーに接続するのにどのように役立ちますか？ 次の図を使用して調べてみましょう。

SIP台形

図に示されているトポロジは、SIP台形と呼ばれます。 プロセスは次のように行われます-

  • 発信者が呼び出しを開始すると、INVITEメッセージがプロキシサーバーに送信されます。 INVITEを受信すると、プロキシサーバーは、DNSサーバーの助けを借りて、呼び出し先のアドレスを解決しようとします。
  • 次のルートを取得した後、発信者のプロキシサーバー（プロキシ1、発信プロキシサーバーとも呼ばれる）は、INVITE要求を着信者の着信プロキシサーバー（プロキシ2）として機能する着信者のプロキシサーバーに転送します。
  • インバウンドプロキシサーバーはロケーションサーバーに接続して、ユーザーが登録した着信者のアドレスに関する情報を取得します。
  • ロケーションサーバから情報を取得した後、コールを宛先に転送します。
  • ユーザーエージェントが自分のアドレスを知ると、コールをバイパスできます。つまり、会話は直接通過します。

SIP-メッセージング

SIPメッセージには、*要求*と*応答*の2つのタイプがあります。

  • 要求の開始行には、要求を定義するメソッドと、要求の送信先を定義するRequest-URIが含まれます。
  • 同様に、応答の開始行には応答コードが含まれます。

リクエスト方法

  • SIPリクエスト*は、通信を確立するために使用されるコードです。 それらを補完するために、一般にリクエストが成功したか失敗したかを示す* SIP応答*があります。

METHODSとして知られるこれらのSIP要求により、SIPメッセージが機能します。

  • メソッドは、特定のアクションが別のユーザーエージェントまたはサーバーによって実行されるように要求するため、SIPリクエストと見なすことができます。
  • 方法は2つのタイプに区別されます-
  • コアメソッド
  • 拡張メソッド

コアメソッド

以下に説明するように、6つのコアメソッドがあります。

招待する

INVITEは、ユーザーエージェントとのセッションを開始するために使用されます。 つまり、INVITEメソッドは、ユーザーエージェント間のメディアセッションを確立するために使用されます。

  • INVITEには、メッセージ本文に発信者のメディア情報を含めることができます。
  • INVITEが成功応答（2xx）を受信したか、ACKが送信された場合、セッションは確立されたと見なされます。
  • INVITE要求が成功すると、2つのユーザーエージェント間に dialog が確立され、セッションを終了するためにBYEが送信されるまで続行されます。
  • 確立されたダイアログ内で送信されるINVITEは、 re-INVITE として知られています。
  • Re-INVITEは、セッションの特性を変更したり、ダイアログの状態を更新したりするために使用されます。

招待の例

次のコードは、INVITEの使用方法を示しています。 

INVITE sips:Bob@TMC.com SIP/2.0
   Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9
   Max-Forwards: 70
   From: Alice<sips:Alice@TTP.com>;tag = 1234567
   To: Bob<sips:Bob@TMC.com>
   Call-ID: 12345601@192.168.2.1
   CSeq: 1 INVITE
   Contact: <sips:Alice@client.ANC.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: replaces
   Content-Type: application/sdp
   Content-Length: ...

   v = 0
   o = Alice 2890844526 2890844526 IN IP4 client.ANC.com
   s = Session SDP
   c = IN IP4 client.ANC.com
   t = 3034423619 0
   m = audio 49170 RTP/AVP 0
   a = rtpmap:0 PCMU/8000

BYE

BYEは、確立されたセッションを終了するために使用される方法です。 これは、セッションを終了するために、呼び出し元または呼び出し先のいずれかが送信できるSIP要求です。

  • プロキシサーバーから送信することはできません。
  • BYE要求は通常、プロキシサーバーをバイパスして、エンドツーエンドでルーティングします。
  • BYEは、保留中のINVITEまたは確立されていないセッションに送信できません。

登録

REGISTERリクエストは、ユーザーエージェントの登録を実行します。 この要求は、ユーザーエージェントによってレジストラーサーバーに送信されます。

  • REGISTERリクエストは、指定されたドメインの信頼できるレジストラに到達するまで転送またはプロキシされます。
  • 登録されているユーザーの To ヘッダーにAOR（レコードのアドレス）が含まれています。
  • REGISTER要求には期間（3600秒）が含まれます。
  • あるユーザーエージェントは、別のユーザーエージェントに代わってREGISTER要求を送信できます。 これは*サードパーティ登録*と呼ばれます。 ここで、 From タグには、 To ヘッダーで識別されたパーティーに代わって登録を送信するパーティーのURIが含まれています。

キャンセル

CANCELは、確立されていないセッションを終了するために使用されます。 ユーザーエージェントはこのリクエストを使用して、以前に開始された保留中のコールの試行をキャンセルします。

  • ユーザーエージェントまたはプロキシサーバーのいずれかで送信できます。
  • CANCELは、ホップごとの要求です。つまり、ユーザーエージェント間の要素を通過し、次のステートフル要素によって生成された応答を受け取ります。

ホップバイホップ

ACK

ACKは、INVITEメソッドへの最終応答を確認するために使用されます。 ACKは、INVITEで利用できない場合、常にINVITE.ACKの方向に進みます。

SDP Ack

  • ACKは、最初のINVITEですでに送信されたメディア記述を変更するために使用することはできません。

SDP Acknowledgement

  • ACKを受信するステートフルプロキシは、ACKを別のプロキシまたはユーザーエージェントにダウンストリームで転送する必要があるかどうかを判断する必要があります。
  • 2xx応答の場合、ACKはエンドツーエンドですが、他のすべての最終応答では、ステートフルプロキシが関係する場合、ホップごとに動作します。

オプション

OPTIONSメソッドは、ユーザーエージェントまたはプロキシサーバーにその機能について照会し、現在の可用性を検出するために使用されます。 要求への応答には、ユーザーエージェントまたはサーバーの機能がリストされます。 プロキシがOPTIONS要求を生成することはありません。

拡張メソッド

申し込む

SUBSCRIBEは、特定のイベントに関する通知を取得する目的でサブスクリプションを確立するために、ユーザーエージェントによって使用されます。

  • サブスクリプションの期間を示す Expires ヘッダーフィールドが含まれています。
  • 期間が経過すると、サブスクリプションは自動的に終了します。
  • サブスクリプションは、ユーザーエージェント間のダイアログを確立します。
  • 有効期限が切れる前にダイアログ内で別のSUBSCRIBEを送信することにより、再度サブスクリプションを再登録できます。
  • ユーザーからサブスクリプションに対して200 OKを受け取ります。
  • ユーザーは、Expires値が0（ゼロ）の別のSUBSCRIBEメソッドを送信することにより、登録を解除できます。

購読例

通知する

NOTIFYは、特定のイベントの発生を取得するためにユーザーエージェントによって使用されます。 通常、サブスクライバーとノーティファイアーの間にサブスクリプションが存在する場合、ダイアログ内でNOTIFYがトリガーされます。

  • ノーティファイアによって受信された場合、すべてのNOTIFYは200 OK応答を受け取ります。
  • NOTIFYには、イベントを示す Event ヘッダーフィールドと、サブスクリプションの現在の状態を示す subscriptionstate ヘッダーフィールドが含まれます。
  • NOTIFYは、サブスクリプションの開始時と終了時に常に送信されます。

公開

PUBLISHは、イベント状態情報をサーバーに送信するためにユーザーエージェントによって使用されます。

公開

  • PUBLISHは、イベント情報のソースが複数ある場合に最も役立ちます。
  • PUBLISH要求は、ダイアログで送信されないことを除いて、NOTIFYに似ています。
  • PUBLISHリクエストには、 Expires ヘッダーフィールドと Min-Expires ヘッダーフィールドが含まれている必要があります。

参照

REFERは、別のユーザーエージェントを参照してダイアログのURIにアクセスするために、ユーザーエージェントによって使用されます。

  • REFERには Refer-To ヘッダーが含まれている必要があります。 これは、REFERの必須ヘッダーです。
  • REFERは、ダイアログの内側または外側に送信できます。
  • 202 Accepted は、他のユーザーエージェントが参照を受け入れたことを示すREFER要求をトリガーします。

INFO

INFOは、メディアセッションを確立した別のユーザーエージェントにコールシグナリング情報を送信するために、ユーザーエージェントによって使用されます。

  • これはエンドツーエンドのリクエストです。
  • プロキシは常にINFO要求を転送します。

更新

セッションが確立されていない場合、UPDATEを使用してセッションの状態を変更します。 ユーザーはUPDATEでコーデックを変更できます。

更新

セッションが確立されると、セッションを変更/更新するために再招待が使用されます。

プラック

PRACKは、暫定応答（1XX）の信頼できる転送の受信を確認するために使用されます。

  • 通常、PRACKは、 RSeq 信頼性のあるシーケンス番号と supported：100rel ヘッダーを含む暫定応答を受信すると、クライアントによって生成されます。
  • PRACKには、 rack ヘッダーに（RSeq＆plus; CSeq）値が含まれます。
  • PRACKメソッドは、100 Trying応答を除くすべての暫定応答に適用されます。100Trying応答は、確実に転送されません。
  • PRACKにはメッセージ本文が含まれる場合があります。オファー/アンサー交換に使用できます。

メッセージ

SIPを使用してインスタントメッセージを送信するために使用されます。 IMは通常、テキスト会話に参加している参加者がリアルタイムで交換する短いメッセージで構成されます。

メッセージ

  • MESSAGEは、ダイアログ内またはダイアログ外に送信できます。
  • MESSAGEの内容は、 MIME 添付ファイルとしてメッセージ本文に含まれています。
  • 通常、メッセージが宛先で配信されたことを示す 200 OK 応答が受信されます。

SIP-応答コード

SIP応答は、クライアントによって生成された要求に応答するために、ユーザーエージェントサーバー（UAS）またはSIPサーバーによって生成されたメッセージです。 UACによる要求の再送信を防ぐための正式な確認応答である可能性があります。

  • 応答には、UACが必要とする情報の追加ヘッダーフィールドが含まれている場合があります。
  • SIPには6つの応答があります。
  • 1xxから5xxはHTTPから借用され、6xxはSIPで導入されました。
  • 1xxは*暫定*応答と見なされ、残りは*最​​終*応答です。
S.No. Function & Description
1

1xx: Provisional/Informational Responses

情報応答は、*呼び出しの進行状況*を示すために使用されます。 通常、応答はエンドツーエンドです（100回の試行を除く）。

2

2xx: Success Responses

このクラスの応答は、要求が受け入れられたことを示すためのものです。

3

3xx: Redirect Responses

通常、これらのクラスの応答は、INVITEへの応答としてリダイレクトサーバーによって送信されます。 これらは、リダイレクトクラス応答とも呼ばれます。

4

4xx: Client Failure Responses

クライアントエラー応答は、UAC側からいくつかのエラーが識別されるため、要求を実行できないことを示します。

5

5xx: Server Failure Response

このクラスの応答は、サーバーのエラーのために要求を処理できないことを示すために使用されます。

6

6xx: Global Failure Response

この応答クラスは、要求が試行された場所で失敗することをサーバーが認識していることを示します。 そのため、リクエストを他の場所に送信しないでください。

SIP-ヘッダー

ヘッダーは、メッセージに関する情報を伝えるSIPメッセージのコンポーネントです。 これは、一連のヘッダーフィールドとして構造化されています。

ほとんどの場合、SIPヘッダーフィールドはHTTPヘッダーフィールドと同じルールに従います。 ヘッダーフィールドは Header：field として定義されます。ヘッダーはヘッダーフィールド名を表すために使用され、fieldは情報を含むトークンのセットです。 各フィールドは、フィールド名の後にコロン（「：」）とフィールド値（つまり、フィールド名：フィールド値）が続きます。

SIPヘッダー-コンパクトフォーム

多くの一般的なSIPヘッダーフィールドには、ヘッダーフィールド名が単一の小文字で示されるコンパクトな形式があります。 いくつかの例を以下に示します-

Header Compact Form
To T
Via V
Call-ID I
Contact M
From F
Subject S
Content-Length I

SIPヘッダー形式

次の図は、一般的なSIPヘッダーの構造を示しています。

SIPヘッダー形式

ヘッダーは、SIPでの使用に応じて次のように分類されます-

  • リンク：/session_initiation_protocol/request_and_response_header_fields [リクエストとレスポンス]
  • リンク：/session_initiation_protocol/request_only_header [リクエストのみ]
  • リンク：/session_initiation_protocol/response_only_header [応答のみ]
  • リンク：/session_initiation_protocol/message_body_header [メッセージ本文]

SIP-セッション記述プロトコル

SDPはSession Description Protocolの略です。 ネットワークを介して参加者が理解できる形式でマルチメディアセッションを記述するために使用されます。 この説明に応じて、パーティは会議に参加するか、いつ、どのように会議に参加するかを決定します。

  • 会議の所有者は、セッションの説明を含むマルチキャストメッセージを送信することにより、ネットワーク上で会議をアドバタイズします。 所有者の名前、セッションの名前、コーディング、タイミングなど。 これらの情報に応じて、広告の受信者はセッションへの参加について決定を下します。
  • SDPは一般に、一般にSIPと呼ばれるセッション開始プロトコルの本文部分に含まれています。
  • SDPはRFC 2327で定義されています。 SDPメッセージは、フィールドと呼ばれる一連の行で構成されます。フィールドの名前は、単一の小文字で省略され、解析を簡素化するために必要な順序になっています。

SDPの目的

SDPの目的は、マルチメディアセッションでメディアストリームに関する情報を伝達し、参加者が特定のセッションの情報に参加または収集できるようにすることです。

  • SDPは、短い構造化されたテキスト記述です。
  • セッションの名前と目的、メディア、プロトコル、コーデック形式、タイミング、トランスポート情報を伝えます。
  • 仮の参加者はこれらの情報を確認し、セッションに参加するかどうか、および参加する場合はセッションに参加する方法とタイミングを決定します。
  • この形式には、<type> = <value>の形式のエントリがあります。<type>は一意のセッションパラメータを定義し、<value>はそのパラメータの特定の値を提供します。 SDPメッセージの一般的な形式は- + x = parameter1 parameter2 …​ パラメーターN *
  • 行は、xなどの単一の小文字で始まります。 文字と=の間にスペースが存在することはありません。また、各パラメーターの間にスペースが1つだけ存在します。 各フィールドには、定義された数のパラメーターがあります。

セッション記述パラメーター

セッションの説明（*はオプションを示す）

  • v =（プロトコルバージョン）
  • o =（所有者/作成者およびセッション識別子）
  • s =（セッション名） i = （セッション情報） u = （説明のURI） e = （メールアドレス） p = （電話番号） c = （接続情報-すべてのメディアに含まれる場合は不要） b = （帯域幅情報） z = （タイムゾーン調整） k = （暗号化キー） a = （ゼロ以上のセッション属性行）

プロトコルバージョン

v =フィールドには、SDPバージョン番号が含まれています。 SDPの現在のバージョンは0であるため、有効なSDPメッセージは常にv = 0で始まります。

原点

o =フィールドには、セッションの発信者とセッションIDに関する情報が含まれています。 このフィールドは、セッションを一意に識別するために使用されます。

  • フィールドには含まれています- + o = <username> <session-id> <version> <network-type> <address-type>
  • username パラメーターには、発信者のログインまたはホストが含まれます。
  • session-id パラメーターは、一意性を確保するために使用されるNetwork Time Protocol（NTP）タイムスタンプまたは乱数です。
  • version は、セッションへの変更ごとに増加する数値フィールドであり、NTPタイムスタンプにすることも推奨されます。
  • network-type は、インターネットでは常にINです。 address-typeパラメーターは、ドット付き10進形式または完全修飾ホスト名のIPv4またはIPv6アドレスのIP4またはIP6のいずれかです。

セッション名と情報

s =フィールドには、セッションの名前が含まれています。 ゼロ以外の文字を含めることができます。 オプションのi =フィールドには、セッションに関する情報が含まれます。 任意の数の文字を含めることができます。

URI

オプションのu =フィールドには、セッションに関する詳細情報を含むURI（Uniform Resource Indicator）が含まれます

メールアドレスと電話番号

オプションのe =フィールドには、セッションのホストの電子メールアドレスが含まれます。 オプションのp =フィールドには電話番号が含まれます。

接続データ

c =フィールドには、メディア接続に関する情報が含まれています。

  • フィールドには含まれています- + c = <ネットワークタイプ> <アドレスタイプ> <接続アドレス>
  • network-type パラメーターは、インターネットではINとして定義されています。
  • address-type は、IPv4アドレスの場合はIP4、IPv6アドレスの場合はIP6として定義されます。
  • connection-address は、メディアパケットを送信するIPアドレスまたはホストであり、マルチキャストまたはユニキャストのいずれかです。
  • マルチキャストの場合、接続アドレスフィールドには以下が含まれます- + connection-address = base-multicast-address/ttl/number-of-addresses

帯域幅

オプションのb =フィールドには、必要な帯域幅に関する情報が含まれています。 それは形式です-

b = modifier：bandwidth −値

時間、繰り返し時間、タイムゾーン

t =フィールドには、セッションの開始時間と終了時間が含まれています。

t =開始時間停止時間

オプションのr =フィールドには、NTPまたは日（[.small]＃d＃）、時間（[.small]＃h＃）、または分（[.small]＃）で指定できる繰り返し時間に関する情報が含まれます。 m＃）。

オプションの[.small] z =フィールドには、タイムゾーンオフセットに関する情報が含まれます。 このフィールドは、発生しているセッションが夏時間から標準時間への変更、またはその逆の場合に使用されます。

メディア発表

オプションの[.small] m =フィールドには、メディアセッションのタイプに関する情報が含まれます。 フィールドには含まれています-

m =メディアポートトランスポートフォーマットリスト

  • メディアパラメータは、オーディオ、ビデオ、テキスト、アプリケーション、メッセージ、画像、またはコントロールのいずれかです。 portパラメーターにはポート番号が含まれています。
  • トランスポートパラメータには、使用されるトランスポートプロトコルまたはRTPプロファイルが含まれます。
  • format-listには、メディアに関する詳細情報が含まれています。 通常、RTPオーディオビデオプロファイルで定義されたメディアペイロードタイプが含まれます。
Example:
m = audio 49430 RTP/AVP 0 6 8 99

これら3つのコーデックのいずれかをオーディオメディアセッションに使用できます。 3つのオーディオチャネルを確立することが目的の場合、3つの別個のメディアフィールドが使用されます。

属性

オプションのa =フィールドには、先行するメディアセッションの属性が含まれます。 このフィールドを使用して* SDPを拡張し、メディアに関する詳細情報を提供できます*。 SDPユーザーが完全に理解していない場合、属性フィールドは無視できます。 メディアフィールドにリストされているメディアペイロードタイプごとに、1つ以上の属性フィールドがあります。

SDPの属性は次のいずれかです。

  • セッションレベル、または
  • メディアレベル。

セッションレベルとは、SDPの最初のメディア行の前に属性がリストされることを意味します。 この場合、属性はその下のすべてのメディア行に適用されます。

メディアレベルとは、メディア行の後にリストされることを意味します。 この場合、属性はこの特定のメディアストリームにのみ適用されます。

SDPには、セッションレベルとメディアレベルの両方の属性を含めることができます。 同じ属性が両方として表示される場合、メディアレベル属性は、その特定のメディアストリームのセッションレベル属性をオーバーライドします。 接続データフィールドは、セッションレベルまたはメディアレベルのいずれかになります。

SDPの例

以下に、RFC 2327から取られたセッションの説明の例を示します- 

v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = mjh@isi.edu(Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait

SIP-オファー/アンサーモデル

SIPでのSDPの使用は、SDPオファー応答RFC 3264に記載されています。 SIPのデフォルトのメッセージ本文タイプは application/sdp です。

  • 発呼側は、通常はINVITEまたはACKでSDPで受信するメディア機能をリストします。
  • 着信側は、INVITEへの200 OK応答にメディア機能をリストします。

SDPの一般的なSIP使用には、バージョン、発信元、件名、時間、接続、1つ以上のメディアと属性のフィールドが含まれます。

  • 件名と時間のフィールドはSIPでは使用されませんが、互換性のために含まれています。
  • SDP標準では、件名フィールドは必須フィールドであり、件名がない場合はs =-であることが推奨される少なくとも1つの文字を含む必要があります。
  • 通常、時間フィールドはt = 00に設定されます。 SIPは、接続、メディア、および属性フィールドを使用して、UA間のセッションをセットアップします。
  • 起点フィールドは、SIPでの使用が制限されています。
  • セッションIDは通常、SIPセッション全体で一定に保たれます。
  • バージョンは、SDPが変更されるたびに増分されます。 送信されるSDPが以前に送信されたSDPから変更されていない場合、バージョンは同じままです。
  • 使用するメディアセッションとコーデックのタイプは接続ネゴシエーションの一部であるため、SIPはSDPを使用して複数の代替メディアタイプを指定し、それらのメディアタイプを選択的に受け入れまたは拒否できます。

オファー/アンサー仕様、RFC 3264では、= rtpmap：を含む属性を各メディアフィールドに使用することを推奨しています。 メディアストリームは、SDP応答の対応するメディアフィールドのポート番号をゼロに設定することにより拒否されます。

例

次の例では、発信者のテスラは、最初のINVITEで伝送されるSDPで2つの可能なオーディオコーデックとビデオコーデックを使用して、オーディオおよびビデオコールをセットアップしたいです- 

v = 0
o = John 0844526 2890844526 IN IP4 172.22.1.102
s = -
c = IN IP4 172.22.1.102
t = 0 0
m = audio 6000 RTP/AVP 97 98
a = rtpmap:97 AMR/16000/1
a = rtpmap:98 AMR-WB/8000/1
m = video 49172 RTP/AVP 32
a = rtpmap:32 MPV/90000

コーデックは、RTP/AVPプロファイル番号97、98によって参照されます。

被呼者のMarryはコールに応答し、最初のメディアフィールドに2番目のコーデックを選択し、AMRセッションのみを必要とする2番目のメディアフィールドを拒否します。 

v = 0
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110
s = -
c = IN IP4 200.201.202.203
t = 0 0
m = audio 60000 RTP/AVP 8
a = rtpmap:97 AMR/16000
m = video 0 RTP/AVP 32

この音声のみの通話が受け入れられない場合、トムはACKを送信し、BYEを送信して通話をキャンセルします。 そうしないと、オーディオセッションが確立され、RTPパケットが交換されます。

この例が示すように、メディアフィールドの数と順序が維持されない限り、発信者は、どのメディアセッションが着信者によって受け入れられ、拒否されたかを特定できません。

オファー/アンサールールは、次のセクションにまとめられています。

オファーを生成するためのルール

SDPオファーには、必要なすべてのSDPフィールドを含める必要があります（これには、v =、o =、s =、c =、およびt =が含まれます）。 これらはSDPの必須フィールドです。

通常、メディアフィールド（[.small]＃m =＃）が含まれますが、必須ではありません。 メディア行には、優先順にリストされているすべてのコーデックが含まれています。 唯一の例外は、エンドポイントが膨大な数のコーデックをサポートしている場合で、最も受け入れられる可能性が高いか、最も優先されるコーデックをリストする必要があります。 さまざまなメディアタイプには、オーディオ、ビデオ、テキスト、MSRP、BFCPなどが含まれます。

回答を生成するためのルール

オファーへのSDPの回答は、次のルールに従って構築する必要があります-

  • 回答には、回答と同じ順序で同じ数の[.small]＃m =＃行が必要です。
  • ポート番号を0に設定すると、個々のメディアストリームを拒否できます。
  • ストリームは、ゼロ以外のポート番号を送信することにより受け入れられます。
  • 各メディアタイプのリストされたペイロードは、オファーにリストされたペイロードのサブセットである必要があります。
  • 動的ペイロードの場合、各方向で同じ動的ペイロード番号を使用する必要はありません。 通常、単一のペイロードのみが選択されます。

セッションを変更するためのルール

どちらの当事者も、別のオファー/アンサー交換を開始してセッションを変更できます。 セッションが変更された場合、次のルールに従う必要があります-

  • 発信元（[.small]＃o =＃）の行バージョン番号は、このSDPが以前の交換と同一であることを示す最後に送信したものと同じであるか、新しいSDPを示す1ずつ増加する必要があります。解析する必要があります。
  • オファーには、既存のすべてのメディア回線が含まれ、同じ順序で送信される必要があります。
  • [.small]＃m =＃行リストの最後に追加のメディアストリームを追加できます。
  • ポート番号を0に設定すると、既存のメディアストリームを削除できます。 このメディアラインは、このセッションのSDPおよび今後のすべてのオファー/アンサー交換に残る必要があります。

通話保留

通話中の一方が一時的に他方を保留にすることができます。 これは、元のINVITEと同じSDPを持つINVITEを送信しますが、 a = sendonly 属性が存在します。 

*a = sendrecv* 属性が存在する別のINVITEを送信することにより、コールが再びアクティブになります。 次の図は、コール保留のコールフローを示しています。

通話保留

SIP-モビリティ

  • パーソナルモビリティ*は、多数のデバイスで一定の識別子を保持する機能です。 SIPはREGISTERメソッドを使用して基本的なパーソナルモビリティをサポートします。これにより、モバイルデバイスはIPアドレスとインターネットへの接続ポイントを変更し、着信コールを受信できます。

また、SIPは*サービスモビリティ* –モバイル時に同じサービスを維持するユーザーの能力もサポートできます。

ハンドオーバー中のSIPモビリティ（プレコール）

デバイスは、単純なsip登録により、連絡先URIをレコードのアドレスにバインドします。 デバイスのIPアドレスに応じて、登録により、この情報はSIPネットワークで自動的に更新されます。

ハンドオーバー中に、ユーザーエージェントは異なるオペレーター間をルーティングし、別のサービスプロバイダーのAORとして連絡先に再度登録する必要があります。

たとえば、次のコールフローの例を見てみましょう。 新しいサービスプロバイダーで新しいSIP URIを一時的に受信したUA。 次に、UAは二重登録を実行します-

  • 最初の登録は、デバイスの連絡先URIを新しいサービスプロバイダーのAOR URIにバインドする新しいサービスオペレーターによるものです。
  • 2番目のREGISTERリクエストは元のサービスプロバイダーにルーティングされ、新しいサービスプロバイダーのAORが連絡先URIとして提供されます。

コールフローの後半で示すように、元のサービスプロバイダーのネットワークにリクエストが届くと、INVITEは新しいサービスプロバイダーにリダイレクトされ、新しいサービスプロバイダーはコールをユーザーにルーティングします。

SIP Mobility

最初の登録の場合、デバイスURIを含むメッセージは次のようになります- 

REGISTER sip:visited.registrar1.com SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca
Max-Forwards: 70
To: Tom <sip:UA1@registrar1.in>
From: Tom <sip:UA1@registrar1.in>;tag = 72d65a24
Call-ID: 4e719d1c1fc9000803630373300@172.22.1.102
CSeq: 1 REGISTER
Contact: <sip:Tom@172.22.1.102:5060>
Expires: 600000
Content-Length: 0

ローミングURIを持つ2番目の登録メッセージは次のようになります- 

REGISTER sip:home.registrar2.in SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u
Max-Forwards: 70
To: Tom <sip:UA1@registrar2.in>
From: Tom <sip:UA1@registrar2.in>;tag = 45375
Call-ID:87nr43i@172.22.1.102
CSeq: 6421 REGISTER
Contact: <sip:UA1@registrar2.in>
Content-Length: 0

上記の図に示されている最初のINVITEは、sip：registrar2.inに送信されます。 2番目のINVITEはsip：sip：Tom@registrar2.inに送信され、* sip：Tom@172.22.1.102*に転送されます。 トムに到達し、セッションを確立できます。 定期的に両方の登録を更新する必要があります。

通話中のモビリティ（再招待）

ユーザーエージェントは、あるネットワークから別のネットワークにスワップするときに、セッション中にIPアドレスを変更する場合があります。 ダイアログのre-INVITEを使用して連絡先URIを更新し、SDPのメディア情報を変更できるため、基本的なSIPはこのシナリオをサポートします。

下の図に記載されているコールフローを見てください。

  • ここで、トムは新しいネットワークを検出し、
  • DHCPを使用して新しいIPアドレスを取得し、
  • re-INVITEを実行して、新しいIPアドレスへのシグナリングとメディアフローを許可します。

UAが両方のネットワークからメディアを受信できる場合、中断は無視できます。 そうでない場合、いくつかのメディアパケットが失われ、通話がわずかに中断されることがあります。

通話中のモビリティ

再招待は次のように表示されます- 

INVITE sip:Jerry@TTP.com SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a
Max-Forwards: 70

To: <sip:Harry@TTP.com>

From: sip:Tom@PPT.com;tag = 70133df4
Call-ID: 76d4861c19c
CSeq: 1 INVITE
Accept: application/sdp
Accept-Language: en

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE
Contact: <sip:172.22.1.102:5060>;
Content-Type: application/sdp
Content-Length: 168

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1
s = -
c = IN IP4 192.168.2.1
b = AS:49
t = 0 0
b = RR:0
b = RS:0
a = rtpmap:97 AMR/8000/1
m = audio 6000 RTP/AVP 96
a = fmtp:102 0-15
a = ptime:20
a = maxptime:240

re-INVITEでは、ViaおよびContactヘッダーフィールドにBowditchの新しいIPアドレスとSDPメディア情報が含まれています。

通話中のモビリティ（ヘッダーの交換あり）

ミッドコールモビリティでは、実際のルートセット（SIPメッセージが通過する必要があるSIPプロキシのセット）を変更する必要があります。 ミッドコールモビリティではre-INVITEを使用できません

たとえば、NATトラバーサルにプロキシが必要な場合、連絡先URIを変更する必要があります—新しいダイアログを作成する必要があります。 したがって、既存のセッションを識別するReplacesヘッダーを持つ新しいINVITEを送信する必要があります。

注-AとBの両方が通話中で、Aが置換ヘッダー（既存のダイアログと一致する必要がある）を使用して別のINVITE（Cから発言）を取得すると、AはINVITEを受け入れてBとのセッションを終了し、転送する必要があります新しく形成されたダイアログへのすべてのリソース。

次の図にコールフローを示します。 これは、Replacesを含むINVITEが受け入れられると、既存のダイアログを終了するためにBYEが自動的に生成されることを除いて、re-INVITEを使用する以前のコールフローに似ています。

通話中のモビリティ

以下に、このシナリオで注意すべき点を示します-

  • トムとジェリーの間の既存のダイアログには、訪問済みの古いプロキシサーバーが含まれています。
  • 新しいワイヤレスネットワークを使用する新しいダイアログには、新しい訪問済みプロキシサーバーを含める必要があります。
  • その結果、TomによってReplacesを含むINVITEが送信され、新しい訪問済みプロキシサーバーを含むが古い訪問済みプロキシサーバーを含まない新しいダイアログが作成されます。
  • JerryがINVITEを受け入れると、BYEが自動的に送信され、セッションに関与しなくなった古い訪問済みプロキシサーバーを経由する古いダイアログが終了します。
  • 結果のメディアセッションは、INVITEのSDPからのトムの新しいIPアドレスを使用して確立されます。

サービスモビリティ

SIPのサービスは、プロキシまたはUAで提供できます。 ユーザーのデバイスが同じサービスで同一に構成されていない限り、パーソナルモビリティとともにサービスモビリティを提供することは困難な場合があります。

SIPは、インターネットを介したサービスモビリティを簡単にサポートできます。 インターネットに接続されている場合、インドで一連のプロキシを使用するように構成されたUAは、ヨーロッパでローミングするときにそれらのプロキシを引き続き使用できます。 メディアは常に2つのUA間を直接流れ、SIPプロキシサーバーを通過しないため、メディアセッションの品質には影響しません。

エンドポイント常駐サービスは、エンドポイントがインターネットに接続されている場合にのみ利用できます。 エンドポイントでインターネット接続が一時的に失われた場合、エンドポイントに実装された着信転送サービスなどの着信サービスは失敗します。 したがって、一部のサービスは、SIPプロキシサーバーを使用してネットワークに実装されます。

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スペースは独立しています。 単一の方向内では、シーケンス番号はトランザクションごとに増分されます。

コールレッグID

ボイスメール

ボイスメールは現在、エンタープライズユーザーにとって非常に一般的です。 電話アプリケーションです。 着信側が利用できない場合、またはコールを受信できない場合、PBXは発呼側に音声メッセージを残すように通知します。

ユーザーエージェントは、着信者の番号に到達できない場合、3xx応答を受け取るか、ボイスメールサーバーにリダイレクトします。 ただし、ボイスメールシステムに使用するメールボックス、つまり、再生するグリーティングと録音されたメッセージを保存する場所をボイスメールシステムに示すには、何らかの種類のSIP拡張が必要です。 これを達成するための2つの方法があります-

  • SIPヘッダーフィールド拡張機能を使用して
  • Request-URIを使用してこの情報を通知する

ユーザー* sip：Tom@finddevguides.com*のボイスメールシステムがsip：voicemail.finddevguides.comにあり、ボイスメールを提供しているとします。ボイスメールサーバーに転送されるINVITEのRequest-URIは次のようになります。 

sip:voicemail.finddevguides.com;target = sip:Tom@finddevguides.com;cause = 486

次の図は、Request-URIがメールボックス識別子と理由（ここでは486）をどのように運ぶかを示しています。

SIPボイスメール

SIP-プロキシとルーティング

知っているように、プロキシサーバーはステートレスまたはステートフルのいずれかです。 ここで、この章では、プロキシサーバーとSIPルーティングについて詳しく説明します。

ステートレスプロキシサーバー

ステートレスプロキシサーバーは、受信したメッセージを単に転送します。 この種類のサーバーは、呼び出しまたはトランザクションの情報を保存しません。

  • ステートレスプロキシは、転送されたSIP要求を忘れます。
  • トランザクションは、ステートレスプロキシを介して高速になります。

ステートフルプロキシサーバー

ステートフルプロキシサーバーは、受信したすべての要求と応答を追跡します。 必要に応じて、保存された情報を将来使用できます。 反対側から応答を受信しない場合、要求を再送信できます。

  • ステートフルプロキシは、転送されたリクエストを記憶するため、事前のルーティングに使用できます。 ステートフルプロキシは、_transaction_状態を維持します。 _Transactionはトランザクションの状態を意味し、 state を呼び出しません。
  • ステートフルプロキシの場合、トランザクションはステートレスほど高速ではありません。
  • ステートフルプロキシは、必要に応じて分岐および再送信できます（例：話中転送など）。

経由および記録ルート

レコードルート

Record-Routeヘッダーは、同じcall-idに対する後続のリクエストのパスに存在することを望むプロキシによってリクエストに挿入されます。 その後、ユーザーエージェントが後続のリクエストをルーティングするために使用します。

Via

Viaヘッダーは、サーバーによって要求に挿入され、ループを検出し、応答がクライアントに戻る方法を見つけるのに役立ちます。 これは、応答のみが宛先に到達するのに役立ちます。

  • UA自身がリクエストを送信するときに、Viaヘッダーフィールドに自身のアドレスを生成して追加します。
  • 要求を転送するプロキシは、独自のアドレスを含むViaヘッダーフィールドをViaヘッダーフィールドのリストの先頭に追加します。
  • 要求に対する応答を生成するプロキシまたはUAは、すべてのViaヘッダーフィールドを要求から順番に応答にコピーしてから、上部のViaヘッダーフィールドで指定されたアドレスに応答を送信します。
  • 応答を受信するプロキシは、上部のViaヘッダーフィールドをチェックし、自身のアドレスと一致します。 一致しない場合、応答は破棄されています。
  • 次に、上部のViaヘッダーフィールドが削除され、応答が次のViaヘッダーフィールドで指定されたアドレスに転送されます。

Viaヘッダーフィールドには、プロトコル名、バージョン番号、およびトランスポート（SIP/2.0/UDP、SIP/2.0/TCPなど）が含まれ、ポート番号と、received、rport、branchなどのパラメーターが含まれます。

  • UAまたはプロキシが、上部のViaヘッダーフィールドで指定されたアドレスとは異なるアドレスからリクエストを受信した場合、受信したタグはViaヘッダーフィールドに追加されます。
  • UAおよびプロキシによってViaヘッダーフィールドにブランチパラメーターが追加されます。これは、Request-URIとTo、From、Call-ID、およびCSeq番号のハッシュ関数として計算されます。

SIPからPSTN

SIP（ソフトフォン）とPSTN（旧電話）は両方とも異なるネットワークであり、異なる言語を話します。 したがって、これら2つのネットワーク間で通信するには、トランスレーター（ここではゲートウェイ）が必要です。

SIP電話がPSTNゲートウェイを介してPSTNに電話をかける方法を示す例を見てみましょう。

この例では、トム*（sip：tom@finddevguides.com）*は一口電話であり、ジェリーはグローバル電話番号+91401234567を使用しています。

ゲートウェイを介したSIPからPSTNへ

次の図は、ゲートウェイを介したSIPからPSTNへのコールフローを示しています。

PSTからPSTNへ

以下に示すのは、SIP電話機からPSTNに電話をかける際に行われるすべてのプロセスの段階的な説明です。

  • まず、（Tom）SIP電話はグローバル番号+91401234567をダイヤルしてジェリーに連絡します。 SIPユーザーエージェントはそれをグローバル番号として認識し、DNSを使用してrequest-uriに変換し、要求をトリガーします。
  • SIP電話機は、INVITEをゲートウェイに直接送信します。
  • ゲートウェイは、PSTN内の次の電話スイッチへのSS7 ISUPトランクを選択することにより、PSTNへのコールを開始します。
  • INVITEからダイヤルされた数字は、ISUP IAMにマッピングされます。 ISUPアドレス完了メッセージ（ACM）は、トランクが作成されたことを示すためにPSTNによって返されます。
  • 電話は着信音を生成し、電話交換機に行きます。 ゲートウェイは、ACMを、ゲートウェイがPSTNからの音声をブリッジするために使用するRTPポートを示すSDPを含む183 Session Progress応答にマップします。
  • 183を受信すると、発信者のUACはゲートウェイから送信されたRTPパケットの受信を開始し、発信者に音声を提示して、着信者がPSTNで進行していることを知らせます。
  • 着信者が電話に応答するとコールが完了し、電話交換機がゲートウェイに応答メッセージ（ANM）を送信します。
  • 次に、ゲートウェイはPSTNオーディオ接続を両方向で切断し、200 OK応答を発信者に送信します。 RTPメディアパスがすでに確立されているため、ゲートウェイは183でSDPに応答しますが、RTP接続は変更されません。
  • UACはACKを送信して、SIPシグナリング交換を完了します。 ISUPには同等のメッセージがないため、ゲートウェイはACKを吸収します。
  • 呼び出し元はBYEをゲートウェイに送信して終了します。 ゲートウェイは、BYEをISUPリリースメッセージ（REL）にマッピングします。
  • ゲートウェイは200OKをBYEに送信し、PSTNからRLCを受信します。

SIP-コーデック

コーダー、デコーダーの略で、コーデックは2つの基本的な操作を行います-

  • まず、アナログ音声信号を同等のデジタル形式に変換して、簡単に送信できるようにします。
  • その後、圧縮されたデジタル信号を元のアナログ形式に変換して、再生できるようにします。

市場には多くのコーデックがあります。一部は無料ですが、ライセンスが必要なものもあります。 コーデックは音質が異なり、それに応じて帯域幅も異なります。

電話やゲートウェイなどのハードウェアデバイスは、いくつかの異なるコーデックをサポートしています。 互いに話し合いながら、使用するコーデックをネゴシエートします。

ここで、この章では、広く使用されているいくつかの一般的なSIPオーディオコーデックについて説明します。

G.711

G.711は、1972年にITUがデジタルテレフォニーで使用するために導入したコーデックです。 コーデックには2つのバリアントがあります。 A-Law はヨーロッパで使用されており、国際電話リンクでは uLaw は米国で使用されています。 そして日本。

  • G.711は対数圧縮を使用します。 各16ビットサンプルを8ビットに圧縮し、1：2の圧縮率を実現します。
  • ビットレートは一方向で64 kbit/sであるため、コールは128 kbit/sを消費します。
  • G.711は、PSTNネットワークで使用されるのと同じコーデックであるため、最高の音声品質を提供します。 ただし、他のコーデックよりも多くの帯域幅を消費します。
  • 多くの帯域幅を利用できるローカルエリアネットワークで最適に機能します。

G.729

G.729は、帯域幅の要件が低いコーデックです。それは良い音質を提供します。

  • コーデックは、オーディオを10ミリ秒のフレームでエンコードします。 サンプリング周波数が8 kHzの場合、10 msフレームには80個のオーディオサンプルが含まれます。
  • コーデックアルゴリズムは各フレームを10バイトにエンコードするため、結果のビットレートは一方向で8 kbit/sです。
  • G.729はライセンスされたコーデックです。 このコーデックを使用したいエンドユーザーは、それを実装するハードウェア（VoIP電話またはゲートウェイ）を購入する必要があります。
  • G.729の頻繁に使用されるバリアントはG.729aです。 元のコーデックとのワイヤ互換性がありますが、CPU要件は低くなります。

G.723.1

G.723.1は、28.8および33 kbit/sモデムリンクを介したコールを許可するコーデックの設計を目的としてITUが発表した競争の結果です。

  • G.723.1には2つのバリアントがあります。 どちらも30ミリ秒のオーディオフレームで動作します（つまり、 240サンプル）が、アルゴリズムは異なります。
  • 最初のバリアントのビットレートは6.4 kbit/sですが、2番目のバリアントのビットレートは5.3 kbit/sです。
  • 2つのバリアントのエンコードされたフレームの長さは、それぞれ24バイトと20バイトです。

GSM 06.10

GSM 06.10は、GSMモバイルネットワーク用に設計されたコーデックです。 GSMフルレートとも呼ばれます。

  • GSMコーデックのこのバリアントは自由に使用できるため、多くの場合、オープンソースのVoIPアプリケーションで使用されます。
  • コーデックは20ミリ秒の長さのオーディオフレームで動作します（つまり、 160サンプル）、各フレームを33バイトに圧縮するため、結果のビットレートは13 kbit/です。

SIP-B2BUA

バックツーバックユーザーエージェント（B2BUA）は、SIPアプリケーションの論理ネットワーク要素です。 SIP UAの一種で、SIPリクエストを受信し、リクエストを再定式化し、新しいリクエストとして送信します。

プロキシサーバーとは異なり、ダイアログの状態を維持し、確立したダイアログで送信されるすべての要求に参加する必要があります。 B2BUAは、SIPのエンドツーエンドの性質を破壊します。

B2BUA –仕組み

B2BUAエージェントは、通話の2つのエンドポイント間で動作し、通信チャネルを2つの*コールレッグ*に分割します。 B2BUAは、UACとUASの連結です。 コールの両端間のすべてのSIPシグナリングに参加し、確立しました。 ダイアログサービスプロバイダーで利用可能なB2BUAは、いくつかの付加価値機能を実装する場合があります。

発信コールレッグでは、B2BUAは_user agent server_（UAS）として機能し、宛先エンドへの_user agent client_（UAC）として要求を処理し、エンドポイント間の信号を連続して処理します。

B2BUAは、処理する呼び出しの完全な状態を維持します。 B2BUAの各サイドは、RFC 3261で指定されている標準のSIPネットワーク要素として動作します。

B2BUAの機能

B2BUAは次の機能を提供します-

  • 通話管理（請求、自動通話切断、通話転送など）
  • ネットワークインターワーキング（おそらくプロトコル適応による）
  • ネットワーク内部の隠蔽（プライベートアドレス、ネットワークトポロジなど）

多くの場合、B2BUAはメディアゲートウェイにも実装され、セッションを完全に制御するためにメディアストリームをブリッジします。

B2BUAの例

多くの構内交換機（PBX）エンタープライズ電話システムには、B2BUAロジックが組み込まれています。

一部のファイアウォールには、ALG（Application Layer Gateway）機能が組み込まれています。これにより、ファイアウォールは、高レベルのセキュリティを維持しながら、SIPおよびメディアトラフィックを許可できます。

B2BUAのもう1つの一般的なタイプは、セッションボーダーコントローラー（SBC）として知られています。

SIP-便利なリソース

次のリソースには、セッション開始プロトコルに関する追加情報が含まれています。 これについての詳細な知識を得るためにそれらを使用してください。

セッション開始プロトコルに関する便利なリンク

セッション開始プロトコルに関する有用な書籍

このページにサイトを登録するには、 contact @ finddevguides.com にメールを送信してください。

「https://www.finddevguides.com/index.php?title=Session-initiation-protocol-quick-guide&oldid=79358」から取得
Powered by MediaWiki