IPマルチメディアサブシステムのSIP拡張

セッション開始プロトコル（SIP）は、IPマルチメディアサブシステム（IMS）における複数の参加者によるマルチメディアセッションのために、第3世代パートナーシッププロジェクト（3GPP）[ 1 ] [ 2 ]で採用されたシグナリングプロトコルです。そのため、IMSフレームワークの中核コンポーネントとみなされています。

SIPは、インターネット技術特別調査委員会（IETF）によって、インターネットプロトコル（IP）ネットワークを介したマルチメディア通信セッションの標準技術として開発されました。インターネットプロトコルスイートのアプリケーション層に位置するSIPは、音声、ビデオ、テキストメッセージを含むリアルタイムセッションの開始、制御、終了のためのメカニズムを提供します。

標準化以来、高度な呼制御、セキュリティ機能、他のインターネットアプリケーションとの統合のサポートなど、プロトコルの機能を拡張するためのいくつかのSIP拡張機能がRFCとして公開されています。 [ 3 ] [ 4 ] [ 5 ]

IMSの開発と維持を目的とした電気通信協会のグループ間の協力関係である3GPPは、IMSでSIP [ 1 ]をうまく利用するための一連の要件を定めました。これらの要件の一部は、SIPの既存の機能と拡張機能を利用することで対応できましたが、他の要件については、3GPPはIETFと協力し、新しいSIP拡張機能[ 6 ]を標準化する必要 がありました。IETFはSIPを汎用的に開発しているため、拡張機能の使用はIMSフレームワークに限定されません。

SIPの3GPP要件

3GPPは、IMSの運用に関するいくつかの一般的な要件を定めています。これには、モバイル端末とネットワーク間のシグナリングメッセージの交換を最小限に抑えることによる無線インターフェースの効率的な利用、セッション確立中ではなくセッション確立前にタスクを実行することによるセッションセットアップ時間の短縮、端末に必要な最小限のサポート、端末モビリティ管理（SIPではなくアクセスネットワークによってサポート）によるローミングおよび非ローミングシナリオのサポート、およびIPv6アドレス指定のサポートが含まれます。

その他の要件には、ユーザーまたはサーバーの情報を交換するためのSIPヘッダー フィールドなどのプロトコル拡張や、登録、再登録、登録解除、イベント通知、インスタント メッセージング、または通話転送などの追加機能を備えた通話制御プリミティブの 要件など、新しいネットワーク機能をサポートするためのSIP メソッドが含まれます。

その他の具体的な要件は以下のとおりである: [ 1 ]

最後に、 DHCPやDNS [ 7 ]などの他のプロトコルやネットワークサービスもSIPと連携して動作するように適応させる必要があります。たとえば、アウトバウンドプロキシ（P-CSCF）の場所やSIP Uniform Resource Identifier（URI）からIPアドレスの解決などです。

拡張交渉メカニズム

SIPには、ユーザーエージェント（UA）またはサーバー間の拡張機能ネゴシエーションのためのメカニズム[ 2 ]があり、 supported、require、unsupportedの3つのヘッダーフィールドで構成され、UAまたはサーバー（つまり、ユーザー端末またはIMSのコールセッション制御機能（CSCF））は、理解できる拡張機能を指定するために使用できます。クライアントがサーバーとのSIPダイアログを開始すると、使用する必要がある拡張機能と理解できる（ supported ）その他の拡張機能を通知し、サーバーは必要な拡張機能のリストとともに応答を送信します。これらの拡張機能がクライアントのメッセージにリストされていない場合、サーバーからの応答はエラー応答になります。同様に、サーバーがクライアントの必要な拡張機能をまったくサポートしていない場合は、サポートされていない拡張機能のリストとともにエラー応答が送信されます。このような拡張機能はオプションタグと呼ばれますが、SIPは新しい方法で拡張することもできます。その場合、ユーザーエージェントまたはサーバーは、サポートするメソッドを通知するためにAllowヘッダーを使用します。特定のダイアログで特定のメソッドの使用を要求するには、そのメソッドに関連付けられた オプション タグを使用する必要があります。

SIP拡張機能

発信者の設定とユーザーエージェントの機能

これら 2 つの拡張機能により、ユーザーは IMS が提供するサービスに関する設定を指定できます。

発信者設定拡張[ 8 ]を使用すると、発信者は、到達したいユーザーエージェントの種類（固定かモバイルか、ボイスメールか人間か、個人用かビジネス用か、提供できるサービスか、サポートされる方法など）と、その検索方法を3つのヘッダーフィールドで示すことができます。Accept -Contactは、目的の宛先ユーザーエージェントを記述し、Reject-Contactは回避するユーザーエージェントを記述し、Request-Dispositionは、ネットワーク内のサーバーによる要求の処理方法（リダイレクトするかどうか、ユーザーを順番に検索するか並列で検索するかなど）を指定します。

ユーザーエージェント機能拡張[ 9 ]を用いることで、ユーザーエージェント（端末）は登録時に自身の情報を記述することができ、他のユーザーが発信者設定拡張ヘッダーに基づいて検索できるようになります。この目的のため、ユーザーエージェントはREGISTERメッセージの Contactヘッダーフィールドに自身の機能をリストします。

イベント通知

イベント通知の目的は、特定のリソース (ユーザー、ボイスメールサービスなど) のステータスを取得し、ステータスが変更されたときにそのステータスの更新を受け取ることです。

IMSフレームワークでは、イベント通知は、連絡を待っている可能性のある他のユーザーにユーザーの存在（「オンライン」または「オフライン」）を知らせたり、ユーザーとそのP-CSCFに自身の登録状態を通知して、ユーザーが連絡可能かどうか、また登録されているパブリックIDを把握したりするために不可欠です。さらに、イベント通知は、ボイスメール（受信トレイに新しい音声メッセージがあることを通知するなど） などの追加サービスの提供にも使用できます。

