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

セッション開始プロトコル （SIP ）は、IPマルチメディアサブシステム（IMS）内の複数の参加者とのマルチメディアセッションを作成および制御するために、第3世代パートナーシッププロジェクト（3GPP）^{[1] [2]}によって選択されたシグナリングプロトコルです。したがって、SIPはIMSフレームワークの重要な要素です。

SIPは、インターネット技術特別調査委員会（IETF）によって、インターネットプロトコル（IP）ネットワークにおけるマルチメディア通信セッションを制御するための標準として開発されました。インターネットプロトコルスイートのアプリケーション層に位置するのが特徴です。RFC（ Request for Comments ）プロトコル勧告で公開されたいくつかのSIP拡張機能が、基本プロトコルに追加され、その機能を拡張しています。^{[3] [4] [5]}

IMSの開発と保守を目的とした電気通信協会のグループ間のコラボレーションである3GPPは、IMSでSIP ^[1]を正常に使用するための一連の要件を規定しました。それらのいくつかは、SIPの既存の機能と拡張機能を使用して対処できましたが、他の場合には、3GPPは新しい要件を満たすためにIETFと協力して新しいSIP拡張機能^[6]を標準化する必要 がありました。IETFは汎用ベースでSIPを開発しているため、拡張機能の使用はIMSフレームワークに制限されません。

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

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

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

• ポリシーと課金制御によるサービス品質のサポート、および宛先ユーザーに警告する前のリソースのネゴシエーションと割り当て。
• 認証、承認、アカウンティングの目的でユーザーを識別します。ユーザーとネットワーク間、およびネットワーク ノード間のセキュリティは、秘密鍵、公開鍵、ダイジェスト、メディア承認拡張機能などの相互認証メカニズムを使用して対処する必要がある重要な問題です。発信者と着信者の両方に相手の ID を提示し、必要に応じてこの情報を非表示にすることもできなければなりません。セッション確立の匿名性とプライバシーも重要です。
• 初期認証と対称暗号キーに基づく整合性と機密性のサポートによる SIP シグナリングの保護。エラー回復と検証も必要です。
• ネットワークによって開始されたセッション解放 (例: ユーザー端末がカバレッジから外れた場合やクレジットが不足した場合)。
• ソース ルーティング メカニズム。SIPメッセージのルーティングには IMS 独自の要件があり、すべての端末発信セッション セットアップ試行はP-CSCF と S-CSCF の両方を通過して、これらのコール セッション制御機能 (CSCF) サーバーが適切にサービスを提供できるようにする必要があります。特定のメッセージには特別なパス要件がある場合もあります。
• IMS と公衆交換電話網(PSTN) 間の相互運用。

最後に、 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ヘッダーを使用します。特定のダイアログで特定のメソッドの使用を要求するには、そのメソッドに関連付けられたオプション タグを使用する必要があります。

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

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

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

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

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

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

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

シグナリング メッセージを効率的に使用するために、イベント スロットリングと呼ばれるメカニズムを通じて、通知レートを制限 (リアルタイム通知ではない) することもできます。さらに、条件付きイベント通知のメカニズムもあり、通知者は、前回のサブスクリプション以降に通知する新しいものがあるかどうかに応じて、完全な 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を定義します。これは、暫定応答の送信者にメッセージが受信されたことを伝えるために使用される要求メッセージです。このメッセージには、確認応答されている暫定応答のRSeqヘッダーフィールドと一致するシーケンス番号であるRACKヘッダーフィールドが含まれており、対応するINVITE要求を識別するCSeq番号も含まれています。ユーザーエージェントが信頼性の高い暫定応答を要求またはサポートしていることを示すために、100relオプションタグが使用されます。

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

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

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

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

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

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

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 : 発信側ユーザー エージェントによって生成された要求の request-URI で最初に示された URI。要求が着信側ユーザーのレジストラ (S-CSCF) に到達すると、レジストラは要求の最初の行の request-URI を着信側ユーザーの登録済み連絡先アドレス (つまり IP アドレス) で書き換え、置き換えられた request-URI をこのヘッダー フィールドに格納します。IMS では、ユーザーは複数の SIP URI (レコード アドレス) で識別される場合があります (たとえば、仕事用の SIP URI と個人用の別の SIP URI)。レジストラが request-URI を有効な連絡先アドレスに置き換える場合、着信側がどのレコード アドレスに招待が送信されたかを把握できるように、元の request-URI を格納する必要があります。
• P-Associated-URI : 登録中のユーザーに関連付けられている追加の URI。これは、REGISTER 要求に対する 200 OK 応答に含まれており、サービス プロバイダーが Address-of-Record (AOR) URI に関連付けている他の URI をユーザーに通知します。

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

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

