JP6348875B2

JP6348875B2 - 中継装置、呼制御システム、呼制御方法、および、呼制御プログラム

Info

Publication number: JP6348875B2
Application number: JP2015102793A
Authority: JP
Inventors: 健二郎荒井
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2015-05-20
Filing date: 2015-05-20
Publication date: 2018-06-27
Anticipated expiration: 2035-05-20
Also published as: JP2016220027A

Description

本発明は、ＳＩＰ（Session Initiation Protocol）を利用した呼制御手順の技術に関し、特に、他網又は端末との境界制御を行うSBC（Session Border Control）の技術に関する。

SIP（RFC3261）を利用した通信では、音声等のメディア情報は、SIPメッセージ（以下、単に、「メッセージ」と呼ぶ場合がある）のボディ部にSDP（Session Description Protocol）の形式で記述される。発側端末と着側端末との間で、実際にその通信に利用されるメディアは、RFC3264で定義されるSDPオファー／アンサーのネゴシエーション手順により確定する。

昨今、移動体の通信手段としてLTE（Long Term Evolution）の導入が進んでおり、LTE上での高品質な音声通信（VoLTE：Voice over LTE）のサービスも開始している。VoLTEの音声通信の制御にはSIPが利用される。VoLTEのガイドラインはGSMA IR.92（「GSM」は登録商標）で規定されており、その具体的な技術仕様は非特許文献１等で規定されている。

VoLTEの技術仕様の大きな特徴の１つに、SIPの拡張機能としてRFC3312/RFC4032で規定されるSIPプリコンディション（以下、単に、「プリコンディション」と呼ぶ場合がある）がある。SIPプリコンディションとは、QoS（Quality of Service）制御（ここでは、音声等のメディアパケット用の帯域や優先クラス設定を、メディアパケットの処理を行うMGW（Media Gateway）等の装置に対して、SDP情報を基に要求・確認することを指す）機能を有するネットワークに接続する端末が、通信に関するリソース確保状況を相手側の端末と交換し、リソース確保が完了したことをSDPから判断し、メディアパケットが確実に発着端末間で疎通可能になった段階でメディアパケットの送信をお互いに開始する仕組みである。

プリコンディションに対応している発側端末が、プリコンディションに未対応の着側端末を呼び出す場合がある。この場合、発側端末が着側端末とセッションを開始する段階で、そのセッションを開始するためのリソース予約が済んでいないまま、SDPのメディアをactiveな状態（a=sendrecv/sendonly/recvonly）（稼働状態）にしてしまうと、着側端末からの通話（RTP（Real-time Transport Protocol）送信）を開始してしまう。しかし、発側端末でのリソース予約は未完了であるためRTPが発側端末まで到達しない（話頭切れ）。

なお、図８には、上記の話頭切れが生じる手順の例がシーケンスとして示されている。VoLTE端末２は、プリコンディション対応だがリソース未予約の発側端末である。着側端末３ａは、例えば、プリコンディション未対応のSIP端末である。IMS（IP Multimedia Subsystem）装置１ａは、VoLTE端末２と着側端末３ａとで送受信されるさまざまなメッセージ（リクエストまたはレスポンス）を処理する中継装置である。図８に示されているメッセージの種別は周知であるため、説明は省略する。

非特許文献１の6.1.2節では、着側端末がプリコンディション未対応の場合を考慮した手順が規定されている。具体的には、発側端末がSIPセッションを開始する段階で、そのセッションを開始するために必要なリソース予約ができていない場合、セッション開始時に送信するInitial INVITEリクエストのSDPオファーには、a=inactive（保留状態を示す）を設定するという手順である。

図９には、非特許文献１が規定する上記手順の例がシーケンスとして示されている。図９のIMS装置１ａ、VoLTE端末２、着側端末３ａはそれぞれ、図８に示すものと同じである。セッション開始時にVoLTE端末２が送信するInitial INVITEリクエストのSDPオファーには、a=inactive（保留状態を示す）が設定されている（SDP_O1:a=inactive）。本SDPオファーを受信した着側端末３ａは、RFC3264に従い、a=inactiveを設定したSDPアンサーを後続のSIPリクエスト又はレスポンスで送信することで（SDP_A1:a=inactive）、一旦非アクティブな状態（a=inactive）でSDPネゴシエーションを行う。VoLTE端末２のリソース予約が完了し（リソース予約済）、アクティブな状態（稼働状態）でSDPオファー／アンサーが行われたのち（SDP_O2:a=sendrecv,SDP_A2:a=sendrecv）、RTP（音声パケット）の送信（通話）が行われることになるため、話頭切れが発生しない。