このため、特定のイベント通知拡張[ 10 ]では、 SUBSCRIBE と NOTIFY という 2 つの新しいメソッド、新しいヘッダー フィールドと応答コード、および加入者と通知者の2 つの役割を持つ SIP におけるイベント通知のフレームワークが定義されています。リソースの状態情報に関心のあるエンティティ (加入者) は、要求の最初の行にリソースの Uniform Resource Identifier (URI) を、イベント ヘッダーにイベントの種類を指定して SUBSCRIBE メッセージを送信します。次に、リソースの状態を追跡する役割を持つエンティティ (通知者) が SUBSCRIBE 要求を受信し、サブスクリプション状態ヘッダーと、メッセージ本体にリソースの状態に関する情報を指定して NOTIFY メッセージを送り返します。リソースの状態が変化するたびに、通知者は新しい NOTIFY メッセージを加入者に送信します。加入者がサブスクライブできるイベントの種類ごとに、新しいイベント パッケージで定義されます。イベントパッケージは、SUBSCRIBEイベント ヘッダーの新しい値と、NOTIFY メッセージでイベント状態情報を伝送する MIMEタイプを記述します。

また、イベント通知機能を示すallow-eventsヘッダーと、サブスクリプション要求が暫定的に承認されたか、または通知機能が要求されたイベントの種類を理解できないために拒否されたかを示す 202 承認済みおよび489 不正イベント応答コードもあります。

シグナリングメッセージを効率的に利用するために、イベントスロットリングと呼ばれるメカニズムを通じて、通知レート（リアルタイム通知ではない）を制限することも可能である。さらに、条件付きイベント通知のメカニズムも用意されており、通知者は、前回のサブスクリプション以降に通知すべき新しい情報があるかどうかに応じて、NOTIFYメッセージ全体を送信するかどうかを決定できる。

州の出版物

イベント通知フレームワークは、ユーザーエージェントがリソースの状態に関するイベントをサブスクライブする方法を定義しますが、その状態をどのように公開するかは規定していません。イベント状態公開のためのSIP拡張[ 11 ]は、ユーザーエージェントがイベント状態を作成し、サブスクライバーに配信する責任を負うエンティティ（通知者）にイベント状態を公開できるようにするために定義されました。

状態公開フレームワークは、新しいメソッド PUBLISH を定義します。このメソッドは、イベント ヘッダーに記述されたイベントとメッセージ本体で伝送された情報を参照して、リクエスト URI で指定されたリソースの状態の公開を要求するために使用されます。

インスタントメッセージ

テキストメッセージングに類似したサービスを提供するためにインスタントメッセージを送信する機能は、インスタントメッセージング拡張で定義されています。[ 12 ]これらのメッセージは互いに無関係であり（つまり、SIPダイアログを生成しない）、SIPシグナリングネットワークを介して送信され、制御メッセージとリソースを共有します。

この機能は、新しいMESSAGEメソッドによってサポートされています。このメソッドを使用すると、リクエストURIで指定されたリソースにインスタントメッセージを送信できます。送信されたコンテンツはメッセージ本文に含まれます。このコンテンツはMIMEタイプとして定義され、最も一般的なタイプ はtext/plainです。

関連するメッセージを含むインスタントメッセージセッションを行うために、メッセージセッションリレープロトコル（MSRP）[ 13 ]が利用可能です。

通話転送

REFERメソッド拡張[ 14 ]は、リクエストメッセージのRefer-Toヘッダーフィールドに含まれるURIで識別されるリソースへの接続をユーザーエージェントに要求するメカニズムを定義します。このメカニズムの典型的な用途はコール転送です。通話中に、REFERメッセージを送信する参加者は、対応するヘッダーフィールドに含まれるURIで識別されるユーザーエージェントに接続するよう受信者に指示します。REFERメッセージはまた、操作の結果に対するイベントサブスクリプションを暗黙的に含み、これにより送信者は受信者が第三者に接続できたかどうかを知ることができます。

ただし、 Refer-Toヘッダー フィールドには、受信者がWeb ページにアクセスすることを要求するためのHTTP URIなど、任意の種類の URI を指定できるため、このメカニズムは通話転送に限定されません。

暫定的な回答の信頼性

基本的なSIP仕様では、[ 15 ]リクエストと最終レスポンス（つまり2XXレスポンスコード）のみが確実に送信されます。つまり、確認応答メッセージ（つまり、リクエストに対応するレスポンスコード、または2XXレスポンスコードに対応するACKリクエスト）が到着するまで、送信者によって再送信されます。このメカニズムが必要なのは、SIPが、メッセージの配信を保証する信頼性の高いトランスポートプロトコル（ TCP ）だけでなく、配信保証のない信頼性の低いトランスポートプロトコル（ UDP）でも動作するためです。さらに、トランスポートネットワークの異なる部分に両方のプロトコルが存在する可能性もあります。

しかし、IMSフレームワークのようなシナリオでは、この信頼性をINVITE要求への暫定応答（通話を開始するためのセッション確立）にまで拡張する必要がある。暫定応答の信頼性拡張[ 16 ]は、呼び出し先に呼び出し音が鳴っていることを発信者に知らせる180 Ringing応答コードなどの暫定応答が正常に受信されたことを確認するメカニズムを提供する。そのために、この拡張は新しいメソッドであるPRACKを定義する。PRACKは、暫定応答の送信者にメッセージが受信されたことを伝えるために使用される要求メッセージである。このメッセージには、確認応答されている暫定応答のRSeqヘッダーフィールドに一致するシーケンス番号であるRACKヘッダーフィールドが含まれ、対応するINVITE要求を識別するCSeq番号も含まれる。ユーザーエージェントが信頼性の高い暫定応答を要求またはサポートしていることを示すために、100relオプションタグが使用されます。

