JP5502860B2 - サポートされるｉｐバージョンを示し、ｓｉｐと互換性のあるｉｐバージョンをサポートするデバイスに到達するための方法 - Google Patents

Description

ＩＰ（インターネット）マルチメディアサブシステム（ＩＭＳ）は、携帯および固定デバイスの両方にマルチメディアサービスおよびボイスオーバーＩＰ呼出を提供するための標準アーキテクチャである。セッション初期化プロトコル（ＳＩＰ）が、ＩＭＳベースの呼出を設定および管理するためのプロトコルとして、主にＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）によって標準化され、統括されてきた。本明細書で使用されるように、「ユーザエージェント」および「ＵＡ」という用語は、携帯電話、携帯情報端末、手持ち式またはラップトップコンピュータ、ネットワークノード、および電気通信能力を有する同様のデバイス等の、携帯デバイスを指すことができるが、それらに限定されない。そのようなＵＡは、加入者識別モジュール（ＳＩＭ）アプリケーション、汎用加入者識別モジュール（ＵＳＩＭ）アプリケーション、可撤性ユーザ識別モジュール（Ｒ−ＵＩＭ）アプリケーションを含む、デバイスおよびその関連汎用集積回路カード（ＵＩＣＣ）から成る場合があり、またはそのようなカードを伴わないデバイス自体から成る場合がある。「ＵＡ」という用語はまた、固定回線電話、デスクトップコンピュータ、セットトップボックス、またはネットワークノード等の、同様の能力を有するが運搬可能ではないデバイスを指してもよい。ＵＡがネットワークノードである時、ネットワークノードは、無線デバイスまたは固定回線デバイス等の別の機能に代わって作用し、無線デバイスまたは固定回線デバイスをシミュレートまたはエミュレートすることができる。例えば、いくつかの無線デバイスについて、典型的にはデバイス上に存在するＩＭＳ ＳＩＰクライアントは、実際にネットワーク内に存在し、最適化されたプロトコルを使用して、デバイスにＳＩＰメッセージ情報を中継する。言い換えれば、伝統的に無線デバイスによって実行された、いくつかの機能は、遠隔ＵＡの形態で分布することができ、その場合、遠隔ＵＡは、ネットワーク内の無線デバイスを表す。「ＵＡ」という用語はまた、ＳＩＰセッションを終結させることができる、任意のハードウェアまたはソフトウェア構成要素も指すことができる。

最初に、本開示の１つ以上の実施形態の例証的実装を以下で提供するが、開示されたシステムおよび／または方法は、現在既知であるか、または既存であるかにかかわらず、任意の数の技法を使用して実装されてもよいことを理解されたい。本開示は、本明細書で例証および説明される例示的設計および実装を含む、以下で例証される例証的実装、図面、および技法に決して限定されるべきではないが、同等物の全範囲とともに、添付の請求項の範囲内で修正されてもよい。

実施形態では、移送アドレススキームに関連する情報を伝達する方法が提供される。方法は、セッション初期化プロトコル（ＳＩＰ）メッセージ内に、複数の移送アドレススキームの同時のサポートに関するインジケータに含むための方法を提供する。

代替実施形態では、移送アドレススキームに関する情報を伝達するように構成されたユーザエージェント（ＵＡ）が提供される。ＵＡは、セッション初期化プロトコル（ＳＩＰ）メッセージ内に、複数の移送アドレススキームの同時のサポートに関するインジケータに含むように構成されたプロセッサを含む。

Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）は、移動および地上回線ネットワーク用のマルチメディアサービスのための次世代ＳＩＰ／ＩＰベースのネットワークとして、ＩＰマルチメディアサブシステム（ＩＭＳ）を標準化している。ＳＩＰおよびＩＭＳは、メッセージが送信されるべきＵＡを指定するためにＩＰアドレスを使用する、インターネットプロトコル（ＩＰ）に基づく。他の移送アドレススキームが、他のプロトコルの下で存在し得るが、「ＩＰアドレス」、「ＩＰバージョン」、および同等物といった用語が、任意の移送アドレススキームを指すために本明細書で使用される。現在、ＩＰｖ４アドレスおよびＩＰｖ６アドレスといった、２種類のＩＰアドレスがある。いくつかのＵＡは、ＩＰｖ４のみをサポートし、他のＵＡは、ＩＰｖ６のみをサポートし、他のＵＡは、ＩＰｖ４およびＩＰｖ６の両方をサポートする（いわゆる（二重スタックＵＡ）。二重スタックＵＡのうちで、いくつかは、一度にＩＰｖ４のみ、またはＩＰｖ６のみを使用することができる。他の二重スタックＵＡは、同じＳＩＰセッション中等の同じ通信中に、ＩＰｖ４およびＩＰｖ６を同時に使用する能力をサポートする。例えば、ＩＰｖ６は、ＩＰｖ４がメディアトラフィックに使用されているのと同時にシグナリングに使用される場合があり、または逆も同様である。

２つのＩＰアドレスバージョンは直接互換性がないため、１つバージョンのみを使用するＵＡから他方のバージョンのみを使用するＵＡに、またはネットワーク内の他のシステムあるいは構成要素の間で、メッセージが送信される時に、典型的には、何らかの種類のアドレス変換が必要とされる。そのような変換は、ＩＰｖ４およびＩＰｖ６メッセージの両方が変換構成要素を通過するように、ネットワーク内に配置されるアドレス変換ゲートウェイまたは同様の構成要素によって、実行される場合がある。２つのＩＰｖ４専用ＵＡの間、２つのＩＰｖ６専用ＵＡの間、または２つの二重スタックＵＡの間のメッセージは、変換構成要素にルート指定されず、またはおそらく、変換なしで変換構成要素を通過することができる。変換構成要素は、ＩＰｖ４専用ＵＡとＩＰｖ６専用ＵＡとの間で、メッセージの適切な変換を行う。

メッセージの変換が必要とされるか否かにかかわらず、変換構成要素を通してメッセージをルート指定することにより、変換が必要とされないメッセージの伝送に不必要な遅延を引き起こし得る。これは、特に、ボイスオーバーＩＰ（ＶｏＩＰ）呼出等の遅延に敏感なＩＰトラフィックにとって重要となり得る。

これらの遅延のうちのいくつかは、ＵＡがＩＰｖ４またはＩＰｖ６アドレスをサポートするかどうかをＩＭＳ ＳＩＰプロキシ構成要素（サービス呼セッション制御機能（Ｓ−ＣＳＣＦ）等）が決定できることを要求することによって、回避することができる。ＵＡがそのような二重スタックＵＡである場合、プロキシ構成要素は、アドレス変換構成要素を介してＵＡのメッセージをルート指定することを回避することができる。これは、ＵＡのメッセージにとって最適なルートを推進することができ、アドレス変換構成要素を介したルーティングが課する追加遅延を回避することができる。

プロキシ構成要素は、ＳＩＰ Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダの中で示されるネットワークアクセス技術の種類に基づいて、ＵＡが二重スタックＵＡであるかどうかを決定する場合がある。つまり、いくつかのネットワークは、二重スタックＵＡのみがこれらのネットワークを使用できることを特定する場合があり、そのようなネットワークがＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダの中で示されると、そのネットワーク内のＵＡが二重スタックＵＡであると仮定することができる。プロキシ構成要素は、そのようなヘッダを読み取ると、ネットワーク内のＵＡがＩＰｖ４またはＩＰｖ６のいずれか一方を使用することができ、ネットワーク内で伝送されるメッセージが変換構成要素を通してルート指定される必要がないことを知る。

そのような提案に従うことにより、二重スタックＵＡを必要とするネットワーク内の変換構成要素を通したメッセージのルーティングを排除する場合がある一方で、全てのデバイスが二重スタックデバイスであることをサポートするが、必ずしも要求しない、他のネットワークがあってもよい。さらに、そのようなネットワークは、所与のデバイスがＩＰｖ４およびＩＰｖ６アドレスの同時使用をサポートする二重スタックＵＡであることを仮定できない。したがって、プロキシ構成要素は、二重スタックＵＡがそのようなネットワーク内でサポートされていることに気付いていない場合があり、変換が必要ではなく、変換構成要素を通したメッセージのルーティングを排除することができる時でさえも、念のために変換構成要素を通してメッセージをルート指定する場合がある。

例えば、ＩＭＳネットワークは、ネットワーク内のＵＡがシグナリングにＩＰｖ６を使用することを要求する場合がある。そのようなＩＰｖ６ベースのＵＡがＩＰｖ４ベースのＵＡと通信している場合、ＩＰｖ４ベースのＵＡがメディア部分を適正に受信し、理解することができるように、ＩＰｖ６ベースのＵＡからの通信のメディア部分は、変換ゲートウェイを通過しなければならない場合がある。

