JP5017425B2 - 呼処理方法及び呼処理サーバ - Google Patents

呼処理方法及び呼処理サーバ Download PDF

Info

Publication number
JP5017425B2
JP5017425B2 JP2010140638A JP2010140638A JP5017425B2 JP 5017425 B2 JP5017425 B2 JP 5017425B2 JP 2010140638 A JP2010140638 A JP 2010140638A JP 2010140638 A JP2010140638 A JP 2010140638A JP 5017425 B2 JP5017425 B2 JP 5017425B2
Authority
JP
Japan
Prior art keywords
request
bandwidth
call processing
response
media gateway
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010140638A
Other languages
English (en)
Other versions
JP2012005045A (ja
Inventor
崇 歌原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2010140638A priority Critical patent/JP5017425B2/ja
Publication of JP2012005045A publication Critical patent/JP2012005045A/ja
Application granted granted Critical
Publication of JP5017425B2 publication Critical patent/JP5017425B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Telephonic Communication Services (AREA)

Description

本発明は、SIP信号路の帯域制御要求に係る呼を処理する技術に関する。
〔SIP通信ネットワークについて〕
最初に、SIPを用いて呼制御を行うSIP通信ネットワークの全体構成及び全体動作について説明する。図5は、SIP通信ネットワークのシステム構成を概略的に示す図である。このSIP通信ネットワークは、ネットワークの加入者が利用する端末5と、端末5から送信された呼接続要求等の呼を制御する呼処理サーバ1と、呼処理サーバ1の指示に従って転送網内外のターミネーション(Termination)を結びつけるメディアゲートウェイ(MG:Media Gateway)3と、端末5と呼処理サーバ1とメディアゲートウェイ3との間をそれぞれ通信可能に物理的に接続するルータRT,スイッチSW,ホームゲートウェイHGW等のネットワーク機器7とで構成されている。
所望する相手に対して音声通話や動画通信を開始する場合、端末5から相手先の端末(不図示)に対してINVITE等の呼接続要求のSIP信号が送信される。詳細には、端末5aからのSIP信号が呼処理サーバ1に送信され、隣接接続された他の呼処理サーバ1aや、その先の呼処理サーバ1bを経由して、そのSIP信号に基づく呼接続要求が相手先の端末に送信される。
そして、両者の端末間(正確には、呼処理サーバ間や、呼処理サーバと端末との間等)でSDP(Session Description Protocol)の内容に基づいてSIPネゴシエーションが行われ、そのネゴシエーション結果がOKである場合に、SIPやメディア(後述)の制御に利用されるSIPセッションが両者の端末間で確立する。
その後、音声通信や動画通信等のメディアのためのセッション情報が決定され、メディアの送受に利用されるメディアセッションが確立した後に、端末間で音声通信や動画通信が可能となる。
なお、図5では、装置間又は機器間の物理的な接続状態,SIPのパケットやメディアのトラフィックが実際に流れる通信経路を実線で示し、SIP信号の論理的な流れを破線で示している。
〔呼処理サーバについて〕
次に、SIP通信ネットワークを構成する装置のうち、呼処理サーバ1について詳細に説明する。呼処理サーバ1は、端末5から送信された呼接続要求等の呼を処理する呼処理部(CSCF:Call Session Control Function)11と、SIP通信ネットワークを構成している装置間又は機器間の通信経路(具体的には、メディアゲートウェイとルータとの間や、ルータとスイッチとの間等の各ノード間のリンク又はパス)のリソースを管理するリソース管理部(RACS:Resource and Admission Control Subsystem)12とで構成されている。なお、リソース管理部12は様々な機能部により構成されているが、特に、リソース管理機能部(A−RACF:Resource and Admission Control Function)と、ポリシー設定機能部(SPDF:Service Policy Decision Function)とで構成される機能部は、呼処理部11からの要求に基づいてメディアゲートウェイ3を制御することから、メディアゲートウェイコントローラ(MGC:Media Gateway Controller)121と呼ばれている。
リソース管理部12は、図6に示すように、SIP通信ネットワークの物理構成を仮想パスとして予めメモリ等に記憶管理している。仮想パスは管理対象に応じて複数生成されており、メディアゲートウェイ3から端末5の存在する方向に向かって、MG仮想パス、L2SW仮想パス(配信サービス用)、L2SW仮想パス(VLAN用)、PON仮想パス、アクセスライン仮想パス等と称呼されている。主な管理情報は各仮想パスの識別子と上限帯域及び使用帯域であり、各仮想パス毎に、ノード間のリンク帯域(上り・下りがある場合には、方路毎のリンク帯域)の上限、ノード内のボトルネック情報(例えば、ノードの転送処理能力等)、サービス種別上で制限される帯域(例えば、配信事業者間での契約帯域やサーバの配信能力帯域等)等が設定管理されている。特に、アクセスライン仮想パスの場合には、加入者の端末を収容していることから、加入者の契約上限帯域や、享受するサービスの上限帯域が記憶管理されている。
更に、リソース管理部12は、これら仮想パスに関する情報以外にも、加入者情報(例えば、契約する付加サービス情報や加入者優先度等)や、上り及び下りの方路毎にSIP信号路情報(SIPネゴシエーションの結果がOKである場合にメディアゲートウェイ3に設定されたSIP信号用のSIPポート情報)等を記憶管理している。
端末間の通信はSIPネゴシエーションによって開始される。まず、リソース管理部12は、端末5からの新たな呼接続要求に基づいて呼処理部11から通信経路の新規確立要求のSIP信号が送信された場合に、そのSIP信号をメディアゲートウェイ3で通過させるか否かを、加入者情報の有無、SIPポート情報の有無、メディアゲートウェイ3に設定されているステータス状態(INS(InService)/OUS(OutOfService))に基づいて決定する。
そして、SIPネゴシエーションの際に決定されるSDPの一部又は全部のメディア情報に従って、端末間の通信に使用するメディア(例えば、図6に示すようなメディア2(音声コーデック種別G711、双方向通信、帯域量が64Kのメディア))を決定する。なお、SDPのメディア情報には、音声や動画等の各種のメディア通信に必要とされる要求帯域や転送品質クラス等の情報が記載されている。
その後、現在の使用帯域に積上又は積下を行い、仮想パス(上り)の契約上限帯域やサービス提供上限帯域に基づいて、例えば図6の矢印の順番で、決定されたメディア2のメディア帯域が利用可能かどうかの受付判定を順次行う。なお、帯域の積上又は積下とは、リソース管理部12が管理している全ての仮想パスから端末間の経路を特定した後に、該当する1以上の仮想パスに対して、通話開始時は要求帯域を加算し、通話終了時は加算されている帯域を減算することを意味している。
そして、経路上のいずれかの仮想パスで帯域の利用が不可能と判断された場合には、受付判定をNGとし、呼処理サーバ1からSIPネゴシエーションを終了する。
一方、全ての仮想パスで帯域の利用が可能であり、受付判定がOKである場合には、SDPで決定したメディア情報に基づいて平均レート値、バースト値を算出してメディアゲートウェイ3に設定すると共に、端末同士を結びつけるターミネーションをメディアゲートウェイ3に生成する。そして、SIPネゴシエーションの結果毎に、図5に示したようなセッション情報(メディア種別、要求帯域、方向属性を有するメディア情報を含む)が、リソース管理部12及びメディアゲートウェイ3にそれぞれ設定されることになる。なお、これら互いのセッション情報は、設定内容が一致するように適時管理されている。
その後、リソース管理部12は、メディアゲートウェイ3に対してピンホール制御及びポリシー制御を行う(図5に示す一点鎖線)。ここでいうピンホール制御とは、メディアゲートウェイ3に対して、端末間や、端末と呼処理サーバ1との間で音声通信や動画通信等のメディアの転送に用いられるメディアポートの設定等を実際に行う制御を意味する。なお、ピンホール制御するタイミングとしては、INI−INVITEでの帯域予約時、200OKでの帯域確保時、BYEでの帯域解放時等であり、このような制御にはmegacoプロトコルが用いられる(megaco制御)。帯域の予約要求・確保要求・変更要求の受付時には、各要求と要求内のメディア情報とを記録する。一方、帯域の削除要求の受付時には、受付済の要求情報と各メディア情報をメモリ等から削除する。
また、ポリシー制御においては、発ユーザ種別や着ユーザ種別、SDP情報内のプライオリティや加入者情報の優先度を識別して、SIP通信ネットワークに輻輳が発生した時に呼の優先度を識別してパケットの通信が規制される。
以上により、リソース管理部12は、SIP通信ネットワークに流入出するパケットの制御を行っている。なお、このような従来のリソース管理部12については、特許文献1に開示されている。
〔メディアゲートウェイについて〕
一方、メディアゲートウェイ3は、リソース管理部12からの指示に従って、SIPポートを設定し、転送網内外を通信可能に結び付けるターミネーションを生成し、端末間等のメディア通信に必要なメディアポートを設定する。なお、メディアゲートウェイ3は、通常、C−BGF(Core Border Gateway Function)、I−BGF(Interconnection Border Gateway Function)、RCEF(Resource Control Enforcement Function)と呼ばれる機能部で構成されている。
〔前提技術について〕
これまで、SIP通信に関する従来のネットワーク構成や動作に関する概要を説明したが、ここで、本発明に対する直接的な前提技術について説明する。
リソース管理部12は、SIPネゴシエーションの前に、前述とは異なる内容のピンホール制御及びポリシング制御を行っている。ここでのピンホール制御とは、SIPポートをメディアゲートウェイ3に設定し、SIP信号が通過するSIP信号路を疎通可能な状態にする処理である。このSIP信号路についても、メディア情報と同様に、メディアゲートウェイ3に生成したターミネーション情報と共にSIP信号路情報としてリソース管理部12及びメディアゲートウェイ3に記憶管理される。SIP信号路情報は、電話や視聴の開始・停止といった端末間の通信に依存しないため、加入者が存在する限り継続的に維持され、呼処理部11と連携してタイマ管理(タイマ更新)される。なお、SIP信号路についても、管理の効率上、メディア情報と同じ形式で扱い、帯域確保要求による開通等と称呼している。
ここで、図7及び図8を用いて、SIP信号路の帯域確保要求及び帯域解放要求の動作について説明する。図7は、SIP信号路の帯域確保要求時及び帯域解放要求時のフローチャートであり、図8は、それら要求時のフローシーケンスである。
リソース管理部12は、最初に、呼処理部11からの信号がSIP信号路の帯域確保要求か帯域解放要求かを判定する(F51)。帯域確保要求である場合には、リソース管理部内でのSIP信号路情報(SIPポート情報)の有無を確認し(F52)、SIP信号路情報がない場合には(S51)、メディアゲートウェイ3に照合依頼を送信して、その応答を受信することによりメディアゲートウェイ側のターミネーション情報を収集し(S52)、メディアゲートウェイ側のターミネーション情報の有無を判定する(F53、S53)。
そして、メディアゲートウェイ側にターミネーション情報が有る場合には、そのターミネーション情報を一旦削除した後に(F54、S54)、一方、メディアゲートウェイ側にターミネーション情報が無い場合には、即座に、Addのピンホール制御及びポリシング制御を行って(F55、S55)、SIP信号路情報をメディアゲートウェイ3に生成し(S56)、その応答により同じSIP信号路情報をリソース管理部12で保持する(S57)。最後に、処理成功の帯域確保要求応答を呼処理部11に返信する(F56、S58)。
一方、F52の確認結果でSIP信号路情報がある場合には(S59)、メディアゲートウェイ3を何ら制御することなく、処理成功の帯域確保要求応答を呼処理部11に送信する(F56、S60)。
また、F51の判定結果でSIP信号路の帯域解放要求である場合には、Subtractのピンホール制御及びポリシング制御を行って(F57、S61)、メディアゲートウェイ側のターミネーション情報を削除し、処理成功の帯域解放要求応答を呼処理部11に返信する。
なお、F54及びS54でメディアゲートウェイ側のターミネーション情報を一旦削除するのは、一部のメディアゲートウェイ3において、同一情報のSIP信号路、つまり同一ターミネーションの上書が許容されていないためである。
特開2003−258855号公報
ここで、SIP信号路の帯域確保要求を送信しても何ら応答がない場合(例えば、メディアゲートウェイでの処理が輻輳しているためにリソース管理部からの帯域確保要求を処理できない場合)には、SIP信号路情報を削除するイベントが発生する。
しかしながら、そのようなイベントが発生した場合には、その帯域確保要求のために確保した呼処理部のメモリ領域が処理中となるため、浮きリソースとしても解放できなくなるという問題があった。
なお、そのような問題に対する解決方法の一つに、SIP信号路を特定するIDや各種情報のAND条件を元に全件検索により上記メモリ領域を特定する方法が挙げられるが、全件検索に要する処理は高負荷であるため、検索を頻繁に繰り返すことにより呼処理サーバの処理能力が低下してしまう。特に、SIP信号路情報をメディア情報と同一ロジックで生成・管理し、処理の効率化を図っている場合には、大量のメディア情報の一部が検索対象となるため、呼処理サーバの処理能力が更に低下してしまう。
また、帯域確保要求を再送信して応答を受信することにより処理中の状態を完了に遷移させることも可能である。しかしながら、以下のような理由で問題がある。
現在、リソース管理部は、タイマ更新によりSIP信号路情報の状態を維持しているため、呼処理部からの帯域確保要求をあえて初回要求信号と同一内容の信号として受信している。リソース管理部は、初回と同一の信号を受信することで、リソース管理部内にSIP信号路情報が有る場合にはタイマ更新のみとして、即座に呼処理部に処理OKの応答を送信している。これにより、タイマ更新時の重複するMG制御処理を軽減している。また、同一信号であるため、リソース管理部内にSIP信号路情報が無い場合には、再設定情報として取り扱うことにより、最速での復旧を可能としている。リソース管理部は、初回の帯域確保要求を受信した時点で該要求情報を格納する領域を生成し、メディアゲートウェイに要求を送信している。このため、リソース管理部から応答が返却されない場合に呼処理部が要求を再送すると、リソース管理部が即座に再送信号に応答すると呼処理部での処理は一旦完結するものの、リソース管理部は初回の要求情報を格納しているため、メディアゲートウェイから応答が返却された場合に初回要求の応答を呼処理部に返却することになる。その他、メディアゲートウェイの制御NGで返却する場合やタイムアウトで返却する場合には、再送への返答と異なってしまう場合がある。後発信号を優先処理して、メディアゲートウェイを毎回制御する方法も考えられるが、一部のメディアゲートウェイにおいて同一ターミネーションに対する同時処理が許容されていない。このため、メディアゲートウェイが制御中であることを考慮して応答する必要がある。
本発明は、上記を鑑みてなされたものであり、SIP信号路の帯域制御要求時に確保された浮くおそれのあるリソースを解放することを課題とする。
請求項1に記載の呼処理方法は、SIPネゴシエーションの結果決定されるメディアを転送するメディアゲートウェイを有する転送系ネットワークに配備され、加入者端末から送信された要求を処理する呼処理手段と、前記転送系ネットワークの経路情報をリソースとして管理しておき、前記SIPネゴシエーションの結果に基づく前記要求の帯域量が前記リソースの残帯域で許容可能か否かを判断し、許容可能な場合には前記要求に係るメディアの転送を許可する設定を前記メディアゲートウェイに行うリソース管理手段と、を備えた呼処理サーバで処理する呼処理方法において、前記呼処理手段により、前記リソース管理手段に送信したSIP信号路の帯域確保要求に対する処理状態を処理中として記憶手段に記憶して管理し、前記リソース管理手段から応答が無い場合に前記帯域確保要求を一定時間間隔で繰り返し再送し、前記リソース管理手段により、前記帯域確保要求を受信した後に、前記帯域確保要求に応じた追加要求又は更新要求を前記メディアゲートウェイに既に送信中であるか否かを判定し、送信中である場合には前記受信した帯域確保要求を破棄し、前記追加要求又は前記更新要求に対する前記メディアゲートウェイからの応答を受信した後に、前記帯域確保要求に対する応答を前記呼処理手段に返信し、前記呼処理手段により、前記帯域確保要求の再送のうちいずれかの再送に対して応答を受信した後に、前記処理状態を前記記憶手段から読み出して処理終了に遷移させることを特徴とする。
本発明によれば、呼処理手段により、リソース管理手段に送信したSIP信号路の帯域確保要求に対する処理状態を処理中として記憶手段に記憶して管理し、リソース管理手段から応答が無い場合に帯域確保要求を一定時間間隔で繰り返し再送し、リソース管理手段により、帯域確保要求を受信した後に、帯域確保要求に応じた追加要求又は更新要求をメディアゲートウェイに既に送信中であるか否かを判定し、送信中である場合には受信した帯域確保要求を破棄し、追加要求又は更新要求に対するメディアゲートウェイからの応答を受信した後に、帯域確保要求に対する応答を呼処理手段に返信し、呼処理手段により、帯域確保要求の再送のうちいずれかの再送に対して応答を受信した後に、処理状態を記憶手段から読み出して処理終了に遷移させるため、SIP信号路の帯域確保要求時に呼処理手段に確保されたリソースを解放することができる。
請求項2に記載の呼処理方法は、SIPネゴシエーションの結果決定されるメディアを転送するメディアゲートウェイを有する転送系ネットワークに配備され、加入者端末から送信された要求を処理する呼処理手段と、前記転送系ネットワークの経路情報をリソースとして管理しておき、前記SIPネゴシエーションの結果に基づく前記要求の帯域量が前記リソースの残帯域で許容可能か否かを判断し、許容可能な場合には前記要求に係るメディアの転送を許可する設定を前記メディアゲートウェイに行うリソース管理手段と、を備えた呼処理サーバで処理する呼処理方法において、前記呼処理手段により、前記リソース管理手段に送信したSIP信号路の帯域解放要求に対する処理状態を処理中として記憶手段に記憶して管理し、前記リソース管理手段から応答が無い場合に前記帯域解放要求を一定時間間隔で繰り返し再送し、前記リソース管理手段により、前記帯域解放要求を受信する毎に前記帯域解放要求に応じた削除要求を前記メディアゲートウェイに繰り返し送信し、いずれかの送信に対して応答を受信した後に、前記帯域解放要求に対する応答を前記呼処理手段に返信し、前記呼処理手段により、前記帯域解放要求の再送のうちいずれかの再送に対して応答を受信した後に、前記処理状態を前記記憶手段から読み出して処理終了に遷移させることを特徴とする。
本発明によれば、呼処理手段により、リソース管理手段に送信したSIP信号路の帯域解放要求に対する処理状態を処理中として記憶手段に記憶して管理し、リソース管理手段から応答が無い場合に帯域解放要求を一定時間間隔で繰り返し再送し、リソース管理手段により、帯域解放要求を受信する毎に帯域解放要求に応じた削除要求をメディアゲートウェイに繰り返し送信し、いずれかの送信に対して応答を受信した後に、帯域解放要求に対する応答を呼処理手段に返信し、呼処理手段により、帯域解放要求の再送のうちいずれかの再送に対して応答を受信した後に、処理状態を記憶手段から読み出して処理終了に遷移させるため、SIP信号路の帯域解放要求時に呼処理手段に確保されたリソースを解放することができる。
請求項3に記載の呼処理サーバは、SIPネゴシエーションの結果決定されるメディアを転送するメディアゲートウェイを有する転送系ネットワークに配備され、加入者端末から送信された要求を処理する呼処理手段と、前記転送系ネットワークの経路情報をリソースとして管理しておき、前記SIPネゴシエーションの結果に基づく前記要求の帯域量が前記リソースの残帯域で許容可能か否かを判断し、許容可能な場合には前記要求に係るメディアの転送を許可する設定を前記メディアゲートウェイに行うリソース管理手段と、を備えた呼処理サーバにおいて、前記呼処理手段は、前記リソース管理手段に送信したSIP信号路の帯域確保要求に対する処理状態を処理中として記憶手段に記憶して管理し、前記リソース管理手段から応答が無い場合に前記帯域確保要求を一定時間間隔で繰り返し再送し、いずれかの再送に対して応答を受信した後に、前記処理状態を前記記憶手段から読み出して処理終了に遷移させ、前記リソース管理手段は、前記帯域確保要求を受信した後に、前記帯域確保要求に応じた追加要求又は更新要求を前記メディアゲートウェイに既に送信中であるか否かを判定し、送信中である場合には前記受信した帯域確保要求を破棄し、前記追加要求又は前記更新要求に対する前記メディアゲートウェイからの応答を受信した後に、前記帯域確保要求に対する応答を前記呼処理手段に返信することを特徴とする。
本発明によれば、呼処理手段は、リソース管理手段に送信したSIP信号路の帯域確保要求に対する処理状態を処理中として記憶手段に記憶して管理し、リソース管理手段から応答が無い場合に帯域確保要求を一定時間間隔で繰り返し再送し、いずれかの再送に対して応答を受信した後に、処理状態を記憶手段から読み出して処理終了に遷移させ、リソース管理手段は、帯域確保要求を受信した後に、帯域確保要求に応じた追加要求又は更新要求をメディアゲートウェイに既に送信中であるか否かを判定し、送信中である場合には受信した帯域確保要求を破棄し、追加要求又は更新要求に対するメディアゲートウェイからの応答を受信した後に、帯域確保要求に対する応答を呼処理手段に返信するため、SIP信号路の帯域確保要求時に呼処理手段に確保されたリソースを解放することができる。
請求項4に記載の呼処理サーバは、SIPネゴシエーションの結果決定されるメディアを転送するメディアゲートウェイを有する転送系ネットワークに配備され、加入者端末から送信された要求を処理する呼処理手段と、前記転送系ネットワークの経路情報をリソースとして管理しておき、前記SIPネゴシエーションの結果に基づく前記要求の帯域量が前記リソースの残帯域で許容可能か否かを判断し、許容可能な場合には前記要求に係るメディアの転送を許可する設定を前記メディアゲートウェイに行うリソース管理手段と、を備えた呼処理サーバにおいて、前記呼処理手段は、前記リソース管理手段に送信したSIP信号路の帯域解放要求に対する処理状態を処理中として記憶手段に記憶して管理し、前記リソース管理手段から応答が無い場合に前記帯域解放要求を一定時間間隔で繰り返し再送し、いずれかの再送に対して応答を受信した後に、前記処理状態を前記記憶手段から読み出して処理終了に遷移させ、前記リソース管理手段は、前記帯域解放要求を受信する毎に前記帯域解放要求に応じた削除要求を前記メディアゲートウェイに繰り返し送信し、いずれかの送信に対して応答を受信した後に、前記帯域解放要求に対する応答を前記呼処理手段に返信することを特徴とする。
本発明によれば、呼処理手段は、リソース管理手段に送信したSIP信号路の帯域解放要求に対する処理状態を処理中として記憶手段に記憶して管理し、リソース管理手段から応答が無い場合に帯域解放要求を一定時間間隔で繰り返し再送し、いずれかの再送に対して応答を受信した後に、処理状態を記憶手段から読み出して処理終了に遷移させ、リソース管理手段は、帯域解放要求を受信する毎に帯域解放要求に応じた削除要求を前記メディアゲートウェイに繰り返し送信し、いずれかの送信に対して応答を受信した後に、帯域解放要求に対する応答を呼処理手段に返信するため、SIP信号路の帯域解放要求時に呼処理手段に確保されたリソースを解放することができる。
本発明によれば、SIP信号路の帯域制御要求時に確保された浮くおそれのあるリソースを解放することができる。
呼処理サーバの機能ブロック構成を示す図である。 SIP信号路の帯域解放要求時のフローシーケンスである。 SIP信号路の帯域確保要求時のフローシーケンスである。 リソース管理部の動作内容を示すフローチャートである。 SIP通信ネットワークのシステム構成を概略的に示す図である。 リソース管理を説明する図である。 従来におけるSIP信号路の帯域確保要求時及び帯域解放要求時のフローチャートである。 従来におけるSIP信号路の帯域確保要求時及び帯域解放要求時のフローシーケンスである。
以下、本発明を実施する一実施の形態について図面を用いて説明する。但し、本発明は多くの異なる様態で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。
〔呼処理サーバの構成及び機能について〕
図1は、呼処理サーバの機能ブロック構成を示す図である。この呼処理サーバは、SIPネゴシエーションの結果決定されるメディアを転送するメディアゲートウェイを有する転送系ネットワークに配備され(図5参照)、加入者の端末5から送信された音声通信や動画通信等の各種要求に係る呼を処理する呼処理部11と、転送系ネットワークの経路情報をリソースとして管理しておき、SIPネゴシエーションの結果に基づく各種要求の帯域量が上記リソースの残帯域で許容可能か否かを判断し、許容可能な場合には対象の要求に係るメディアの転送を許可する設定をメディアゲートウェイ3に行うリソース管理部12とで構成されている。なお、これら機能説明は背景技術で説明した機能を概要的に説明するものであり、詳細には背景技術で述べた機能を具備するものである。以下、それら各機能部が有する本実施の形態での特徴的機能を説明する。
呼処理部11は、リソース管理部12にSIP信号路の帯域確保要求又は帯域解放要求を送信した後に、そのSIP信号路の各要求に対する処理状態を処理中として処理状態記憶部13に記憶して管理し、リソース管理部12から応答が無い場合に、タイマ管理部14から通知された一定時間間隔で同要求を繰り返し再送し、いずれかの再送に対して応答を受信した後に、処理状態を処理状態記憶部13から読み出して処理中から完了又は処理終了に遷移させる機能を有している。
リソース管理部12は、呼処理部11からの要求を処理する呼処理制御部21と、その処理内容に応じてメディアゲートウェイ3を制御するMG制御部22とで構成されている。初回の帯域確保要求を受信した時には、その帯域確保要求に対応するターミネーションの追加要求又は更新要求(換言すれば、SIP信号路の確保要求)をメディアゲートウェイ3に送信し、次回以降の帯域確保要求を受信した時には、追加要求又は更新要求がメディアゲートウェイ3に既に送信中であるか否かを判定し、送信中である場合には受信した帯域確保要求を破棄し、追加要求又は更新要求に対するメディアゲートウェイ3からの応答を受信した後に、帯域確保要求に対する応答を呼処理部11に返信する機能を有している。
一方、初回の帯域解放要求を受信した時には、その帯域解放要求に対応するターミネーションの削除要求(換言すれば、SIP信号路の解放要求)をメディアゲートウェイ3に送信し、次回以降の帯域解放要求を受信する毎に同様の削除要求をメディアゲートウェイ3に一律繰り返し送信し、いずれかの送信に対して応答を受信した後に、帯域解放要求に対する応答を呼処理部11に返信する機能を有している。
なお、リソース管理部12は、megacoプロトコルを用いたピンホール制御やポリシング制御により、メディアゲートウェイ3へのターミネーションの追加要求、更新要求、削除要求を実現している。
メディアゲートウェイ3は、呼処理サーバ1からターミネーションの追加要求又は更新要求を受信した場合には、そのターミネーションを追加又は更新してSIP信号路情報としてメモリ上で管理し、ターミネーションの削除要求を受信した場合には、そのターミネーションをSIP信号路情報から削除する。また、メディアゲートウェイ3での処理が輻輳中に各要求を受信した場合には、トランザクションペンディングリクエスト(Transaction Pending Request)を呼処理サーバ1に送信して、受信した要求のトランザクションがペンディング状態であることを伝えることが可能である。なお、SIP信号路情報は呼処理サーバ1及びメディアゲートウェイ3で保持されるが、SIP信号路情報をメディア情報と同一ロジックで生成し、管理することも可能である。これにより、呼処理サーバ1等での処理の効率化を図ることができる。
一方、リソース管理部12は、そのトランザクションペンディングリクエストに対してトランザクションペンディングリプライ(Transaction Pending Reply)を返信する。リソース管理部12がメディアゲートウェイ3に対して張っているタイマの最大時間が終了するまで、又はメディアゲートウェイ3での処理が完了するまで、リソース管理部12とメディアゲートウェイ3との間で、トランザクションペンディングリクエストとトランザクションペンディングリプライとが交互に繰り返し送受される。
〔呼処理サーバの動作について〕
次に、呼処理サーバの動作について説明する。まず、SIP信号路の帯域解放要求時の動作について説明する。図2は、SIP信号路の帯域解放要求時のフローシーケンスである。
最初に、SIP信号路の帯域解放要求送信要求を受信した場合に、呼処理部11により、帯域解放要求がリソース管理部12の呼処理制御部21に送信され(S1)、その送信と共に又は送信後に、その帯域解放要求に対する処理状態が処理中として記憶管理される(S2)。
次いで、呼処理制御部21により、リソース管理部内にSIP信号路情報を既に保持している場合に、呼処理部11から送信された帯域解放要求に対応するSubtract送信要求がリソース管理部12のMG制御部22に渡される(S3)。
次いで、MG制御部22により、Subtract送信要求に対応するターミネーションの削除要求(Subtract Request)がメディアゲートウェイ3に送信される(S4)。
ここで、メディアゲートウェイ3での処理が輻輳状態である場合には、メディアゲートウェイ3により、トランザクションペンディングリクエストがMG制御部22に送信される(S5)。
トランザクションペンディングリクエストが送信された場合には、MG制御部22により、トランザクション終了(換言すれば、ターミネーション削除終了)までのタイマのタイムアウト時間が最大で210秒まで拡大され(S6)、トランザクションペンディングリプライが返信される(S7)。なお、MG制御部22は、トランザクションペンディングリクエストを受信する毎にタイマを所定の時間だけ延長し、最大210秒までしか延長しないようにすることも可能である。
S5及びS7は、MG制御部22とメディアゲートウェイ3との間で繰り返されるが、タイムアウト時間を経過してもメディアゲートウェイ3から削除処理終了の応答がない場合を前提に以下動作の説明を続ける。
タイマ管理部14からタイマ通知された場合に、呼処理部11により、S1で送信した帯域解放要求と同じ帯域解放要求が再送される(S8)。
次いで、呼処理制御部21により、呼処理部11から再送された帯域解放要求に対応するSubtract送信要求がリソース管理部12のMG制御部22に再度渡される(S9)。
次いで、MG制御部22により、再度渡されたSubtract送信要求に対応するターミネーションの削除要求(Subtract Request)がメディアゲートウェイ3に再送される(S10)。
なお、S8は、タイマ通知される毎に繰り返し行われ、S9及びS10は、帯域解放要求が繰り返し送信される毎に繰り返される。ここで、メディアゲートウェイ3での削除処理が終了したものとして以下説明を続ける。
削除要求に対する応答(Subtract Reply)がメディアゲートウェイ3から返信された場合(S11)には、MG制御部22により、その応答に含まれる削除処理結果が判断され(S12)、メディアゲートウェイ3での削除処理が失敗した場合には、NGの応答(Subtract Reply (NG))が呼処理制御部21に返信され(S13)、成功した場合には、OKの応答(Subtract Reply (OK))が返信される(S14)。例えば、メディアゲートウェイ3から返信された応答に含まれる削除処理結果が、code=435、431、411,430のうちいずれかである場合には、メディアゲートウェイ3からMG制御部22にNGの応答(Subtract Reply (errorcode=431) 等)が返信され、MG制御部22から呼処理制御部21にNGの応答(Subtract Reply (errorcode=Unknown_Session_ID))が返信される。
呼処理制御部21がMG制御部22からNGの応答を受信した場合には、呼処理制御部21により、帯域解放要求応答(NG(errorcode=Unknown_Session_ID))が呼処理部11に返信され(S15)、OKの応答を受信した場合には、帯域解放要求応答(OK)が返信される(S16)。
最後に、呼処理部11により、メディアゲートウェイ3での削除処理結果にかかわらず、帯域解放要求応答(S15、S16)を受信した場合には、帯域解放要求に対する処理状態が処理中から完了に遷移される(S17、S18)。これにより、帯域解放要求のために確保していたメモリ領域が解放される。換言すれば、初回の帯域解放要求で処理中となっていたSIP信号路の管理状態が完結されることになる。
続いて、SIP信号路の帯域確保要求時の動作について説明する。図3は、SIP信号路の帯域確保要求時のフローシーケンスである。
最初に、SIP信号路の帯域確保要求送信要求を受信した場合に、呼処理部11により、帯域確保要求がリソース管理部12の呼処理制御部21に送信され(S31)、その送信と共に又は送信後に、その帯域確保要求に対する処理状態が処理中として記憶管理される(S32)。
次いで、呼処理制御部21により、リソース管理部内にSIP信号路情報を既に保持している場合に、呼処理部11から送信された帯域確保要求に対応するAdd送信要求又はModify送信要求がリソース管理部12のMG制御部22に渡される(S33)。なお、本実施の形態における帯域確保要求とは、帯域を新規に追加(Add)する場合と、帯域を更新(Modify)する場合との両方を含む。
次いで、MG制御部22により、Add送信要求に対応するターミネーションの追加要求(Add Request)又は更新要求(Modify Request)がメディアゲートウェイ3に送信される(S34)。
ここで、メディアゲートウェイ3での処理が輻輳状態である場合には、メディアゲートウェイ3により、トランザクションペンディングリクエストがMG制御部22に送信される(S35)。
トランザクションペンディングリクエストが送信された場合には、MG制御部22により、トランザクション終了(換言すれば、ターミネーション追加・更新終了)までのタイマのタイムアウト時間が最大で210秒まで拡大され、そのトランザクションが記憶管理されて(S36)、トランザクションペンディングリプライが返信される(S37)。なお、MG制御部22は、トランザクションペンディングリクエストを受信する毎にタイマを所定の時間だけ延長し、最大210秒までしか延長しないようにすることも可能である。
S35及びS37は、MG制御部22とメディアゲートウェイ3との間で繰り返されるが、タイムアウト時間を経過してもメディアゲートウェイ3から追加処理終了の応答がない場合を前提に以下動作の説明を続ける。
タイマ管理部14からタイマ通知された場合に、呼処理部11により、S31で送信した帯域確保要求と同じ帯域確保要求が再送される(S38)。
次いで、呼処理制御部21により、MG制御部22で記憶管理されているトランザクションが検索され(S39)、メディアゲートウェイ3との間でのトランザクションの有無が判断される(S40)。以降、これに要する時間をMG制御中という。
そして、S40の判断の結果、トランザクションが有る場合にはメディアゲートウェイ3での追加処理が未終了であるため、S38で再送された帯域確保要求が破棄される(S41)。そして、メディアゲートウェイ3での追加処理又は更新処理が終了した後に、メディアゲートウェイ3からの応答を期待する。
なお、S38は、タイマ通知される毎に繰り返し行われ、S39〜S41は、帯域解放要求が繰り返し再送される毎に繰り返される。
その後、追加要求に対する応答(Add Reply)又は更新要求に対応する応答(Modify Reply)がメディアゲートウェイ3から返信された場合(S42)には、MG制御部22により、Add送信要求又はModify送信要求に対する応答(Add Reply/Modify Reply)が呼処理制御部21に返信され(S43)、呼処理制御部21により、帯域確保要求応答が呼処理部11に返信される(S44)。
最後に、呼処理部11により、帯域確保要求に対する処理状態が処理中から完了に遷移される(S45)。これにより、帯域確保要求のために確保していたメモリ領域が解放される。換言すれば、初回の帯域確保要求で処理中となっていたSIP信号路の管理状態が完結されることになる。
なお、S42以降の各処理に代えて、帯域解放要求のフローで説明したS9以降の各処理と同様の処理を適用することも可能である。
リソース管理部12は、帯域解放要求の場合には、その要求が初回(送信)であっても次回以降(再送)であっても、削除要求をメディアゲートウェイ3に一律繰り返して送信する。一方、帯域確保要求の場合には、MG制御中であるか否かを判定し、MG処理中の場合には要求を破棄する。帯域確保要求の場合であっても、MG制御中の判断ロジックを行うことなく帯域解放要求の場合と同様に全ての要求をメディアゲートウェイ3に再送することも可能である。逆に、帯域解放要求の場合であっても、MG制御中の判断ロジックを含めることも可能である。但し、帯域解放要求の場合には、削除処理に対するメディアゲートウェイ3からの応答に含まれる処理結果の内容が明確なので、判断ロジックをなくしてシンプルに要求する方が好ましい。
なお、意図しない状態ではあるが、帯域確保要求において、その要求が初回であって、SIP信号路情報が有る場合には、リソース管理部12は、重複設定を避けるために、要求されたSIP信号路に係るターミネーションの有無をメディアゲートウェイ3に事前確認し(以降、MG照合という)、一旦削除処理を実行した後に、帯域確保要求に対応するAdd信号又はModify信号をメディアゲートウェイ3に送信することも可能である。
次に、リソース管理部12の動作内容について具体的に説明する。図4は、リソース管理部の動作内容を示すフローチャートである。
なお、呼処理部11によってタイマがタイマ管理部14に既に登録されており、一定時間間隔でタイマ通知を受ける毎に、応答が返信されて処理が完結するまで、帯域確保要求又は帯域解放要求がリソース管理部12に繰り返し送信されているものとする。また、それら各要求を初回に送信する場合には、再送識別子を含めることなく各要求が送信されるものとする。これにより、リソース管理部12においてSIP信号路情報の有無の判定や、MG制御中であるか否かの判定のロジックをスキップすることができ、処理軽減によりリソース管理部12からの応答速度を向上することができる。
リソース管理部12は、呼処理部11から送信された信号種別が帯域解放要求である場合には(F1→F2)、その要求が初回であっても次回以降であっても、削除要求(Subtract Request)をメディアゲートウェイ3に一律送信し、その要求に対する応答の処理結果に応じた返信を呼処理部11に送信する(F2)。
一方、送信された信号種別が帯域確保要求であって、再送識別子が設定され、現在送信している信号種別が追加要求(Add Request)であり、SIP信号路情報が無い場合には(F1→F3→F4→F5→F6)、上述したMG照合を行い、要求されたSIP信号路に係るメディアゲートウェイ3でのターミネーションの有無を判定する(F6)。
F6での判定の結果、MG照合依頼応答にターミネーションが有る場合には(F6→F7→F8)、削除要求(Subtract Request)をメディアゲートウェイ3に送信してターミネーションを一旦削除した後に(F8)、追加要求(Add Request)を送信して、帯域確保結果を呼処理部11に返信する(F9)。
一方、F6での判定の結果、MG照合依頼応答にターミネーションが無い場合には(F6→F7→F9)、削除要求(Subtract Request)をメディアゲートウェイに送信することなく、追加要求(Add Request)を送信して、帯域確保結果を呼処理部11に返信する(F9)。
また、送信された信号種別が帯域確保要求であって、再送識別子が設定され、現在送信している信号種別が追加要求(Add Request)であり、Flow−StatusがEnableであり、SIP信号路情報が有る場合には(F1→F3→F4→F5→F10)、MG制御中か否かが判定される(F10)。
F10での判定の結果、MG制御中であって、メディアゲートウェイ3との間でのトランザクションが有る場合には(F10→F11→F12)、呼処理部から再送された帯域確保要求を破棄し、追加要求(Add Request)は再送しない(F12)。
一方、MG制御中であって、メディアゲートウェイ3との間でのトランザクションが無い場合には(F10→F11→F6)、F6に遷移する。
一方、MG制御中であるが、メディアゲートウェイ3との間でのトランザクションに有無が混在する場合には(F10→F11→F13)、MG照合を行ってMG照合依頼応答にターミネーションが有るか否かを確認すると共に、リソース管理部12にメディア情報があるか否かを確認する(F13)。
F13での確認の結果、リソース管理部12にメディア情報がなく、メディアゲートウェイ3にターミネーションがある場合には、F8に遷移し、削除要求(Subtract Request)をメディアゲートウェイ3に送信してターミネーションを一旦削除した後に、F9に遷移して、追加要求(Add Request)を送信する。
一方、F13での確認の結果、リソース管理部12にメディア情報がなく、メディアゲートウェイ3にターミネーションがない場合には、F9に遷移し、追加要求(Add Request)を送信する。
一方、F13での確認の結果、リソース管理部12にメディア情報があり、メディアゲートウェイ3にターミネーションがある場合には、既に応答済み(Add Replyを返信済み)のメディア、又は双方向開通で既に開通済みのメディアと判断して、何も送信しない(F14)。
一方、F13での確認の結果、リソース管理部12にメディア情報があり、メディアゲートウェイ3にターミネーションがない場合には、F12に遷移し、呼処理部から再送された帯域確保要求を破棄し、追加要求(Add Request)は再送しない。
F10の判定に戻り、F10での判定の結果、MG制御中以外の場合には、メディアゲートウェイ3から返信された追加要求に対する応答(Add Reply)を受信した後に、帯域確保要求応答を呼処理部11に返信する(F15)。帯域確保要求応答が呼処理部11までの間で消失したと判断する。
同様に、送信された信号種別が帯域確保要求であって、再送識別子が設定され、現在送信している信号種別が更新要求(Modify Request)であり、Flow−StatusがEnableであり、SIP信号路情報が有る場合にも(F1→F3→F4→F16→F17)、MG制御中か否かが判定される(F17)。
F17での判定の結果、MG制御中であって、メディアゲートウェイ3との間でのトランザクションが有る場合には(F17→F18→F19)、呼処理部から再送された帯域確保要求を破棄し、変更要求(Modify Request)は再送しない(F19)。
一方、MG制御中であって、メディアゲートウェイ3との間でのトランザクションが無い場合には(F17→F18→F20)、更新要求(Modify Request)をメディアゲートウェイ3に再送する(F20)。但し、Flow−StatusがEnableの場合には、INS(InService)を送信し、Flow−StatusがDisabledの場合には、OUS(OutOfService)を送信する。
一方、MG制御中であるが、メディアゲートウェイ3との間でのトランザクションに有無が混在する場合には(F17→F18→F21)、トランザクションがないメディアに対して更新要求(Modify Request)をメディアゲートウェイ3に再送する(F21)。但し、Flow−StatusがEnableの場合には、INS(InService)を送信し、Flow−StatusがDisabledの場合には、OUS(OutOfService)を送信する。
F17の判定に戻り、F17での判定の結果、MG制御中以外の場合には、メディアゲートウェイ3から返信された更新要求に対する応答(Modify Reply)を受信した後に、帯域確保要求応答を呼処理部11に返信する(F22)。帯域確保要求応答が呼処理部11までの間で消失したと判断する。
本実施の形態によれば、呼処理部11により、リソース管理部12に送信したSIP信号路の帯域確保要求に対する処理状態を処理中として処理状態記憶部13に記憶して管理し、リソース管理部12から応答が無い場合に帯域確保要求を一定時間間隔で繰り返し再送し、リソース管理部12により、帯域確保要求を受信した後に、帯域確保要求に応じた追加要求又は更新要求をメディアゲートウェイに既に送信中であるか否かを判定し、送信中である場合には受信した帯域確保要求を破棄し、追加要求又は更新要求に対するメディアゲートウェイからの応答を受信した後に、帯域確保要求に対する応答を呼処理部11に返信し、呼処理部11により、帯域確保要求の再送のうちいずれかの再送に対して応答を受信した後に、処理状態を処理状態記憶部13から読み出して処理終了に遷移させるので、SIP信号路の帯域確保要求時に呼処理部11に確保されたリソースを解放することができる。
本実施の形態によれば、呼処理部11により、リソース管理部12に送信したSIP信号路の帯域解放要求に対する処理状態を処理中として処理状態記憶部13に記憶して管理し、リソース管理部12から応答が無い場合に帯域解放要求を一定時間間隔で繰り返し再送し、リソース管理部12により、帯域解放要求を受信する毎に帯域解放要求に応じた削除要求をメディアゲートウェイに繰り返し送信し、いずれかの送信に対して応答を受信した後に、帯域解放要求に対する応答を呼処理部11に返信し、呼処理部11により、帯域解放要求の再送のうちいずれかの再送に対して応答を受信した後に、処理状態を処理状態記憶部13から読み出して処理終了に遷移させるので、SIP信号路の帯域解放要求時に呼処理部11に確保されたリソースを解放することができる。
最後に、本実施の形態で説明した呼処理サーバ1は、コンピュータで構成される。すなわち、処理状態記憶部13は、メモリ等の記憶手段で実現される。また、呼処理部11と、リソース管理部12と、呼処理制御部21と、MG制御部22と、タイマ管理部14とは、CPU等の演算手段で実現され、プログラムで実行される。
また、本実施の形態で説明した呼処理サーバ1をプログラムとして光記憶装置や磁気記憶装置等の記録媒体に読出可能に記録し、この記録媒体をコンピュータに組み込んだり、若しくは記録媒体に記録されたプログラムを、任意の通信回線を介してコンピュータにダウンロードしたり、又は記録媒体からインストールし、該プログラムでコンピュータを動作させることにより、上述した各処理を呼処理サーバ1として機能させることができるのは勿論である。
1…呼処理サーバ
3…メディアゲートウェイ(MG)
5…端末
7…ネットワーク機器
11…呼処理部(呼処理手段)
12…リソース管理部(リソース管理手段)
13…処理状態記憶部(記憶手段)
14…タイマ管理部
21…呼処理機能部
22…MG制御部
121…メディアゲートウェイコントローラ(MGC)
S…フローシーケンスにおけるステップ
F…フローチャートにおけるステップ

Claims (4)

  1. SIPネゴシエーションの結果決定されるメディアを転送するメディアゲートウェイを有する転送系ネットワークに配備され、
    加入者端末から送信された要求を処理する呼処理手段と、
    前記転送系ネットワークの経路情報をリソースとして管理しておき、前記SIPネゴシエーションの結果に基づく前記要求の帯域量が前記リソースの残帯域で許容可能か否かを判断し、許容可能な場合には前記要求に係るメディアの転送を許可する設定を前記メディアゲートウェイに行うリソース管理手段と、を備えた呼処理サーバで処理する呼処理方法において、
    前記呼処理手段により、
    前記リソース管理手段に送信したSIP信号路の帯域確保要求に対する処理状態を処理中として記憶手段に記憶して管理し、前記リソース管理手段から応答が無い場合に前記帯域確保要求を一定時間間隔で繰り返し再送し、
    前記リソース管理手段により、
    前記帯域確保要求を受信した後に、前記帯域確保要求に応じた追加要求又は更新要求を前記メディアゲートウェイに既に送信中であるか否かを判定し、送信中である場合には前記受信した帯域確保要求を破棄し、前記追加要求又は前記更新要求に対する前記メディアゲートウェイからの応答を受信した後に、前記帯域確保要求に対する応答を前記呼処理手段に返信し、
    前記呼処理手段により、
    前記帯域確保要求の再送のうちいずれかの再送に対して応答を受信した後に、前記処理状態を前記記憶手段から読み出して処理終了に遷移させることを特徴とする呼処理方法。
  2. SIPネゴシエーションの結果決定されるメディアを転送するメディアゲートウェイを有する転送系ネットワークに配備され、
    加入者端末から送信された要求を処理する呼処理手段と、
    前記転送系ネットワークの経路情報をリソースとして管理しておき、前記SIPネゴシエーションの結果に基づく前記要求の帯域量が前記リソースの残帯域で許容可能か否かを判断し、許容可能な場合には前記要求に係るメディアの転送を許可する設定を前記メディアゲートウェイに行うリソース管理手段と、を備えた呼処理サーバで処理する呼処理方法において、
    前記呼処理手段により、
    前記リソース管理手段に送信したSIP信号路の帯域解放要求に対する処理状態を処理中として記憶手段に記憶して管理し、前記リソース管理手段から応答が無い場合に前記帯域解放要求を一定時間間隔で繰り返し再送し、
    前記リソース管理手段により、
    前記帯域解放要求を受信する毎に前記帯域解放要求に応じた削除要求を前記メディアゲートウェイに繰り返し送信し、いずれかの送信に対して応答を受信した後に、前記帯域解放要求に対する応答を前記呼処理手段に返信し、
    前記呼処理手段により、
    前記帯域解放要求の再送のうちいずれかの再送に対して応答を受信した後に、前記処理状態を前記記憶手段から読み出して処理終了に遷移させることを特徴とする呼処理方法。
  3. SIPネゴシエーションの結果決定されるメディアを転送するメディアゲートウェイを有する転送系ネットワークに配備され、
    加入者端末から送信された要求を処理する呼処理手段と、
    前記転送系ネットワークの経路情報をリソースとして管理しておき、前記SIPネゴシエーションの結果に基づく前記要求の帯域量が前記リソースの残帯域で許容可能か否かを判断し、許容可能な場合には前記要求に係るメディアの転送を許可する設定を前記メディアゲートウェイに行うリソース管理手段と、を備えた呼処理サーバにおいて、
    前記呼処理手段は、
    前記リソース管理手段に送信したSIP信号路の帯域確保要求に対する処理状態を処理中として記憶手段に記憶して管理し、前記リソース管理手段から応答が無い場合に前記帯域確保要求を一定時間間隔で繰り返し再送し、いずれかの再送に対して応答を受信した後に、前記処理状態を前記記憶手段から読み出して処理終了に遷移させ、
    前記リソース管理手段は、
    前記帯域確保要求を受信した後に、前記帯域確保要求に応じた追加要求又は更新要求を前記メディアゲートウェイに既に送信中であるか否かを判定し、送信中である場合には前記受信した帯域確保要求を破棄し、前記追加要求又は前記更新要求に対する前記メディアゲートウェイからの応答を受信した後に、前記帯域確保要求に対する応答を前記呼処理手段に返信することを特徴とする呼処理サーバ。
  4. SIPネゴシエーションの結果決定されるメディアを転送するメディアゲートウェイを有する転送系ネットワークに配備され、
    加入者端末から送信された要求を処理する呼処理手段と、
    前記転送系ネットワークの経路情報をリソースとして管理しておき、前記SIPネゴシエーションの結果に基づく前記要求の帯域量が前記リソースの残帯域で許容可能か否かを判断し、許容可能な場合には前記要求に係るメディアの転送を許可する設定を前記メディアゲートウェイに行うリソース管理手段と、を備えた呼処理サーバにおいて、
    前記呼処理手段は、
    前記リソース管理手段に送信したSIP信号路の帯域解放要求に対する処理状態を処理中として記憶手段に記憶して管理し、前記リソース管理手段から応答が無い場合に前記帯域解放要求を一定時間間隔で繰り返し再送し、いずれかの再送に対して応答を受信した後に、前記処理状態を前記記憶手段から読み出して処理終了に遷移させ、
    前記リソース管理手段は、
    前記帯域解放要求を受信する毎に前記帯域解放要求に応じた削除要求を前記メディアゲートウェイに繰り返し送信し、いずれかの送信に対して応答を受信した後に、前記帯域解放要求に対する応答を前記呼処理手段に返信することを特徴とする呼処理サーバ。
JP2010140638A 2010-06-21 2010-06-21 呼処理方法及び呼処理サーバ Active JP5017425B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010140638A JP5017425B2 (ja) 2010-06-21 2010-06-21 呼処理方法及び呼処理サーバ

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010140638A JP5017425B2 (ja) 2010-06-21 2010-06-21 呼処理方法及び呼処理サーバ

Publications (2)

Publication Number Publication Date
JP2012005045A JP2012005045A (ja) 2012-01-05
JP5017425B2 true JP5017425B2 (ja) 2012-09-05

Family

ID=45536466

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010140638A Active JP5017425B2 (ja) 2010-06-21 2010-06-21 呼処理方法及び呼処理サーバ

Country Status (1)

Country Link
JP (1) JP5017425B2 (ja)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3613325B2 (ja) * 2000-01-27 2005-01-26 富士通株式会社 ルータ及び該ルータを用いたネットワーク及びネットワーク制御方法
JP4962854B2 (ja) * 2007-03-28 2012-06-27 日本電気株式会社 優先制御装置、sipシステム、優先制御プログラム及び優先制御方法
JP4802261B2 (ja) * 2008-09-26 2011-10-26 日本電信電話株式会社 リソース管理装置およびリソース管理方法

Also Published As

Publication number Publication date
JP2012005045A (ja) 2012-01-05

Similar Documents

Publication Publication Date Title
US8908509B2 (en) Flow admission control in an IP network
US6453349B1 (en) Apparatus and method for resource reservation in a network system
US7522591B2 (en) Policy settable peer-to-peer session apparatus
US8570870B2 (en) Incremental addition and scale-back of resources adapting to network resource availability
US7830888B2 (en) Method and system of providing differentiated services
US8228945B2 (en) Streaming communication system
JP2006287331A (ja) 輻輳制御ネットワーク中継装置、および輻輳制御ネットワーク中継方法
US20060218353A1 (en) Method and apparatus for implementing path-based traffic stream admission control in a wireless mesh network
US20120166659A1 (en) Node and Method for Quality of Service (QoS) Control
WO2007082448A1 (fr) Procédé de qualité de service (qos) garantie, dispositif de gestion de ressources et système d'accès multi-services
WO2006093221A1 (ja) 伝送制御装置およびその方法
JP2007506295A (ja) Sipハンドオーバー時に割り当てられた資源を開放する方法
US7506050B2 (en) Method for checking transmission resources of a packet-oriented communication network when there are topology changes
KR100705564B1 (ko) 네트워크에서의 자원 관리 장치 및 방법
JP5078668B2 (ja) 呼制御システム及び呼制御方法
JP2003258880A (ja) ネットワークおよびノードおよびデータ転送方法
EP2395707B1 (en) Method, system and equipment for call processing
JP5017425B2 (ja) 呼処理方法及び呼処理サーバ
Ejzak et al. Network Overload and Congestion: A comparison of ISUP and SIP
JP4802261B2 (ja) リソース管理装置およびリソース管理方法
JP3866646B2 (ja) 帯域管理装置および方法、プログラム、記録媒体
WO2008064578A1 (fr) Procédé, système, réseau d'accès et terminal d'accès pour libérer une ressource qos
JP2010045605A (ja) 通信システム
JP5017420B2 (ja) セッション情報整合処理方法及び呼制御サーバ
JP4157941B2 (ja) Ethernet網

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120530

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120605

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120611

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150615

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5017425

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350