JP6549523B2 - 要求先端末のオプション機能の非使用を整合する網間制御方法、ｓｉｐサーバ及びプログラム - 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を変換する処理を実行することもできる。SIP/SDPの特徴として、要求元端末と要求先端末との間でオプション機能を整合することが期待されている。しかしながら、リクエストやレスポンスの中で、その使用が明示されたオプション機能がある一方で、明示されていないオプション機能もある。

ＳＩＰによれば、セッション開始リクエスト（INVITE）の送信開始から、最終の成功レスポンス（200OK）までのセッション確立中の状態を、「アーリーダイアログ」と定義される。アーリーダイアログで提供されるメディアとして、例えばＰＳＴＮ（Public Switched Telephone Network：公衆電話回線網）について、呼接続の前に、発信側に聞こえる呼び出しトーンがある。

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

具体的なオプション機能としては、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=inactiveであり、
非使用オプションは、a=sendrecvであることも好ましい。

本発明の網間接続方法における他の実施形態によれば、
リクエストは、SDP(Session Description Protocol) with precondition有りの暫定応答確認リクエスト(PRACK)であり、
要求元オプションは、「SDP有り」であり、
非使用オプションは、「SDP無し」であることも好ましい。

本発明の網間接続方法における他の実施形態によれば、
リクエストは、セッション変更リクエスト(Re-INVITE)であり、
要求元オプションは、「SDP無し」であり、
非使用オプションは、「SDP有り」であることも好ましい。

本発明の網間接続方法における他の実施形態によれば、
リクエストは、セッション開始リクエスト(INVITE)であり、
要求元オプションは、「precondition使用」且つ「100rel使用」であり、
非使用オプションは、「precondition非使用」且つ「100rel非使用」であり、
第２のステップについて、ＳＩＰサーバは、要求先端末から成功レスポンス(200OK)を受信した際に、リクエストの要求元オプションに対する非使用オプションを選択し、
第３のステップを実行することなく、セッションを確立することも好ましい。

本発明の網間接続方法における他の実施形態によれば、
第２のステップについて、ＳＩＰサーバは、エラーレスポンスに対する確認リクエスト(ACK)を、要求先端末へ送信することも好ましい。

本発明の網間接続方法における他の実施形態によれば、
ＳＩＰサーバは、
第１のステップについて、要求元端末からリクエストを受信した際に、セッション更新リクエスト(UPDATE)の要求元オプションを取得し、
第３のステップについて、要求先端末から成功レスポンスを受信した際に、セッション更新リクエスト(UPDATE)の要求先オプションを取得することも好ましい。