"3GPP TS 24.229 V12.6.0 (2014-09)"、［平成27年5月7日検索］、インターネット〈URL：http://www.3gpp.org/dynareport/24229.htm〉

網の運用形態によっては、Initial INVITEに設定する最初のSDPオファーでa=inactiveを設定することを非許容とする必要がある。このような運用形態としては、例えば、INVITEリクエストに対する200 OK受信時に時間課金を開始するという運用形態がある。この運用形態は、話頭切れなどで通話できなかったにもかかわらず時間課金されてしまうという不都合を回避したい場合などに採用される。

しかし、図１０のシーケンスに示すように、Initial INVITEに設定する最初のSDPオファーでa=inactiveを設定することを非許容とするSIP網５に対して、リソース未予約のVoLTE端末２が保留状態で発信した場合（SDP_O1:a=inactive）、SIP網５から488 (Not Acceptable Here)等のエラーレスポンスが返却され呼損となってしまう。また、VoLTE端末との接続を可能とするために、SIP網のポリシを変更し、SIP網内の全てのノードとその網に収容（接続）されている端末の実装を変更する場合には、莫大なコストを要してしまう。

そこで、本発明は、上記事情に鑑みて、網の運用形態がどのような運用形態であっても、その網内のノード、および、その網に接続されている端末を改変することなく、呼制御を確実に実現することを課題とする。

前記課題を解決するために、請求項１に記載の発明は、発側網と着側網との境界に設置されている中継装置であって、前記発側網に通信可能に接続されている発側端末からのリクエストの受信、および、前記発側端末へのレスポンスの送信を行うUAS機能部と、前記着側網に通信可能に接続されている着側端末へのリクエストの送信、および、前記着側端末からのレスポンスの受信を行うUAC機能部と、前記発側端末からのリクエストに設定されているオファーの状態が保留状態である場合には前記UAS機能部は動作させるが前記UAC機能部は動作させず、稼働状態である場合には前記UAS機能部および前記UAC機能部を動作させ、呼制御を行う呼制御部と、を備える、ことを特徴とする。

また、請求項４に記載の発明は、発側網と着側網との境界に設置されている中継装置と、前記発側網に接続されている発側端末と、前記着側網に接続されている着側端末と、が通信可能に接続されている呼制御システムであって、前記中継装置は、前記発側端末からのリクエストの受信、および、前記発側端末へのレスポンスの送信を行うUAS機能部と、前記着側端末へのリクエストの送信、および、前記着側端末からのレスポンスの受信を行うUAC機能部と、前記発側端末からのリクエストに設定されているオファーに設定されている状態が保留状態である場合には前記UAS機能部は動作させるが前記UAC機能部は動作させず、稼働状態である場合には前記UAS機能部および前記UAC機能部を動作させ、呼制御を行う呼制御部と、を備える、ことを特徴とする。

また、請求項５に記載の発明は、発側網と着側網との境界に設置されている中継装置における呼制御方法であって、前記発側網に通信可能に接続されている発側端末からのリクエストに設定されているオファーの状態が保留状態である場合には、前記発側端末からのリクエストの受信、および、前記発側端末へのレスポンスの送信は行うが、前記着側網に通信可能に接続されている着側端末へのリクエストの送信、および、前記着側端末からのレスポンスの受信は行わないUASステップと、前記発側端末からのリクエストのオファーに設定されている状態が稼働状態である場合には、前記発側端末からのリクエストの受信、前記着側端末へのリクエストの送信、前記着側端末からのレスポンスの受信、および、前記発側端末へのレスポンスの送信を行うUAS/UACステップと、を実行する、ことを特徴とする。

また、請求項６に記載の発明は、発側網と着側網との境界に設置されている中継装置としてコンピュータを、前記発側網に通信可能に接続されている発側端末からのリクエストの受信、および、前記発側端末へのレスポンスの送信を行うUAS機能手段、前記着側網に通信可能に接続されている着側端末へのリクエストの送信、および、前記着側端末からのレスポンスの受信を行うUAC機能手段、前記発側端末からのリクエストに設定されているオファーの状態が保留状態である場合には前記UAS機能手段を動作させるが前記UAC機能部は動作させず、稼働状態である場合には前記UAS機能手段および前記UAC機能手段を動作させ、呼制御を行う呼制御手段、として機能させるための呼制御プログラムである。