また、複数のアクセスネットワークサポートし、異なる種類のアクセスネットワーク間で移動してもよい、いわゆるデュアルモードＵＡがある。例えば、ＵＡは、符号分割多重アクセス（ＣＤＭＡ）ＩＳ−２０００（一般的にＣＤＭＡ １ｘと呼ばれる）アクセスネットワークおよびグローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）／汎用パケット無線サービス（ＧＰＲＳ）アクセスネットワークの両方をサポートする場合がある。デュアルモードＵＡの存在により、ネットワークは、ＵＡの移送アドレススキーム能力がどのようなものであるか確実に仮定できない場合がある。そのようなＵＡが、二重スタックＵＡを必要とするネットワークから、二重スタックＵＡをサポートするが必要とはしないネットワークへと移動した場合、プロキシ構成要素は、たとえ変換構成要素を通したルーティングが必要ではなくても、変換構成要素を通してメッセージをルート指定する場合がある。したがって、ネットワークアクセス技術の種類と移送アドレススキームのサポートの種類との間の関連は、メッセージがアドレス変換構成要素を通してルート指定される必要があるかどうかを決定するための、決して望ましいとはいえない技法である。

種々の実施形態では、ＳＩＰ ＵＡが、ネットワークおよび他のＵＡに、ＳＩＰ ＵＡがサポートするＩＰバージョンおよび／またはＩＰバージョンの組み合わせを示すことを可能にし、どのＩＰバージョンおよび／またはＩＰバージョンの組み合わせを別のＳＩＰ
ＵＡが使用するかをＳＩＰ ＵＡが発見することを可能にし、別のＳＩＰ ＵＡがサポートするべきＩＰバージョンまたはＩＰバージョンの組み合わせの選好または要件をＳＩＰ ＵＡが示すことを可能にする、機構が提供される。

Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ （ＩＥＴＦ） Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ （ＲＦＣ） ３８４０は、ＵＡがその能力をネットワークおよび他のＵＡに示すためのＳＩＰにおける機構を定義している。一実施形態では、ＲＦＣ ３８４０による、新規メディア機能タグが定義される。メディア機能タグ名の一例は、「ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ」となり得るが、他の構文および符号化が可能である。ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓメディア機能タグは、通信デバイスが、シグナリングおよびメディアの両方のためのＩＰｖ４、シグナリングおよびメディアの両方のためのＩＰｖ６、同時にシグナリングのためのＩＰｖ６およびメディアのためのＩＰｖ４、または同時にシグナリングのためのＩＰｖ４およびメディアのためのＩＰｖ６をサポートするかどうかを示すことができる。いくつかの実施形態では、機能タグまたは他の指標は、シグナリングおよびメディアの両方のための単一のＩＰバージョンを示すよりもむしろ、または、シグナリングに１つ、メディアに１つといった、異なるＩＰバージョンの同時使用を示すよりもむしろ、単一の移送アドレススキームのみを示す場合がある。

複数のトークン／タグ／識別子／指標を定義することができ、それぞれＩＰバージョンを示し、おそらく、ＩＰバージョンがシグナリングのみまたはメディアのみに該当するかどうかも示す。トークン／タグ／識別子／指標のうちの１つ以上がｓｉｐ．ｉｐ−ｖｅｓｉｏｎｓメディア機能タグと関連する時に、ＵＡ用のサポートされたＩＰバージョンおよび／またはバージョンの組み合わせを特定することができる。トークン／タグ／識別子／指標の典型的な値は、ＵＡがシグナリングおよびメディアの両方のためにＩＰｖ４アドレスをサポートできることを示す「ｉｐｖ４」、ＵＡがシグナリングおよびメディアの両方のためにＩＰｖ６アドレスをサポートできることを示す「ｉｐｖ６」、ＵＡがＩＰｖ４およびＩＰｖ６アドレスの両方をサポートできるが、シグナリングのためのＩＰｖ４アドレスおよびメディアのためのＩＰｖ６アドレスしか使用できないことを示す「ｉｐｖ４ｓ−ｉｐｖ６ｍ」、ならびに、ＵＡがＩＰｖ４およびＩＰｖ６アドレスの両方をサポートできるが、シグナリングのためのＩＰｖ６アドレスおよびメディアのためのＩＰｖ４アドレスしか使用できないことを示す「ｉｐｖ６ｓ−ｉｐｖ４ｍ」を含む場合がある。

この機能タグとともに使用するために適切な値は、平等関係を伴うトークン／タグ／識別子／指標を含む場合がある。例えば、ＩＰｖ４しかサポートしないＵＡは、以下によって指定される場合がある。
＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ４”
ＩＰｖ４およびＩＰｖ６をサポートするが、シグナリングおよびメディアが同じバージョンを使用するＳＩＰセッションしかサポートできないＵＡは、以下によって指定される場合がある。
＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ４， ｉｐｖ６”
ＩＰｖ４およびＩＰｖ６をサポートし、ならびに、シグナリングおよびメディアが同じバージョンを使用するＳＩＰセッションをサポートし、また、シグナリングのためのＩＰｖ６およびメディアのためのＩＰｖ４を同時にサポートすることもできるが、シグナリングのためのＩＰｖ４およびメディアのためのＩＰｖ６を同時にサポートすることができないＵＡは、以下によって指定される場合がある。
＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ４， ｉｐｖ６， ｉｐｖ６ｓ−ｉｐｖ４ｍ”
ＩＰｖ４およびＩＰｖ６をサポートし、ならびに、シグナリングおよびメディアが同じバージョンを使用するＳＩＰセッションをサポートし、また、シグナリングのためのＩＰｖ６およびメディアのためのＩＰｖ４を同時にサポートし、かつシグナリングのためのＩＰｖ４およびメディアのためのＩＰｖ６を同時にサポートすることもできるＵＡは、以下の表で示されるようなトークン／タグ／識別子／指標によって指定される場合がある。

トークン／タグ／識別子／指標は、ＤＳＬ（デジタル加入者回線）、ＷｉＦｉ（ワイヤレスフィデリティ）、ＧＥＲＡＮ（グローバルシステムフォーモバイルコミュニケーションＥＤＧＥ無線アクセスネットワーク）、ＵＴＲＡＮ（汎用移動電気通信システム地上波無線アクセスネットワーク）、ＬＴＥ（ロングタームエボリューション）、ＣＤＭＡ２０００（符号分割多重アクセス）、ＷｉＭａｘ（マイクロ波アクセス用の世界的相互運用性）、またはその他等の、特定のアクセスネットワーク上でＩＰバージョンを識別するように、さらに拡張させることができる。これは、可能なタグ値の数を増加させる。例えば、ＧＥＲＡＮおよびＤＳＬの両方をサポートするＵＡは、以下の表で示されるようなタグによって指定される場合がある。

ＵＡは、ＲＦＣ ３８４０で特定されるように、ＳＩＰ ＲＥＧＩＳＴＥＲ要求およびＳＩＰ ＩＮＶＩＴＥ等の他の初期ＳＩＰ要求のＣｏｎｔａｃｔヘッダに、ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓメディア機能タグを含むことができる。例えば、ＵＡは、複数のＩＰバージョンをサポートできることを、ＳＩＰ Ｃｏｎｔａｃｔヘッダの中で通告することができる。

ＳＩＰ要求におけるＣｏｎｔａｃｔヘッダを調べることによって、プロキシ構成要素（Ｓ−ＣＳＣＦ等）は、どのＩＰバージョンの能力および組み合わせをＵＡがサポートするか決定することができる。ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓメディア機能タグに記載された能力および組み合わせに基づいて、Ｓ−ＣＳＣＦは、別のドメインと相互運用する時に、セッションのシグナリング部分および／またはメディア部分が、変換ゲートウェイを通してルート指定されるかどうかを決定する等の、措置を講じることができる。ＵＡが１つの形態の移送アドレス指定を使用することが許可されたアクセスネットワークから、ＵＡが新規移送アドレス指定または新規および古い移送アドレス指定の組み合わせを使用することができるアクセスネットワークへの移動等であるが、それに限定されない、ＵＡの能力が変化する場合、ＵＡは、上記の機構を介して、そのアドレス指定能力をシグナリングすることができる。

ＵＡは、ＲＦＣ ３２６１で特定されるように、ＳＩＰ ＯＰＴＩＯＮＳ要求を送信することによって、別のＵＡによってサポートされるＩＰバージョンを発見することができる。ＳＩＰ ＯＰＴＩＯＮＳ要求に応答する時、ＵＡは、ＵＡによってサポートされるＩＰバージョンの能力および組み合わせを示す＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓメディア機能タグを含有する、Ｃｏｎｔａｃｔヘッダを含むことができる。

ＩＥＴＦ ＲＦＣ ３８４１は、ある能力をサポートするＵＡに連絡する選好および要件をＵＡが示すことを可能にする、機構を定義する。Ａｃｃｅｐｔ−ＣｏｎｔａｃｔヘッダおよびＲｅｊｅｃｔ−Ｃｏｎｔａｃｔヘッダと、ＲＦＣ ３８４１で定義される機構とを使用して、ＵＡは、特定のＩＰバージョンの能力および組み合わせをサポートする別のＵＡにルート指定する選好を表現してもよい。

例えば、ＩＰｖ４のみをサポートするＵＡは、変換機能の必要性を回避するために、シグナリングおよびメディアの両方のためのＩＰｖ４をサポートする別のユーザのＵＡに連絡することを好んでもよい。こうするために、ＵＡは、＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ４”という機能タグを含有するＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダを、ＳＩＰ
ＩＮＶＩＴＥに含むことができる。例えば、以下である。
Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔ： ^＊；＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ４” ＳＩＰおよびＩＭＳは、同じＳＩＰ ＵＲＩまたは公衆ユーザアイデンティティを使用してアドレス可能である、複数のＵＡを登録する能力をサポートする。同じＳＩＰ ＵＲＩまたは公衆ユーザアイデンティティを共有するＵＡは、異なるＩＰアドレスバージョンと、異なるＩＰアドレスバージョンの異なる組み合わせをサポートする能力とを含む、異なる能力を有してもよい。＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ４”という機能タグを含有するＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダを含有する、ＳＩＰ ＩＮＶＩＴＥ要求によって標的化されるユーザのために機能するＳ−ＣＳＣＦは、複数のＵＡがユーザに登録される場合、ＳＩＰ ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダの中の＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ４”に登録したＵＡに、ＳＩＰ ＩＮＶＩＴＥ要求を優先的にルート指定する。