セッションの説明の更新

UPDATEメソッド拡張[ 17 ]の目的は、ユーザーエージェントが、最初のINVITEリクエストに対する最終レスポンスが生成される前に、ダイアログ内で更新されたセッション記述情報を提供できるようにすることです。これにより、着信側にアラートが通知される前に、通話リソースのネゴシエーションと割り当てを行うことができます。

前提条件

IMSフレームワークでは、着信側が一度アラート通知を受けたら、セッションが失敗する可能性を最小限に抑えることが求められます。失敗の重要な原因の一つは、セッションをサポートするためのネットワークリソースを予約できないことであり、そのため、これらのリソースは電話が鳴る前に割り当てておく必要があります。しかし、IMSでは、リソースを予約するために、ネットワークは着信側のIPアドレス、ポート、およびセッションパラメータを認識する必要があり、そのためには、セッションを確立するための最初のオファー/アンサー交換（INVITE要求）が開始されている必要があります。基本的なSIPでは、この交換によって最終的に着信側がアラート通知を受けます。この問題を解決するために、前提条件[ 18 ]の概念が導入されました。この概念では、発信側はオファーにおいてセッションに関する一連の制約（コーデックやQoS要件など）を明示し、着信側はセッションを確立したりユーザにアラート通知したりすることなく、オファーに応答します。このセッションの確立は、発信側と着信側の両方が前提条件が満たされていることに同意した場合にのみ行われます。

前提条件SIP拡張は、新しいオプションタグ（前提条件）と定義されたオファー/アンサー交換を備えたSIPと、SIPメッセージの本文で伝送されるストリーミングメディア初期化パラメータを記述するために使用されるフォーマットであるセッション記述プロトコル（SDP）の両方に影響します。新しいSDP属性は、リソース予約の現在のステータス、セッション確立を続行するための予約の望ましいステータス、そして予約ステータスを確認するタイミングを示す確認ステータスを記述することを目的としています。

PRACKおよびUPDATEリクエストを使用したSDPオファー/アンサーモデル

IMSでは、初期セッションパラメータネゴシエーションは、暫定応答とセッション記述更新拡張、およびメッセージ本文のSDPを使用して行うことができます。SDPで記述された最初のオファーはINVITEリクエストによって伝送され、発信者がサポートするコーデックに対応します。このリクエストは、発信者と着信者の両方がサポートするコーデックのSDPリストを含む暫定的な信頼性応答コード183 Session Progressによって応答されます。この暫定応答に対応するPRACKは、コーデックを選択し、QoSネゴシエーションを開始するために使用されます。

QoSネゴシエーションはPRACK要求によってサポートされ、これにより発信側ネットワークでリソース予約が開始され、2XX応答コードが返されます。この応答が送信されると、着信側もコーデックを選択し、自側でリソース予約を開始します。その後、予約の進行状況を通知するためにUPDATE要求が送信され、2XX応答コードが返されます。典型的なオファー/アンサー交換では、[ 19 ]発信側が予約を完了するとUPDATEが1回送信され、着信側が応答して最終的にリソースの割り当てを完了します。そして、通話に必要なすべてのリソースが確保されると、発信者に通知されます。

識別と充電

IMSフレームワークでは、認証、認可、課金のためにユーザーIDを管理することが不可欠です。IMSはIPネットワーク上でマルチメディアサービスを提供することを目的としていますが、ユーザーに課金するためのメカニズムも必要です。これらの機能はすべて、新しい特別なヘッダーフィールドによってサポートされています。

Pヘッダー

SIPのプライベートヘッダー拡張[ 6 ]（Pヘッダーとも呼ばれる）は、特定のトポロジと下位層プロトコルの特性を持つプライベートネットワークにのみ適用可能な特別なヘッダーフィールドです。より一般的なソリューションがなかったため、3GPPの要件を満たすために特別に設計されました。

これらのヘッダー フィールドは、課金や通話が通過するネットワークに関する情報など、さまざまな目的で使用されます。

  • P-Charging-Vector：IMS Charging Identity（ICID）値、ICID値を生成するSIPプロキシのアドレス、Inter Operator Identifier（IOI）などの課金情報の集合。セッションの確立時、またはダイアログ外の独立したトランザクションとして入力されることがあります。
  • P-Charging-Function-Address：ユーザーのホームネットワークにおける課金機能（課金記録またはイベントを受信する機能エンティティ）のアドレス。このアドレスは、ダイアログの確立時またはスタンドアロントランザクションとして設定され、トランザクションに関与する各プロキシに通知されます。
  • P-Visited-Network-ID：訪問ネットワークの識別文字列。これは登録時に使用され、ローミングユーザーにサービスを提供しているネットワークをユーザーのホームネットワークに通知します。これにより、ホームネットワークはローミング契約に従って登録を承認できます。
  • P-Access-Network-Info ：無線アクセス技術やセルIDなど、アクセス技術（接続を提供するネットワーク）に関する情報。サービスプロキシやホームネットワークに通知することで、サービスの最適化や、無線ネットワーク内でのユーザーの位置特定に役立てられます。
  • P-Called-Party-ID：発信側ユーザーエージェントによって生成されたリクエストのリクエストURIで最初に示されたURI。リクエストが着信側ユーザーのレジストラ（S-CSCF）に到達すると、レジストラはリクエストの1行目のリクエストURIを着信側ユーザーの登録済み連絡先アドレス（IPアドレス）に書き換え、このヘッダーフィールドに置き換えたリクエストURIを保存します。IMSでは、ユーザーは複数のSIP URI（アドレス・オブ・レコード）で識別される場合があります。例えば、仕事用のSIP URIと個人用のSIP URIなどです。レジストラがリクエストURIを有効な連絡先アドレスに置き換える場合、着信側がどのアドレス・オブ・レコードに招待が送信されたかを把握できるように、元のリクエストURIを保存する必要があります。
  • P-Associated-URI : 登録中のユーザーに関連付けられた追加のURI。REGISTERリクエストに対する200 OKレスポンスに含まれ、サービスプロバイダがアドレス・オブ・レコード（AOR）URIに関連付けている他のURIをユーザーに通知します。

