(57)【要約】  通信ネットワークにおいてノード間のメディアセッションを管理する制御ノードにおける改良された方法において、２つのノード間で少なくとも１つのメディアセッション記述メッセージを交換し（Ｓ１０）、前記少なくとも１つのメッセージが前記メディアセッションに関する潜在的設定を示す少なくとも１つのオプションタグを含むか否かを判定する（Ｓ２０）。その後、前記少なくとも１つのオプションタグを、前記ネットワークについてサポートされる設定を示すネットワークサポーテッドオプションタグのセットと比較し（Ｓ３０）、前記比較に基づいて前記メディアセッション記述メッセージを修正する（Ｓ４０）。
2012506664.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークにおいてノード間のメディアセッションを管理する制御ノードにおける改良された方法であって、
２つのノード間でメディアセッション記述メッセージを交換するステップ（Ｓ１０）と、
前記少なくとも１つのメッセージが前記メディアセッションに関する潜在的設定を示す少なくとも１つのオプションタグを含むか否かを判定するステップ（Ｓ２０）と、
前記少なくとも１つのオプションタグを、前記ネットワークについてサポートされる設定を示すネットワークサポーテッドオプションタグのセットと比較するステップ（Ｓ３０）と、
前記比較に基づいて前記メディアセッション記述メッセージを修正するステップ（Ｓ４０）と、
を備えることを特徴とする方法。
【請求項２】
前記修正するステップ（Ｓ４０）は、前記少なくとも１つのオプションタグが前記ネットワークサポーテッドオプションタグに対応しない場合に、前記少なくとも１つのオプションタグによって示される潜在的設定を除去するステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記メディアセッション記述メッセージは、少なくともセッション記述パート及びメディア記述パートを含む
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記セッション記述パートが少なくとも１つのオプションタグを含む場合に、前記セッション記述パートに関して前記比較するステップ及び前記修正するステップを実行する
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記メディア記述パートが少なくとも１つのオプションタグを含む場合に、前記メディア記述パートに関して前記比較するステップ及び前記修正するステップを更に実行する
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記制御ノードの中に前記セットを維持管理して更新するステップ
を更に備えることを特徴とする請求項１に記載の方法。
【請求項７】
別のノードの中に前記セットを維持管理して更新するステップと、
前記セッション記述メッセージの中で規定されるオプションタグに応えて前記セットを前記制御ノードへ信号伝達するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項８】
通信ネットワークにおいてノード間のメディアセッションを管理する制御ノードにおける装置であって、
２つのノード間で交換される少なくとも１つのメディアセッション記述メッセージを管理する手段（１０）と、
前記少なくとも１つのメッセージが前記メディアセッションに関する潜在的設定を示す少なくとも１つのオプションタグを含むか否かを判定する手段（２０）と、
前記少なくとも１つのオプションタグを、前記ネットワークについてサポートされる設定を示すネットワークサポーテッドオプションタグのセットと比較する手段（３０）と、
前記比較に基づいて前記メディアセッション記述メッセージを修正する手段（４０）と、
を備えることを特徴とする装置。
【請求項９】
ネットワークサポーテッドオプションタグの前記セットを格納する手段
を更に備えることを特徴とする請求項８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、通信システムにおけるセッション管理に関し、具体的には、そのようなシステムにおけるセッションセットアップシグナリングに関する。
【背景技術】
【０００２】
通信システムにおける２以上の当事者間のセッションの中でストリーミングマルチメディアコンテンツを交換することに関連して、所謂セッション記述プロトコル（ＳＤＰ）［４］は、そのようなセッションの中のメディア（例えば、オーディオ、ビデオ）を記述するプロトコルである。これは、セッション告知(announcement)、セッション招待、及び他の形式のマルチメディアセッション開始を目的としてマルチメディア通信セッションを記述することが意図されている。ＳＤＰは、メディア形式のコンテンツそのものは提供しないが、２つのエンドポイントがメディアタイプ及びメディアフォーマットについて合意できるようにするために、２つのエンドポイント間の交渉を簡単に提供する。記述されることの例は、使用すべきコーデック、及び、ビットレートと、場合によっては更に、メディアが両方向に進むか（双方向）一方向にのみ進むか（単一方向）である。ＳＤＰは、一般的に、ＳＩＰ  ＩＮＶＩＴＥのボディの中に含まれる。ＳＩＰ（セッション開始プロトコル）［５］は、スタックプロトコルであり、例えば、通信システムにおいて呼び出し音(ring back)及び話中音(busy tone)が生成されることや呼をリダイレクトすることが可能であることを確実にするものである。
【０００３】
ＳＤＰは、当初は、単一方向フローのみを記述することが意図されていた。しかしながら、ＳＤＰは、双方向フローも扱うように拡張されてきた。提案／回答(offer/answer)は、ＳＤＰの中で使用される典型的なメカニズムであり、主要なアイデアは、呼を開始するユーザエージェント（ＵＡ）が、様々なメディアオプション及び各メディアの推奨コーデックのセットを伴う（ＳＩＰ−ＩＮＶＩＴＥメッセージの中で搬送される）ＳＤＰを提案するということである。ＳＤＰの提案を受信するＵＡは、反対方向の別のＳＩＰメッセージの中で、好ましいコーデック設定を返す。この提案／回答の交換が行われると、セッションが開始し、メディアが、セッションの中で２つの参加者（エージェント）の間を流れることになる。
【０００４】
ＳＤＰ又はＳＤＰメッセージは、典型的には、下記の２つのパートから成る。
【０００５】
・コンタクト情報及び開始／停止時刻を伴う、セッションに関する一般的な記述を与えるセッションレベル記述パート。セッションレベル上のパラメータ及び属性は、全メディアレベル記述に対して影響を与える。
【０００６】
・０以上のメディア記述を伴うメディアレベル記述パート。各メディア記述は、メディア（例えば、オーディオ又はビデオ）を定義する。メディアレベル上のパラメータは、１つのメディア記述に対してのみ適用される。
【０００７】
ＳＤＰの使用は、問題を伴わない訳ではない。本明細書において言及されるような従来のＳＤＰに伴う典型的な問題は、様々なビットレートを伴う様々な伝送フォーマット又はコーデックを提案するセッションを記述することが、ほとんど同じメディア記述を繰り返す必要なしには不可能であることである。その結果は、ともすれば曖昧になる巨大なセッション記述である。
【０００８】
最近開発された所謂ＳＤＰ能力交渉フレームワーク(SDP Capability Negotiation framework)(SDPCapNeg [1])は、ＩＥＴＦ  ＭＭＵＳＩＣ  ＷＧにおけるＳＤＰ提案／回答のためのフレームワークである。SDPCapNegの役割は、ＳＤＰに関する問題の大部分を解決しながらも依然として従来のＳＤＰとの後方互換性を持てることである。
【０００９】
コアのSDPCapNegフレームワークは、例えば所与のメディアのための様々な伝送フォーマットを提案することを、（従来のＳＤＰに関する深刻な制限として前述したような）ほとんど同じ内容を伴う幾つかのメディア記述を記載する必要なしに可能にする。
【００１０】
SDPCapNegフレームワークは、拡張の追加を支援する。これらの拡張は、ＳＤＰの中の所謂オプションタグによって識別される。拡張の１つは、"med-v0"というオプションタグによって識別されるメディア能力(SDPMedCapNeg)［２］である。このオプションタグは、例えば様々なビットレート要件を伴う様々なコーデックオプションを提案することを可能とし、これは、従来のＳＤＰでは不可能だったことである。
【００１１】
SDPCapNegフレームワークは、多数の能力属性（tcap及びacapという属性名）を導入し、また、能力属性を参照する多数の潜在的設定(potential configuration)（pcfgという属性名）を指定する可能性を導入する。SDPMedCapNegは、更に多くの能力属性を追加し、また、メディアのための能力交換を行うが実際のセッション・セットアップは後の段階で行うことを可能にする潜伏(latent)設定というコンセプトも追加する。
【００１２】
SDPCapNegに伴う潜在性(potential)は、ＩＭＳ環境の中で少々の問題を導入するかもしれない。１つの深刻な問題は、フレームワークが拡張をサポートするので、ネットワークの中でサポートされていない拡張がユーザエージェントによってセッション・セットアップ交渉の中で導入されるというリスクである。この問題は、SDPCapNegフレームワークが、これらの拡張を理解しない中間ノードに対してその拡張を隠蔽することが可能であるという事実によって、大きくなる。
【００１３】
【００１４】
【００１５】
それゆえ、サポートされない拡張の使用が曖昧な又は理解不可能なＳＤＰメッセージを結果としてもたらさないように保証する手段に対するニーズが存在する。
【発明の概要】
【００１６】
本発明の態様は、通信システムにおける、ＳＤＰメッセージ又は類似のメッセージの中の拡張に関する改良された管理を提供する方法及び装置を提供することである。
【００１７】
本発明の基本的な態様は、通信ネットワークにおいてノード間のメディアセッションを管理する制御ノードにおける改良された方法を開示する。最初に、２つのノード間でメディアセッション記述メッセージを交換し（Ｓ１０）、前記メッセージが少なくとも１つのオプションタグを含むか否かを判定する（Ｓ２０）。前記オプションタグは、前記メディアセッションのための潜在的設定を示す。続いて、前記オプションタグを、前記ネットワークに対してサポートされる設定を示すネットワークサポーテッドオプションタグのセットと比較する（Ｓ３０）。最後に、前記比較に基づいてメディアセッション開始メッセージを修正する（Ｓ４０）。
【００１８】
本発明の利点には、以下のものが含まれる。
−  ＵＡによるSDPCapNeg拡張の制御されない(uncontrolled)追加を回避すること。
−  拡張をどのように扱うかに関するルールを明確化し、それゆえ、問題となるエラー事例があまり発生しないようにすること。
−  曖昧なSDPCapNegの潜在的設定のリスクが減少すること。
−  ＳＩＰ−ＲＥＧＩＳＴＥＲの際に各ＵＡに対してサポートされるSDPCapNeg拡張を信号伝達する必要性が減少すること。
【図面の簡単な説明】
【００１９】
添付の図面と共に行われる以下の説明を参照することにより、本発明を、その更なる目的及び利点と共に、最もよく理解することができるだろう。
【図１】本発明を実装可能なシステムのイラストである。
【図２】本発明に従う方法の実施形態の概略フローチャートである。
【図３】本発明に従う方法の更なる実施形態の概略フローチャートである。
【図４】本発明に従う装置の実施形態のイラストである。
【発明を実施するための形態】
【００２０】
（略語）
ＣＳＣＦ  呼セッション制御機能
従来の(conventional)ＳＤＰ  SDPCapNeg又はその拡張を使用しないＳＤＰ
ＩＰ  移動サブシステム(Mobility Subsystem)
ＳＡＰ  セッション告知プロトコル(Session Announcement Protocol)
SDPCapNeg  SDP Capability Negotiation （フレームワーク）
SDPMedCapNeg  SDP Media Capability Negotiation （拡張）
ＳＧＢ  セッションボーダーゲートウェイ
ＳＧＣ  セッションボーダーコントローラ
ＳＤＰ  セッション記述プロトコル
ＳＩＰ  セッション開始プロトコル
ユーザエージェント
【００２１】
本発明が進化したフレームワークの理解を更に向上させるために、先行技術に伴う具体的な問題の幾つかを以下で論じる。加えて、本発明が有益になり得るシステムに関する幾つかの主要なコンセプト及びパーツを説明する。
【００２２】
前述したＳＤＰは、ストリーミングメディアの初期パラメータ(initialization parameters)をＡＳＣＩＩ文字列（又は類似のもの）で記述するためのフォーマットである。ＳＤＰは、ＳＩＰ及びＨＴＴＰなどのような多数の伝送プロトコルと共に使用可能である。しかしながら、本発明については、ＳＤＰはＳＩＰの文脈において記述される。これは、セッション告知(announcement)、セッション招待、及び他の形式のマルチメディアセッション開始を目的としてマルチメディア通信セッションを記述することが意図されている。ＳＤＰは、メディア形式のコンテンツそのものは提供しないが、２つのエンドポイントがメディアタイプ及びメディアフォーマットについて合意できるようにするために、２つのエンドポイント間の交渉を簡単に提供する。これにより、ＳＤＰが将来のメディアタイプ及びメディアフォーマットをサポートすることが可能になり、この技術に基づくシステムに前方互換性を持たせることが可能となる。ＳＤＰスタックに密接に関連し、且つＳＤＰスタックの主要な側面として見られるものとして、本質的には、以下の５つの用語が存在する。
【００２３】
●カンファレンス：  これは、２以上の通信ユーザと彼らが使用するソフトウェアとのセットである。
●セッション：  セッションは、メディアの送信者及び受信者、並びにデータのフローストリーム(flowing stream)である。
●セッション告知(announcement)：  セッション告知は、予測的／先行的(proactive)な態様でセッション記述をユーザへ伝達するメカニズムである（即ち、セッション記述はユーザによって明示的には要求されない）。
●セッション広告(advertisement)：  告知と同じである。
●セッション記述：  マルチメディアセッションを発見して参加するための十分な情報を伝達するための、明確に定義されたフォーマットである。
【００２４】
セッションは、１行につき１つの属性／値ペアの連なりによって記述される。属性名は１文字であり、＝及び値が続く。オプションの値は、＝＊によって指定される。値は、ＡＳＣＩＩ文字列であるか、又は、スペースによって区切られる特定のタイプのシーケンスである。なお、属性名は、関連するシンタックス構造の中でのみ（即ち、Ｓｅｓｓｉｏｎ、Ｔｉｍｅ、又はＭｅｄｉａの中でのみ）一意である。
【００２５】
セッションボーダーコントローラ（ＳＢＣ）は、幾つかのＶｏＩＰネットワークにおいて使用される、セッションを認識する(session aware)デバイスであり、シグナリング、及び更に通常は呼をセットアップし実行し切断することに伴うメディアストリームに対する制御を行うために、使用される。ＳＢＣは、ＶｏＩＰ呼における発呼側及び被呼側の当事者又はエージェント（主として、ＳＩＰ、Ｈ．３２３、及びＭＧＣＰ呼シグナリングプロトコルを使用するもの）の間のシグナリングパス及び／又はメディアパスに挿入される。典型的には、ＳＢＣは、各呼に伴う呼制御データのストリームを修正し、恐らく、実行可能な呼の種類を制限したり、コーデックの選択肢を変更したりするなどする。
【００２６】
前述のSDPCapNegプロトコルに伴う幾つかの問題の事例は、次の通りである。
●ＩＭＳ−非ＩＭＳ相互作用：  非ＩＭＳクライアントは、ＩＭＳ環境においてサポートされない拡張を導入するかもしれない。
●ＩＭＳバージョンの問題：  様々なＩＭＳネットワークが、標準の異なるバージョンに準拠するように実装されるかもしれない。ネットワークＡは、例えばメディア能力交換を受け付けるかもしれないが、ネットワークＢは受け付けない。
【００２７】
この問題に対する既知のソリューションは、ＩＰモビリティサブシステム呼セッション制御機能（ＩＭＳ  ＣＳＣＦ）又はセッションボーダーゲートウェイ（ＳＢＧ）が、未知の属性又は拡張をＳＤＰから削除するようにＳＤＰを検査して書き換え可能であることである。しかしながら、これは多数の問題を引き起こす。
【００２８】
例えば、メディア能力［２］及びＣＳ［３］拡張のＳＤＰを使用して下記のＳＤＰを提供することを考える。
【００２９】
m=audio
a=creq:med-v0,ccap-v0
a=ccap:1 IN
a=ccap:2 PSTN
a=mcap:1 AMR
・
・
a=pcfg:1 m=1 c=2
【００３０】
ＣＳＣＦは、（オプションタグ"med-v0"によって示される）メディア能力をサポートするが、（"ccap-v0"によって示される）ＣＳ拡張のＳＤＰ、及び関連するccap属性はサポートしない。それゆえ、"a=ccap"属性を伴う行はＳＤＰから消去される。
【００３１】
しかしながら、問題は、"a=pcfg"の行において、潜在的設定を形成するために幾つかの能力属性が参照されており、参照されるccap属性が除去されているために潜在的設定が曖昧になるということである。
【００３２】
参照される属性のうちの幾つかは相互に関連している場合があるので、この振る舞いは深刻な問題をもたらし得る。例えば、帯域属性は特定の伝送フォーマットに対してのみ妥当である可能性があり、１以上の被参照属性を除去することは、ＳＤＰの受信者が解釈することが困難又は不可能な潜在的設定を引き起こす可能性がある。
【００３３】
他の例は、"a=pcfg"の行に"+"オプションを使用することである。
【００３４】
m=audio
a=ccap:1 IN
a=ccap:2 PSTN
a=mcap:1 AMR
・
・
a=pcfg:1 +med-v0 +ccap-v0 m=1 c=2
a=pcfg:2 +med-v0 m=1
【００３５】
前述の例と同様、"ccap-v0"オプションはサポートされておらず、対応する"a=ccap"属性は未知であるために除去される。この場合、"a=pcfg:1 +med-v0 +ccap-v0 m=1 c=2"の行が曖昧になる。
【００３６】
曖昧な潜在的設定は、注意が払われない場合、解決できるか疑わしい未知の相互運用能力の問題を引き起こす場合がある。
【００３７】
本発明の実施形態の基本的なコンセプトは、ＳＤＰを検査してSDPCapNegフレームワークに対してサポートされる拡張のリストに基づいてＳＤＰを拒絶又は修正するＣＳＣＦ又はＳＢＧ（又は類似の中間デバイス）の中に、SDPCapNegポリシー機能を実装することである。本発明は、例えばＩＭＳフレームワークの外のＳＢＣによって利用可能であるので、ＳＢＧやＣＳＣＦのようなＩＭＳエンティティには限定されない。
【００３８】
図１は、セッションボーダーゲートウェイ（ＳＢＧ）経由で公衆インターネットと相互接続するＩＭＳシステムを概説する。ＩＭＳは、多数の呼セッション制御機能（ＣＳＣＦ）を含み、そこを介してセッションセットアップシグナリングが転送される。本発明では、ＣＳＣＦ及びＳＢＧが、セットアップ対象のセッションを記述するＳＤＰに関するポリシングを実行する。しかしながら、本発明は、セッションセットアップシグナリングに対するポリシングを行う任意のノードに対して適用可能である。
【００３９】
図１において、セッションは、無線３ＧＰＰインタフェース経由でＩＭＳネットワークに接続するハンドヘルドデバイスと、ＤＳＬ接続経由で公衆インターネットに接続するラップトップとの間でセットアップされる。
【００４０】
図２を参照して、本発明の基本的な実施形態を説明する。
【００４１】
２つのユーザエージェント又は当事者の間で直接又は中間ノード経由でメディアセッションが開始される、図１に示す状況を考える。最初に、メディアセッション記述メッセージ（例えば、ＳＤＰ）が、２つのセッション参加者の間で交換される（Ｓ１０）。メディアセッション記述メッセージが検査され、メッセージが何らかのオプションタグを含むか否かが判定される（Ｓ２０）。オプションタグは、潜在的設定を理解するために何らかの機能が必要であるということを示す。その機能は、両エンドポイント（即ち、各参加者）において必要であるが、単数又は複数の中間ノードにおいても必要である可能性がある。続いて、メディアセッション記述の中に存在する全てのオプションタグが、ネットワークにサポートされるオプションタグのセットと比較される（Ｓ３０）。これは好ましくは、システム中のノードの中に、サポートされるオプションタグに関するリスト又はテーブルを維持管理することにより可能となる。定義されたオプションタグの間に食い違いがあり、リストされたオプションタグ（例えば、定義されたオプションタグ）がリストの中に存在しない場合、メディアセッション記述メッセージは、曖昧なメッセージを防止するように修正される。
【００４２】
メディアセッション記述メッセージを修正するステップは、典型的には、メッセージのセッション記述パート及びメッセージのメディア記述パートの両方に対して実行される。
【００４３】
本発明の更なる実施形態によれば、検査及びポリシングは、３つのステップにおいて実行される。
【００４４】
１．セッションレベルで：  １以上のサポートされないオプションタグがセッションレベルで与えられる場合、全ての潜在的潜伏設定(potential and latent configurations)がＳＤＰ全体において除去される。
【００４５】
２．各メディア記述に対して：
ａ）１以上のサポートされないオプションタグがメディア記述に関して指定されている場合、そのメディア記述について全ての潜在的設定が除去される。
ｂ）メディアセッションの中の各潜在的設定に対して：  １以上のサポートされないオプションタグが指定されている場合、そのオプションタグが除去される。
【００４６】
３．各潜伏設定に対して：  １以上のサポートされないオプションタグが指定されている場合、その潜在的設定が除去される。
【００４７】
図３を参照して、本発明のフローチャートの更なる実施形態を示すフローチャートを説明する。中核の態様は、依然として、オプションタグが発生していないかＳＤＰを検査して、サポートされない（オプションタグによって示される）拡張のサポートを必要とするからサポート不可能な潜在的潜伏設定を除去することである。フローチャートによって与えられるポリシー機能は、SDPCapNegのＳＤＰに対して安全なポリシングを行うことを望む任意のノード（例えば、ＣＳＣＦ又はＳＢＧ）に実装可能である。
【００４８】
特に、SDPCapNegフレームワークに対する拡張は、ＳＤＰの中で"a=creq"属性又は"a=pcfg"行上の"+"パラメータのいずれかを使用するオプションタグによって示される拡張の使用を明示することが必要とされる。また、SDPCapNeg拡張に対するサポートは、"a=csup"オプションを用いて示すことができる。
【００４９】
本発明の実施形態に従う、例えばＩＭＳ  ＳＢＧ及び／又はＣＳＣＦにおけるポリシー機能は、次に、そのような拡張がないかＳＤＰを検査し、それらに対して必要なポリシングを実行しなければならない。
【００５０】
SDPCapNeg［１］は、ＳＤＰの受信者が、理解できない拡張をどのように扱うべきかを規定する。
【００５１】
［エンティティがＳＤＰを生成し、そのＳＤＰの受信者がＳＤＰ能力交渉を適切に処理するために１以上のＳＤＰ能力交渉拡張（baseを除く）をセッションレベル又はメディアレベルでサポートすることを要求する場合、セッションレベル及び／又はメディアレベルで必要とされる拡張を特定するオプションタグと共に"a=creq"属性が含まれなければならない。１以上の特定の潜在的設定においてのみ拡張のサポートが必要である場合、代わりに、その潜在的設定がその旨を示す方法を提供する（セクション３．５．１参照）。基本的な交渉フレームワークのサポートは、"a=pcfg"属性の存在によって暗示され（セクション３．５．１参照）、それゆえ、baseオプションタグ("cap-v0")と共に"a=creq"属性を含む必要はない。
【００５２】
ＳＤＰを受信するものの"creq"属性の中にリストされる必要な拡張のうちの１以上をサポートしない受信者は、本文書において規定されるＳＤＰ能力交渉を実行してはならない。セッションレベルで提供されるサポートされない拡張については、これは、ＳＤＰ能力交渉が全く行われてはならないということを暗示する。メディアレベルでのサポートされない拡張については、これは、問題のメディアストリームに対してＳＤＰ能力交渉が行われてはならないということを暗示する。］
【００５３】
本発明のノード（例えば、ＳＢＧ又はＣＳＣＦ）の中のポリシー機能の役割は、ネットワークによってサポートされないSDPCapNegに対する拡張に対応するＳＤＰの部分（パーツ）を除去することである。
【００５４】
この方法は、以下の例示的な実施形態に関連して最もよく説明することができる。
【００５５】
a=creq属性によって示される拡張
a=creqがメディアレベルで与えられ、この拡張がネットワークによってサポートされない場合、ポリシー機能は、そのメディアに関してSDPCapNegフレームワークを完全に除去することになる。換言すれば、全ての潜在的設定が除去される。
【００５６】
例：
m=audio …
a=fmtp…
a=rtpmap…
a=creq:med-v0
a=tcap:1 …
…
a=pcfg:1 …
a=pcfg:2 …
【００５７】
"med-v0"拡張（メディア能力）がサポートされない。これがもたらす結果は、このメディアに対してSDPCapNegフレームワークの全体が除去されるということである。そこで、ＳＤＰは下記のようになるように修正される。
【００５８】
m=audio …
a=fmtp…
a=rtpmap…
a=creq:med-v0
a=tcap:1 …
【００５９】
換言すると、潜在的設定が除去される。オプションとして、"a=creq"行も同様に除去してもよい。
【００６０】
サポートされないオプションタグが"a=creq"行においてセッションレベルで指定される場合、潜在的な及び／又は潜伏の設定は、ＳＤＰ全体から除去されることになる。
【００６１】
"a=pcfg"行上の"+"パラメータによって示される拡張
必要とされる拡張が"a=pcfg"行上のオプションタグとして示される場合、ポリシー機能の役割は、サポートされないSDPCapNeg拡張に対応する"a=pcfg"行を除去することである。
【００６２】
例
m=audio …
a=fmtp…
a=rtpmap…
a=tcap:1 …
…
a=pcfg:1 +med-v0 …
a=pcfg:2 …
【００６３】
前述の例と同様、"med-v0"はネットワークによってサポートされず、これは、行"a=pcfg:1 +med-v0 …"がＳＤＰから除去されるということを意味する。結果として得られるＳＤＰは、以下のようになるであろう。
【００６４】
m=audio …
a=fmtp…
a=rtpmap…
a=tcap:1 …
…
a=pcfg:2 …
【００６５】
ＳＤＰの知的設計(intelligent design)
本発明の実施形態を最大限に利用し、同時に、古いＩＭＳリリースに対して後方互換性を持たせるために、SDPCapNegに対する拡張を必要としない幾つかの基本的な潜在的設定が与えられるという意味において階層的なやり方でＳＤＰを作成することが有益である。
【００６６】
更なる実施形態によれば、ＵＡ  ＡからＵＡ  ＢへのＳＩＰ  ＩＮＶＩＴＥは、下記のＳＤＰを含む。
【００６７】
m=audio …
a=fmtp…
a=rtpmap…
a=tcap:1 …
…
a=pcfg:1 +med-v0 +ccap-v0 …
a=pcfg:2 +med-v0 …
a=pcfg:3 …
【００６８】
ホームＣＳＣＦの中のポリシー機能は、拡張ccap-v0をサポートしない。それゆえ、対応する"a=pcfg"行がＳＤＰから消去されることになる。その結果、ＳＤＰは以下のようになる。
【００６９】
m=audio …
a=fmtp…
a=rtpmap…
a=tcap:1 …
…
a=pcfg:2 +med-v0 …
a=pcfg:3 …
【００７０】
ＵＡ  Ｂが位置するネットワークがmed-v0をサポートしない可能性は大いにある。それゆえ、対応する"a=pcfg"行も同様に消去されることになり、その結果、ＳＤＰは以下のようになる。
【００７１】
m=audio …
a=fmtp…
a=rtpmap…
a=tcap:1 …
…
a=pcfg:3 …
【００７２】
換言すると、この例では、基本的なSDPCapNegフレームワークだけがサポートされる。
【００７３】
後になってＩＭＳネットワーク内のハードウェア及びソフトウェアが更新されるにつれて、潜在的設定が少ししかＳＤＰから除去されないようになってくる可能性がある。このことは、ネットワークが許可するならばエンドユーザに対してより豊かな体験（エクスペリエンス）をもたらすことになり、同時に、１以上の拡張がネットワークによって許可されないために本発明で説明するポリシー機能によって除去される場合であっても、予測可能なエクスペリエンスを保証することになる。
【００７４】
本発明の実施形態を説明するために、興味のある読者には、付録のアルゴリズム擬似コードを参照することをお勧めする。このコードは、ポリシー機能をどのように実装可能であるかに関する短い概要を与える。これは、シンタックス上、図３のフローチャートに類似している。
【００７５】
サポートされる拡張のリスト
規定されたオプションタグとサポートされるオプションタグとの比較を可能にするためには、SDPCapNegに対するサポートされる拡張のリスト（ホワイトリスト）がポリシー機能によって維持管理される必要があり、すると、ポリシー機能の役割は、ＳＤＰの中で規定されるオプションタグがサポートされるか否かを調べることである。一例として、このホワイトリストは、下記の表１のようになる。
【００７６】
表１
|------------------|----------------------------------------|
|３ＧＰＰリリース  |  オプションタグを伴うサポートされる拡張|
|------------------|----------------------------------------|
|７                |  {“cap-v0”}                          |
|８                |  {“cap-v0”,”med-v0”}               |
|９                |  {“cap-v0”,”med-v0”,”foo-bar”}   |
|------------------|----------------------------------------|
【００７７】
例えばローカルポリシールールが原因で、リストに対する変形が存在する場合もある。例えば、オペレータは、たとえ装置がそれをサポート可能であったとしても、自身のＩＭＳネットワークにおいて"foo-bar"拡張が使用されることを望まないかもしれない。除去ポリシーは、料金請求の問題にも属する。
【００７８】
ＳＤＰの拒絶
上述の修正オプションとは別に、ＳＤＰを完全に拒絶する可能性も存在する。そこで、理由文字列(reason string)の中に、どの拡張がサポートされないかを含め、サポートされない拡張を示すオプションタグを含むあらゆるＳＤＰを拒絶することが有益である。これは、セッションレベルでも、メディアレベルでも、その両方でも実装される。
【００７９】
図４を参照して、本発明に従う方法を可能にする装置を説明する。本装置は、着信シグナル及び発信シグナルの処理のためのよく知られた手段を備え、これについては更に説明することをしない。加えて、本装置は、通信システムにおけるエンティティ間のメディアセッション記述メッセージを管理するユニット１０を備える。この意味での管理は、メディアセッション記述メッセージの受信、送信、及び中継などの処理を含むように使用される。加えて、本装置は、管理されるメッセージを検査し、セッションのための潜在的設定を示すオプションタグ又は拡張／拡張パラメータをこのメッセージが含むか否かを判定するユニット２０を備える。規定されるあらゆるオプションタグを、ネットワーク全体によって又は各参加ユーザエージェントによってサポートされるオプションタグのリストと比較することを可能にするために、比較ユニット３０が含まれる。最後に、本装置は、比較結果に基づいて管理対象のメディアセッション記述メッセージを修正するように構成された修正ユニット４０を備える。
【００８０】
具体的には、比較ユニット３０は更に、システムにおいてサポートされるオプションタグのリストを維持管理して更新するように構成される。
【００８１】
本発明の利点には、下記のものが含まれる。
１．ＵＡにより行われるSDPCapNeg拡張の制御されない追加が効率的に回避される。
２．拡張をどのように扱うかに関する明確なルール  →  問題となるエラーの事例が少なくなる。
３．曖昧なSDPCapNeg潜在的設定のリスクが回避される。
４．ＩＭＳ装置がアップグレードされるにつれて、より多くのオプションが利用可能になる。それゆえ、ユーザに対してより豊かなエクスペリエンスが与えられるが、依然として、SDPCapNeg拡張に対して限られたサポートしかしないネットワークにおいて基本的なサービスを保証するように後方互換性が与えられる。
５．ＳＩＰ−ＲＥＧＩＳＴＥＲにおいて各ＵＡに対してサポートされるSDPCapNeg拡張を信号伝達する必要性が減少する。これは、SDPCapNeg拡張に関して異なるサポートを行う異なるＩＭＳネットワークの中に位置する２つのＵＡが通信することを望む場合に、いずれにせよ同期することが困難なことである。
６．最低限の拡張能力データベース。
【００８２】
提案される発明は、SDPCapNeg及びその拡張のセキュアな使用を保証するために、ＩＭＳネットワークの中の適用可能な部分に含まれることが勧められる。
【００８３】
強調しておくことが必要なこととして、前述のＳＤＰ能力交渉フレームワーク及びその拡張は、現在進行中の作業である。その意味するところは、属性名及びオプションタグは変更されるかもしれないということである。しかしながら、主要な設計原理は、それほど変更されることはないであろう。
【００８４】
当業者によって理解されるであろうこととして、添付の請求の範囲によって規定される本発明の範囲から逸脱することなしに、本発明に対して様々な修正及び変更を行うことができる。
【００８５】
参考文献
[1]    Andreasen, F., "SDP Capability Negotiation", http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation/  
(work in progress), July 2008.
[2]    Gilman. R, et. al., “SDP media capabilities Negotiation” http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-capabilities/  (work in progress), July 2008.
[3]    M. Garcia-Martin, et al., “Miscellaneous Capabilities in SDP”  http://tools.ietf.org/id/draft-garcia-mmusic-sdp-misc-cap-00.txt (work in progress), April 2008.
[4]    The IETF RFC’s listed below can be found at http://www.ietf.org/rfc.html .
[5]    SDP “Session Description Protocol”, IETF, RFC4556
[6]    SIP “Session Initiation Protocol”, IETF, RFC3261
【００８６】
付録
アルゴリズム擬似コード
下記の擬似コードは、実際の実装においてポリシー機能がどのように機能するかに関する短い概要を与える。この擬似コードは、シンタックス上は図３のフローチャートに類似している。
function police_SDP()
{
// function that checks if unsupported extensions
// to SDPCapNeg are specified and takes 
// necessary actions when needed.
if (option tags on session level) {
// a=creq given on session level
// check if unsupported extension is
// specified
if (any of the option tags not supported) {
remove all "a=pcfg" lines in SDP
exit function
}
} else {
for each (media in SDP) {
if (option tags on media level) {
// a=creq given on media level
// check if unsupported extension is
// specified
if (any of the option tags not supported) {
remove all "a=pcfg" lines for given media
exit to next media
}
} else {
for each (potential configuration) {
// check if potential configuration mandates
// unsupported extension by means of "+" option 
// on pcfg line
if ("+" option specifies unsupported 
extension(s) indicated by option tags) {
remove potential configuration from SDP
}
}
}
}
for each (latent configuration) {
// check if latent configuration mandates
// unsupported extension by means of "+" option 
// on pcfg line
if ("+" parameter specifies unsupported 
extension(s) indicated by option tags) {
remove latent configuration from SDP
}
}
}
}
【図１】
2012506664.tif 000003
【図２】
2012506664.tif 000004
【図３】
2012506664.tif 000005
【図４】
2012506664.tif 000006
【手続補正書】
【提出日】平成22年6月28日(2010.6.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
通信ネットワークにおいてノード間のメディアセッションを管理する制御ノードによって実行される改良された方法であって、
２つのノード間で少なくとも１つのメディアセッション記述メッセージを交換するステップ（Ｓ１０）と、
前記少なくとも１つのメッセージが前記メディアセッションに関する潜在的設定をサポートする拡張を示す少なくとも１つのオプションタグを含むか否かを判定するステップ（Ｓ２０）と、
前記少なくとも１つのオプションタグを、前記ネットワークについてサポートされる拡張を示すネットワークサポーテッドオプションタグのセットと比較するステップ（Ｓ３０）と、
前記比較に基づいて前記メディアセッション記述メッセージを修正するステップ（Ｓ４０）と、
を備えることを特徴とする方法。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項８
【補正方法】変更
【補正の内容】
【請求項８】
通信ネットワークにおいてノード間のメディアセッションを管理する制御ノードにおける装置であって、
２つのノード間で交換される少なくとも１つのメディアセッション記述メッセージを管理する手段（１０）と、
前記少なくとも１つのメッセージが前記メディアセッションに関する潜在的設定をサポートする拡張を示す少なくとも１つのオプションタグを含むか否かを判定する手段（２０）と、
前記少なくとも１つのオプションタグを、前記ネットワークについてサポートされる拡張を示すネットワークサポーテッドオプションタグのセットと比較する手段（３０）と、
前記比較に基づいて前記メディアセッション記述メッセージを修正する手段（４０）と、
を備えることを特徴とする装置。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】変更
【補正の内容】
【００１３】
特許公開ＷＯ２００８／０８３４７０は、コーデック交渉プロセスにおけるメディエーターを開示する。このメディエーターは、コーデック交渉を必要とする通信セッションの確立に関係するエンドポイントからシグナリングを受信し、知っているトポロジ情報に応じたコーデックポリシー基準に基づいてコーデックの選択に影響を与える。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】変更
【補正の内容】
【００１４】
これ以降Ｄ２と呼ばれる文書"SDP capability negotiation; draft-ietf-mmusic-sdp-capability-netotiation-ion-0.9tft" by F.Andreasenは、ＩＥＴＦのインターネットドラフトである。このドラフトは、ＳＤＰの中で１以上の代替伝送プロトコル又は属性をそのように交渉するかを開示する。Ｄ２によれば、これは、能力交渉パラメータと、これらのパラメータを使用する関連する提案／回答手順とにより、後方互換性を有するやり方でＳＤＰを拡張することによって、可能となる。加えて、汎用ＳＤＰ能力交渉フレームワークが規定される。
【手続補正書】
【提出日】平成23年9月8日(2011.9.8)
【手続補正１】
【補正対象項目名】手続補正１
【補正方法】変更
【補正の内容】
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信ネットワークにおいてノード間のメディアセッションを管理する制御ノードによって実行される改良された方法であって、
２つのノード間で少なくとも１つのメディアセッション記述メッセージを交換するステップ（Ｓ１０）と、
前記少なくとも１つのメッセージが前記メディアセッションに関する潜在的設定をサポートする拡張を示す少なくとも１つのオプションタグを含むか否かを判定するステップ（Ｓ２０）と、
前記少なくとも１つのオプションタグを、前記ネットワークについてサポートされる拡張を示すネットワークサポーテッドオプションタグのセットと比較するステップ（Ｓ３０）と、
前記比較に基づいて前記メディアセッション記述メッセージを修正するステップ（Ｓ４０）と、
を備えることを特徴とする方法。
【請求項２】
前記修正するステップ（Ｓ４０）は、前記少なくとも１つのオプションタグが前記ネットワークサポーテッドオプションタグに対応しない場合に、前記少なくとも１つのオプションタグによって示される潜在的設定を除去するステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記メディアセッション記述メッセージは、少なくともセッション記述パート及びメディア記述パートを含む
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記セッション記述パートが少なくとも１つのオプションタグを含む場合に、前記セッション記述パートに関して前記比較するステップ及び前記修正するステップを実行する
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記メディア記述パートが少なくとも１つのオプションタグを含む場合に、前記メディア記述パートに関して前記比較するステップ及び前記修正するステップを更に実行する
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記制御ノードの中に前記セットを維持管理して更新するステップ
を更に備えることを特徴とする請求項１に記載の方法。
【請求項７】
別のノードの中に前記セットを維持管理して更新するステップと、
前記セッション記述メッセージの中で規定されるオプションタグに応えて前記セットを前記制御ノードへ信号伝達するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項８】
通信ネットワークにおいてノード間のメディアセッションを管理する制御ノードにおける装置であって、
２つのノード間で交換される少なくとも１つのメディアセッション記述メッセージを管理する手段（１０）と、
前記少なくとも１つのメッセージが前記メディアセッションに関する潜在的設定をサポートする拡張を示す少なくとも１つのオプションタグを含むか否かを判定する手段（２０）と、
前記少なくとも１つのオプションタグを、前記ネットワークについてサポートされる拡張を示すネットワークサポーテッドオプションタグのセットと比較する手段（３０）と、
前記比較に基づいて前記メディアセッション記述メッセージを修正する手段（４０）と、
を備えることを特徴とする装置。
【請求項９】
ネットワークサポーテッドオプションタグの前記セットを格納する手段
を更に備えることを特徴とする請求項８に記載の装置。
【手続補正２】
【補正対象項目名】手続補正２
【補正方法】削除
【補正の内容】
【国際調査報告】
2012506664.tif 000007
2012506664.tif 000008
2012506664.tif 000009