JP6566522B2 - 要求元端末のオプション機能の非使用を整合する網間制御方法、ｓｉｐサーバ及びプログラム - Google Patents

Description

本発明は、ＩＭＳ(IP Multimedia Subsystem)におけるＳＩＰ(Session Initiation Protocol)／ＳＤＰ(Session Description Protocol)制御の技術に関する。

ＩＭＳは、ＩＰ(Internet Protocol)ベースのマルチメディア通信サービスを提供するものであって、３ＧＰＰ(3rd Generation Partnership Project)国際標準として規定されている（例えば非特許文献１参照）。ＩＭＳとは、アクセスネットワークに依存することなく、ＩＰパケットのトランスポートを制御するコアネットワークである。ＩＰ−ＣＡＮ(IP-Connectivity Access Network)と称される複数のアクセスネットワークが、シームレスに収容される。ＩＭＳによれば、異なるアクセスネットワークを介して、共通のマルチメディア通信サービス（例えばＩＰ電話、テレビ電話、ＩＭ(Instant Message)等）を提供することができる。

ＩＭＳは、主にセッション制御機能（ＣＳＣＦ(Call Session Control Function)）と共に、アプリケーションサービス制御機能（ＡＳ(Application Server）やユーザ情報蓄積機能（ＨＳＳ(Home Subscriber Server)）を搭載する。ＣＳＣＦは、サービス制御ネットワークの制御の核であるセッションを制御する機能であり、ユーザ端末（ＵＡ(User Agent)）間の通信セッションの設定及び解放を実現する。また、ＣＳＣＦは、ＳＩＰ（Session Initiation Protocol：セッション制御プロトコルである）やＳＤＰ（Session Description Protocol：セッション記述プロトコル）によってメッセージを交換する。更に、ＣＳＣＦは、接続されるセッションのサービス条件に応じて、ＡＳを選択的に利用する。

ＩＭＳを利用したサービスとして、例えば音声電話サービスがある。音声電話サービスは、主に回線交換方式によって提供されてきたが、固定電話事業者ではＩＰ電話が、携帯電話事業者ではＶｏＬＴＥ（Voice over LTE）が運用されている。携帯電話事業者や固定電話事業者がＩＰ方式のみで音声電話サービスを提供する場合、異なる通信事業者のＩＰネットワーク（ＩＭＳやＮＧＮ(Next Generation Network)等）間を相互接続する必要がある。

異なるＩＭＳの間、例えばＡＳ(Application Server)やＩＢＣＦ(Interconnection Border Control Function)を介して接続することができる。ＡＳは主にＳ−ＣＳＣＦと通信するものであり、ＩＢＣＦは主に異なる通信事業者間に配置される。ＩＢＣＦは、プロトコル変換用のトランスコーディングとして機能する。また、異なるＩＭＳ−ＡＧＷ(IP Multimedia Subsystem - Access Gateway)間は、例えばＴｒＧＷ(Translation Gateway)を介して接続することもできる。これらＡＳやＩＢＣＦ、ＴｒＧＷは、ネットワーク毎に異なる独自のＳＩＰパラメータやＳＤＰのメディア情報に応じて、プロトコルを整合し、網間差分をできる限りなくすようなすることができる。

尚、ＩＭＳサービスについて、コアネットワーク側及び端末側のそれぞれが搭載するオプション機能も規定されている（例えば非特許公報２参照）。オプション機能は、SIP/SDPに記述される、例えばDirection属性やprecondition属性等がある。これは、各通信事業者が自ら運営する網内でのみ提供するＩＭＳサービスに応じて、最適に選択される。また、セッションの要求先端末がprecondition非対応であっても、セッション確立におけるアーリーメディアのメディアクリッピングを生じないように制御する技術もある（例えば特許文献１参照）。

特開２０１５−１６２８２７号公報

3GPP TS 23.228 「IP Multimedia Subsystem (IMS); Stage 2」 3GPP TS 24.229 「IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3」

しかしながら、要求元端末が接続するネットワークでは「オプションＡ非使用」であって、要求先端末が接続するネットワークでは「オプションＡ使用」となる場合もある。セッションの要求元端末と要求先端末との間でオプション機能に差がある場合、セッションを確立することができなかったり、確立できたとしてもタイミング的な不具合が発生することがある。

勿論、異なるマルチメディアネットワーク間を相互接続するＡＳ（又はＩＢＣＦ／ＴｒＧＷ）によって、SIP/SDPを変換する処理を実行することもできる。しかしながら、リクエストやレスポンスの中で、その使用が明示的に示されたオプション機能がある一方で、明示されていないオプション機能もある。

ＳＩＰによれば、セッション開始リクエスト（INVITE）の送信開始から、最終の成功レスポンス（200OK）までのセッション確立中の状態を、「アーリーダイアログ」と定義される。

ここで、要求元端末と要求先端末との間で、セッションの確立タイミングが一致しない場合、要求先端末は、リソース確保が完了した直後に、メディアが途中から流れるという、タイミング的な不都合も生じる。これは、セッションの要求先端末が、メディアを流すためのリソース（通信路）を確保できていない状態（リソース未確保）で、要求元端末からメディアが流し始めることが問題となる。

具体的なオプション機能としては、SDPに含まれるprecondition属性がある。これは、要求元端末と要求先端末が互いにリソース確保状態となったことを確認した後に、メディアを流し始めるために用いられる。要求先端末は、a=inactiveを送信するときはリソース未確保であるために、preconditionにもリソース未確保であることを明示したSIP/SDPを送信する。そして、リソースを確保できたタイミングで、a=sendrecv及びpreconditionでリソース確保済を明示したSIP/SDPへ切り替える。しかしながら、オプション機能であるため、要求元端末が、a=inactiveやpreconditionのオプション機能を使用していない可能性がある。

また、リソース確保済を明示したSIP/SDPの中で使用されるSIPメソッドとして、UPDATEメソッドやSDP有りPRACKメソッドがある。これらもオプション機能であり、いずれも要求元端末で使用していない可能性がある。例えば、ＩＢＣＦやＴｒＧＷが、SIPメソッドの変換機能を有していても、要求元端末のオプション機能の使用状態によっては、代替可能なSIPメソッドが存在しない可能性もある。

そこで、本発明によれば、任意のオプション機能について、要求元端末で非使用であって、要求先端末で使用であっても、相互に整合することができる網間制御方法、ＳＩＰサーバ及びプログラムを提供することを目的とする。

本発明によれば、要求元端末が接続されたマルチメディアネットワークと、要求先端末が接続されたマルチメディアネットワークとの間に配置されたＳＩＰサーバにおける網間接続方法において、
ＳＩＰサ−バは、
セッションにおける要求元端末の非使用オプションに対して要求先端末が使用する場合における使用オプションを登録しており、
要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送する第１のステップと、
要求先端末から成功レスポンスを受信した際に、要求元端末の要求元オプションと要求先端末の要求先オプションとを記憶する第２のステップと、
要求元オプションが非使用オプションであり且つ要求先オプションが使用オプションである場合、非使用オプションに更新すべき更新リクエストを、要求先端末へ送信する第３のステップと
を実行することを特徴とする。

本発明の網間接続方法における他の実施形態によれば、
リクエストは、セッション開始リクエスト(INVITE)であり、
要求元オプションの非使用オプションは、a=sendrecvであり、
要求先オプションの使用オプションは、a=inactiveである
ことも好ましい。

本発明の網間接続方法における他の実施形態によれば、
ＳＩＰサ−バは、第２のステップについて、リクエストの種類に応じて、
（１）確認リクエストを要求先端末へ送信し、その後、要求先端末から確認レスポンスを受信した際に、第３のステップへ移行するか、
（２）確認リクエストを要求先端末へ送信し、その後、第３のステップへ移行するか、
又は、
（３）確認リクエストを要求先端末へ送信することなく、第３のステップへ移行する
ことも好ましい。

本発明の網間接続方法における他の実施形態によれば、
ＳＩＰサ−バは、第３のステップについて、
要求先端末から更新成功レスポンスを受信した際に、要求元端末へ成功レスポンスを送信することも好ましい。

本発明の網間接続方法における他の実施形態によれば、
ＳＩＰサーバは、第２のステップについて、
要求元端末の要求元オプションが非使用オプションに変更されるか否かを確認するために、
要求先端末から受信した暫定レスポンスをそのまま、要求元端末へ転送し、
要求元端末から送信された暫定応答確認リクエストをそのまま、要求先端末へ転送し、
要求先端末から返信された暫定応答確認レスポンスをそのまま、要求元端末へ転送し、
要求元オプションが非使用オプションであり、且つ、要求先オプションが使用オプションである場合、セッションの切断シーケンスを実行し、改めて、第１のステップから第３のステップまでを実行することも好ましい。

本発明の網間接続方法における他の実施形態によれば、
ＳＩＰサーバは、
異なるＣＳＣＦ間に接続されたＡＳ(Application Server)若しくはＩＢＣＦ(Interconnection Border Control Function)、又は、
異なるＩＭＳ−ＡＧＷ(IP Multimedia Subsystem - Access Gateway)間に接続されたＴｒＧＷ(Translation Gateway)であり、
要求元端末は、要求元のＵＡ(User Agent)又はネットワーク通信装置であり、
要求先端末は、要求先のＵＡ又はネットワーク通信装置であることも好ましい。

本発明によれば、要求元端末が接続されたマルチメディアネットワークと、要求先端末が接続されたマルチメディアネットワークとの間に配置されたＳＩＰサーバにおいて、
セッションにおける要求元端末の非使用オプションに対して要求先端末が使用する場合における使用オプションを登録したオプション登録手段と、
要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送するリクエスト転送手段と、
要求先端末から成功レスポンスを受信した際に、要求元端末の要求元オプションと要求先端末の要求先オプションとを記憶する確認リクエスト送信手段と、
要求元オプションが非使用オプションであり且つ要求先オプションが使用オプションである場合、非使用オプションに更新すべき更新リクエストを、要求先端末へ送信する更新リクエスト送信手段と
を有することを特徴とする。

本発明によれば、要求元端末が接続されたマルチメディアネットワークと、要求先端末が接続されたマルチメディアネットワークとの間に配置されたＳＩＰサーバに搭載されたコンピュータを機能させるプログラムにおいて、
セッションにおける要求元端末の非使用オプションに対して要求先端末が使用する場合における使用オプションを登録したオプション登録手段と、
要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送するリクエスト転送手段と、
要求先端末から成功レスポンスを受信した際に、要求元端末の要求元オプションと要求先端末の要求先オプションとを記憶する確認リクエスト送信手段と、
要求元オプションが非使用オプションであり且つ要求先オプションが使用オプションである場合、非使用オプションに更新すべき更新リクエストを、要求先端末へ送信する更新リクエスト送信手段と
してコンピュータを機能させることを特徴とする。

本発明の網間制御方法、ＳＩＰサーバ及びプログラムによれば、任意のオプション機能について、要求元端末で非使用であって、要求先端末で使用であっても、相互に整合することができる。特に、リクエストやレスポンスの中で明示されるオプション機能に限られず、明示されないオプション機能についても相互の差分を整合することができる。

本発明におけるシステム構成図である。 本発明におけるシーケンス図である。 本発明における具体的な実施形態のシーケンス図である。 第２のステップについて他の実施形態を表すシーケンス図である。 要求元端末のオプション機能を確認するためのシーケンス図である。 本発明におけるアプリケーションサーバの機能構成図である。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

図１は、本発明におけるシステム構成図である。

図１によれば、要求元端末２１が接続されたマルチメディアネットワークと、要求先端末２２が接続されたマルチメディアネットワークとの間に、ＳＩＰサーバ１が配置されている。ＳＩＰサーバ１は、異なるＣＳＣＦ間に接続されたＡＳ若しくはＩＢＣＦ、又は、
異なるＩＭＳ−ＡＧＷ間に接続されたＴｒＧＷであってもよい。尚、以下の実施形態では、異なるマルチメディアネットワーク間に配置されたＳＩＰサーバは、ＡＳであるとして説明する。

図１によれば、ＡＳ１を経由して、要求元端末２１と要求先端末２２との間で、セッションのリクエストとレスポンスとを転送することができる。要求元端末２１及び２２は、例えばオプションＡの機能について、以下のように使用／非使用の関係にあるとする。
要求元端末２１＝オプションＡ機能「非使用」
要求先端末２２＝オプションＡ機能「使用」
尚、要求元端末は、要求元のＵＡ(User Agent)に限られず、要求元のネットワーク通信装置（例えば要求元ＡＳ又は要求元ＩＢＣＦ）であってもよい。また、要求先端末も、要求先のＵＡに限られず、要求先のネットワーク通信装置（同様に例えば要求先ＡＳ又は要求先ＩＢＣＦ）であってもよい。例えば、要求元ＡＳと要求先ＡＳとは、網間接続用のＳＩＰサーバであるＡＳを介して通信するであってもよい。

図２は、本発明における基本シーケンス図である。

（Ｓ０）ＡＳ１は、セッションにおける要求元端末２１の要求元オプションの非使用に対して要求先端末２２が使用の場合における対応関係を登録しておく。
（要求元オプション）＜−＞ （使用オプション）
オプションａ ＜−＞ オプションＡ

［第１のステップ］
（Ｓ１１）要求元端末２１は、要求先端末２２へ向けて「リクエスト」を送信する。リクエストには、「オプションａ（オプションＡ非使用）」を示す要求元オプションが含まれている。
（Ｓ１２）リクエストを受信したＡＳ１は、要求元端末２１は「オプションＡ非使用」である、と確定する。
（Ｓ１３）そして、ＡＳ１は、「オプションＡ非使用」（オプションａ使用）を示すリクエストをそのまま、要求先端末２２へ転送する。

［第２のステップ］
（Ｓ２１）これに対し、要求先端末２２は、「オプションＡ使用」としている。このとき、要求先端末２２は、「オプションＡ使用」を示す成功レスポンスを、ＡＳ１へ返信する場合がある。
（Ｓ２２）ＡＳ１は、要求先端末２２が「オプションＡ使用」であると確認する。これによって、要求元端末２１の要求元オプションと要求先端末２２の要求先オプションとを記憶する。そして、ＡＳ１は、要求先端末２２に対して、オプションＡに対する非使用オプションの「オプションａ」を選択する。
尚、その後、ＡＳ１は、要求元端末２１から受信したリクエストの種類に応じて、確認リクエストを要求先端末２２へ送信するか否かを制御するものであってもよい。

［第３のステップ］
（Ｓ３１）次に、ＡＳ１は、要求元オプションが非使用オプションであり且つ要求先オプションが使用オプションである場合、非使用オプションに更新すべき「オプションａ」を示す更新リクエストを、要求先端末２２へ送信する。
（Ｓ３２）要求先端末２２は、オプションＡの使用から、オプションａの使用（オプションＡの非使用）へ更新されたと認識する。このとき、要求先端末２２は、オプションａを示す更新成功レスポンスを、ＡＳ１へ返信する。
（Ｓ３３）ＡＳ１は、要求先端末２２から更新成功レスポンスを受信することによって、要求先オプションはオプションａの使用（オプションＡの非使用）であると認識する。
（Ｓ３４）そして、ＡＳ１は、要求元端末２１へ、成功レスポンスを返信する。
（Ｓ３５）これに対し、要求元端末２１は、確認リクエストを、ＡＳ１へ送信する。

Ｓ１１〜Ｓ３５によれば、端末間のオプション機能が明示されていない場合であっても、リクエスト−レスポンスの交換の中で成功レスポンスを発生させた後、更新リクエストを送信することによって、そのオプション機能を非使用として整合させることができる。即ち、要求先端末２２がオプションＡを使用している場合であっても、ＡＳ１は、要求元端末２１へその旨を通知する必要がない。ＡＳ１は、直ぐに、非使用オプションａを用いて要求先端末とオプション機能を整合させることができる。
また、本発明のシーケンスが実行されたとしても、要求元端末と要求先端末との間で通信可能状態に遷移したことを確認した後に通信を開始するために、一方の端末から送信されたメディアが欠落することがない。

要求元端末及び要求先端末で整合すべきオプション機能としては、例えば以下のようなものがある。
Direction（メディア方向）属性
precondition使用、及び、リソース確保状態
UPDATE信号
100rel
SDP有りPRACK信号
SDP無しRe-INVITE信号

図３は、本発明における具体的な実施形態のシーケンス図である。

図３によれば、リクエストは、セッション開始リクエスト(INVITE)である。
また、要求元端末２１及び要求先端末２２は、以下のようなオプション機能の設定になっているとする。
（要求元端末２１）
a=inactive非使用（a=sendrecv使用）
precondition使用、且つ、リソース確保済
UPDATE使用
100rel使用
（要求先端末２２）
a=inactive使用
precondition使用、且つ、リソース未確保
UPDATE使用
100rel使用

「a=」は、メディア記述部に含まれており、メディアの方向性を表すDirection属性である。Direction属性は、各端末がメディアを相手方端末へ流して良いか否かを判断するものである。即ち、Directionを使用しているか否かを明示するものではない。パラメータとしては、「sendrecv」（両方向）、「sendonly」（送信のみ）、「recvonly」（受信のみ）、「inactive」（送受信なし）がある。
尚、「a=」属性が省略されている場合、「a=sendrecv」が設定されているものとして処理が実行される。

a=sendrecvを含むSDP Offerのリクエストに対しては、SDP Answerに何を返信してもよい、とする条件がある。
そのために、要求元端末２１が、SDPにa=sendrecvを記述したリクエストを送信した場合、要求先端末２２は、a=inactiveを返信してもよい。但し、要求先端末２２は、a=inactive非使用としている可能性もある。

この場合、ＡＳ１が、要求元端末２１から要求先端末２２へのSDP Offerのa= sendrecvをa=inactiveに変換し、要求先端末２２から要求元端末２１へのSDP Answerのa=inactiveをa=sendrecvに変換することもできる。
しかしながら、要求元端末２１はa=sendrecvであるのに対し、要求先端末２２はa=inactiveであるために、要求元端末２１が直ぐにメディアを流した場合、要求先端末２２でそのメディアを再生することができない。

図３の実施形態によれば、図２に基本シーケンスに基づいて、具体的に以下のようなシーケンスを実行する。

（Ｓ０）ＡＳ１は、以下のようなリスト（非使用選択オプション機能リスト）に、非使用オプションに対する使用オプションを登録しているとする。
（非使用オプションａ） <-> （オプションＡ）
a=sendrecv <-> a=inactive
これは、「a=inactive使用」の要求先端末２２に対しては、「a=sendrecv」で整合することを意味する。

このリストは、システム運用者によって予め設定されたものであってもよい。また、使用頻度が低いオプション機能ほど、優先度を高く設定することが好ましい。このリストには、その他、a=inactive、precondition、100relなども含まれる。

（Ｓ１１）要求元端末２１が、要求先端末のＵＲＩ(Uniform Resource Indicator)を宛先情報として、セッション開始リクエスト（例えばSIP:INVITE）を送信する。ここで、要求元端末２１は、自らのオプション機能の使用状態（a=sendrecv使用、precondition使用(リソース確保済)、100rel使用）に従って、SIP/SDPパラメータを載せる。
［SIP:INVITE］
−ＳＩＰヘッダ
Supported: 100rel,precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
−ＳＤＰ
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos optional remote sendrecv
a=sendrecv

（Ｓ１２）ＡＳ１は、セッション開始リクエストに含まれるSIP/SDPパラメータに基づいて、要求元端末２１の使用可能なオプション機能を記憶する。
ここで、要求元端末２１がＵＡである場合、端末種別を特定するために、User-Agentヘッダ、P-Asserted-Identityヘッダ又はFromヘッダに含まれるSIP URIやtel URIを用いてもよい。また、要求元端末２１がネットワーク通信装置である場合、網種別を特定するために、P-Charging-Vectorヘッダのioiパラメータ、P-Asserted-IdentityヘッダやFromヘッダに含まれるSIP URIのドメイン部を用いてもよい。

（Ｓ１３）ＡＳ１は、受信したセッション開始リクエストをそのまま、要求先端末２２へ転送する。

（Ｓ２１）要求先端末２２は、受信したセッション開始リクエストから「a=sendrecv使用」（a=inactive非使用）を知る。ここで、要求先端末２２は、自らのオプション機能の使用状態（a=inactive使用、precondition(リソース未確保)、100rel使用）を示す暫定レスポンス（SIP:183(INVITE)）を返信する。
［SIP:183(INVITE)］
−ＳＩＰヘッダ
Supported: 100rel,precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
−ＳＤＰ
a=curr:qos local none
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=inactive

（Ｓ２２）ＡＳ１は、暫定レスポンス（SIP:183(INVITE)）から、要求先端末２２のオプション機能の使用状態を記憶する。特に、要求先端末２２は、「a=inactive使用」であることを確認する。そして、ＡＳ１は、以下のように動作するように制御する。
−要求先端末がリソース確保状態となるようprecondition処理を実行する
−要求元端末への応答信号の送信は、要求先端末からa=sendrecvとなってから実行する。

（Ｓ２３）ＡＳ１は、暫定レスポンスに対する暫定応答確認リクエスト（SIP:PRACK）を、要求先端末２２へ送信する。

（Ｓ２４）要求先端末２２は、暫定応答確認リクエストに対する暫定応答確認レスポンス（SIP:200(PRACK)）を、ＡＳ１へ返信する。

（Ｓ３１）ＡＳ１は、要求先端末２２のリソース確保が完了しているであろう時点を、例えば所定時間のタイムアウトによって判断する。その後、a=inactiveをa=sendrecvに更新すべき更新リクエスト（SIP:UPDATE）を、要求先端末２２へ送信する。
［SIP:UPDATE］
−ＳＩＰヘッダ
Require: precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
−ＳＤＰ
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv

（Ｓ３２）要求先端末２２は、受信した更新リクエストに対して、自身のオプション機能の使用状態（precondition非使用、UPDATE非使用、100rel使用）を示す更新成功レスポンス（SIP:200(UPDATE)）を返信する。
［SIP:200(UPDATE)］
−ＳＩＰヘッダ
Require: precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
−ＳＤＰ
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv

（Ｓ３３）ＡＳ１は、要求先端末が「a=inactive非使用」（a=sendrecv使用）である、と確定する。
ここで、要求先端末２２がＵＡである場合、端末種別を特定するために、User-Agentヘッダ、P-Asserted-Identityヘッダ又はToヘッダに含まれるSIP URIやtel URIを用いてもよい。また、要求先端末２２がネットワーク通信装置である場合、網種別を特定するために、P-Charging-Vectorヘッダのioiパラメータ、P-Asserted-Identityヘッダ又はToヘッダに含まれるSIP URIのドメイン部を用いてもよい。

尚、a=inactiveをa=sendrecvに変換しても、エラーレスポンスが返信される場合、別のオプション機能に差分があるとみなす。その場合、Ｓ３１へ戻って、他のオプション機能の変換を試行する。
また、ＡＳ１は、Ｓ２１の暫定レスポンスと同等のパラメータが、Ｓ３２の更新成功レスポンスに含まれている場合、Ｓ３１及びＳ３２を繰り返し実行するか、切断シーケンスを実行する。要求先端末２２をa=sendrecvに遷移させることができない限り、要求元端末２１がリソースを確保しても、直ぐに端末間でメディアを流すことができない。

（Ｓ３４）ＡＳ１は、暫定レスポンス（例えばSIP:183(INVITE)）を、要求元端末２１へ送信する。
［SIP:183］
−ＳＩＰヘッダ
Supported: 100rel,precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
−ＳＤＰ
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv

（Ｓ３５）要求元端末２１は、暫定レスポンスを受信した場合、暫定応答確認リクエスト（SIP:PRACK）を、ＡＳ１へ送信する。

（Ｓ３６）ＡＳ１は、暫定応答確認リクエストを受信した場合、要求先端末２２には転送せず、暫定応答確認レスポンス（SIP:200(PRACK)）を要求元端末２１へ返信する。

図３のように、要求先端末２２をa=sendrecvに遷移させることによって、要求元端末２１がリソースを確保した際に、直ぐに端末間でメディアを流すことができる。

図４は、第２のステップについて他の実施形態を表すシーケンス図である。

第２のステップについて、ＡＳ１は、要求元端末２１から受信したリクエストの種類に応じて、以下のように異なるいずれか１つのシーケンスを実行するものであってもよい。

（第１のシーケンス）セッション開始リクエスト「INVITE」の場合、ＡＳ１は、確認リクエストを要求先端末２２へ送信し、その後、要求先端末２２から確認レスポンスを受信した際に、第３のステップへ移行する。これは、図３のＳ２３及びＳ２４に相当する。
Ｓ１１及びＳ１３のリクエストが、セッション開始リクエスト「INVITE」である場合、ＡＳ１は、要求先端末２２から暫定レスポンス「183」を受信した後、暫定応答確認リクエスト「PRACK」を要求先端末２２へ送信する（図３のＳ２３参照）。
その後、ＡＳ１は、要求先端末２２から、暫定応答確認レスポンス「200(PRACK)」を受信した際に（図３のＳ２４参照）、第３のステップ（図３のＳ３１参照）へ移行する。
但し、具体的には、Ｓ２１の暫定レスポンスが「183(INVITE)」には、Require:100relが含まれていることを要する。

（第２のシーケンス）セッション更新リクエスト「Re-INVITE」の場合、ＡＳ１は、確認リクエストを要求先端末２２へ送信し、その後、第３のステップへ移行する。これは、図４（ａ）に表すシーケンスである。
Ｓ１１及びＳ１３のリクエストが、セッション更新リクエスト「Re-INVITE」である場合、ＡＳ１は、要求先端末２２から成功レスポンス「200(INVITE)」を受信した後、成功応答確認リクエスト「ACK」を要求先端末２２へ送信する（図４のＳ２３参照）。
その後、第３のステップ（図３のＳ３１参照）へ移行する。

（第３のシーケンス）更新リクエスト「UPDATE」の場合、ＡＳ１は、確認リクエストを要求先端末へ送信することなく、直ぐに、第３のステップへ移行する。これは、図４（ｂ）に表すシーケンスである。
Ｓ１１及びＳ１３のリクエストが、更新リクエスト「UPDATE」である場合、ＡＳ１は、要求先端末２２から成功レスポンス「200(UPDATE)」を受信した後、直ぐに、第３のステップ（図３のＳ３１参照）へ移行する。

図５は、要求元端末のオプション機能を確認するためのシーケンス図である。

図５によれば、要求元端末の要求元オプションが非使用オプションに変更されるか否かを確認することができる。
（Ｓ１１〜Ｓ２２）図３のＳ１１〜Ｓ２２と全く同じである。
（Ｓ４１）ＡＳ１は、Ｓ２１で受信した暫定レスポンス（183(INVITE)）をそのまま、要求元端末２１へ転送する。
（Ｓ４２）要求元端末２１は、受信した暫定レスポンスに対して、暫定応答確認リクエスト（SIP:PRACK）を、ＡＳ１へ送信する。
（Ｓ４３）ＡＳ１は、要求元端末２１から受信した暫定応答確認リクエスト（SIP:PRACK）をそのまま、要求先端末２２へ転送する。
（Ｓ４４）要求先端末２２は、受信した暫定応答確認リクエストに対して、暫定応答確認レスポンス（SIP:200(PRACK)）を、ＡＳ１へ返信する。
（Ｓ４５）ＡＳ１は、受信した暫定応答確認レスポンスをそのまま、要求元端末２１へ返信する。

（Ｓ４６）ＡＳ１は、要求元端末２１のオプション機能の使用状態と、要求先端末２２のオプション機能の使用状態とを、暫定応答確認リクエスト及び暫定応答確認レスポンスのSIP/SDPの交換によって確定する。ここでも、要求元端末が「a=inactive非使用」（a=sendrecv使用）に対して、要求先端末が「a=inactive使用」であることを確定する。

（Ｓ４７）ここで、要求元端末が「a=inactive使用」に自ら変更するか、要求先端末が「a=inactive非使用」に自ら変更しない限り、端末間でメディアを通信することができない。ＡＳ１は、要求元オプションが非使用オプションであり、且つ、要求先オプションが使用オプションである場合、セッションの切断シーケンスを実行し、改めて、図３のシーケンスを実行する。ＡＳ１は、セッションにメディアが流れていないことを検知して、切断シーケンスを実行するものであってもよい。

図６は、本発明におけるアプリケーションサーバの機能構成図である。

図６によれば、アプリケーションサーバ１は、オプション登録部１０と、リクエスト転送部１１と、確認リクエスト送信部１２と、更新リクエスト送信部１３と、メディア転送部１４とを有する。これら機能構成部は、マルチメディアネットワーク間に配置されたサーバに搭載されたコンピュータを機能させるプログラムを実行することによって実現される。
オプション登録部１０は、セッションにおける要求元端末の非使用オプションに対して要求先端末が使用する場合における使用オプションを登録したものである（図２のＳ０参照）。
リクエスト転送部１１は、要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送する（図２のＳ１参照）。
確認リクエスト送信部１２は、要求先端末から成功レスポンスを受信した際に、要求元端末の要求元オプションと要求先端末の要求先オプションとを記憶する（図２のＳ２参照）。
更新リクエスト送信部１３は、要求元オプションが非使用オプションであり且つ要求先オプションが使用オプションである場合、非使用オプションに更新すべき更新リクエストを、要求先端末へ送信する（図２のＳ３参照）。
メディア転送部１４は、要求元端末２１と要求先端末２２との間で、メディアを中継して転送する。

以上、詳細に説明したように、本発明のセッション制御方法、ＳＩＰサーバ及びプログラムによれば、任意のオプション機能について、要求元端末で非使用であって、要求先端末で使用であっても、相互に整合することができる。特に、リクエストやレスポンスの中で明示されたオプション機能に限られず、明示されていないオプション機能についても相互の差分を整合することができる。

これによって、セッションに基づくオプション機能の不一致に基づく不具合を回避し、相互接続性を高めることができる。具体的には、移動体事業者が、自社網サービスに最適化されていない端末（例えばＳＩＭフリー端末など）と、自社網サービスの相互接続性を高めることができる。

また、本発明によれば、端末に特別な機能を搭載することなく、通信事業者がＩＭＳにアプリケーションサーバ（又はＩＢＣＦ）を設置するだけでよい。そのために、セッションの要求元端末及び要求先端末がオプション機能の「使用／非使用」を認識する必要がない。即ち、端末から見て、ＩＭＳを介した既存シーケンスに変更を加える必要がない。また、異なる事業者に運用されるＩＭＳやＩＰネットワークに対しても、汎用的に用いることができる。

前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

１ ＡＳ、ＩＢＣＦ、ＴｒＧＷ
１０ オプション登録部
１１ リクエスト転送部
１２ 確認リクエスト送信部
１３ 更新リクエスト送信部
１４ メディア転送部
２１ 要求元端末
２２ 要求先端末

Claims (8)

1. 要求元端末が接続されたマルチメディアネットワークと、要求先端末が接続されたマルチメディアネットワークとの間に配置されたＳＩＰサーバにおける網間接続方法において、
   前記ＳＩＰサ−バは、
   セッションにおける要求元端末の非使用オプションに対して要求先端末が使用する場合における使用オプションを登録しており、
   要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送する第１のステップと、
   要求先端末から成功レスポンスを受信した際に、要求元端末の要求元オプションと要求先端末の要求先オプションとを記憶する第２のステップと、
   要求元オプションが非使用オプションであり且つ要求先オプションが使用オプションである場合、非使用オプションに更新すべき更新リクエストを、要求先端末へ送信する第３のステップと
   を実行することを特徴とする網間接続方法。
2. 前記リクエストは、セッション開始リクエスト(INVITE)であり、
   要求元オプションの前記非使用オプションは、a=sendrecvであり、
   要求先オプションの前記使用オプションは、a=inactiveである
   ことを特徴とする請求項１に記載の網間接続方法。
3. 前記ＳＩＰサ−バは、第２のステップについて、前記リクエストの種類に応じて、
   （１）確認リクエストを要求先端末へ送信し、その後、要求先端末から確認レスポンスを受信した際に、第３のステップへ移行するか、
   （２）確認リクエストを要求先端末へ送信し、その後、第３のステップへ移行するか、
   又は、
   （３）確認リクエストを要求先端末へ送信することなく、第３のステップへ移行する
   ことを特徴とする請求項１又は２に記載の網間接続方法。
4. 前記ＳＩＰサ−バは、第３のステップについて、
   要求先端末から更新成功レスポンスを受信した際に、要求元端末へ成功レスポンスを送信する
   ことを特徴とする請求項１から３のいずれか１項に記載の網間接続方法。
5. 前記ＳＩＰサーバは、第２のステップについて、
   要求元端末の要求元オプションが非使用オプションに変更されるか否かを確認するために、
   要求先端末から受信した暫定レスポンスをそのまま、要求元端末へ転送し、
   要求元端末から送信された暫定応答確認リクエストをそのまま、要求先端末へ転送し、
   要求先端末から返信された暫定応答確認レスポンスをそのまま、要求元端末へ転送し、
   要求元オプションが非使用オプションであり、且つ、要求先オプションが使用オプションである場合、セッションの切断シーケンスを実行し、改めて、第１のステップから第３のステップまでを実行する
   ことを特徴とする請求項１から４のいずれか１項に記載の網間接続方法。
6. 前記ＳＩＰサーバは、
   異なるＣＳＣＦ間に接続されたＡＳ(Application Server)若しくはＩＢＣＦ(Interconnection Border Control Function)、又は、
   異なるＩＭＳ−ＡＧＷ(IP Multimedia Subsystem - Access Gateway)間に接続されたＴｒＧＷ(Translation Gateway)であり、
   前記要求元端末は、要求元のＵＡ(User Agent)又はネットワーク通信装置であり、
   前記要求先端末は、要求先のＵＡ又はネットワーク通信装置である
   ことを特徴とする請求項１から５のいずれか１項に記載の網接続方法。
7. 要求元端末が接続されたマルチメディアネットワークと、要求先端末が接続されたマルチメディアネットワークとの間に配置されたＳＩＰサーバにおいて、
   セッションにおける要求元端末の非使用オプションに対して要求先端末が使用する場合における使用オプションを登録したオプション登録手段と、
   要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送するリクエスト転送手段と、
   要求先端末から成功レスポンスを受信した際に、要求元端末の要求元オプションと要求先端末の要求先オプションとを記憶する確認リクエスト送信手段と、
   要求元オプションが非使用オプションであり且つ要求先オプションが使用オプションである場合、非使用オプションに更新すべき更新リクエストを、要求先端末へ送信する更新リクエスト送信手段と
   を有することを特徴とするＳＩＰサ−バ。
8. 要求元端末が接続されたマルチメディアネットワークと、要求先端末が接続されたマルチメディアネットワークとの間に配置されたＳＩＰサーバに搭載されたコンピュータを機能させるプログラムにおいて、
   セッションにおける要求元端末の非使用オプションに対して要求先端末が使用する場合における使用オプションを登録したオプション登録手段と、
   要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送するリクエスト転送手段と、
   要求先端末から成功レスポンスを受信した際に、要求元端末の要求元オプションと要求先端末の要求先オプションとを記憶する確認リクエスト送信手段と、
   要求元オプションが非使用オプションであり且つ要求先オプションが使用オプションである場合、非使用オプションに更新すべき更新リクエストを、要求先端末へ送信する更新リクエスト送信手段と
   してコンピュータを機能させることを特徴とするプログラム。