ユーザー データベース アクセス用に、さらにプライベート ヘッダーが定義されています。

  • P-User-Database : [ 20 ]特定のリクエストを生成したユーザーのプロファイルを含むユーザーデータベース、つまりホーム加入者サーバー(HSS)のアドレス。HSSは一意のマスターデータベースですが、信頼性と拡張性の観点から、異なるノードに分散することができます。この場合、特定のユーザーを処理するHSSを見つけるために加入者ロケーション機能(SLF)が必要です。ユーザーリクエストが管理ドメインのエッジにあるI-CSCFに到達すると、このエンティティは対応するHSSについてSLFを照会し、S-CSCFがSLFを再度照会する必要がないように、HSSアドレスをP-User-DatabaseヘッダーでS-CSCFに送信します。これにより、S-CSCFはHSSに直接照会して、ユーザーに関する情報(登録時の認証情報など)を取得できるようになります。[ 21 ]
  • P-Profile-Key : [ 22 ]特定のSIPリクエストの宛先SIP URIに対応するプロファイルをユーザーデータベース（HSS）に照会するために使用するキー。このキーはプロキシ間で転送され、データベースへの照会を高速化します。最初のプロキシがこのキーを見つけ、他のプロキシはこのキーを用いて直接データベースに照会します。これは、ワイルドカードサービスID（正規表現に一致するパブリックサービスID）を使用する場合に便利です。最初の照会では、キーを見つけるために正規表現を解決する必要があるためです。

主張されたアイデンティティ

信頼ネットワーク内におけるアサートされたIDのためのプライベート拡張[ 23 ]は、信頼されたSIPサーバーのネットワークが、認証されたユーザーのIDを、そのID情報の生成、転送、および使用に関する事前に合意されたポリシーを持つ管理ドメイン内でのみアサートできるようにすることを目的としています。これらの拡張により、ユーザーはプライバシーを要求することも可能になり、自身のIDが信頼ドメイン外に拡散されることを防ぎます。プライバシーを要求するには、プライバシートークンIDをPrivacyヘッダーフィールドに挿入する必要があります。 [ 24 ]

主な機能はP-Asserted-Identity拡張ヘッダーによってサポートされています。プロキシサーバーが信頼できないエンティティからのリクエストを受信し、ユーザーを認証（つまり、ユーザーが本人であることを確認する）すると、認証済みのIDをこのヘッダーに挿入し、通常どおりリクエストを転送します。これにより、信頼ドメイン（つまり、事前に合意されたセキュリティポリシーを持つ信頼されたエンティティのネットワーク）内でこのSIPリクエストを受信する他のプロキシサーバーは、ユーザーの再認証を行うことなく、P-Asserted-Identityヘッダーに含まれるID情報を安全に利用できます。

P -Preferred-Identity拡張ヘッダーも定義されているため、複数のパブリック ID を持つユーザーは、ユーザーが認証されるときに、どのパブリック ID を P-Asserted-Identity ヘッダーに含める必要があるかをプロキシに指示できます。

最後に、プライバシーが要求された場合、プロキシは、ユーザー要求を信頼されていない ID (信頼ドメインの外部) に転送する前に、P-Asserted-Identity ヘッダーを削除して、信頼されたドメインの外部でアサートされた ID 情報を保持する必要があります。

ユーザ自身ではなく、ユーザのサービスの識別を扱うための類似の拡張ヘッダーが存在する[ 25 ]。この場合、サービス（例：音声通話、インスタントメッセージセッション、 IPTVストリーミング）を識別するために、 Uniform Resource Nameが使用される[ 26 ] 。

セキュリティメカニズム

IMSにおけるアクセスセキュリティは、まずS-CSCFによってユーザーの認証と認可が行われ、次にP-CSCFとユーザー間の安全な接続が確立されることで実現されます。これを実現するメカニズムはいくつかあります。例えば、以下のようなものがあります。

SIPのセキュリティメカニズム合意拡張[ 28 ]は、P-CSCFと端末が使用するセキュリティアルゴリズムとパラメータをネゴシエートするための安全なメカニズムを提供するために導入されました。この拡張では、ネゴシエーションプロセスをサポートするために、3つの新しいヘッダーフィールドが使用されています。

  • まず、端末は、サポートするメカニズム、認証、暗号化アルゴリズムを含むsecurity-clientヘッダー フィールドを REGISTER 要求に追加します。
  • 次に、P-CSCFは、クライアントの応答と同じ情報を含むセキュリティサーバーヘッダーフィールドを応答に追加しますが、P-CSCFへの参照が追加されます。複数のメカニズムが存在する場合、それらは優先度値に関連付けられます。
  • 最後に、ユーザーエージェントは、ネゴシエートされたパラメータ（受信したセキュリティサーバヘッダーフィールドと同じ内容を持つセキュリティ検証ヘッダーフィールドを含む）を使用して、作成したばかりの安全な接続を介して新しい REGISTER 要求を送信します。この手順により、ネゴシエーションメカニズムが中間者攻撃から保護されます。攻撃者が、端末に弱いセキュリティアルゴリズムを選択させるために、セキュリティサーバヘッダーフィールドから最も強力なセキュリティメカニズムを削除した場合、セキュリティ検証ヘッダーフィールドとセキュリティサーバヘッダーフィールドは一致しなくなります。セキュリティ検証ヘッダーフィールドの内容は、新しく確立された安全なアソシエーションを介して送信されるため、このアソシエーションが攻撃者によってリアルタイムで破壊されない限り（つまり、P-CSCF が進行中の中間者攻撃を検出する前）、変更できません。