同様に、＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎ ＝ ”ｉｐｖ６”という機能タグを含有するＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダを含有する、ＳＩＰ ＩＮＶＩＴＥ要求によって標的化されるユーザのために機能するＳ−ＣＳＣＦは、複数のＵＡがユーザに登録される場合、ＳＩＰ ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダの中の＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ６”に登録したＵＡに、ＳＩＰ ＩＮＶＩＴＥ要求を優先的にルート指定する。Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダは、ＲＦＣ ３８４１の仕様に従うことができる。

同様に、＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎ ＝ ”ｉｐｖ４ｓ− ｉｐｖ６ｍ”という機能タグを含有するＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダを含有する、ＳＩＰ ＩＮＶＩＴＥ要求によって標的化されるユーザのために機能するＳ−ＣＳＣＦは、複数のＵＡがユーザに登録される場合、ＳＩＰ ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダの中の＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ４ｓ−ｉｐｖ６ｍ”に登録したＵＡに、ＳＩＰ ＩＮＶＩＴＥ要求を優先的にルート指定する。Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダは、ＲＦＣ ３８４１の仕様に従うことができる。

同様に、＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎ ＝ ”ｉｐｖ６ｓ−ｉｐｖ４ｍ”という機能タグを含有するＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダを含有する、ＳＩＰ ＩＮＶＩＴＥ要求によって標的化されるユーザのために機能するＳ−ＣＳＣＦは、複数のＵＡがユーザに登録される場合、ＳＩＰ ＲＥＧＩＳＴＥＲ要求のＣｏｎｔａｃｔヘッダの中の＋ｓｉｐ．ｉｐ−ｖｅｒｓｉｏｎｓ ＝ ”ｉｐｖ６ｓ−ｉｐｖ４ｍ”に登録したＵＡに、ＳＩＰ ＩＮＶＩＴＥ要求を優先的にルート指定する。Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダは、ＲＦＣ ３８４１の仕様に従うことができる。

代替実施形態では、ＳＩＰメッセージは、デバイスによってサポートされた、また最初に使用されたＩＰバージョンを識別する、ＳＩＰヘッダフィールド（ＲＦＣ ３４２７で定義される過程に従って定義される、Ｐ−Ｈｅａｄｅｒ値等であるが、それに限定されない）を含有することができる。ヘッダは、いくつかの異なる方法で構築することができる。例えば、単一のＳＩＰヘッダフィールドは、上記で説明されるような１つ以上のタグを含有することができ、アクセス型につき単一のＳＩＰヘッダフィールドがあり得る、または、メディアのための１つのＳＩＰヘッダフィールド、および制御シグナリングのための別のＳＩＰヘッダフィールドがあり得る。ＳＩＰヘッダフィールドは、ＳＩＰ ＵＡによって含むことができ、または、プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）等であるがそれに限定されない、プロキシによって追加することができる。

代替実施形態では、ＳＩＰメッセージは、デバイスのＩＰ能力を表すＸＭＬ本文を含有することができる。ＸＭＬ本文は、ＩＰｖ４のみ、ＩＰｖ４メディアのみ、ＩＰｖ４制御のみ、ＩＰＶ６のみ、ＩＰｖ６メディアのみ、および／またはＩＰｖ６制御のみを表すタグを含有することができる。

場合によっては、ＸＭＬ本体は、既存のメディア型である「ａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ−ｉｍｓ＋ｘｍｌ」となり得る（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ （３ＧＰＰ） Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ （ＴＳ） ２４．２２９を参照）。代替として、新規メディア型および対応するＸＭＬスキーマを割り当てることができる。ｃｏｎｔｅｎｔ−ｄｉｓｐｏｓｉｔｉｏｎヘッダ値は、３ｇｐｐ−ａｌｔｅｒｎａｔｉｖｅ−ｓｅｒｖｉｃｅまたは３ｇｐｐ−ｓｅｒｖｉｃｅ−ｉｎｆｏ、あるいは新規の値となり得る。新規メディア型のデフォルトのｃｏｎｔｅｎｔ−ｄｉｓｐｏｓｉｔｉｏｎヘッダ値が、割り当てられなければならない場合がある。

以下の実施例では、ｔＳｕｐｐｏｒｔｅｄＩＰ、ｅＳｕｐｐｏｒｔｅｄＩＰ、およびｌＳｕｐｐｏｒｔｅｄＩＰといった、３つの異なるＸＭＬ構造が提示される。３つのうちの１つは、新規ＸＭＬスキーマまたは「ａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ−ｉｍｓ＋ｘｍｌ」として知られているＸＭＬスキーマのいずれか一方から参照することができる。当然ながら、ＤＴＤまたはＲｅｌａｘ ＮＧ等の他のＸＭＬスキーマ表現も、実質的に同じ情報で作成することができる。加えて、可能な将来の拡張のためのフック（すなわち、＜ｘｓ：ａｎｙＡｔｔｒｉｂｕｔｅ／＞または＜ｘｓ：ａｎｙ ｎａｍｅｓｐａｃｅ＝”＃＃ａｎｙ” ｐｒｏｃｅｓｓＣｏｎｔｅｎｔｓ＝”ｌａｘ” ｍｉｎＯｃｃｕｒｓ＝”０”
ｍａｘＯｃｃｕｒｓ＝”ｕｎｂｏｕｎｄｅｄ”／＞等のステートメントによって可能となる）も、含むことができる。ＸＭＬ構造（ｔＳｕｐｐｏｒｔｅｄＩＰ、ｅＳｕｐｐｏｒｔｅｄＩＰ、およびｌＳｕｐｐｏｒｔｅｄＩＰ等）は、新規ＸＭＬスキーマまたは「ａｐｐｌｉｃａｔｉｏｎ／３ｇｐｐ−ｉｍｓ＋ｘｍｌ」として知られているＸＭＬスキーマにおける要素、要素コンテンツ、または属性のいずれかになることができる。加えて、ｌＳｕｐｐｏｒｔｅｄＩＰを使用して、相対的順序または選好を示す、ゼロ以上の選好を記載することが可能となる。例えば、最初の入力が、いずれの追加入力よりも好まれ、例えば、＜ｓｕｐｐｏｒｔｅｄＩＰ＞ＩＰＶ６−ｏｎｌｙ ＩＰｖ４−ｏｎｌｙ＜／ｓｕｐｐｏｒｔｅｄＩＰ＞において、「ＩＰＶ６−ｏｎｌｙ」が好まれ、「ＩＰｖ４−ｏｎｌｙ」は代替物である。デバイスのＩＰ能力を符号化するＸＭＬスキーマは、さらに制約し、最小限で１つのＩＰ能力が記載されることを要求することができる。別の制約は、いずれのＩＰ能力も１度以上記述されないこととなり得る。いくつかの能力が相互と併せて発生しないことを制約することさえ可能となり得る。

３ＧＰＰ ＴＳ ２４．２２９の拡張例を以下に挙げる。

＜仕様拡張開始＞
７．６．２ 文書型定義
ＸＭＬ構文の定義によるＸＭＬスキーマを、表７．７Ａで定義する。

７．６．３ ＸＭＬスキーマ記述
この従属節は、表７．７Ａで定義されるようなＩＭ文書型定義の要素を説明する。
＜ｉｍｓ−３ｇｐｐ＞：これは、ＩＭＳ ＸＭＬ本体のルート要素である。それは常に存在するものとする。表７．７ＡのＸＭＬスキーマの将来版のＸＭＬインスタンス文書は、本書の表７．７ＡのＸＭＬスキーマに対して有効であるものとする。本書の表７．７ＡのＸＭＬスキーマのＸＭＬインスタンス文書は、本書で説明されるＸＭＬスキーマバージョンの値に等しい、ｉｍｓ−３ｇｐｐ要素の一部であるバージョン属性値を有するものとする。
＜ｓｅｒｖｉｃｅ−ｉｎｆｏ＞：特定のトリガ点のためにＨＳＳから受信される透過的要素は、この随意的な要素内に配置される。
＜ａｌｔｅｒｎａｔｉｖｅ−ｓｅｒｖｉｃｅ＞：本書では、ＩＭ ＣＮサブシステム内に緊急セッションを確立する試行のための応答として、代替サービスが使用される。要素は、呼出が成功するべき代替サービスを表す。代替サービスは、サービス情報の種類によって表される。なぜ代替サービスが提案されるかという考えられる理由が含まれてもよい。＜ａｌｔｅｍａｔｉｖｅ−ｓｅｒｖｉｃｅ＞要素は、代替サービスの種類を示す＜ｔｙｐｅ＞要素と、随意的な要素である＜ａｃｔｉｏｎ＞要素とを含有する。
＜ｔｙρｅ＞要素は、本書では「ｅｍｅｒｇｅｎｃｙ」という値のみを含有する。
＜ａｃｔｉｏｎ＞要素は、本書では「ｅｍｅｒｇｅｎｃｙ−ｒｅｇｉｓｔｒａｔｉｏｎ」という値のみを含有する。
＜ｒｅａｓｏｎ＞要素は、なぜセッション設定がリダイレクトされたかという理由を伴う説明文を含有する。ＵＥは、ユーザに指示を与えるために、この情報を使用してもよい。ＩＰ−ｃａｐａｂｉｌｉｔｉｅｓ属性は、ＩＰ能力および選好を記載する。１つより多くの値が存在する場合、順序付けが重要であり、相対的かつ減少する選好を示す。空のリストは、列挙されたＩＰ能力のうちのいずれかに対する選好がないものとして解釈される。