請求項１，４，５，６に記載の発明によれば、中継装置の呼制御部は、発側端末からのリクエストのオファーに設定されている状態が保留状態である場合には、UAC機能部を動作させず、発側端末からのリクエストに対してレスポンスを返して終端させる。これにより、発側端末のリソースが未予約であって着側端末を呼び出すことができないという呼損を回避することができる。また、発側端末からのリクエストのオファーに設定されている状態が稼働状態であるときにUAC機能部を動作させることで、発側端末のリソースが予約済になってから着側端末を呼び出すという通常の呼制御を実現することができる。このとき、網のポリシを変更したり、端末を改変したりする必要はない。
したがって、網の運用形態がどのような運用形態であっても、その網内のノード、および、その網に接続されている端末を改変することなく、呼制御を確実に実現することができる。

また、請求項２に記載の発明は、請求項１に記載の中継装置において、前記UAS機能部は、前記保留状態を示す前記オファーが設定された前記リクエストに対して、アンサーが設定されたレスポンスを前記発側端末に送信し、前記発側網と前記中継装置との間にダイアログを生成する、ことを特徴とする。

請求項２に記載の発明によれば、UAS機能部が発側網と中継装置との間にダイアログを生成することで、一度受信した、保留状態を示すオファーを破棄せずに済ませることができる。よって、後になって、リソース予約済となった発側端末から同じオファーを再度受信する必要がないため、着側端末とのセッションに開始に必要な処理手順を簡略化することができる。

また、請求項３に記載の発明は、請求項１または請求項２に記載の中継装置において、前記発側網は、VoLTE網であり、前記発側端末は、VoLTE端末であり、前記着側網は、SIP網であり、前記着側端末は、プリコンディション未対応の端末である、ことを特徴とする。

請求項３に記載の発明によれば、VoLTE端末のリソースが予約済になってからプリコンディション未対応の着側端末を呼び出すという呼制御を実現することができる。

本発明によれば、網の運用形態がどのような運用形態であっても、その網内のノード、および、その網に接続されている端末を改変することなく、呼制御を確実に実現することができる。

本実施形態の呼処理システムの全体構成図である。本発明の特徴の説明図である。本実施形態の呼処理システムにて送受信されるメッセージ（SIPリクエストおよびSIPレスポンス）のメッセージ種別の一覧表である。パターン１のSDP設定に基づく処理例１を示すシーケンス図である。パターン２のSDP設定に基づく処理例２を示すシーケンス図である。パターン３のSDP設定に基づく処理例３を示すシーケンス図である。呼処理プログラムを実行するコンピュータを示す図である。従来技術によって生じる話頭切れを示すシーケンス図である。非特許文献１の技術による、話頭切れの防止を示すシーケンス図である。 VoLTE端末と、「a=inactive」設定非許容となるSIP網との接続を示すシーケンス図である。

本発明を実施するための形態（実施形態）について、図面を参照しながら詳細に説明する。
図１に示すように、本実施形態の呼処理システムは、ＳＢＣ１（中継装置）と、VoLTE端末２（発側端末）と、着側端末３とを備える。本実施形態では、VoLTE端末２から着側端末３への発呼を行う場合について説明する。図１のVoLTE網４は発側網となり、SIP網５は着側網となる。

ＳＢＣ１は、VoLTE網４およびSIP網５の境界に配置されるゲートウェイ装置である。ＳＢＣ１は、UAS機能部１１と、UAC機能部１２と、呼制御部１３といった機能部を備える。

UAS機能部１１は、ＳＢＣ１をUAS（User Agent Server）として機能させる部位である。具体的には、UAS機能部１１は、VoLTE端末２からのSIPリクエスト（リクエスト）の受信、および、VoLTE端末２へのSIPレスポンス（レスポンス）の送信を行う。

UAC機能部１２は、ＳＢＣ１をUAC（User Agent Client）として機能させる部位である。具体的には、UAC機能部１２は、着側端末３へのSIPリクエストの送信、および、着側端末３からのSIPレスポンスの受信を行う。

呼制御部１３は、VoLTE端末２と着側端末３との通話に必要な呼制御を行う。