メディア認証

IMSにおいてサービス品質（QoS）を提供するためにリソースを予約する必要があることから、アドミッション制御とサービス拒否攻撃からの保護という新たなセキュリティ上の問題が生じます。伝送リソースを取得するには、ユーザーエージェントはネットワーク（ポリシー適用ポイント、つまりPEP）に認証トークンを提示する必要があります。このトークンはP-CSCFから取得されます。P-CSCFはQoSポリシー制御を担当している場合もあれば、認証トークンを最初に提供するネットワーク内のポリシー制御エンティティ（ポリシー決定機能、つまりPDF）とのインターフェースを備えている場合もあります。

メディア認証のためのプライベート拡張[ 29 ]は、認証トークンの取得メカニズムと、P-CSCFからユーザーエージェントへこれらのトークンを伝送するためのP-Media-Authorizationヘッダーフィールドを定義することにより、セッションシグナリングをネットワーク内のメディアに適用されるQoSメカニズムにリンクします。この拡張は、信頼関係のある管理ドメイン内でのみ適用可能です。これは、IMSのような特殊なSIPネットワーク向けに特別に設計されたものであり、一般的なインターネット向けではありません。

ソースルーティングメカニズム

ソースルーティングとは、メッセージの送信者がメッセージが通過する経路を部分的または完全に指定できるメカニズムです。SIPでは、送信者が設定するルートヘッダーフィールドに、メッセージが通過するプロキシのセットをリストすることで、この機能をサポートします。IMSのコンテキストでは、ユーザーからのリクエストまたはユーザーへのリクエストが通過する必要がある特定のネットワークエンティティ（特定のCSCFなど）が存在するため、それらはルートヘッダーフィールドにリストされます。送信者がこれらのエンティティを検出し、ルートヘッダーフィールドに値を設定できるようにするために、主に2つの拡張ヘッダーフィールド、つまりpathとservice-routeが存在します。

パス

非隣接コンタクトを登録するための拡張ヘッダーフィールド[ 30 ]は、 Pathヘッダーフィールドを提供します。このPathヘッダーフィールドは、REGISTERメッセージが通過する際に、ユーザーエージェントとそのレジストラの間に位置するプロキシのSIP URIを蓄積し、送信します。これにより、レジストラは、ユーザーエージェントに戻るために経由する必要があるプロキシの順序を検出し、記録することができます。

IMSでは、すべてのユーザーエージェントはP-CSCFによってサービスを受けます。P-CSCFは、ユーザーがIMSネットワークに入ると、ダイナミックホストコンフィギュレーションプロトコルまたは同等のメカニズムを使用して検出されます。ユーザーエージェントとの間のすべてのリクエストとレスポンスは、このプロキシを通過する必要があります。ユーザーがホームレジストラ（S-CSCF）に登録すると、P-CSCFはREGISTERメッセージのPathヘッダーフィールドに独自のSIP URIを追加します。これにより、S-CSCFはユーザーの連絡先情報に関連付けられたこの情報を受信して​​保存します。このようにして、S-CSCFはルートヘッダーフィールドにP-CSCFのURIをリストすることにより、そのユーザー宛のすべてのリクエストを対応するP-CSCF経由で転送します。

サービスルート

登録時のサービスルート検出の拡張[ 31 ]は、登録者がREGISTER要求に対する2XX応答で使用するService-Routeヘッダーフィールドで構成され、登録ユーザーに、そのユーザーが発信したすべての要求を転送する必要があるエンティティを通知します。

IMSでは、レジストラはホームネットワークのS-CSCFであり、すべてのリクエストはこのエンティティによって処理される必要があるため、サービスルートヘッダーフィールドに独自のSIP URIを含めます。ユーザーは、すべてのリクエストのルートヘッダーフィールドにこのSIP URIを含めることで、リクエストがホームS-CSCFを経由して転送されるようにします。

グローバルにルーティング可能なユーザーエージェントURI

IMSでは、ユーザーは複数の端末（携帯電話、コンピュータなど）やアプリケーションインスタンス（ビデオ電話、インスタントメッセージ、ボイスメールなど）を同じパブリックID（SIP URIなど）で識別することができます。そのため、リクエストを目的のデバイスまたはアプリケーションにルーティングするためのメカニズムが必要です。これがグローバルルーティング可能なユーザーエージェントURI（GRU）[ 32 ]です。GRUは特定のユーザーエージェントインスタンス（端末またはアプリケーションインスタンス）を識別し、それをグローバルに行うURIです（つまり、インターネット上の他のどのユーザーエージェントからでも、そのユーザーエージェントにメッセージをルーティングできます）。