上記の実施例では、ＩＰ−ｃａｐａｂｉｌｉｔｉｅｓは、ａｌｔｅｒｎａｔｉｖｅ−ｓｅｒｖｉｃｅ要素の属性として記載される。同じフィールドは、ｓｅｒｖｉｃｅ−ｉｎｆｏ要素、任意の他の要素、または新規要素の属性にもなり得る。代替として、ＩＰ−ｃａｐａｂｉｌｉｔｉｅｓをＸＭＬ要素自体として実装することができる。例えば、上記の実施例のｔＳｕｐｐｏｒｔｅｄＩＰを参照されたい。

これらの実施形態のうちのいずれかでは、レジストラ、ＳＩＰプロキシノード、またはＳ−ＣＳＣＦ等であるがそれらに限定されない、ネットワークノードが、ＳＩＰメッセージに関するセッションで２つの異なる移送アドレススキームを同時に使用できることを示す、タグまたは他の指標を含有するＳＩＰメッセージを受信すると、ネットワークノードは、セッションのシグナリング部分および／またはメディア部分が変換ゲートウェイを通してルート指定されるか否かを決定することができる。例えば、第１のＵＡがメディアのためのＩＰｖ４およびシグナリングのためのＩＰｖ６をサポートすることを示すＳＩＰメッセージをネットワークノードが受信し、第１のＵＡが、メディアおよびシグナリングの両方にＩＰｖ４を使用する第２のＵＡに連絡しようとしている場合、ネットワークノードは、変換ゲートウェイを通してセッションのシグナリング部分をルート指定する場合がある。代替として、第１のＵＡがメディアのためのＩＰｖ６およびシグナリングのためのＩＰｖ４をサポートすることを示すＳＩＰメッセージをネットワークノードが受信し、第１のＵＡが、メディアおよびシグナリングの両方にＩＰｖ４を使用する第２のＵＡに連絡しようとしている場合、ネットワークノードは、変換ゲートウェイを通してセッションのメディア部分をルート指定する場合がある。
例えば、本発明は以下の項目を提供する。
（項目１）
移送アドレススキームに関係する情報を伝える方法であって、
セッション初期化プロトコル（ＳＩＰ）メッセージに複数の移送アドレススキームの同時のサポートに関係するインジケータを含むことを包含する、方法。
（項目２）
上記インジケータは、
第２のユーザエージェント（ＵＡ）とのコンタクトを確立することを試みる第１のＵＡによって用いられる少なくとも１つの移送アドレススキームと、
該第２のＵＡによってサポートされる少なくとも１つの移送アドレススキームを該第１のＵＡに知らせる、該第１のＵＡから該第２のＵＡに対する要求と、
該第２のＵＡが用い、該第１のＵＡが選ぶ少なくとも１つの移送アドレススキームの仕様と
のうちの少なくとも１つを伝える、項目１に記載の方法。
（項目３）
上記インジケータは、
メディア機能タグと、
ＳＩＰヘッダフィールドと、
拡張可能マークアップ言語（ＸＭＬ）本文と
のうちの１つである、項目２に記載の方法。
（項目４）
上記第１のＵＡが上記第２のＵＡとのコンタクトを確立することを試み、上記インジケータが上記メディア機能タグである場合、少なくとも１つのトークンが該メディア機能タグに関連付けられ、該少なくとも１つのトークンは、
シグナリングのための移送アドレススキームと、
メディアのための移送アドレススキームと、
シグナリングおよびメディアの両方のための移送アドレススキームと
のうちの少なくとも１つを指定する、項目３に記載の方法。
（項目５）
上記移送アドレススキームは、
ＩＰｖ４と、
ＩＰｖ６と
のうちの少なくとも１つである、項目４に記載の方法。
（項目６）
上記メディア特徴タグの使用法は、
Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）３８４０と、
ＩＥＴＦ ＲＦＣ３８４１と
のうちの１つの仕様に従う、項目４に記載の方法。
（項目７）
上記メディア機能タグは、初期ＳＩＰ要求のＣｏｎｔａｃｔヘッダに含まれる、項目４に記載の方法。
（項目８）
第１の組のトークンは第１のネットワークアクセス技術に適用し、第２の組のトークンは第２のネットワークアクセス技術に適用する、項目４に記載の方法。
（項目９）
上記第１のＵＡが上記第２のＵＡによって用いられる少なくとも１つのアドレススキームを該第１のＵＡに知らせるように該第２のＵＡに要求した場合、該第２のＵＡは該第１のＵＡにメディア機能タグを送り、該メディア機能タグは、
シグナリングと、
メディアと、
シグナリングおよびメディアの両方と
のうちの少なくとも１つに対する該第２のＵＡによって用いられる少なくとも１つのアドレススキームを指定する少なくとも１つのトークンを含む、項目３に記載の方法。
（項目１０）
上記移送アドレススキームは、
ＩＰｖ４と、
ＩＰｖ６と
のうちの少なくとも１つである、項目９に記載の方法。
（項目１１）
上記第１のＵＡは、ＩＥＴＦ ＲＦＣ３２６１の仕様に従うＳＩＰ ＯＰＴＩＯＮＳ要求を送ることによって、上記第２のＵＡによって用いられる少なくとも１つのアドレススキームを該第１のＵＡに知らせるように該第２のＵＡに要求する、項目９に記載の方法。
（項目１２）
上記第２のＵＡは、上記ＳＩＰ ＯＰＴＩＯＮＳ要求に応答して上記第１のＵＡに送られるメッセージのＣｏｎｔａｃｔヘッダに上記メディア機能タグを含む、項目１１に記載の方法。
（項目１３）
上記第１のＵＡが、該第１のＵＡが選び、上記第２のＵＡが用いる上記少なくとも１つの移送アドレススキームを指定する場合、該第１のＵＡは、
シグナリングのための好ましい移送アドレススキームと、
メディアのための好ましい移送アドレススキームと、
シグナリングおよびメディアの両方のための好ましい移送アドレススキームと
のうちの少なくとも１つを指定する少なくとも１つのトークンを含むメディア機能タグを該第２のＵＡに送ることによって、優先度を指定する、項目３に記載の方法。
（項目１４）
上記好ましい移送アドレススキームは、
ＩＰｖ４と、
ＩＰｖ６と
のうちの少なくとも１つである、項目１３に記載の方法。
（項目１５）
上記第１のＵＡは、ＩＥＴＦ ＲＦＣ ３８４１の仕様に従うＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに優先度を含むことによって、該第１のＵＡが選び、上記第２のＵＡが用いる上記少なくとも１つの移送アドレススキームを指定する、項目１３に記載の方法。
（項目１６）
移送アドレススキームに関係する情報を伝えるように構成されるユーザエージェント（ＵＡ）であって、
セッション初期化プロトコル（ＳＩＰ）メッセージに複数の移送アドレススキームの同時サポートに関係するインジケータを含むように構成されるプロセッサを備えている、ＵＡ。
（項目１７）
上記インジケータは、
上記ＵＡによって用いられる少なくとも１つの移送アドレススキームと、
第２のＵＡのための該ＵＡからの要求であって、該第２のＵＡによってサポートされる少なくとも１つの移送アドレススキームを該ＵＡに知らせる、要求と、
該ＵＡが選び、該第２のＵＡが用いる少なくとも１つの移送アドレススキームの仕様と
のうちの１つを伝える、項目１６に記載のＵＡ。
（項目１８）
上記インジケータは、
メディア機能タグと、
ＳＩＰヘッダフィールドと、
拡張可能なマークアップ言語（ＸＭＬ）本文と
のうちの１つである、項目１７に記載のＵＡ。
（項目１９）
上記ＵＡが上記第２のＵＡとのコンタクトを確立することを試み、上記インジケータが上記メディア機能タグである場合、少なくとも１つのトークンが該メディア機能タグに関連付けられ、該少なくとも１つのトークンは、
シグナリングのため該ＵＡが用いている移送アドレススキームと、
メディアのため該ＵＡが用いている移送アドレススキームと、
シグナリングおよびメディアの両方のため該ＵＡが用いている移送アドレススキームと
のうちの少なくとも１つを指定する、項目１８に記載のＵＡ。
（項目２０）
上記移送アドレススキームは、
ＩＰｖ４と、
ＩＰｖ６と
のうちの少なくとも１つである、項目１９に記載のＵＡ。
（項目２１）
上記メディア特徴タグの使用法は、
インターネット技術標準化委員会（ＩＥＴＦ）Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）３８４０と、
ＩＥＴＦ ＲＦＣ３８４１と
のうちの１つの仕様に従う、項目１９に記載のＵＡ。
（項目２２）
上記メディア機能タグは、初期ＳＩＰ要求のＣｏｎｔａｃｔヘッダに含まれる、項目１９に記載のＵＡ。
（項目２３）
第１の組のトークンは第１のネットワークアクセス技術に適用し、第２の組のトークンは第２のネットワークアクセス技術に適用する、項目１９に記載のＵＡ。
（項目２４）
上記ＵＡが上記第２のＵＡによって用いられる少なくとも１つのアドレススキームを該ＵＡに知らせるように該第２のＵＡに要求した場合、該第２のＵＡは該ＵＡにメディア機能タグを送り、該メディア機能タグは、
シグナリングと、
メディアと、
シグナリングおよびメディアの両方と
のうちの少なくとも１つに対する該第２のＵＡによって用いられる少なくとも１つのアドレススキームを指定する少なくとも１つのトークンを含む、項目１８に記載のＵＡ。
（項目２５）
上記移送アドレススキームは、
ＩＰｖ４と、
ＩＰｖ６と
のうちの少なくとも１つである、項目２４に記載のＵＡ。
（項目２６）
上記ＵＡは、ＩＥＴＦ ＲＦＣ ３２６１の仕様に従うＳＩＰ ＯＰＴＩＯＮＳ要求を送ることによって、上記第２のＵＡによって用いられる少なくとも１つのアドレススキームを該ＵＡに知らせるように該第２のＵＡに要求する、項目２４に記載のＵＡ。
（項目２７）
上記第２のＵＡは、上記ＳＩＰ ＯＰＴＩＯＮＳ要求に応答して上記ＵＡに送られるメッセージのＣｏｎｔａｃｔヘッダに上記メディア機能タグを含む、項目２６に記載のＵＡ。
（項目２８）
上記ＵＡが、該ＵＡが好み、上記第２のＵＡが用いる上記少なくとも１つの移送アドレススキームを指定する場合、該ＵＡは、
シグナリングのための好ましい移送アドレススキームと、
メディアのための好ましい移送アドレススキームと、
シグナリングおよびメディアの両方のための好ましい移送アドレススキームと
のうちの少なくとも１つを指定する少なくとも１つのトークンを含むメディア機能タグを該第２のＵＡに送ることによって、優先度を指定する、項目１８に記載のＵＡ。
（項目２９）
上記好ましい移送アドレススキームは、
ＩＰｖ４と、
ＩＰｖ６と
のうちの少なくとも１つである、項目２８に記載のＵＡ。
（項目３０）
上記ＵＡは、ＩＥＴＦ ＲＦＣ３８４１の仕様に従うＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダに優先度を含むことによって、該ＵＡが好み、上記第２のＵＡが用いる上記少なくとも１つの移送アドレススキームを指定する、項目２８に記載のＵＡ。