VoLTE端末２は、LTE上での音声通信を行う端末である。VoLTE端末２は、SIPプリコンディションに対応している。

着側端末３は、SIP上での音声通信を行う端末である。本実施形態では、VoLTE端末２は、SIPプリコンディションに未対応であるとする。

VoLTE網４は、ＳＢＣ１とVoLTE端末２とを通信可能に接続する網である。VoLTE網４には、ＳＢＣ１とVoLTE端末２との間で転送されるSIPリクエストおよびSIPレスポンスを転送するノード（例：ブリッジ、ルータ。図示せず。）が配置されている。また、VoLTE網４に対して、VoLTE網４のノードのトラフィック監視をしたり、VoLTE網４のポリシを変更したりするための管理装置（図示せず）が通信可能に接続されている。

SIP網５は、ＳＢＣ１と着側端末３とを通信可能に接続する網である。SIP網５には、ＳＢＣ１と着側端末３との間で転送されるSIPリクエストおよびSIPレスポンスを転送するノード（例：ブリッジ、ルータ。図示せず。）が配置されている。また、SIP網５に対して、SIP網５のノードのトラフィック監視をしたり、SIP網５のポリシを変更したりするための管理装置（図示せず）が通信可能に接続されている。

本実施形態のＳＢＣ１は、UAS機能部１１およびUAC機能部１２によって、SIPリクエスト受信およびSIPレスポンス送信を担うUASと、SIPリクエスト送信およびSIPレスポンス受信を担うUACとの両方の機能を備えるB2BUA（Back-to-back User Agent）として動作する。

図２に示すように、B2BUA機能を実装したＳＢＣ１は、VoLTE端末２から受信するSIPリクエストのSDPオファーの方向属性がa=inactiveであるとき、つまり、SDPオファーに設定されている状態が保留状態であるときは、UASとしてのみ動作し、VoLTE端末２とのSDPネゴシエーションを実施する（ステップＳ１０１，Ｓ１０２）。よって、SDPオファーに設定されている状態が保留状態であるときは、ＳＢＣ１は、後位である着側端末３とのセッションを確立するための処理を行わない。

その後、ＳＢＣ１は、発側からのSDPオファーの方向属性がa=inactive以外、つまりa=sendrecv/sendonly/recvonlyになった段階でUACとしての動作を開始する。つまり、ＳＢＣ１は、SDPオファーに設定されている状態が稼働状態であるときは、UACとしても動作し、着側端末３とのSDPネゴシエーションを実施する（ステップＳ１０３〜Ｓ１０６）。よって、SDPオファーに設定されている状態が稼働状態になった段階で、ＳＢＣ１は、後位である着側端末３とのセッションを確立するための処理を開始する。

図２に示したB2BUA機能を実装したＳＢＣ１の処理について説明する。ＳＢＣ１が実行する処理は、呼制御部１３が担当する。本実施形態では、ＳＢＣ１の処理としてパターン１〜３までの３種類のSDP設定がなされた具体例を取り上げる。また、本実施形態の呼処理システムにて送受信されるメッセージ（SIPリクエストおよびSIPレスポンス）のメッセージ種別の一覧を図３に示す。

例えば、図３のパターン１の処理において、「発側」（VoLTE端末２）から「SBC」（ＳＢＣ１）に送信されるInitial-INVITEのメッセージ（SIPリクエスト）は、「オファー（１）」と呼ぶ。また、パターン１の処理において、着側（着側端末３）からＳＢＣ１に送信される200 OK（INVITE）のメッセージは、「アンサー（２）」と呼ぶ。なお、図３のメッセージ種別の意味は周知であるため、その説明は省略する。

（パターン１のSDP設定に基づく処理例１）
本パターンは、ＳＢＣ１が、a=inactiveを含むSDPアンサーを設定した183 (Session Progress)を発側に送信し、その後発側からアーリーダイアログ上でactive状態（稼働状態）になったSDPオファーを設定したUPDATEリクエストを受信する場合の例である。シーケンス図を図４に示す。
なお、SIP網５は、最初のＳＤＰオファーに対するa=inactiveの設定を非許容とする（後記のパターン２，３についても同様）。