本発明の網間接続方法における他の実施形態によれば、
ＳＩＰサーバは、
異なるＣＳＣＦ間に接続されたＡＳ(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使用、UPDATE使用
（要求先端末２２）a=inactive非使用（a=sendrecv使用）、UPDATE非使用

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

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

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

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

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

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

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

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

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

（Ｓ２１）要求先端末２２は、受信したセッション開始リクエストから「a=inactive使用」を知る。ここで、要求先端末２２は、「a=inactive非使用」であるために、失敗レスポンス（SIP:488(INVITE)）を、ＡＳ１へ返信する。

（Ｓ２２）ＡＳ１は、失敗レスポンスを受信した際に、要求先端末２２に対して、a=inactiveに対する非使用オプションの「a=sendrecv」を選択する。

（Ｓ２３）そして、ＡＳ１は、失敗レスポンスに対する確認リクエスト（SIP:ACK）を要求先端末２２へ送信する。これによって、ＡＳ１は、失敗レスポンスの受け入れを、要求先端末２２へ通知する。

（Ｓ３１）次に、ＡＳ１は、a=inactiveをa=sendrecvに変換したセッション開始リクエスト（SIP:INVITE）を、要求先端末２２へ送信する。
［SIP:INVITE］
−ＳＩＰヘッダ
Supported: 100rel,precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
−ＳＤＰ
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos optional remote sendrecv
a=sendrecv

（Ｓ３２）要求先端末２２は、受信したセッション開始リクエストに対して、自身のオプション機能の使用状態（precondition非使用、UPDATE非使用、100rel使用）に基づいて、暫定レスポンス（SIP:183(INVITE)）を返信する。
［SIP:183(INVITE)］
−ＳＩＰヘッダ
Require: 100rel
Allow: INVITE, ACK, CANCEL, BYE, PRACK
−ＳＤＰ
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=inactive非使用」であると確定する。尚、a=inactiveをa=sendrecvに変換しても、エラーレスポンスが返信される場合、別のオプション機能に差分があるとみなす。その場合、Ｓ１２へ戻って、他のオプション機能の変換を試行する。

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

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

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

（Ｓ３７）要求元端末２１は、リソース確保が完了した後、更新リクエスト（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

（Ｓ３８）ＡＳ１は、受信した更新リクエストを要求先端末２２へ転送せずに、更新成功レスポンス（SIP:200(UPDATE)）を、要求元端末２１へ返信する。要求先端末２２は「UPDATE非使用」であるために、ＡＳ１は、要求元端末２１か受信したUPDATE信号を終端し、要求先端末２２へその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

尚、UPDATEのオプション機能は、Ｓ１１について、要求元端末２１からセッション開始リクエストを受信した際に、セッション更新リクエスト(UPDATE)の要求元オプションを取得する。また、Ｓ３２について、要求先端末２２から暫定レスポンス（成功レスポンス）を受信した際に、セッション更新リクエスト(UPDATE)の要求先オプションを取得する。

図３のシーケンスによって、要求先端末２２に対するオプション機能をa=sendrecvに変換することによって、要求元端末２１におけるリソース確保の完了時に、直ぐに端末間でメディアを流すことができる。

図４は、図３と比較して、第２のステップについて失敗レスポンスではなく成功レスポンスが返信された場合のシーケンス図である。

図４によれば、要求元端末及び要求先端末のオプション機能の使用状態は、以下のように設定されているとする。
要求元端末
・a=inactive使用
・precondition使用、且つ、リソース未確保状態
・UPDATE使用
・100rel使用
要求先端末
・a=inactive使用
・precondition非使用
・UPDATE使用
・100rel非使用

図４（ａ）は、要求先端末のオプション機能を認識していない場合に実行されるシーケンス図である。

ＳＩＰにおけるpreconditionとは、要求元端末と要求先端末との間で、リソース確保状態のパラメータを、SDPを用いて相互に交換するものである。これによって、端末間で、セッション開始リクエストを送信した時にリソースを確保できていなくても、相手方のリソース確保の完了を確認することができる。

（Ｓ０）ＡＳ１は、以下のようなリスト（非使用選択オプション機能リスト）に、使用オプションに対する非使用オプションを登録しているとする。
（オプションＡ） <-> （非使用オプションａ）
precondition使用 <-> precondition非使用
100rel使用 <-> 100rel非使用
このリストは、システム運用者によって予め設定されたものであってもよい。

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

（Ｓ１２）ＡＳ１は、受信したセッション開始リクエストから、要求元端末２１のオプション機能の使用状態を記憶する。ＡＳ１は、要求先端末２２が100rel非使用であることを予め記憶している場合、図４（ａ）のＳ１３以降を実行することなく、図４（ｂ）のＳ１１から実行することができる。
また、ＡＳ１は、要求元端末２１のオプション機能の使用状態に応じて、以下の動作を決定する。
−要求元端末２１がリソース確保状態となるようprecondition処理を実行する。
−要求元端末２１がリソース確保状態となるまで、要求先端末２２へセッション開始リクエスト(INVITE)を送信しない。
−要求元端末２１とのＳＤＰネゴシエーションと、要求先端末２２とのＳＤＰネゴシエーションとを独立して管理する。

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

（Ｓ２１）要求先端末２２は、precondition非使用、且つ、100rel非使用である場合、成功レスポンス（SIP:200(INVITE)）をＡＳ１へ返信する。成功レスポンスのパラメータは、例えば以下のようなものである。
［SIP:200(INVITE)］
ＳＩＰヘッダ
Allow: INVITE, ACK, CANCEL, BYE, UPDATE
ＳＤＰ
a=inactive
ＡＳ１は、受信した成功レスポンスをそのまま、要求元端末２１へ転送する。

（Ｓ２２）ＡＳ１は、SDPを含む成功レスポンスを受信した場合、要求先端末２２のオプション機能「precondition非使用」「100rel非使用」（要求元オプションに対する非使用オプション）を記憶する。但し、100rel非使用とは、100rel非使用の場合と、100relを使用しているものの当該制御信号では非使用とする場合とがある。

（Ｓ２３）要求元端末２１は、セッションを確立したとして確認リクエスト（SIP:ACK）をＡＳ１へ送信する。
また、ＡＳ１は、受信した確認リクエストをそのまま、要求先端末２２へ転送する。

ここで、要求元端末２１は、「リソース未確保状態、且つ、a=inactive状態」であるために、通信することができない。図４では図示しないが、要求元端末２１は、リソース確保が完了したタイミングでa=sendrecvを含む更新リクエスト（SIP:Re-INVITE）を要求先端末へ送信し、セッションを疎通できる状態にする必要がある。この処理が完了するまでは、要求元端末２１と要求先端末２２とで通信することはできない。

（Ｓ３）そこで、ＡＳ１は、要求元端末２１及び要求先端末２２に対して、一度、切断シーケンスを実行し、セッションを切断する。

図４（ｂ）は、要求先端末のオプション機能を既に認識している場合に実行されるシーケンス図である。

（Ｓ１１）要求元端末２１は、改めて、同一の要求先端末２２に対して、新たなセッション開始リクエスト(INVITE)を送信する。

（Ｓ１２）ＡＳ１は、要求先端末２２のオプション機能「SDP無し」「100rel非使用」を既に認識している。そのために、ＡＳ１は、要求元端末２１との間でprecondition処理を実行するための暫定レスポンス（SIP:183(INVITE)）を、要求元端末２１へ返信する。
ＳＩＰヘッダ
Require: 100rel,precondition
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
ＳＤＰ
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
a=inactive

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

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

（Ｓ１５）要求元端末２１は、リソース確保が完了した場合、その旨を通知する更新リクエスト（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

（Ｓ１６）ＡＳ１は、受信した更新リクエスト(UPDATE)を要求先端末２２へ転送することなく、更新成功レスポンス（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

（Ｓ１７）そして、ＡＳ１は、precondition処理が完了し、要求元端末２１のリソース確保が完了した際に、セッション開始リクエスト（SIP:INVITE）を要求先端末２２へ送信する。
［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

（Ｓ２１）要求先端末２２は、「precondition非使用、且つ、100rel非使用」であるために、成功レスポンス（SIP:200(INVITE)）をＡＳ１へ返信する。
［SIP:200(INVITE)］
−ＳＩＰヘッダ
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, PRACK
−ＳＤＰ
a=sendrecv

（Ｓ２２）ＡＳ１は、受信した成功レスポンス（SIP:200(INVITE)）から、要求先端末２２のオプション機能の使用状態を記憶する。
図４（ａ）のＳ１３〜Ｓ２３を実行していた場合、ＡＳ１は、要求先端末２２に対してprecondition手順と100rel手順を回避したことで、失敗レスポンスが解消されたために、要求先端末２２が「precondition非使用、且つ、100rel非使用」であると判定する。
そして、ＡＳ１は、受信した成功レスポンス（SIP:200(INVITE)）から、ＳＤＰを削除して、要求元端末２１へ送信する。

（Ｓ２３）要求元端末２１は、SDP無しの成功レスポンス（SIP:200(INVITE)）を受信した場合、セッション確立成功と認識する。そして、要求元端末２１は、確認リクエスト（SIP:ACK）をＡＳ１へ送信する。
ＡＳ１は、受信した確認リクエスト（SIP:ACK）をそのまま、要求先端末２２へ転送する。

図４によれば、前述したように、要求元端末２１ではprecondition確立を実行してリソース確保状態となる。また、要求元端末２１と要求先端末２２との間でセッションが確立すると直ぐに、端末間でメディアを流すことができる。

＜第２の実施形態：ＳＤＰに基づくセッション開始リクエスト＞
図５は、本発明の第２の実施形態に基づくシーケンス図である。

図５によれば、要求元端末及び要求先端末のオプション機能の使用状態は、以下のようであるとする。
要求元端末
a=inactive使用
precondition使用、且つ、リソース未確保
SDP有りPRACK使用
要求先端末
a=inactive非使用
precondition非使用
SDP有りPRACK非使用

（Ｓ０）ＡＳ１は、以下のようなリスト（非使用選択オプション機能リスト）に、使用オプションに対する非使用オプションを登録しているとする。
（オプションＡ） <-> （非使用オプションａ）
SDP有り <-> SDP無し

図５によれば、要求元端末２１から要求先端末２２へセッション開始リクエスト（SIP:INVITE）が送信され、正常に、暫定レスポンス（183(INVITE)）が返信されている。その後、暫定応答確認リクエスト（SIP:PRACK）のシーケンスについて、図２の基本シーケンスを適用したものを、以下に表す。

（Ｓ１１）要求元端末２１は、リソース確保が完了した際に、その旨を通知する暫定応答確認リクエスト（SIP:PRACK）を、ＡＳ１へ送信する。
［SIP:PRACK］
−ＳＩＰヘッダ
Require: 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 mandatory remote sendrecv
a=sendrecv
（Ｓ１２）ＡＳ１は、要求元端末２１のオプション機能の使用状態（SDP有り、且つ、PRACK使用）を記憶する。
（Ｓ１３）ＡＳ１は、受信した暫定応答確認リクエスト（SIP:PRACK）を、要求先端末２２へ転送する。

（Ｓ２１）要求先端末２２は、暫定応答確認リクエスト（SIP:PRACK）に対して、SDP非使用である場合、暫定応答確認失敗レスポンス（SIP:488(PRACK)）をＡＳ１へ返信する。
（Ｓ２２）ＡＳ１は、暫定応答確認失敗レスポンスを受信した場合、要求先端末２２のオプション機能を、「SDP無しPRACK」を選択する。尚、失敗レスポンスは、特定のエラー種別（SIP Status Codeで識別）に限定してもよいし、全てのエラー種別を対象にしてもよい。

（Ｓ３１）ＡＳ１は、暫定応答確認リクエスト（SDP無しPRACK）を、要求先端末２２へ送信する。
（Ｓ３２）要求先端末２２は、暫定応答確認成功レスポンス（SIP:200(PRACK)）を、ＡＳ１へ返信する。
（Ｓ３３）ＡＳ１は、暫定応答確認成功レスポンス（SIP:200(PRACK)）によって、要求先端末２２のオプション機能の使用状態を記憶する。ここでは、ＡＳ１は、要求先端末２２に対して、SDP有りPRACKを非使用と記憶する。
（Ｓ３４）そして、ＡＳ１は、SDP Offerに対するSDP Answerを含む暫定応答確認成功レスポンス（SIP:200(PRACK)）を、要求元端末２１へ送信する。
［SIP:200(PRACK)］
−ＳＩＰヘッダ
Require: 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

＜第３の実施形態：ＳＤＰに基づくセッション変更リクエスト＞
図６は、本発明の第３の実施形態に基づくシーケンス図である。

図６によれば、要求元端末及び要求先端末におけるオプション機能の使用状態は、以下のように設定されているとする。
要求元端末： SDP無しRe-INVITEの使用
要求先端末： SDP無しRe-INVITEの非使用（SDP有り）

（Ｓ１１）要求元端末２１は、要求先端末２２との通信中セッションに対して、セッション変更リクエスト（SIP:Re-INVITE）を送信する。このセッション変更リクエストは、要求元のＣＳＣＦ群を経由して、ＡＳ１へ転送される。ここでは、セッション変更リクエストは、「SDP無し」である。
（Ｓ１２）ＡＳ１は、要求元端末のオプション機能の使用状態として、「SDP無しRe-INVITEの使用」を記憶する。
ここで、要求先端末２２のオプション機能が「SDP無しRe-INVITE非使用」に予め設定されている場合、Ｓ１３〜Ｓ２３を省略して、Ｓ２４へ移行する。そして、ＡＳ１は、以下の動作を実行することを決定する。
−要求元端末２１との間でSDP無しセッション変更リクエストの処理を完結させる。
−要求先端末２２に対するセッション変更リクエストについては、要求元端末２１との
間の処理の結果、要求先端末２２へ転送すべき情報があれば実行する。
（Ｓ１３）ＡＳ１は、セッション変更リクエスト（SDP無し）を、要求先端末２２へ転送する。

（Ｓ２１）要求先端末２２は、SDP有りのオプション機能の使用状態であるために、セッション変更リクエストに対するセッション変更失敗レスポンス（SIP:400(Re-INVITE)）を返信する。
（Ｓ２２）ＡＳ１は、セッション更新失敗レスポンスを受信した場合、要求先端末２２のオプション機能「SDP無しRe-INVITE」を非使用と選択する。尚、失敗レスポンスは、特定のエラー種別（SIP Status Codeで識別）に限定してもよいし、全てのエラー種別を対象にしてもよい。
（Ｓ２３）ＡＳ１は、要求先端末２２へ、確認リクエスト(SIP:ACK)を返信する。
（Ｓ２４）そして、ＡＳ１は、SDP有りのセッション変更成功レスポンス(SIP:200(Re-INVITE)を、要求元端末２１へ送信する。ここに含まれるSDPは、通信中状態に遷移する前のセッション確立手順などであり、ＡＳ１が認識した要求先端末２２の使用可能なオプション機能の全て含めて載せる。
（Ｓ２５）要求元端末２１は、SDP有りのセッション変更成功レスポンスを受信した場合、SDP有りの確認リクエスト（SIP:ACK）を送信する。

（Ｓ３１）ＡＳ１は、要求元端末２１のSDP有りのセッション変更リクエスト（SIP:Re-INVITE）を、要求先端末２２へ送信する。
（Ｓ３２）要求先端末２２は、セッション変更リクエストを受信した場合、SDP有りのセッション変更成功レスポンス（SIP:200(Re-INVITE)）を、ＡＳ１へ返信する。
（Ｓ３３）ＡＳ１は、要求先端末２２のオプション機能の使用状態を記憶する。ここでは、ＡＳ１は、要求先端末２２に対して、「SDP無しRe-INVITE非使用」（SDP有り）を記憶する。
（Ｓ３４）ＡＳ１は、要求先端末２２へ、確認リクエスト(SIP:ACK)を送信する。

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

図７によれば、アプリケーションサーバ１は、オプション登録部１０と、リクエスト転送部１１と、オプション選択部１２と、リクエスト再送信部１３と、メディア転送部１４とを有する。これら機能構成部は、マルチメディアネットワーク間に配置されたＳＩＰサーバに搭載されたコンピュータを機能させるプログラムを実行することによって実現される。
オプション登録部１０は、セッションにおける要求元端末の要求元オプションに対して要求先端末が非使用な場合における非使用オプションを登録したものである（前述したＳ０参照）。
リクエスト転送部１１は、要求元端末２１からリクエストを受信した際に、当該リクエストを要求先端末２２へ転送する（前述したＳ１参照）。
オプション選択部１２は、要求先端末２２からエラーレスポンスを受信した際に、リクエストの要求元オプションに対する非使用オプションを選択する（前述したＳ２参照）。
リクエスト再送信部１３は、選択された非使用オプションに基づく同一のリクエストを、再度、要求先端末２２へ送信する（前述したＳ３参照）。
メディア転送部１４は、要求元端末２１と要求先端末２２との間で、メディアを中継して転送する。

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

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

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

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

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

Claims (10)

1. 要求元端末が接続されたマルチメディアネットワークと、要求先端末が接続されたマルチメディアネットワークとの間に配置されたＳＩＰサーバにおける網間接続方法において、
   ＳＩＰサーバは、
   セッションにおける要求元端末の要求元オプションに対して要求先端末が非使用な場合における非使用オプションを登録しており、
   要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送する第１のステップと、
   要求先端末からエラーレスポンスを受信した際に、前記リクエストの要求元オプションに対する非使用オプションを選択する第２のステップと、
   選択された前記非使用オプションに基づく同一のリクエストを、再度、要求先端末へ送信する第３のステップと
   を実行することを特徴とする網間接続方法。
2. 前記リクエストは、セッション開始リクエスト(INVITE)であり、
   前記要求元オプションは、a=inactiveであり、
   前記非使用オプションは、a=sendrecvである
   ことを特徴とする請求項１に記載の網間接続方法。
3. 前記リクエストは、SDP(Session Description Protocol) with precondition有りの暫定応答確認リクエスト(PRACK)であり、
   前記要求元オプションは、「SDP有り」であり、
   前記非使用オプションは、「SDP無し」である
   ことを特徴とする請求項１に記載の網間接続方法。
4. 前記リクエストは、セッション変更リクエスト(Re-INVITE)であり、
   前記要求元オプションは、「SDP無し」であり、
   前記非使用オプションは、「SDP有り」である
   ことを特徴とする請求項１に記載の網間接続方法。
5. 前記リクエストは、セッション開始リクエスト(INVITE)であり、
   前記要求元オプションは、「preconditon使用」且つ「100rel使用」であり、
   前記非使用オプションは、「preconditon非使用」且つ「100rel非使用」であり、
   第２のステップについて、前記ＳＩＰサーバは、要求先端末から成功レスポンス(200OK)を受信した際に、前記リクエストの要求元オプションに対する非使用オプションを選択し、
   第３のステップを実行することなく、セッションを確立する
   ことを特徴とする請求項１に記載の網間接続方法。
6. 第２のステップについて、前記ＳＩＰサーバは、前記エラーレスポンスに対する確認リクエスト(ACK)を、前記要求先端末へ送信する
   ことを特徴とする請求項１から４のいずれか１項に記載の網間接続方法。
7. 前記ＳＩＰサーバは、
   第１のステップについて、要求元端末からリクエストを受信した際に、セッション更新リクエスト(UPDATE)の要求元オプションを取得し、
   第３のステップについて、要求先端末から成功レスポンスを受信した際に、セッション更新リクエスト(UPDATE)の要求先オプションを取得する
   ことを特徴とする請求項１から６のいずれか１項に記載の網間接続方法。
8. 前記ＳＩＰサーバは、
   異なるＣＳＣＦ間に接続されたＡＳ(Application Server)若しくはＩＢＣＦ(Interconnection Border Control Function)、又は、
   異なるＩＭＳ−ＡＧＷ(IP Multimedia Subsystem - Access Gateway)間に接続されたＴｒＧＷ(Translation Gateway)であり、
   前記要求元端末は、要求元のＵＡ(User Agent)又はネットワーク通信装置であり、
   前記要求先端末は、要求先のＵＡ又はネットワーク通信装置である
   ことを特徴とする請求項１から７のいずれか１項に記載の網接続方法。
9. 要求元端末が接続されたマルチメディアネットワークと、要求先端末が接続されたマルチメディアネットワークとの間に配置されたＳＩＰサーバにおいて、
   セッションにおける要求元端末の要求元オプションに対して要求先端末が非使用な場合における非使用オプションを登録したオプション登録手段と、
   要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送するリクエスト転送手段と、
   要求先端末からエラーレスポンスを受信した際に、前記リクエストの要求元オプションに対する非使用オプションを選択するオプション選択手段と、
   選択された前記非使用オプションに基づく同一のリクエストを、再度、要求先端末へ送信するリクエスト再送信手段と
   を有することを特徴とするＳＩＰサーバ。
10. 要求元端末が接続されたマルチメディアネットワークと、要求先端末が接続されたマルチメディアネットワークとの間に配置されたＳＩＰサーバに搭載されたコンピュータを機能させるプログラムにおいて、
    セッションにおける要求元端末の要求元オプションに対して要求先端末が非使用な場合における非使用オプションを登録したオプション登録手段と、
    要求元端末からリクエストを受信した際に、当該リクエストを要求先端末へ転送するリクエスト転送手段と、
    要求先端末からエラーレスポンスを受信した際に、前記リクエストの要求元オプションに対する非使用オプションを選択するオプション選択手段と、
    選択された前記非使用オプションに基づく同一のリクエストを、再度、要求先端末へ送信するリクエスト再送信手段と
    してコンピュータを機能させることを特徴とするプログラム。