ここで、本開示のより完全な理解のために、添付の図面および発明を実施するための形態と関連して、以下の簡単な説明を参照し、類似参照数字は、類似部品を表す。
図１は、本開示の実施形態による、ＩＭＳアーキテクチャの一部分の略図である。 図２は、本開示の実施形態による、移送アドレススキームに関連する情報を伝達する方法の図である。 図３は、本開示の種々の実施形態のうちのいくつかのために構成されたＵＡを含む、無線通信システムの略図である。 図４は、本開示の種々の実施形態のうちのいくつかのために構成されたＵＡのブロック図である。 図５は、本開示の種々の実施形態のうちのいくつかのために構成されたＵＡ上に実装されてもよい、ソフトウェア環境の略図である。 図６は、本開示のいくつかの実施形態を実装するために好適なプロセッサおよび関連構成要素を図示する。

図１は、ＩＭＳアーキテクチャに存在してもよい、構成要素の一部分を図示する。ＩＭＳ能力を伴う第１のＵＡ１１０は、ＳＩＰベースのメッセージを送受信することができる。以前の論議は、２つのＵＡ間のＳＩＰセッションに焦点を当てているが、単一のＵＡが、複数の他のＵＡにメッセージを同時に送信するか、または複数の他のＵＡからメッセージを同時に受信する場合があることを理解されたい。図１の実施形態では、他のＵＡは、第２のＵＡ１２０および第３のＵＡ１３０によって表されているが、他の実施形態では、異なる数の他のＵＡが存在し得る。

実施形態では、第１のＵＡ１１０が、第２のＵＡ１２０および第３のＵＡ１３０に、第１のＵＡ１１０がサポートする移送アドレススキームまたはスキームの組み合わせを通知することを希望する場合がある。そうするために、第１のＵＡ１１０は、ＳＩＰメッセージ１４０を第２のＵＡ１２０および第３のＵＡ１３０に送信する。ＳＩＰメッセージ１４０は、ＳＩＰ ＩＮＶＩＴＥまたは何らかの他のＳＩＰメッセージである場合がある。ＳＩＰメッセージ１４０は、移送アドレススキームに関するＣｏｎｔａｃｔヘッダに、指標１５０を含むことができる。この場合、指標は、第１のＵＡ１１０がサポートする少なくとも１つの移送アドレススキームを特定する。

代替として、Ｃｏｎｔａｃｔヘッダの中の指標１５０は、第１のＵＡ１１０が、レジストラ、ＳＩＰプロキシノード、またはＳ−ＣＳＣＦであるがそれらに限定されない、ネットワークノード１６０に送信する、ＳＩＰ ＲＥＧＩＳＴＥＲ要求に含まれる場合がある。次いで、第１のＵＡ１１０が後続メッセージを第２のＵＡ１２０および／または第３のＵＡ１３０に送信すると、第１のＵＡ１１０がサポートする移送アドレススキームに関する情報が、ネットワークノード１６０において入手可能となる。

別の実施形態では、第２のＵＡ１２０および第３のＵＡ１３０が使用している移送アドレススキームまたはスキームの組み合わせを発見することを、第１のＵＡ１１０が希望する場合がある。この場合、ＳＩＰメッセージ１４０は、ＲＦＣ ３２６１に従うＳＩＰ ＯＰＴＩＯＮＳ要求となる場合があり、指標１５０は、第２のＵＡ１２０および第３のＵＡ１３０が、第１のＵＡ１１０に、それらが使用している１つまたは複数の移送アドレススキームを通知することを要求する、ＳＩＰ ＯＰＴＩＯＮＳ要求の一部分となる場合がある。ＳＩＰ ＯＰＴＩＯＮＳ要求を受信すると、第２のＵＡ１２０および／または第３のＵＡ１３０は、第２のＵＡ１２０および／または第３のＵＡ１３０が使用している１つまたは複数の移送アドレススキームを示すメディア機能タグを含むＣｏｎｔａｃｔヘッダを含有する、ＳＩＰメッセージを、第１のＵＡ１１０に返送することができる。

別の実施形態では、第２のＵＡ１２０および第３のＵＡ１３０に、第２のＵＡ１２０および第３のＵＡ１３０が使用することを第１のＵＡ１１０が好む移送アドレススキームまたはスキームの組み合わせを通知することを、第１のＵＡ１１０が希望する場合がある。この場合、ＳＩＰメッセージ１４０は、ＲＦＣ ３８４１で定義されるようなＡｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダを含むことができる。指標１５０は、好ましい移送アドレススキームまたはスキームの組み合わせを特定する、Ａｃｃｅｐｔ−Ｃｏｎｔａｃｔヘッダの一部分となる場合がある。いくつかの実施形態では、指標１５０は、第２のＵＡ１２０および第３のＵＡ１３０の両方に対する同じ選好を示す。他の実施形態では、第１のＳＩＰメッセージ１４０ａの中の第１の指標１５０ａは、第２のＵＡ１２０に対する第１の選好を示すことができ、第２のＳＩＰメッセージ１４０ｂの中の第２の指標１５０ｂは、第３のＵＡ１２０に対する第２の選好を示すことができる。

ネットワークノード１６０がＳＩＰメッセージ１４０を受信すると、ネットワークノード１６０は、指標１５０を調べて、指標１５０によって特定されるメディアおよびシグナリングのための移送アドレススキームを決定することができる。次いで、ネットワークノード１６０は、ＳＩＰメッセージに関するセッションのシグナリング部分および／またはメディア部分が変換ゲートウェイまたは他の変換構成要素を通してルート指定されるか否かを決定することができる。

図２は、移送アドレススキームに関する情報を伝達する方法２００の実施形態を示す。ブロック２１０では、複数の移送アドレススキームの同時のサポートに関するインジケータがＳＩＰメッセージに含まれる。

図３は、ＵＡ１１０の実施形態を含む、無線通信システムを図示する。ＵＡ１１０は、本開示の側面を実装するために動作可能であるが、本開示は、これらの実装に限定されるべきではない。携帯電話として図示されているが、ＵＡ１１０は、無線ハンドセット、ポケットベル、携帯情報端末（ＰＤＡ）、携帯用コンピュータ、タブレットコンピュータ、またはラップトップコンピュータを含む、種々の形態を成してもよい。多くの好適なデバイスは、これらの機能のうちのいくつかまたは全てを組み合わせる。本開示のいくつかの実施形態では、ＵＡ１１０は、携帯用、ラップトップ、またはタブレットコンピュータのような汎用コンピュータデバイスではなく、むしろ、携帯電話、無線ハンドセット、ポケットベル、またはＰＤＡ等の特殊用途通信デバイスである。別の実施形態では、ＵＡ１１０は、携帯用、ラップトップ、または他のコンピュータデバイスであってもよい。ＵＡ１１０は、ゲーム、在庫管理、ジョブ制御、および／またはタスク管理機能等の、特殊活動をサポートしてもよい。