ＳＢＣ１は、Initial-INVITE（ToヘッダのtagがないINVITEリクエスト）でa=inactiveが設定されたSDPオファー（SDP_O1）（オファー（１））を、VoLTE網４を介してリソース未予約のVoLTE端末２から受信する（ステップＳ１，Ｓ３）。その際、VoLTE網４からVoLTE端末２に対して100 Tryingが送信される（ステップＳ２）。

ＳＢＣ１は、VoLTE網４に対して100 Trying送信（ステップＳ４）後、直ちに183 (Session Progress) レスポンスにa=inactiveの方向属性を設定したSDPアンサー（SDP_A1）（アンサー（１））を設定してVoLTE端末２に送信する（ステップＳ５）。

UAS機能部１１は、送信される183 (Session Progress) レスポンスのto-tagを生成することで、ＳＢＣ１とVoLTE網４との間にDialog-A（VoLTE端末２から受信したCall-IDヘッダ・from-tagの値、および、VoLTE端末２に送信したTo-tagの値で構成）を生成する（ステップＳ６）。UAS機能部１１が、ＳＢＣ１とVoLTE網４との間にDialog-Aを生成することで、一度受信した、a=inactiveが設定されたSDPオファー（SDP_O1）を破棄せずに済ませることができる。よって、後になって、リソース予約済となったVoLTE端末２からSDPオファー（SDP_O1）を再度受信する必要がないため、着側端末３とのセッションに開始に必要な処理手順を簡略化することができる。

その後、ＳＢＣ１は、183 (Session Progress) レスポンスの到達確認として、VoLTE端末２からのPRACKリクエストの受信処理（ステップＳ７）と、VoLTE端末２への、当該リクエストに対する200 OKレスポンスの送信処理（ステップＳ８）を行う。
なお、説明の便宜上、「200 OK」を、単に、「200」と表記する場合がある。

VoLTE端末２にてリソースの予約が完了した後（リソース予約済）、ＳＢＣ１は、Dialog-A上でa=inactive以外の方向属性が設定されたSDPオファー(SDP_O2)（オファー（２））が設定されたUPDATEリクエストを受信する（ステップＳ９）。すると、ＳＢＣ１は、着側端末３とのセッションを開始するため、UPDATEリクエストに設定されたSDPを基に生成されるSDP（SDP_O2）（オファー（２））を設定したInitial INVITEリクエストを、SIP網５を介して着側端末３に送信する（ステップＳ１０，Ｓ１２）。その際、SIP網５からＳＢＣ１に対して100 Tryingが送信される（ステップＳ１１）。

着側端末３は、SIP網５に対して100 Trying送信（ステップＳ１３）後、ＳＢＣ１に対して直ちに180 Ringingを送信する（ステップＳ１４）。180 Ringing受信時点で、ＳＢＣ１と着側端末３との間にDialog-B（送信したCall-IDヘッダ・from-tagの値、および、受信したto-tagの値で構成）が生成される（ステップＳ１５）。その後、ＳＢＣ１は、180 Ringingの到達確認として、着側端末３へのPRACKリクエストの送信処理（ステップＳ１６）と、着側端末３からの、当該リクエストに対する200 OKレスポンスの受信処理（ステップＳ１７）を行う。

その後、ＳＢＣ１は、着側端末３から200 OK（INVITE）でSDPアンサー（SDP_A2）（アンサー（２））を受信する（ステップＳ１８）。すると、ＳＢＣ１は、当該SDPアンサーを基に生成したSDP（SDP_A2）（アンサー（２））を、以前（ステップＳ９）VoLTE端末２から受信したUPDATEリクエストに対する200 OKレスポンスに設定して、VoLTE端末２に送信する（ステップＳ１９）。

ＳＢＣ１は、UPDATEリクエストに対する200 OKレスポンスの送信直後に、180 Ringingレスポンスと、Initial INVITEリクエストに対する200 OKレスポンスをDialog-A上でVoLTE端末２に送信する（ステップＳ２０，Ｓ２１）。その後、ＳＢＣ１は、VoLTE端末２から受信するACKを着側端末３に対して疎通させる（ステップＳ２２）ことで、VoLTE端末２と着側端末３とは、通話を開始する。

（パターン２のSDP設定に基づく処理例２）
本パターンは、ＳＢＣ１が、a=inactiveを含むSDPアンサーを設定した183 (Session Progress)を発側に送信し、その後発側からアーリーダイアログ上でactive状態（稼働状態）になったSDPオファーを設定したPRACKリクエストを受信する場合の例である。シーケンス図を図５に示す。