信頼されたネットワーク内でのアサートされたアイデンティティのためのプライベート拡張^[23]は、信頼された SIP サーバーのネットワークが、この識別情報の生成、転送、および使用に関する事前に合意されたポリシーを持つ管理ドメイン内でのみ、認証されたユーザーのアイデンティティをアサートできるように設計されています。これらの拡張により、ユーザーはプライバシーを要求して、自分のアイデンティティが信頼ドメインの外部に広がらないようにすることもできます。そのことを示すには、プライバシー トークン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] 。この場合、} Uniform Resource Namesはサービス（音声通話、インスタントメッセージセッション、 IPTVストリーミングなど）を識別するために使用される^{[26] 。}

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

• HTTP ダイジェストアクセス認証は^{基本的なSIP仕様[15]}の一部でありユーザーとプロキシ間のトランスポート層セキュリティ接続につながります
• AKAを使用したHTTPダイジェストアクセス認証^[27]は、ユーザのスマートカードからの情報を使用し、通常P-CSCFと端末の間に2つのIPsecセキュリティアソシエーションを作成する、携帯電話ネットワーク向けの以前のメカニズムのより安全なバージョンです。

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

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

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]は、REGISTERメッセージが通過する際に、ユーザーエージェントとそのレジストラの間にあるプロキシのSIP URIを蓄積して送信する}Pathヘッダーフィールドを提供します。このようにして、レジストラはユーザーエージェントに戻るために通過する必要があるプロキシのシーケンスを検出して記録することができます。

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

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

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

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

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

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

圧縮アルゴリズムは、メッセージ内で繰り返される単語を、これらの単語がすべて 1 回だけ出現する辞書内の位置で置き換えることによってこの操作を実行します。最初のアプローチでは、この辞書は圧縮器によって各メッセージに対して構築され、メッセージ自体とともに解凍器に送信されます。ただし、異なるメッセージで多くの単語が繰り返されるため、 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 トラバーサルメカニズムが必要です。

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

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

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

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

• PSTNインターワーキングサービスプロトコル（PINT）^[40]は、SIPとSDPを拡張してPSTNの従来の電話通話サービス（基本的な電話通話、ファックスサービス、電話でのコンテンツの受信など）にアクセスします。
• PSTNのサービス要求インターネットサービス（SPIRITS）^[41]は、PINTとは逆の機能、つまりPSTNからインターネットサービスへのアクセスをサポートする機能を提供します。

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

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

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

• 次世代ネットワーク
• ボイスオーバーIP
• ティスパン

• ポイクセルカ、ミーッカ。メイヤー、ゲオルグ。ハルタビル、ヒシャム;ニエミ、アキ（2006年3月10日）。 IMS: IP マルチメディアの概念とサービス (第 2 版)。ジョン・ワイリー＆サンズ。ISBN 978-0-470-01906-1. 2014年11月15日閲覧。^{[永久リンク切れ‍ ]}
• カマリロ、ゴンサロ、ガルシア・マルティン、ミゲル A. (2008 年 11 月 4 日)。3G IP マルチメディア サブシステム (IMS): インターネットと携帯電話の世界の融合 (第 3 版)。John Wiley & Sons。ISBN 978-0-470-51662-1. 2014年11月15日閲覧。^{[永久リンク切れ‍ ]}

• 3rd Generation Partnership Project の IP マルチメディア サブシステムに関するページ
• IPマルチメディアサブシステムのコールフロー