これらのURIは、SIP URIにgrパラメータを追加することで構築されます。このパラメータは、ユーザーエージェントインスタンスを識別する値を持つパブリックSIP URI、またはプライバシー保護のためGRUUとユーザーIDの関係を明らかにしない特別に作成されたURIのいずれかです。これらのURIは通常、登録プロセス中に取得されます。登録するユーザーエージェントは、そのSIPインスタンスを一意に識別するUniform Resource Name (URN)を送信します。レジストラ（つまりS-CSCF）はGRUUを構築し、登録されたIDとSIPインスタンスに関連付けて、レスポンスでユーザーエージェントに返します。S-CSCFは、そのGRUUへのリクエストを受信すると、登録されたSIPインスタンスにリクエストをルーティングできるようになります。

シグナリング圧縮

IMSでは、無線インターフェースやその他の低帯域幅アクセスを含むネットワークリソースの効率的な利用が不可欠であり、これにより遅延の面でユーザーに許容できるエクスペリエンスが提供されます。この目的を達成するために、SIPメッセージはSigComp [ 33 ]（シグナリング圧縮） と呼ばれるメカニズムを使用して圧縮できます。

圧縮アルゴリズムは、メッセージ内で繰り返される単語を、それらの単語がすべて一度だけ出現する辞書内の位置で置き換えることによってこの操作を実行します。最初のアプローチでは、この辞書は圧縮器によって各メッセージに対して作成され、メッセージ自体と一緒に解凍器に送信されます。しかし、多くの単語が異なるメッセージで繰り返されるため、SigComp [ 34 ]の拡張操作は、後続のメッセージ間で共有辞書を使用する方法を定義します。さらに、後続のメッセージに沿って辞書を構築するプロセスを高速化し、最初のINVITEメッセージ以降の高い圧縮率を提供するために、SIPは共通のSIPおよびSDP用語で既に構築されている静的SIP/SDP辞書[ 35 ]を提供します。

SIPメッセージの圧縮を希望することを示すメカニズム[ 36 ]があります。このメカニズムは、SIP URIのcomp=sigcompパラメータを定義します。これは、URIで識別されるSIPエンティティがSigCompをサポートし、圧縮されたメッセージを受信する意思があることを示します。リクエストURIで使用される場合、このパラメータはリクエストを圧縮することを示し、Viaヘッダーフィールドで使用される場合、後続のレスポンスを圧縮することを示せます。

コンテンツ間接化

SIPメッセージをさらに短くし、リソースを効率的に利用するために、コンテンツ間接拡張[ 37 ]により、メッセージのMIMEボディ部分を外部参照（通常はHTTP URI）に置き換えることが可能になります。これにより、メッセージの受信者は、利用可能な帯域幅に応じて、リソースを取得するために参照に従うかどうかを決定できます。

NATトラバーサル

ネットワークアドレス変換（NAT）は、端末がプライベートネットワークの外部からアクセスすることを不可能にします。これは、端末がNATを通過する際に、プライベートアドレスがパブリックアドレスにマッピングされるためです。そのため、シグナリングプレーンとメディアプレーンの両方にNATトラバーサルメカニズムが必要です。

インターネットエンジニアリングタスクフォースのRFC 6314 [ 38 ]は、SIPシグナリングのための対称応答ルーティングとクライアント開始接続、メディアストリームのためのSTUN、TURN、ICE（これら2つを組み合わせたもの）の使用など、これを実現するためのさまざまな方法を要約して統合しています。

インターネット プロトコル バージョン 6 の互換性

インターネット技術タスクフォースのRFC 6157 [ 39 ]では、IPv6への移行中にSIPが両方のインターネットプロトコルバージョン間で正常に動作することを保証するために必要なメカニズムについて説明しています。プロキシサーバーとDNSエントリがこれらの推奨事項に従って両方のネットワーク間でメッセージを中継するように適切に設定されている限り、SIPシグナリングメッセージは異種のIPv4 / IPv6ネットワークを介して送信できますが、ユーザーエージェントはメディアストリームを直接交換できるように拡張を実装する必要があります。これらの拡張は、セッション記述プロトコルのオファー/アンサー初期交換に関連しており、両端のIPv4およびIPv6アドレスを収集して直接通信を確立するために使用されます。

他の技術との連携

IMS が正常に動作するために、これまで説明した SIP のすべての拡張機能に加え、IMS フレームワークが既存のネットワーク インフラストラクチャ、主に公衆交換電話網(PSTN) と相互運用してサービスを交換することも必要です。

この要件に対応する標準はいくつかありますが、たとえば PSTN とインターネット(つまり IMS ネットワーク) 間で相互運用するサービスに関する次の 2 つの標準があります。

また、PSTN-SIP ゲートウェイでは、各ネットワークの一方の端との通話をサポートする必要があります。

  • SIP-T（電話用セッション開始プロトコル）[ 42 ]では、これらのゲートウェイの実践と使用法について説明しています。
  • ISDNユーザーパート（ISUP）からセッション開始プロトコル（SIP）へのマッピング[ 43 ]により、 SIPシグナリングメッセージをPSTNで使用されるシグナリングシステムNo.7 （SS7）のISUPメッセージに変換したり、その逆を行ったりすることが可能になる。

さらに、SIP INFOメソッド拡張は、シグナリングダイアログに影響を与えずに端末間でユーザー情報を伝送するように設計されており、ユーザーに電話キーパッド機能を提供するためのデュアルトーンマルチ周波数シグナリングを伝送するために使用できます。[ 44 ]

参照