ＳＢＣ１は、Initial INVITE（ToヘッダのtagがないINVITEリクエスト）でa=inactiveが設定されたSDPオファー（SDP_O1）（オファー（１））を、VoLTE網４を介してリソース未予約のVoLTE端末２から受信する（ステップＳ３１，Ｓ３３）。その際、VoLTE網４からVoLTE端末２に対して100 Tryingが送信される（ステップＳ３２）。

ＳＢＣ１は、VoLTE網４に対して100 Trying送信（ステップＳ３４）後、直ちに183 (Session Progress) レスポンスにa=inactiveの方向属性を設定したSDPアンサー（SDP_A1）（アンサー（１））を設定してVoLTE端末２に送信する（ステップＳ３５）。

UAS機能部１１は、送信される183 (Session Progress) レスポンスのto-tagを生成することで、Dialog-A（VoLTE端末２から受信したCall-IDヘッダ・from-tagの値、および、VoLTE端末２に送信したTo-tagの値で構成）を生成する（ステップＳ３６）。UAS機能部１１が、ＳＢＣ１とVoLTE網４との間にDialog-Aを生成することで、一度受信した、a=inactiveが設定されたSDPオファー（SDP_O1）を破棄せずに済ませることができる。よって、後になって、リソース予約済となったVoLTE端末２からSDPオファー（SDP_O1）を再度受信する必要がないため、着側端末３とのセッションに開始に必要な処理手順を簡略化することができる。

VoLTE端末２にてリソースの予約が完了した後（リソース予約済）、ＳＢＣ１は、Dialog-A上でa=inactive以外の方向属性が設定されたSDPオファー(SDP_O2)（オファー（２））が設定されたPRACKリクエストを受信する（ステップＳ３７）。すると、ＳＢＣ１は、着側端末３とのセッションを開始するため、PRACKリクエストに設定されたSDPを基に生成されるSDP（SDP_O2）を設定したInitial INVITEリクエストを着側端末３に送信する（ステップＳ３８，Ｓ４０）。その際、SIP網５からＳＢＣ１に対して100 Tryingが送信される（ステップＳ３９）。

着側端末３は、SIP網５に対して100 Trying送信（ステップＳ４１）後、ＳＢＣ１に対して直ちに180 Ringingを送信する（ステップＳ４２）。180 Ringing受信時点で、ＳＢＣ１と着側端末３との間にDialog-B（送信したCall-IDヘッダ・from-tagの値、および、受信したto-tagの値で構成）が生成される（ステップＳ４３）。その後、VoLTE端末２は、180 Ringingの到達確認として、着側端末３へのPRACKリクエストの送信処理（ステップＳ４４）と、着側端末３からの、当該リクエストに対する200 OKレスポンスの受信処理（ステップＳ４５）を行う。

その後、ＳＢＣ１は、着側端末３から200 OK（INVITE）でSDPアンサー（SDP_A2）（アンサー（２））を受信する（ステップＳ４６）。すると、ＳＢＣ１は、当該SDPアンサーを基に生成したSDP（SDP_A2）（アンサー（２））を、以前（ステップＳ３７）VoLTE端末２から受信したPRACKリクエストに対する200 OKレスポンスに設定して、VoLTE端末２に送信する（ステップＳ４７）。

ＳＢＣ１は、PRACKリクエストに対する200 OKレスポンスの送信直後に、180 Ringingレスポンスと、Initial INVITEリクエストに対する200 OKレスポンスをDialog-A上でVoLTE端末２に送信する（ステップＳ４８，Ｓ４９）。その後、ＳＢＣ１は、VoLTE端末２から受信するACKを着側端末３に対して疎通させる（ステップＳ５０）ことで、VoLTE端末２と着側端末３とは、通話を開始する。

（パターン３のSDP設定に基づく処理例３）
本パターンは、ＳＢＣ１が、Initial-INVITEリクエストに対して、a=inactiveを含むSDPアンサーを設定した200 (OK)レスポンスを発側に送信し、その後発側からコンファームダイアログ上でactive状態（稼働状態）になったSDPオファーを設定したUPDATEリクエストを受信する場合の例である。シーケンス図を図６に示す。