ＵＡ１１０は、ディスプレイ４０２を含む。ＵＡ１１０はまた、ユーザによる入力のために、概して４０４と呼ばれる、タッチセンサ式表面、キーボード、または他の入力キーも含む。キーボードは、ＱＷＥＲＴＹ、Ｄｖｏｒａｋ、ＡＺＥＲＴＹ、および逐次タイプ等の、完全または縮小英数キーボード、または電話キーパッドと関連するアルファベット文字を伴う従来の数字キーパッドであってもよい。入力キーは、さらなる入力機能を提供するように内向きに押下されてもよい、トラックホイール、終了またはエスケープキー、トラックボール、および他のナビゲーションまたは機能キーを含んでもよい。ＵＡ１１０は、ユーザが選択するためのオプション、ユーザが作動させるための制御、および／またはユーザが指図するためのカーソルあるいは他の指標を提示してもよい。ＵＡ１１０はさらに、ダイヤルする番号、またはＵＡ１１０の動作を構成するための種々のパラメータ値を含む、ユーザからのデータ入力を受け取ってもよい。ＵＡ１１０はさらに、ユーザコマンドに応じて、１つ以上のソフトウェアまたはファームウェアアプリケーションを実行してもよい。これらのアプリケーションは、ユーザ対話に反応して種々のカスタマイズされた機能を果たすようにＵＡ１１０を構成してもよい。加えて、ＵＡ１１０は、例えば、無線基地局、無線アクセスポイント、またはピアＵＡ１１０から、無線でプログラムおよび／または構成されてもよい。

ＵＡ１１０によって実行可能な種々のアプリケーションの中には、ディスプレイ４０２がウェブページを表示することを可能にするウェブブラウザがある。ウェブページは、無線ネットワークアクセスノード、携帯電話の基地局、ピアＵＡ１１０、または任意の他の無線通信ネットワークあるいはシステム４００との無線通信を介して、取得されてもよい。ネットワーク４００は、インターネット等の有線ネットワーク４０８に連結される。無線リンクおよび有線ネットワークを介して、ＵＡ１１０は、サーバ４１０等の種々のサーバ上の情報にアクセスできる。サーバ４１０は、ディスプレイ４０２上に示されてもよいコンテンツを提供してもよい。代替として、ＵＡ１１０は、リレー型またはホップ型の接続で、仲介の役割を果たすピアＵＡ１１０を通してネットワーク４００にアクセスしてもよい。

図４は、ＵＡ１１０のブロック図を示す。ＵＡ１１０の種々の既知の構成要素が描写されているが、実施形態では、記載された構成要素および／または記載されていない付加的な構成要素の一部が、ＵＡ１１０に含まれてもよい。ＵＡ１１０は、デジタル信号プロセッサ（ＤＳＰ）５０２と、メモリ５０４とを含む。示されるように、ＵＡ１１０はさらに、アンテナおよびフロントエンドユニット５０６と、無線周波数（ＲＦ）送受信機５０８と、アナログベースバンド処理ユニット５１０と、マイクロホン５１２と、イヤホンスピーカ５１４と、ヘッドセットポート５１６と、入力／出力インターフェース５１８と、可撤性メモリカード５２０と、ユニバーサルシリアルバス（ＵＳＢ）ポート５２２と、短距離無線通信サブシステム５２４と、アラート５２６と、キーパッド５２８と、タッチセンサ式表面を含んでもよい液晶ディスプレイ（ＬＣＤ）５３０と、ＬＣＤコントローラ５３２と、電荷結合素子（ＣＣＤ）カメラ５３４と、カメラコントローラ５３６と、グローバルポジショニングシステム（ＧＰＳ）センサ５３８とを含んでもよい。実施形態では、ＵＡ１１０は、タッチセンサ式画面を提供しない、別の種類のディスプレイを含んでもよい。実施形態では、ＤＳＰ５０２は、入力／出力インターフェース５１８を通過せずに、メモリ５０４と直接通信してもよい。

ＤＳＰ５０２または何らかの他の形態のコントローラあるいは中央処理ユニットは、メモリ５０４に記憶された、またはＤＳＰ５０２自体内に含有されるメモリに記憶された、組み込みソフトウェアまたはファームウェアに従って、ＵＡ１１０の種々の構成要素を制御するように動作する。組み込みソフトウェアまたはファームウェアに加えて、ＤＳＰ５０２は、メモリ５０４に記憶された、または、可撤性メモリカード５２０のような携帯用データ記憶媒体等の情報担体媒体を介して、あるいは有線または無線ネットワーク通信を介して利用可能となった、他のアプリケーションを実行してもよい。アプリケーションソフトウェアは、所望の機能性を提供するようにＤＳＰ５０２を構成する、コンパイルされた一式の機械可読命令を備えてもよく、または、アプリケーションソフトウェアは、ＤＳＰ５０２を間接的に構成するようにインタープリタまたはコンパイラによって処理される、高次ソフトウェア命令であってもよい。

アンテナおよびフロントエンドユニット５０６は、無線信号と電気信号との間で変換するように提供されてもよく、ＵＡ１１０が、セルラーネットワークまたは何らかの他の利用可能な無線通信ネットワークから、あるいはピアＵＡ１１０から、情報を送受信することを可能にする。実施形態では、アンテナおよびフロントエンドユニット５０６は、ビーム形成および／または多重入出力（ＭＩＭＯ）動作を支援するように、複数のアンテナを含んでもよい。当業者に公知であるように、ＭＩＭＯ動作は、困難なチャネル条件を克服し、および／またはチャネルスループットを増加させるために使用することができる、空間的多様性を提供してもよい。アンテナおよびフロントエンドユニット５０６は、アンテナ同調および／またはインピーダンス整合構成要素、ＲＦ電力増幅器、および／または低雑音増幅器を含んでもよい。

ＲＦ送受信機５０８は、周波数偏移を提供し、受信したＲＦ信号をベースバンドに変換し、ベースバンド伝送信号をＲＦに変換する。いくつかの説明では、無線送受信機またはＲＦ送受信機は、変調／復調、符号化／復号、インターリービング／デインタリービング、拡散／逆拡散、逆高速フーリエ変換（ＩＦＦＴ）／高速フーリエ変換（ＦＦＴ）、周期的接頭辞添付／除去、および他の信号処理機能等の、他の信号処理機能性を含むと理解されてもよい。簡単にする目的で、ここでの説明は、ＲＦおよび／または無線段階から、この信号処理の説明を分離し、その信号処理を、アナログベースバンド処理ユニット５１０および／またはＤＳＰ５０２あるいは他の中央処理ユニットに概念的に割り当てる。いくつかの実施形態では、ＲＦ送受信機５０８、アンテナおよびフロントエンド５０６の複数部分、およびアナログベースバンド処理ユニット５１０が、１つ以上の処理ユニットおよび／または特定用途向け集積回路（ＡＳＩＣ）に組み入れられてもよい。

アナログベースバンド処理ユニット５１０は、入力および出力の種々のアナログ処理、例えば、マイクロホン５１２およびヘッドセット５１６からの入力、ならびにイヤホン５１４およびヘッドセット５１６への出力のアナログ処理を提供してもよい。そのためには、アナログベースバンド処理ユニット５１０は、ＵＡ１１０が携帯電話として使用されることを可能にする、内蔵マイクロホン５１２およびイヤホンスピーカ５１４に接続するためのポートを有してもよい。アナログベースバンド処理ユニット５１０はさらに、ヘッドセットまたは他のハンズフリーマイクロホンおよびスピーカ構成に接続するためのポートを含んでもよい。アナログベースバンド処理ユニット５１０は、１つの信号方向にデジタル・アナログ変換を、反対の信号方向にアナログ・デジタル変換を提供してもよい。いくつかの実施形態では、アナログベースバンド処理ユニット５１０の機能性の少なくとも一部が、デジタル処理構成要素によって、例えば、ＤＳＰ５０２によって、または他の中央処理ユニットによって提供されてもよい。

ＤＳＰ５０２は、変調／復調、符号化／復号、インターリービング／デインタリービング、拡散／逆拡散、逆高速フーリエ変換（ＩＦＦＴ）／高速フーリエ変換（ＦＦＴ）、周期的接頭辞添付／除去、および無線通信と関連する他の信号処理機能を行ってもよい。実施形態では、例えば、符号分割多重アクセス（ＣＤＭＡ）技術用途で、伝送器機能のために、ＤＳＰ５０２は、変調、符号化、インターリービング、および拡散を行ってもよく、受信機機能のために、ＤＳＰ５０２は、逆拡散、デインターリービング、復号、および復調を行ってもよい。別の実施形態では、例えば、直交周波数分割多重アクセス（ＯＦＤＭＡ）技術用途で、伝送器機能のために、ＤＳＰ５０２は、変調、符号化、インターリービング、逆高速フーリエ変換、および周期的接頭辞添付を行ってもよく、受信機機能のために、ＤＳＰ５０２は、周期的接頭辞除去、高速フーリエ変換、デインターリービング、復号、および復調を行ってもよい。他の無線技術用途では、さらに他の信号処理機能、および信号処理機能の組み合わせが、ＤＳＰ５０２によって行われてもよい。