参考文献

  1. ^ a b c Garcia-Martin, M. (2005年5月). 3GPP (3rd-Generation Partnership Project) Release 5におけるSIP (Session Initiation Protocol)要件の入力. IETF . doi : 10.17487/RFC4083 . RFC 4083. 2014年11月29日閲覧.
  2. ^ a bカマリロ、ゴンサロ;ガルシア＝マルティン、ミゲル・A. (2008 年 11 月 4 日)。3G IP マルチメディア サブシステム (IMS): インターネットとセルラー世界の融合(第 3 版)。ジョン・ワイリー＆サンズ。ページ 55–336。ISBN​​ 978-0-470-51662-1. 2014年11月30日時点のオリジナルよりアーカイブ。2014年11月15日閲覧。
  3. ^ Poikselkä, Miikka; Mayer, Georg; Khartabil, Hisham; Niemi, Aki (2006年3月10日). The IMS: IP multimedia concepts and services (第2版). John Wiley & Sons. pp.  320– 331. ISBN 978-0-470-01906-1. 2014年11月15日時点のオリジナルよりアーカイブ。2014年11月15日閲覧。
  4. ^ Red Hat. 「8.6. SIP AND IMS EXTENSIONS」 . redhat.com . 2014年11月15日閲覧。
  5. ^ Systems & Networks Training. 「IMSにおけるSIP」 . snt.co.uk. 2015年3月28日時点のオリジナルよりアーカイブ。2014年11月15日閲覧。
  6. ^ a b Jesske, R.; Drage, K.; Holmberg, C. (2014年7月). 3GPPにおけるセッション開始プロトコル（SIP）のプライベートヘッダー（Pヘッダー）拡張. IETF . doi : 10.17487/RFC7315 . RFC 7315. 2014年11月15日閲覧.
  7. ^ Rosenberg, J.; Schulzrinne, H. (2002年6月).セッション開始プロトコル（SIP）：SIPサーバーの配置. IETF . doi : 10.17487/RFC3263 . RFC 3263. 2014年12月1日閲覧.
  8. ^ Rosenberg, J.; Schulzrinne, H.; Kyzivat, P. (2004年8月).セッション開始プロトコル（SIP）の発信者設定. IETF . doi : 10.17487/RFC3841 . RFC 3841 . 2014年12月1日閲覧.
  9. ^ Rosenberg, J.; Schulzrinne, H.; Kyzivat, P. (2004年8月). SIP (セッション開始プロトコル) におけるユーザーエージェント機能の指定. IETF . doi : 10.17487/RFC3840 . RFC 3840 . 2014年12月1日閲覧.
  10. ^ Roach, A. (2002年6月).セッション開始プロトコル（SIP）固有のイベント通知. IETF . doi : 10.17487/RFC3265 . RFC 3265. 2014年12月1日閲覧.
  11. ^ Niemi, A. (2004年10月).イベント状態発行のためのセッション開始プロトコル（SIP）拡張. IETF . doi : 10.17487/RFC3903 . RFC 3903. 2014年12月2日閲覧.
  12. ^ Campbell, B.; Ed., Rosenberg; J., Schulzrinne; H., Huitema; C., and; D., Gurle (2002年12月).インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張. IETF . doi : 10.17487/RFC3428 . RFC 3428 . 2014年12月2日閲覧.
  13. ^ Campbell, B.; 編, Mahy; R., 編; Jennings, C. (2007年9月).メッセージセッションリレープロトコル (MSRP) . IETF . doi : 10.17487/RFC4975 . RFC 4975. 2014年12月2日閲覧.
  14. ^ Sparks, R. (2003年4月).セッション開始プロトコル（SIP）Referメソッド. IETF . doi : 10.17487/RFC3515 . RFC 3515. 2014年12月2日閲覧.
  15. ^ a b Rosenberg, J.; et al. (2002年6月). SIP: セッション開始プロトコル. IETF . doi : 10.17487/RFC3261 . RFC 3261. 2014年11月15日閲覧。
  16. ^ Rosenberg, J.; Schulzrinne, H. (2002年6月).セッション開始プロトコル（SIP）における暫定応答の信頼性. IETF . doi : 10.17487/RFC3262 . RFC 3262 . 2014年12月2日閲覧.
  17. ^ Rosenberg, J. (2002年10月).セッション開始プロトコル（SIP）UPDATEメソッド. IETF . doi : 10.17487/RFC3311 . RFC 3311. 2014年12月2日閲覧.
  18. ^ Camarillo, G.; 編, Marshall, W., 編; Rosenberg, J. (2002年10月).リソース管理とセッション開始プロトコル（SIP）の統合. IETF . doi : 10.17487/RFC3312 . RFC 3312 . 2014年12月3日閲覧.
  19. ^ EvenHelix. 「IMSからIMSへの通話」（PDF） . eventhelix.com/ . 2015年1月22日時点のオリジナル（PDF）からアーカイブ。 2014年12月3日閲覧。
  20. ^ Camarillo, G.; Blanco, G. (2006年4月).セッション開始プロトコル (SIP) P-User-Database プライベートヘッダー (P-Header) . IETF . doi : 10.17487/RFC4457 . RFC 4457. 2014年12月5日閲覧.
  21. ^ EvenHelix. 「IMS登録」（PDF） . eventhelix.com/ . 2014年12月5日閲覧。
  22. ^ Camarillo, G.; Blanco, G. (2007年8月).セッション開始プロトコル（SIP）Pプロファイルキープライベートヘッダー（Pヘッダー） . IETF . doi : 10.17487/RFC5002 . RFC 5002. 2014年12月5日閲覧.
  23. ^ Jennings, C.; Peterson, J.; Watson, M. (2002年11月).信頼ネットワーク内でのアサートIDのためのセッション開始プロトコル（SIP）のプライベート拡張. IETF . doi : 10.17487/RFC3325 . RFC 3325 . 2014年12月3日閲覧.
  24. ^ Peterson, J. (2002年11月). 「セッション開始プロトコル（SIP）のプライバシーメカニズム」 . IETF . doi : 10.17487/RFC3323 . RFC 3323. 2014年12月3日閲覧.
  25. ^ Drage, K. (2010年11月).サービス識別のためのセッション開始プロトコル（SIP）拡張. IETF . doi : 10.17487/RFC6050 . RFC 6050. 2014年12月5日閲覧.
  26. ^ Rosenberg, J. (2010年6月). SIP（​​セッション開始プロトコル）における通信サービスの識別. IETF . doi : 10.17487/RFC5897 . RFC 5897. 2014年12月5日閲覧.
  27. ^ Niemi, A.; Arkko, J.; Torvinen, V. (2002年9月). Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) . IETF . doi : 10.17487/RFC3310 . RFC 3310 . 2014年12月5日閲覧。
  28. ^ Arkko, J.; Torvinen, V.; Camarillo, G.; Niemi, A.; Haukka, T. (2003年1月).セッション開始プロトコル（SIP）のセキュリティメカニズム協定. IETF . doi : 10.17487/RFC3329 . RFC 3329. 2014年12月5日閲覧.
  29. ^ Marshall, W. (2003年1月).メディア認証のためのプライベートセッション開始プロトコル（SIP）拡張. IETF . doi : 10.17487/RFC3313 . RFC 3313. 2014年12月5日閲覧.
  30. ^ Willis, D.; Hoeneisen, B. (2002年12月).非隣接コンタクトの登録のためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド. IETF . doi : 10.17487/RFC3327 . RFC 3327 . 2014年12月5日閲覧.
  31. ^ Willis, D.; Hoeneisen, B. (2003年10月).セッション開始プロトコル（SIP）登録時のサービスルート検出拡張ヘッダーフィールド. IETF . doi : 10.17487/RFC3608 . RFC 3608. 2014年12月5日閲覧.
  32. ^ Rosenberg, J. (2009年10月). SIP (セッション開始プロトコル) におけるグローバルルーティング可能なユーザーエージェントURI (GRUU) の取得と使用. IETF . doi : 10.17487/RFC5627 . RFC 5627 . 2014年12月5日閲覧.
  33. ^ Price, R.; Bormann, C.; Christoffersson, J.; Hannu, H.; Liu, Z.; Rosenberg, J. (2003年1月). Signaling Compression (SigComp) . IETF . doi : 10.17487/RFC3320 . RFC 3320. 2014年12月4日閲覧.
  34. ^ Hannu, H.; Christoffersson, J.; Forsgren, S.; Leung, K.-C.; Liu, Z.; Price, R. (2003年1月). Signaling Compression (SigComp) - Extended Operations . IETF . doi : 10.17487/RFC3321 . RFC 3321 . 2014年12月4日閲覧。
  35. ^ Garcia-Martin, M.; Bormann, C.; Ott, J.; Price, R.; Roach, A. (2003年2月).シグナリング圧縮のためのセッション開始プロトコル（SIP）およびセッション記述プロトコル（SDP）静的辞書（SigComp） . IETF . doi : 10.17487/RFC3485 . RFC 3485. 2014年12月4日閲覧.
  36. ^ Camarillo, G. (2003年2月).セッション開始プロトコル（SIP）の圧縮. IETF . doi : 10.17487/RFC3486 . RFC 3486. 2014年12月4日閲覧.
  37. ^ Burger, E. (2006年5月). SIPメッセージにおけるコンテンツ間接化のメカニズム. IETF . doi : 10.17487/RFC4483 . RFC 4483. 2014年12月4日閲覧.
  38. ^ Boulton, C.; Rosenberg, J.; Camarillo, G.; Audet, F. (2011年7月).クライアントサーバー型SIPにおけるNATトラバーサルの実践. IETF . doi : 10.17487/RFC6314 . RFC 6314. 2014年12月5日閲覧.
  39. ^カマリロ、G.エル、マルキ。 K、そして; V.、グルバニ (2011 年 4 月)。セッション開始プロトコル (SIP) における IPv6 の移行。IETF。土井: 10.17487/RFC6157。RFC 6157 。2014 年12 月 5 日に取得。
  40. ^ Petrack, S.; Conroy, L. (2000年6月). PINTサービスプロトコル：電話通話サービスへのIPアクセスのためのSIPおよびSDPの拡張. IETF . doi : 10.17487/RFC2848 . RFC 2848. 2014年12月5日閲覧.
  41. ^ Gurbani, V.; Ed., Brusilovsky; A., Faynberg; I., Gato; J., Lu; H., and; M., Unmehop​​a (2004年10月). SPIRITS (Services in PSTN requesting Internet Services) プロトコル. IETF . doi : 10.17487/RFC3910 . RFC 3910 . 2014年12月5日閲覧。
  42. ^ Vemuri, A.; Peterson, J. (2002年9月).電話用セッション開始プロトコル（SIP-T）：コンテキストとアーキテクチャ. IETF . doi : 10.17487/RFC3372 . RFC 3372. 2014年12月5日閲覧.
  43. ^ Camarillo, G.; Roach, A.; Peterson, J.; Ong, L. (2002年12月).統合サービスデジタル網（ISDN）ユーザ部（ISUP）とセッション開始プロトコル（SIP）のマッピング. IETF . doi : 10.17487/RFC3398 . RFC 3398 . 2014年12月5日閲覧.
  44. ^ Holmberg, C.; Burger, E.; Kaplan, H. (2011年1月).セッション開始プロトコル（SIP）INFOメソッドおよびパッケージフレームワーク. IETF . doi : 10.17487/RFC6086 . RFC 6086. 2014年12月5日閲覧.

本

「 https://en.wikipedia.org/w/index.php?title=SIP_extensions_for_the_IP_Multimedia_Subsystem&oldid=1324154111」より取得