ＳＢＣ１は、Initial INVITE（ToヘッダのtagがないINVITEリクエスト）でa=inactiveが設定されたSDPオファー（SDP_O1）（オファー（１））を、VoLTE網４を介してリソース未予約のVoLTE端末２から受信する（ステップＳ６１，Ｓ６３）。その際、VoLTE網４からVoLTE端末２に対して100 Tryingが送信される（ステップＳ６２）。

ＳＢＣ１は、VoLTE網４に対して100 Tryingを送信（ステップＳ６４）する。その後、UAS機能部１１は、直ちに180 Ringing、および、Initial-INVITEリクエストに対して、a=inactiveの方向属性を設定したSDPアンサー（SDP_A1）（アンサー（１））を含む200 OKレスポンスをVoLTE端末２に送信する（ステップＳ６５，Ｓ６６）。この段階でＳＢＣ１とVoLTE端末２との間でDialog-A（パターン１，２のDialog-Aと同様に構成）が確立される（ステップＳ６７）。ＳＢＣ１は、VoLTE端末２からACKを受信する（ステップＳ６８）。UAS機能部１１が、ＳＢＣ１とVoLTE網４との間にDialog-Aを確立することで、一度受信した、a=inactiveが設定されたSDPオファー（SDP_O1）を破棄せずに済ませることができる。よって、後になって、リソース予約済となったVoLTE端末２からSDPオファー（SDP_O1）を再度受信する必要がないため、着側端末３とのセッションに開始に必要な処理手順を簡略化することができる。

VoLTE端末２にてリソースの予約が完了した後（リソース予約済）、ＳＢＣ１は、Dialog-A上でa=inactive以外の方向属性が設定されたSDPオファー(SDP_O2)（オファー（２））が設定されたUPDATEリクエストを受信する（ステップＳ６９）。すると、ＳＢＣ１は、着側端末３とのセッションを開始するため、UPDATEリクエストに設定されたSDPを基に生成されるSDP（SDP_O2）（オファー（２））を設定したInitial INVITEリクエストを、SIP網５を介して着側端末３に送信する（ステップＳ７０，Ｓ７２）。その際、SIP網５からＳＢＣ１に対して100 Tryingが送信される（ステップＳ７１）。

着側端末３は、SIP網５に対して100 Trying送信（ステップＳ７３）後、ＳＢＣ１に対して直ちに180 Ringingを送信する（ステップＳ７４）。180 Ringing受信時点で、ＳＢＣ１と着側端末３との間にDialog-B（送信したCall-IDヘッダ・from-tagの値、および、受信したto-tagの値で構成）が生成される（ステップＳ７５）。その後、ＳＢＣ１は、180 Ringingの到達確認として、着側端末３へのPRACKリクエストの送信処理（ステップＳ７６）と、着側端末３からの、当該リクエストに対する200 OKレスポンスの受信処理（ステップＳ７７）を行う。

その後、ＳＢＣ１は、着側端末３から200 OK（INVITE）でSDPアンサー（SDP_A2）（アンサー（２））を受信する（ステップＳ７８）。すると、ＳＢＣ１は、着側端末３にACKを送信し（ステップＳ７９）、当該SDPアンサーを基に生成したSDP（SDP_A2）を、以前（ステップＳ６９）VoLTE端末２から受信したUPDATEリクエストに対する200 OKレスポンスに設定して送信する（ステップＳ８０）ことで、VoLTE端末２と着側端末３とは、通話を開始する。

本実施形態によれば、ＳＢＣ１の呼制御部１３は、VoLTE端末２からのリクエストのオファーに設定されている状態が保留状態（a=inactive）である場合には、UAC機能部１２を動作させず、VoLTE端末２からのリクエストに対してレスポンスを返して終端させる。これにより、VoLTE端末２のリソースが未予約であって着側端末３を呼び出すことができないという呼損を回避することができる。また、VoLTE端末２からのリクエストのオファーに設定されている状態が稼働状態（a=sendrecv/sendonly/recvonly）であるときにUAC機能部１２を動作させることで、VoLTE端末２のリソースが予約済になってから着側端末３を呼び出すという通常の呼制御を実現することができる。このとき、網のポリシを変更したり、端末を改変したりする必要はない。
したがって、網の運用形態がどのような運用形態であっても、その網内のノード、および、その網に接続されている端末を改変することなく、呼制御を確実に実現することができる。

（プログラム）
また、上記実施形態に係る中継装置が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、中継装置と同様の機能を実現する呼制御プログラムを実行するコンピュータの一例を説明する。