ＤＳＰ５０２は、アナログベースバンド処理ユニット５１０を介して無線ネットワークと通信してもよい。いくつかの実施形態では、通信は、インターネット接続を提供してもよく、ユーザがインターネット上のコンテンツへのアクセスを獲得することと、Ｅメールおよびテキストメッセージを送受信することとを可能にする。入力／出力インターフェース５１８は、ＤＳＰ５０２ならびに種々のメモリおよびインターフェースを相互接続する。メモリ５０４および可撤性メモリカード５２０は、ソフトウェアおよびデータを提供して、ＤＳＰ５０２の動作を構成してもよい。インターフェースの中には、ＵＳＢインターフェース５２２および短距離無線通信サブシステム５２４があってもよい。ＵＳＢインターフェース５２２は、ＵＡ１１０を充電するために使用されてもよく、また、ＵＡ１１０が周辺デバイスとして機能し、パーソナルコンピュータまたは他のコンピュータシステムと情報を交換することを可能にしてもよい。短距離無線通信サブシステム５２４は、赤外線ポート、Ｂｌｕｅｔｏｏｔｈインターフェース、ＩＥＥＥ ８０２．１１準拠無線インターフェース、または、ＵＡ１１０が他の近くのＵＡおよび／または無線基地局と無線通信することを可能にしてもよい、任意の他の短距離無線通信サブシステムを含んでもよい。

入力／出力インターフェース５１８はさらに、誘起されると、例えば、ベルを鳴らす、メロディを再生する、または振動することによって、ＵＡ１１０にユーザへ通知を提供させる、アラート５２６にＤＳＰ５０２を接続してもよい。アラート５２６は、無音で振動することによって、または特定の架電者に対して特定の事前に割り当てられたメロディを再生することによって、着信電話、新しいテキストメッセージ、および予約のリマインダ等の種々の事象のうちのいずれかをユーザに警告するための機構としての機能を果たしてもよい。

キーパッド５２８は、インターフェース５１８を介してＤＳＰ５０２に連結し、ユーザが選択を行う、情報を入力する、あるいはＵＡ１１０に入力を提供するための１つの機構を提供する。キーボード５２８は、ＱＷＥＲＴＹ、Ｄｖｏｒａｋ、ＡＺＥＲＴＹ、および逐次タイプ等の、完全または縮小英数字キーボード、または電話キーパッドと関連するアルファベット文字を伴う従来の数字キーパッドであってもよい。入力キーは、さらなる入力機能を提供するように内向きに押下されてもよい、トラックホイール、終了またはエスケープキー、トラックボール、および他のナビゲーションまたは機能キーを含んでもよい。別の入力機構は、タッチスクリーン能力を含み、また、ユーザにテキストおよび／またはグラフィックを表示してもよい、ＬＣＤ５３０であってもよい。ＬＣＤコントローラ５３２は、ＤＳＰ５０２をＬＣＤ５３０に連結する。

ＣＣＤカメラ５３４は、装備された場合、ＵＥ１０がデジタル写真を撮ることを可能にする。ＤＳＰ５０２は、カメラコントローラ５３６を介してＣＣＤカメラ５３４と通信する。別の実施形態では、電荷結合素子カメラ以外の技術に従って動作するカメラが採用されてもよい。ＧＰＳセンサ５３８は、グローバルポジショニングシステム信号を復号するようにＤＳＰ５０２に連結され、それにより、ＵＡ１１０がその位置を決定することを可能にする。種々の他の周辺機器もまた、付加的な機能、例えば、ラジオおよびテレビ受信を提供するように含まれてもよい。

図５は、ＤＳＰ５０２によって実装されてもよい、ソフトウェア環境６０２を図示する。ＤＳＰ５０２は、そこからソフトウェアの他の部分が動作するプラットフォームを提供する、オペレーティングシステムドライバ６０４を実行する。オペレーティングシステムドライバ６０４は、アプリケーションソフトウェアにアクセス可能である標準化インターフェースを伴うノードハードウェアに対するドライバを提供する。オペレーティングシステムドライバ６０４は、ＵＡ１１０上で作動するアプリケーションの間で制御を転送する、アプリケーション管理サービス（「ＡＭＳ」）６０６を含む。図５には、ウェブブラウザアプリケーション６０８、メディアプレーヤアプリケーション６１０、およびＪａｖａ（登録商標）アプレット６１２も示されている。ウェブブラウザアプリケーション６０８は、ウェブブラウザとして動作するようにＵＡ１１０を構成し、ユーザがフォームに情報を入力し、ウェブページを検索および閲覧するようにリンクを選択することを可能にする。メディアプレーヤアプリケーション６１０は、音声または視聴覚媒体を読み出し、再生するようにＵＡ１１０を構成する。Ｊａｖａ（登録商標）アプレット６１２は、ゲーム、ユーティリティ、および他の機能性を提供するようにＵＡ１１０を構成する。構成要素６１４は、本開示に関係する提供性を提供する場合がある。

上記で説明されるＵＡ１１０および他の構成要素は、上記で説明される動作に関する命令を実行することが可能である、処理構成要素を含む場合がある。図６は、本明細書で開示される１つ以上の実施形態を実装するために好適な処理構成要素１３１０を含む、システム１３１０の実施例を図示する。プロセッサ１３１０（中央プロセッサユニットまたはＣＰＵと呼ばれてもよい）に加えて、システム１３００は、ネットワーク接続デバイス１３２０、ランダムアクセスメモリ（ＲＡＭ）１３３０、読み出し専用メモリ（ＲＯＭ）１３４０、２次記憶装置１３５０、入出力（Ｉ／Ｏ）デバイス１３６０を含む場合がある。場合によっては、これらの構成要素のうちのいくつかは、存在しなくてもよく、または、相互と、あるいは示されていない他の構成要素と、種々の組み合わせで組み合わせられてもよい。これらの構成要素は、単一の物理的実体に、または１つより多くの物理的実体に位置する場合がある。プロセッサ１３１０によって取られるものとして本明細書で説明される、任意の動作は、プロセッサ１３１０によって単独で、または、図面に示されている、あるいは示されていない１つ以上の構成要素と併せて、プロセッサ１３１０によって取られる場合がある。

プロセッサ１３１０は、それがネットワーク接続デバイス１３２０、ＲＡＭ１３３０、ＲＯＭ１３４０、または２次記憶装置１３５０（ハードディスク、フロッピー（登録商標）ディスク、または光ディスク等の、種々のディスクベースのシステムを含む場合がある）からアクセスする場合がある、命令、コード、コンピュータプログラム、またはスクリプトを実行する。１つだけのプロセッサ１３１０が示されているが、複数のプロセッサが存在してもよい。したがって、命令は、プロセッサによって実行されるものとして論議されてもよいが、命令は、同時に、連続的に、または別様に、１つまたは複数のプロセッサによって実行されてもよい。プロセッサ１３１０は、１つ以上のＣＰＵチップとして実装されてもよい。

ネットワーク接続デバイス１３２０は、モデム、モデムバンク、イーサネット（登録商標）デバイス、ユニバーサルシリアルバス（ＵＳＢ）インターフェースデバイス、シリアルインターフェース、トークンリングデバイス、光ファイバ分散データインターフェース（ＦＤＤＩ）デバイス、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス、符号分割多重アクセス（ＣＤＭＡ）デバイス、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）無線送受信機デバイス等の無線送受信機デバイス、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ）デバイス、および／またはネットワークに接続するための他の周知のデバイスの形態を成してもよい。これらのネットワーク接続デバイス１３２０は、プロセッサ１３１０が情報を受信する場合がある、またはプロセッサ１３１０が情報を出力する場合がある、インターネットまたは１つ以上の電気通信ネットワーク、あるいは他のネットワークと、プロセッサ１３１０が通信することを可能にしてもよい。

ネットワーク接続デバイス１３２０はまた、無線周波数信号またはマイクロ波周波数信号等の電磁波の形態で、データを無線で伝送および／または受信することが可能な１つ以上の送受信機構成要素１３２５も含む場合がある。代替として、データは、導電体の表面の中または上、同軸ケーブルの中、導波管の中、光ファイバ等の光媒体の中、または他の媒体の中で伝播してもよい。送受信機構成要素１３２５は、別個の受信および伝送ユニット、または単一の送受信機を含む場合がある。送受信機１３２５によって伝送または受信される情報は、プロセッサ１３１０によって処理されたデータ、またはプロセッサ１３１０によって実行される命令を含んでもよい。そのような情報は、例えば、コンピュータデータベースバンド信号または搬送波で具現化された信号の形態で、ネットワークから受信され、ネットワークに出力されてもよい。データは、データを処理または生成するか、あるいはデータを伝送または受信するために望ましくてもよいような異なる順序に従って、順序付けられてもよい。ベースバンド信号、搬送波に組み込まれた信号、または、現在使用されている、あるいは今後開発される他の種類の信号が、伝送媒体と呼ばれてもよく、当業者に周知のいくつかの方法に従って生成されてもよい。