図７は、呼制御プログラムを実行するコンピュータを示す図である。図７に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ（Random Access Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。

ここで、図７に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。

また、呼制御プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、ハードディスクドライブ１０９０に記憶される。具体的には、上記実施形態で説明した呼制御プログラムが実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。

また、呼制御プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。

なお、呼制御プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、呼制御プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

（その他）
本実施形態では、「a=inactive」が設定された最初のSDPオファーを非許容とするSIP網５とVoLTE網４を相互接続する場合のSIP終端手順として、SIP網５とVoLTE網４の間にＳＢＣ１を設置し、ＳＢＣ１で終端する手順について説明したが、手順自体の配備はＳＢＣに限定しなくともよい。

本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１ＳＢＣ（中継装置）
２ VoLTE端末（発側端末）
３着側端末
４ VoLTE網（発側網）
５ SIP網（着側網）
１１ UAS機能部
１２ UAC機能部
１３呼制御部

Claims

発側網と着側網との境界に設置されている中継装置であって、
前記発側網に通信可能に接続されている発側端末からのリクエストの受信、および、前記発側端末へのレスポンスの送信を行うUAS機能部と、
前記着側網に通信可能に接続されている着側端末へのリクエストの送信、および、前記着側端末からのレスポンスの受信を行うUAC機能部と、
前記発側端末からのリクエストに設定されているオファーの状態が保留状態である場合には前記UAS機能部は動作させるが前記UAC機能部は動作させず、稼働状態である場合には前記UAS機能部および前記UAC機能部を動作させ、呼制御を行う呼制御部と、を備える、
ことを特徴とする中継装置。
前記UAS機能部は、前記保留状態を示す前記オファーが設定された前記リクエストに対して、アンサーが設定されたレスポンスを前記発側端末に送信し、前記発側網と前記中継装置との間にダイアログを生成する、
ことを特徴とする請求項１に記載の中継装置。
前記発側網は、VoLTE網であり、
前記発側端末は、VoLTE端末であり、
前記着側網は、SIP網であり、
前記着側端末は、プリコンディション未対応の端末である、
ことを特徴とする請求項１または請求項２に記載の中継装置。
発側網と着側網との境界に設置されている中継装置と、前記発側網に接続されている発側端末と、前記着側網に接続されている着側端末と、が通信可能に接続されている呼制御システムであって、
前記中継装置は、
前記発側端末からのリクエストの受信、および、前記発側端末へのレスポンスの送信を行うUAS機能部と、
前記着側端末へのリクエストの送信、および、前記着側端末からのレスポンスの受信を行うUAC機能部と、
前記発側端末からのリクエストに設定されているオファーの状態が保留状態である場合には前記UAS機能部は動作させるが前記UAC機能部は動作させず、稼働状態である場合には前記UAS機能部および前記UAC機能部を動作させ、呼制御を行う呼制御部と、を備える、
ことを特徴とする呼制御システム。
発側網と着側網との境界に設置されている中継装置における呼制御方法であって、
前記発側網に通信可能に接続されている発側端末からのリクエストに設定されているオファーの状態が保留状態である場合には、前記発側端末からのリクエストの受信、および、前記発側端末へのレスポンスの送信は行うが、前記着側網に通信可能に接続されている着側端末へのリクエストの送信、および、前記着側端末からのレスポンスの受信は行わないUASステップと、
前記発側端末からのリクエストのオファーに設定されている状態が稼働状態である場合には、前記発側端末からのリクエストの受信、前記着側端末へのリクエストの送信、前記着側端末からのレスポンスの受信、および、前記発側端末へのレスポンスの送信を行うUAS/UACステップと、を実行する、
ことを特徴とする呼制御方法。
発側網と着側網との境界に設置されている中継装置としてコンピュータを、
前記発側網に通信可能に接続されている発側端末からのリクエストの受信、および、前記発側端末へのレスポンスの送信を行うUAS機能手段、
前記着側網に通信可能に接続されている着側端末へのリクエストの送信、および、前記着側端末からのレスポンスの受信を行うUAC機能手段、
前記発側端末からのリクエストに設定されているオファーの状態が保留状態である場合には前記UAS機能手段を動作させるが前記UAC機能部は動作させず、稼働状態である場合には前記UAS機能手段および前記UAC機能手段を動作させ、呼制御を行う呼制御手段、
として機能させるための呼制御プログラム。