ＲＡＭ１３３０は、揮発性データを記憶するために、および、おそらくプロセッサ１３１０によって実行される命令を記憶するために、使用される場合がある。ＲＯＭ１３４０は、典型的には２次記憶装置１３５０のメモリ容量よりも小さいメモリ容量を有する、不揮発性メモリデバイスである。ＲＯＭ１３４０は、命令、およびおそらく命令の実行中に読み出されるデータを記憶するために、使用される場合がある。ＲＡＭ１３３０およびＲＯＭ１３４０の両方へのアクセスは、典型的には、２次記憶装置１３５０へのアクセスよりも速い。２次記憶装置１３５０は、典型的には、１つ以上のディスクドライブまたはテープドライブから成り、ＲＡＭ１３３０が全作業データを保持するほど十分に大きくない場合に、データの不揮発性記憶のために、またはオーバーフローデータ記憶デバイスとして使用される場合がある。２次記憶装置１３５０は、ＲＡＭ１３３０にロードされるプログラムが実行のために選択されると、そのようなプログラムを記憶するために使用されてもよい。

Ｉ／Ｏデバイス１３６０は、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイヤル、マウス、トラックボール、音声認識装置、カード読取装置、紙テープ読取装置、プリンタ、ビデオモニタ、または他の周知の入力デバイスを含んでもよい。また、送受信機１３２５は、ネットワーク接続デバイス１３２０の構成要素である代わりに、またはそれに加えて、Ｉ／Ｏデバイス１３６０の構成要素と見なされる場合がある。Ｉ／Ｏデバイス１３６０のいくつかまたは全ては、ディスプレイ４０２および入力４０４等の、ＵＡ１１０の前述の図面に描写された種々の構成要素と実質的に同様であってもよい。

ＴＳ ２４．２２９ Ｖ７．８．０ （２００７−１２）といった、３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ （３ＧＰＰ） Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ （ＴＳ）が、参照することにより本明細書に組み込まれる。また、”ＳＩＰ： Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ”， ＲＦＣ ３２６１， Ｊｕｎｅ ２００２、ならびに、ＲＦＣ ３８４０、ＲＦＣ ３８４１、およびＲＦＣ ３２６１も、参照することにより本明細書に組み込まれる。

いくつかの実施形態を本開示で提供したが、開示されたシステムおよび方法は、本開示の精神または範囲から逸脱することなく、多くの他の具体的形態で具現化されてもよいことを理解されたい。本実施例は、制限的ではなく例証的と見なされるものであり、本明細書で与えられる詳細に制限されることを意図するものではない。例えば、種々の要素または構成要素が組み合わされるか、または別のシステムに統合されてもよく、または、ある特徴が省略されるか、あるいは実装されなくてもよい。

また、個別または別個のものとして種々の実施形態で説明および例証される、技術、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、または方法と組み合わされるか、あるいは統合されてもよい。相互に連結される、または直接連結される、あるいは通信するものとして示される、または論議される他の項目は、電気的であろうと、機械的であろうと、または別の方法であろうと、何らかのインターフェース、デバイス、または中間構成要素を通して、間接的に連結されるか、または通信してもよい。変更、置換、および改変の他の実施例が、当業者によって究明可能であり、本明細書で開示される精神および範囲から逸脱することなく行うことができる。

Claims (14)

1. 移送アドレススキームに関係する情報を伝える方法であって、
   該方法は、セッション初期化プロトコル（ＳＩＰ）メッセージ内に、少なくとも１つの通信セッションの間、ユーザエージェント（ＵＡ）が、通信のために複数の移送アドレススキームを同時にサポートすることが可能であるかどうかを示すインジケータを含むことを包含し、
   該インジケータは、該複数の移送アドレススキームのうちの第１のものがシグナリングのために用いられることと、該複数の移送アドレススキームのうちの第２のものがメディアのために用いられることとを示す、方法。
2. 前記インジケータは、
   第２のＵＡとのコンタクトを確立することを試みる第１のＵＡによって用いられる少なくとも１つの移送アドレススキームと、
   該第２のＵＡによってサポートされる少なくとも１つの移送アドレススキームを該第１のＵＡに知らせるようにという、該第１のＵＡから該第２のＵＡに対する要求と、
   該第２のＵＡが用い、該第１のＵＡが選ぶ少なくとも１つの移送アドレススキームの仕様と
   のうちの少なくとも１つを伝える、請求項１に記載の方法。
3. 前記インジケータは、
   メディア機能タグと、
   ＳＩＰヘッダフィールドと、
   拡張可能マークアップ言語（ＸＭＬ）本文と
   のうちの１つである、請求項２に記載の方法。
4. 前記第１のＵＡが前記第２のＵＡとのコンタクトを確立することを試み、前記インジケータが前記メディア機能タグである場合、少なくとも１つのトークンは、該メディア機能タグに関連付けられ、該少なくとも１つのトークンは、
   シグナリングのための移送アドレススキームと、
   メディアのための移送アドレススキームと、
   シグナリングおよびメディアの両方のための移送アドレススキームと
   のうちの少なくとも１つを指定する、請求項３に記載の方法。
5. 前記メディア機能タグは、初期ＳＩＰ要求のＣｏｎｔａｃｔヘッダに含まれる、請求項４に記載の方法。
6. 前記第２のＵＡによって用いられる少なくとも１つのアドレススキームを前記第１のＵＡに知らせるように該第１のＵＡが該第２のＵＡに要求した場合、該第２のＵＡは、該第１のＵＡにメディア機能タグを送り、該メディア機能タグは、
   シグナリングと、
   メディアと、
   シグナリングおよびメディアの両方と
   のうちの少なくとも１つに対する該第２のＵＡによって用いられる少なくとも１つのアドレススキームを指定する少なくとも１つのトークンを含む、請求項３に記載の方法。
7. 前記第１のＵＡが選び、前記第２のＵＡが用いる前記少なくとも１つの移送アドレススキームを該第１のＵＡが指定する場合、該第１のＵＡは、
   シグナリングのための好ましい移送アドレススキームと、
   メディアのための好ましい移送アドレススキームと、
   シグナリングおよびメディアの両方のための好ましい移送アドレススキームと
   のうちの少なくとも１つを指定する少なくとも１つのトークンを含むメディア機能タグを該第２のＵＡに送ることによって、優先度を指定する、請求項３に記載の方法。
8. 移送アドレススキームに関係する情報を伝えるように構成されているデバイスであって、
   該デバイスは、セッション初期化プロトコル（ＳＩＰ）メッセージ内に、少なくとも１つの通信セッションの間、該デバイスが、通信のために複数の移送アドレススキームを同時にサポートすることが可能であるかどうかを示すインジケータを含むように構成されているプロセッサを備え、
   該インジケータは、該複数の移送アドレススキームのうちの第１のものがシグナリングのために用いられることと、該複数の移送アドレススキームのうちの第２のものがメディアのために用いられることとを示す、デバイス。
9. 前記インジケータは、
   前記デバイスによって用いられる少なくとも１つの移送アドレススキームと、
   第２のデバイスのための該デバイスからの要求であって、該第２のデバイスによってサポートされる少なくとも１つの移送アドレススキームを該デバイスに知らせるようにという要求と、
   該デバイスが選び、該第２のデバイスが用いる少なくとも１つの移送アドレススキームの仕様と
   のうちの１つを伝える、請求項８に記載のデバイス。
10. 前記インジケータは、
    メディア機能タグと、
    ＳＩＰヘッダフィールドと、
    拡張可能なマークアップ言語（ＸＭＬ）本文と
    のうちの１つである、請求項９に記載のデバイス。
11. 前記デバイスが前記第２のデバイスとのコンタクトを確立することを試み、前記インジケータが前記メディア機能タグである場合、少なくとも１つのトークンは、該メディア機能タグに関連付けられ、該少なくとも１つのトークンは、
    シグナリングのため該デバイスが用いている移送アドレススキームと、
    メディアのため該デバイスが用いている移送アドレススキームと、
    シグナリングおよびメディアの両方のため該デバイスが用いている移送アドレススキームと
    のうちの少なくとも１つを指定する、請求項１０に記載のデバイス。
12. 前記メディア機能タグは、初期ＳＩＰ要求のＣｏｎｔａｃｔヘッダに含まれる、請求項１１に記載のデバイス。
13. 前記第２のデバイスによって用いられる少なくとも１つのアドレススキームを前記デバイスに知らせるように該デバイスが該第２のデバイスに要求した場合、該第２のデバイスは、該デバイスにメディア機能タグを送り、該メディア機能タグは、
    シグナリングと、
    メディアと、
    シグナリングおよびメディアの両方と
    のうちの少なくとも１つに対する該第２のデバイスによって用いられる少なくとも１つのアドレススキームを指定する少なくとも１つのトークンを含む、請求項１０に記載のデバイス。
14. 前記デバイスが好み、前記第２のデバイスが用いる前記少なくとも１つの移送アドレススキームを該デバイスが指定する場合、該デバイスは、
    シグナリングのための好ましい移送アドレススキームと、
    メディアのための好ましい移送アドレススキームと、
    シグナリングおよびメディアの両方のための好ましい移送アドレススキームと
    のうちの少なくとも１つを指定する少なくとも１つのトークンを含むメディア機能タグを該第２のデバイスに送ることによって、優先度を指定する、請求項１０に記載のデバイス。