(57)【特許請求の範囲】
【請求項１】
発端末が接続される第１の網と、着端末が接続される第２の網との間をＳＩＰ（Session Initiation Protocol）によって相互に接続するゲートウェイに設置され、前記発端末の呼により前記発端末と前記着端末との間の通信路を確立する前に、前記発端末の呼出中であることを表す所定の呼出音を前記発端末に対して提供するための呼出音提供装置であって、
呼出音を生成する呼出音生成部と、
前記発端末の呼により前記発端末と前記着端末との間の通信路を確立する前に、通信路の確立要求に対する前記第２の網からの所定の応答のＳＩＰメッセージを受信した際に、当該ＳＩＰメッセージに、事前に取り決めた記述が有るか否かにより、前記呼出音生成部からの呼出音送出の要否を判定し、呼出音送出が必要な場合には前記呼出音生成部から前記発端末に向けて呼出音を送出する呼出音送出制御部と、
を備える呼出音提供装置。
【請求項２】
前記応答とは、ＳＩＰ（Session Initiation Protocol）の180応答、181応答、182応答、183応答のうちいずれかである、
請求項１に記載の呼出音提供装置。
【請求項３】
前記記述は、前記ＳＩＰメッセージのヘッダ部のＰアーリーメディアヘッダ指定行に含まれている、
ことを特徴とする請求項２に記載の呼出音提供装置。
【請求項４】
前記記述は、前記ＳＩＰメッセージのボディ部のＣＡＴ指定行に含まれている、
ことを特徴とする請求項２に記載の呼出音提供装置。
【請求項５】
前記呼出音送出制御部は、前記呼出音生成部からの呼出音送出が不要と認識した場合に、前記第２の網から入力されるメディアパケットを前記第１の網に転送する、
請求項１に記載の呼出音提供装置。
【請求項６】
発端末が接続される第１の網と、着端末が接続される第２の網と、これらの間をＳＩＰ（Session Initiation Protocol）によって相互に接続するゲートウェイとを含む通信システムを制御し、前記発端末の呼により前記発端末と前記着端末との間の通信路を確立する前に、前記発端末の呼出中であることを表す所定の呼出音を前記発端末に対して提供するための呼出音提供方法であって、
前記発端末の呼により前記発端末と前記着端末との間の通信路を確立する前に、通信路の確立要求に対する前記第２の網からの所定の応答のＳＩＰメッセージを受信した際に、当該ＳＩＰメッセージのボディ部に予め取り決めた記述が有るか否かにより、前記ゲートウェイが呼出音送出の要否を判定し、呼出音送出が必要な場合には前記ゲートウェイが生成した呼出音を、前記発端末に向けて送出する、
ことを特徴とする呼出音提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼出音提供装置および呼出音提供方法に関し、複数網間で通信路を確立する通信システムにおける呼出音の制御に関する。
【背景技術】
【０００２】
例えば、固定電話と携帯電話とは互いに異なる事業者が管理する複数の網にそれぞれ接続されるのが一般的である。したがって、固定電話と携帯電話との間で通話する場合には、固定電話が接続された一方の網と、携帯電話が接続されたもう一方の網との間をゲートウェイを介して相互に接続し、固定電話と携帯電話との間で通信路（セッション）を確立し、その後でユーザが通話を開始することになる。
【０００３】
また、固定電話や携帯電話から発信した際は、通信路を確立する前に、着信者を呼出中であることを発信者に通知するためにＲＢＴ(Ring Back Tone：呼出音)が発側の端末に提供される。例えば、「プルルッ・・・」のような音が呼出音ＲＢＴとして用いられる。従来の公衆交換網（ＰＳＴＮ：Public Switched Telephone Networks）同士の相互接続時は、着側の網に含まれる交換機にて呼出音ＲＢＴを提供することが一般的である。
【０００４】
また、複数のＶｏＩＰ（Voice over IP）網間を相互接続する場合にも、現状では公衆交換網（ＰＳＴＮ）を経由した接続が一般的であるが、今後はＩＰ（Internet Protocol）ベースの相互接続形態への移行が見込まれる（非特許文献１参照）。
【０００５】
また、ＩＰベースの網間相互接続を行う際に、網間に配備されるゲートウェイ装置の具体的な製品の例が、非特許文献２および非特許文献３にそれぞれ示されている。なお、非特許文献２および非特許文献３のいずれのゲートウェイ装置も、呼出音提供装置としての特別な機能は備えていない。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】坂谷・荒井・鐘ヶ江、“ＩＰ相互接続仕様に関する標準化活動”、ＮＴＴ技術ジャーナル、２０１４年７月１日、第２６巻、第７号、ｐ．６３−６５．
【非特許文献２】“キャリアグレードの高信頼性を確保したＮＧＮを支える網間ゲートウェイ”、ビジネスコミュニケーション、２００９年４月１日、第４６巻、第４号、ｐ４２−４５．
【非特許文献３】“Sonus SBC 5100”、［online］、SONUS NETWORKS, INC.、［２０１６年１月２５日検索］、インターネット<URL:http://www.sonus.net/ja/products/session-border-controllers/sonus-sbc-5100>
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、複数の網を相互接続した場合に、呼出音ＲＢＴを発側網／着側網のどちらで提供するかについて、明確な標準規定は無い。したがって、ＩＰ網においては、発端末が呼出音ＲＢＴを生成する場合もあれば、着側網が呼出音ＲＢＴを生成する場合もある。
【０００８】
例えば、ＴＴＣ（一般社団法人 情報通信技術委員会）が規定しているドキュメント「JT-Q3402」によれば、次の事項が規定されている。「ＳＤＰ（Session Description Protocol）を含まない180(Ringing)レスポンス受信を契機に発端末が音源を生成する」なお、この規格は、主に固定端末に適用される。また、主に携帯電話端末の仕様として利用される「GSMA IR92」の規格においても、呼出音ＲＢＴは発端末で生成することを期待している。
【０００９】
つまり、「TTC JT-Q3402」や「GSMA IR92」の規格を採用している場合には、網側が呼出音ＲＢＴを生成して発端末に送出する必要はない。しかし、現実には、着信者を呼出中に呼出音ＲＢＴ相当の音声（音楽など）を着側網から発端末に提供するサービスが存在している。それ以外にも、事業者のポリシによっては、着側網から呼出音を送出するケースも想定される。
【００１０】
現在、事業者網間を接続する場合には、公衆交換網ＰＳＴＮを経由するようにシステムを構成するのが一般的である。しかし、ＰＳＴＮ系の設備はいずれ維持限界を迎えるため、今後はＩＰ網同士の相互接続が進む見通しである。
【００１１】
しかしながら、上記のように呼出音ＲＢＴを発側網／着側網のどちらで提供するかについて明確な規定が無いので、特にＩＰ網同士を相互接続した場合に問題が生じる可能性が高い。すなわち、発側網の設備と着側網の設備とのいずれも、相手側が呼出音ＲＢＴを生成して送出することを期待している状況になり、発端末のユーザに呼出音ＲＢＴが届かない状況の発生が危惧される。
【００１２】
その結果、実際には呼出中であるにもかかわらず、発端末のユーザは呼出音ＲＢＴの代わりに無音状態を認識する。そして、発端末のユーザが接続に失敗したものと思い込み、呼出中に接続を途中放棄することになる。そのため、通信が成立しない。
【００１３】
上記のような状況で、問題が生じないＩＰ網間接続を実現するためには、発側網／着側網のいずれかで呼出音ＲＢＴの送出に関わる機能を改修しなければならず、実際には端末もしくは網内装置の改修が必要であるため、期間および費用を要してしまう。
【００１４】
上記の事項について、より具体的な内容を、各図面を参照しながら以下に説明する。
複数の網を相互接続した一般的な通信システムにおける呼出音の送出動作例を図７、図８、および図９にそれぞれ示す。
【００１５】
図７に示した通信システムは、固定端末に相当する発端末５３にて呼出音を生成する例である。この通信システムにおいては、固定端末に相当する発端末５３が発側網５１に接続され、呼出先の着端末５４が着側網５２に接続されている状況を想定している。したがって通信システムは、発端末５３と着端末５４との間の通信を可能にするために、発側網５１と着側網５２とを相互接続するように構成される。ここで、発側網５１および着側網５２は、例えば互いに異なる通信事業者が所有または管理するのが一般的な状況である。
【００１６】
図７に示すように、発端末５３の呼により着端末５４との間の通信路を確立する際には、最初のシーケンスＱ３１で発端末５３が、着端末５４に対するＳＩＰ（Session Initiation Protocol：セッション確立プロトコル）のリクエスト「INVITE with SDP(offer)」を発側網５１に送出する。発側網５１は、呼出先の着端末５４が接続されている着側網５２に向けて、シーケンスＱ３２で、このリクエスト「INVITE with SDP(offer)」を中継する。
【００１７】
着側網５２は、シーケンスＱ３３で、このリクエスト「INVITE with SDP(offer)」を着端末５４に中継する。これにより着端末５４は、発端末５３からのＳＩＰのリクエスト「INVITE with SDP(offer)」を受信する。
【００１８】
着端末５４はシーケンスＱ３４で、ＳＩＰのレスポンス「180 without SDP」を着側網５２に返す。着側網５２はシーケンスＱ３５で、このレスポンス「180 without SDP」を発側網５１に中継する。発側網５１は、シーケンスＱ３６で、このレスポンス「180 without SDP」を発端末５３に中継する。これにより発端末５３は、着端末５４からのレスポンス「180 without SDP」を受信する。
【００１９】
図７に示した通信システムにおいては、発端末５３は、着端末５４から受け取ったレスポンス「180 without SDP」により、着端末５４を呼出中であると認識する。そして、発端末５３自身が内蔵する音源を用いて、シーケンスＱ３７で呼出音ＲＢＴを生成する。この呼出音ＲＢＴが、実際の音響として発端末５３を操作するユーザ、すなわち発信者が知覚できるように発端末５３の不図示のスピーカから出力される。
【００２０】
例えば、上記のＴＴＣドキュメント「JT-Q3402」の規定に従って動作する通信システムにおいては、図７に示したシーケンスの動作を行うので、発端末５３自身が呼出音ＲＢＴを出力する。この場合は、着側網５２は呼出音ＲＢＴを送出する必要はない。
【００２１】
図８に示した通信システムは、着側網６２の不図示の音源サーバから呼出音ＲＢＴを送出する例である。この通信システムにおいても、発端末６３の呼により着端末６４との間の通信路を確立する際には、最初のシーケンスＱ４１で発端末６３がＳＩＰのリクエスト「INVITE with SDP(offer)」を発側網６１に送出する。これを受け取った発側網６１は、呼出先の着端末６４が接続されている着側網６２に向けて、シーケンスＱ４２で、このリクエスト「INVITE with SDP(offer)」を中継する。
【００２２】
着側網６２は、シーケンスＱ４３で、このリクエスト「INVITE with SDP(offer)」を着端末６４に中継する。これにより着端末６４は、発端末６３からのＳＩＰのリクエスト「INVITE with SDP(offer)」を受信する。着端末６４はシーケンスＱ４４で、ＳＩＰのレスポンス「183 with SDP」を着側網６２に返す。着側網６２は、シーケンスＱ４５で、ＳＩＰのレスポンス「183 with SDP」を、発側網６１に中継する。このレスポンス「183 with SDP」は、何らかのメディア、この場合は呼出音ＲＢＴを着側網６２が流す意図があることを示している。
【００２３】
発側網６１は、シーケンスＱ４６で、このレスポンス「183 with SDP」を発端末６３に中継する。これにより発端末６３は、着端末６４からのレスポンス「183 with SDP」を受信する。また、着側網６２は、シーケンスＱ４７で不図示の音源サーバにより、呼出音ＲＢＴのメディアパケットを送出する。この呼出音ＲＢＴは発側網６１を経由して発端末６３に届く。また、発端末６３は、受け取ったレスポンス「183 with SDP」によりメディアパケットが届くことを認識しているので、発側網６１を経由して受け取った呼出音ＲＢＴのメディアパケットを処理して再生し、呼出音ＲＢＴの音響として不図示のスピーカから出力する。
【００２４】
一方、図９に示した通信システムは、公衆交換網であるＰＳＴＮ７２から呼出音ＲＢＴを送出する例である。この通信システムにおいては、固定端末に相当する発端末７３が発側網７１に接続され、呼出先の着端末（図示せず）が発側網７１とは異なる着側網（図示せず）に接続されている状況を想定している。そして通信システムは、発側網７１と着側網とを相互接続するために、公衆交換網であるＰＳＴＮ７２を用いている。図９のように、ＰＳＴＮ７２を利用して複数の網を相互接続する場合には、着側の網に含まれる交換機にて呼出音ＲＢＴを提供することが一般的である。
【００２５】
図９に示した通信システムにおいても、発端末７３の呼により不図示の着端末との間の通信路を確立する際には、最初のシーケンスＱ５１で発端末７３がＳＩＰのリクエスト「INVITE with SDP(offer)」を送出する。これを受け取った発側網７１は、ＰＳＴＮ７２に向けて、シーケンスＱ５２でメッセージＩＡＭ（Initial Address Message）を送出する。このメッセージＩＡＭは、指定の相手まで回線の接続を要求することを意味しており、主な情報として発信者電話番号、および着信者電話番号が含まれている。
【００２６】
ＰＳＴＮ７２は、発側網７１から受信したメッセージＩＡＭに従い、着端末が接続されている着側網との間でメッセージのやり取りを行う。そして、シーケンスＱ５３でメッセージＣＰＧ（Call Progress）をＰＳＴＮ７２が発側網７１に向けて送出する。このメッセージＣＰＧは、呼出中などの途中経過を知らせる意味を持つ。
【００２７】
発側網７１は、ＰＳＴＮ７２から受け取ったメッセージＣＰＧに従い、シーケンスＱ５４で、レスポンス「183 with SDP」を発端末７３に向けて送出する。また、着側網で生成される呼出音ＲＢＴがＰＳＴＮ７２に入力されるので、ＰＳＴＮ７２はこの呼出音ＲＢＴをシーケンスＱ５５で発側網７１に転送する。この呼出音ＲＢＴは、更に発側網７１から発端末７３に向けて転送される。
【００２８】
また、発端末７３はシーケンスＱ５４で受け取ったレスポンス「183 with SDP」によりメディアパケットが届くことを認識しているので、発側網７１を経由して受け取った呼出音ＲＢＴのメディアパケットを処理して再生し、呼出音ＲＢＴの音響として出力する。
【００２９】
図９に示した通信システムのように、ＰＳＴＮ７２を介して複数の網を相互接続する場合には、呼出音ＲＢＴの送出について現状で問題が生じることはない。しかし、非特許文献１に示されているように、ＰＳＴＮ７２を利用することなく複数のＩＰ網を相互接続する状況においては、例えば図７に示した通信システムと、図８に示した通信システムとが混在することが想定される。
【００３０】
ＰＳＴＮを利用せずに複数の網を相互接続した一般的な通信システムにおいて、呼出音の提供に支障が生じる場合の具体例を図１０に示す。図１０に示した通信システムにおいては、固定端末に相当する発端末８３が発側網８１に接続され、携帯電話端末に相当する呼出先の着端末８４が着側網８２に接続されている状況を想定している。したがって通信システムは、発端末８３と着端末８４との間の通信を可能にするために、発側網８１と着側網８２とをＰＳＴＮを使わずに相互接続するように構成される。ここで、発側網８１および着側網８２は、例えば互いに異なる通信事業者が所有または管理している状況である。したがって、発側網８１および着側網８２のそれぞれは規格で定められた事項を除くと、相手側の端末の状況を知ることはできない。
【００３１】
図１０に示すように、発端末８３の呼により着端末８４との間の通信路を確立する際には、シーケンスＱ６０にて、着端末８４と着側網８２との間の回線上に、メディア転送用のリソースは確保されていない。このとき、最初のシーケンスＱ６１で発端末８３が、着端末８４に対するＳＩＰのリクエスト「INVITE with SDP(offer，preconditionなし)」を発側網８１に向けて送出する。これを受け取った発側網８１は、呼出先の着端末８４が接続されている着側網８２に向けて、シーケンスＱ６２でリクエスト「INVITE with SDP(offer，preconditionなし)」を中継する。
【００３２】
着側網８２は、シーケンスＱ６３で、このリクエスト「INVITE with SDP(offer，preconditionなし)」を着端末８４に中継する。これにより着端末８４は、発端末８３からのＳＩＰのリクエスト「INVITE with SDP(offer，preconditionなし)」を受信する。着端末８４は、入力されたリクエストに対するＳＩＰのレスポンス「183 with SDP(answer)」をシーケンスＱ６４で着側網８２に向けて送出する。
【００３３】
着側網８２は、このレスポンス「183 with SDP(answer)」をシーケンスＱ６５で発側網８１に中継する。また、発側網８１は、このレスポンス「183 with SDP(answer)」をシーケンスＱ６６で発端末８３に中継する。これにより発端末８３は、着端末８４からのレスポンス「183 with SDP(answer)」を受信する。
【００３４】
図１０に示した通信システムにおいて、発端末８３は、シーケンスＱ６６で受け取ったレスポンスに「183 with SDP(answer)」が含まれているので、何らかのメディア、つまり呼出音ＲＢＴが着側網８２の不図示の音源サーバから送信されるものと期待する。
【００３５】
また、何らかのメディアの転送を可能にするために、シーケンスＱ６７で、着端末８４と着側網８２との間の回線上に、メディア転送用のリソースを確保する。但し、図１０に示す例では、着側網８２に呼出音ＲＢＴを送出する意図がない状況を想定している。そのため、着端末８４はシーケンスＱ６８でレスポンス「180 without SDP」を送出する。このレスポンス「180 without SDP」は、呼出音ＲＢＴを発端末８３側で生成することを期待するものである。
【００３６】
着側網８２は、シーケンスＱ６９で、このレスポンス「180 without SDP」を発側網８１に中継する。また、発側網８１は、シーケンスＱ７０で、このレスポンス「180 without SDP」を発端末８３に中継する。これにより発端末８３は、着端末８４からのレスポンス「180 without SDP」を受信する。
【００３７】
発端末８３は、ＴＴＣドキュメント「JT-Q3402」の規定に従って動作する。この発端末８３は、シーケンスＱ７０でレスポンス「180 without SDP」を受信する前に、シーケンスＱ６６でレスポンス「183 with SDP(answer)」を受信しているので、着側網８２から呼出音ＲＢＴが送信されることを期待する。よって発端末８３自身は、内部で呼出音ＲＢＴを生成しない。
【００３８】
しかし、実際には着端末８４は「GSMA IR92」の規定に従って動作するので、着端末８４は呼出音ＲＢＴを送出しない。したがって、発端末８３が着端末８４を呼出中であるにもかかわらず、呼出音ＲＢＴが出力されることはなく、ユーザには無音状態と認識されてしまう。このため、ユーザは呼出に失敗したと思い込み、呼出をキャンセルすることになる。
【００３９】
図１０に示した通信システムにおいて呼出音ＲＢＴの問題が生じるのは、各網の事業者のポリシの違いや、通信規格上の違いに起因する。
例えば、主に携帯電話端末が参照する「GSMA IR.92 - IMS Profile for Voice and SMS(v9.0)」の規格においては、要約すれば図１０のシーケンスＱ６４のような状況における重要な事項として、次に示すような事項が規定されている。
【００４０】
（１）リクエスト「INVITE」の受信の際に、ＳＤＰを含むレスポンス「183(Session Progress)」を送信する必要がある。
（２）リクエスト「INVITE」の受信の際に、リソースが確保されるまでは、レスポンス「180(Ringing)」を送信してはいけない。
【００４１】
一方、主に固定端末が参照する「TTC JT-Q.3402」の規格によれば、要約すると、図１０のシーケンスＱ６６，Ｑ７０のレスポンスを受信した発端末８３の状況に相当する重要な事項として、次に示すような事項が規定されている。
【００４２】
（３）ＳＤＰを含まないレスポンス「180(Ringing)」を受信した場合には、その時点より、呼出中音は自身の音源により生成しなければならない。
（４）端末はＳＤＰを含むレスポンス「1xx」を受信した場合には、パスを接続することによりアーリーメディアを確立できなければならない。以降、端末は同一ダイアログにおいて、どのレスポンス「1xx」を受信しても、そのＳＤＰの有無にかかわらず、受信メディアの再生を継続しなければならない。すなわち、メディアの張り替え処理を行ってはならない。
【００４３】
図１０に示した通信システムにおいて、着端末８４は上記（１）の規定に従い、シーケンスＱ６４でＳＤＰを含むレスポンス「183」を送信している。また、着端末８４は上記（２）の規定に従い、リソースの確保に成功した後のシーケンスＱ６８で、ＳＤＰなしのレスポンス「180」を送信している。また、着端末８４がＳＤＰなしのレスポンス「180」を送信することにより、上記（３）の規定により、発端末８３がそれ自身で呼出音ＲＢＴを生成することを期待し、着端末８４は呼出音ＲＢＴを送出しない。
【００４４】
しかし、図１０に示す発端末８３は、シーケンスＱ６６で受信したレスポンス「183」にＳＤＰが含まれているため、上記（４）の規定に従って動作する。すなわち、次のシーケンスＱ７０でレスポンス「180」を受信しても、呼出音ＲＢＴのメディアパケットが着側網８２から送信されるものと期待し、発端末８３自身が呼出音ＲＢＴを生成することはない。その結果、図１０に示すように呼出の際に発端末８３が無音状態になってしまう。
【００４５】
本発明は、上記の状況に鑑みてなされたものであり、相互に接続する複数の網の間で呼出音の送出ポリシに関する明確な取り決めが存在しない状況であっても、着端末の呼出時に発端末のユーザに対して呼出音を確実に与えることが可能な呼出音提供装置および呼出音提供方法を提供することを目的とする。
【課題を解決するための手段】
【００４６】
（１）発端末が接続される第１の網と、着端末が接続される第２の網との間をＳＩＰ（Session Initiation Protocol）によって相互に接続するゲートウェイに設置され、前記発端末の呼により前記発端末と前記着端末との間の通信路を確立する前に、前記発端末の呼出中であることを表す所定の呼出音を前記発端末に対して提供するための呼出音提供装置であって、
呼出音を生成する呼出音生成部と、
前記発端末の呼により前記発端末と前記着端末との間の通信路を確立する前に、通信路の確立要求に対する前記第２の網からの所定の応答のＳＩＰメッセージを受信した際に、当該ＳＩＰメッセージに、事前に取り決めた記述が有るか否かにより、前記呼出音生成部からの呼出音送出の要否を判定し、呼出音送出が必要な場合には前記呼出音生成部から前記発端末に向けて呼出音を送出する呼出音送出制御部と、
を備える。
【００４７】
この呼出音提供装置によれば、着側の前記第２の網が呼出音を送出しない場合に、前記呼出音送出制御部の制御により前記呼出音生成部の生成した呼出音を、前記ゲートウェイから前記発端末に向けて送出できる。また、着側の前記第２の網が呼出音を送出する場合には、前記呼出音生成部から呼出音を送出しないので、前記第２の網の呼出音を優先的に前記発端末に届けることができる。
【００５４】
（２）前記応答とは、ＳＩＰ（Session Initiation Protocol）の180応答、181応答、182応答、183応答のうちいずれかである、
上記（１）に記載の呼出音提供装置。
【００５５】
この呼出音提供装置によれば、ＳＩＰの18x応答によって呼出音送出の要否を判定したり、この応答を受信した際に着端末の情報を取得して呼出音送出の要否に係る情報を取得することができる。
（３）前記記述は、前記ＳＩＰメッセージのヘッダ部のＰアーリーメディアヘッダ指定行に含まれている、
ことを特徴とする上記（２）に記載の呼出音提供装置。
これにより、通信システムは、このＰアーリーメディアヘッダ指定行を、呼出音を制御するための新たな取り決めの１つとして利用できる。
（４）前記記述は、前記ＳＩＰメッセージのボディ部のＣＡＴ指定行に含まれている、
ことを特徴とする上記（２）に記載の呼出音提供装置。
これにより、通信システムは、このＣＡＴ指定行を、呼出音を制御するための新たな取り決めの１つとして利用できる。
【００５６】
（５）前記呼出音送出制御部は、前記呼出音生成部からの呼出音送出が不要と認識した場合に、前記第２の網から入力されるメディアパケットを前記第１の網に転送する、
上記（１）に記載の呼出音提供装置。
【００５７】
この呼出音提供装置によれば、呼出音が着側の前記第２の網からメディアパケットとして送出される場合に、このメディアパケットをそのまま転送することで、呼出音を発端末に届けることができる。したがって、発端末のユーザは、呼出音提供装置自体が生成する呼出音だけでなく、着側の前記第２の網が独自のサービスとして提供する特別な呼出音も利用できる。
【００５８】
（６）発端末が接続される第１の網と、着端末が接続される第２の網と、これらの間をＳＩＰ（Session Initiation Protocol）によって相互に接続するゲートウェイとを含む通信システムを制御し、前記発端末の呼により前記発端末と前記着端末との間の通信路を確立する前に、前記発端末の呼出中であることを表す所定の呼出音を前記発端末に対して提供するための呼出音提供方法であって、
前記発端末の呼により前記発端末と前記着端末との間の通信路を確立する前に、通信路の確立要求に対する前記第２の網からの所定の応答のＳＩＰメッセージを受信した際に、当該ＳＩＰメッセージのボディ部に予め取り決めた記述が有るか否かにより、前記ゲートウェイが呼出音送出の要否を判定し、呼出音送出が必要な場合には前記ゲートウェイが生成した呼出音を、前記発端末に向けて送出する、
ことを特徴とする。
【００５９】
この呼出音提供方法によれば、着側の前記第２の網が呼出音を送出しない場合に、前記ゲートウェイが生成した呼出音を、前記ゲートウェイから前記発端末に向けて送出できる。また、着側の前記第２の網が呼出音を送出する場合には、前記ゲートウェイ自体が呼出音を生成しないので、前記第２の網の呼出音を優先的に前記発端末に届けることができる。
【発明の効果】
【００６０】
本発明の呼出音提供装置および呼出音提供方法によれば、相互に接続する複数の網の間で呼出音の送出ポリシに関する明確な取り決めが存在しない状況であっても、着端末の呼出時に発端末のユーザに対して呼出音を確実に与えることができる。すなわち、着側の前記第２の網が呼出音を送出しない場合に、前記ゲートウェイが生成した呼出音を、前記ゲートウェイから前記発端末に向けて自動的に送出できる。また、着側の前記第２の網が呼出音を送出する場合には、前記ゲートウェイ自体が呼出音を生成しないので、前記第２の網の呼出音を優先的に前記発端末に届けることができる。
【図面の簡単な説明】
【００６１】
【図１】本発明の実施形態における呼出音提供装置を含む通信システムの構成および動作の概要を示すシーケンス図である。
【図２】図１に示した通信システムに含まれるゲートウェイ装置の特徴的な動作（１）を示すフローチャートである。
【図３】ゲートウェイ装置が図２の動作（１）を実施する場合のシステムの動作手順を示すシーケンス図である。
【図４】図１に示した通信システムに含まれるゲートウェイ装置の特徴的な動作（２）を示すフローチャートである。
【図５】ゲートウェイ装置が図４の動作（２）を実施する場合のシステムの動作手順を示すシーケンス図である。
【図６】ゲートウェイ装置が図４の動作（２）を実施する場合に転送されるＳＩＰメッセージの具体例およびゲートウェイ装置の判定動作を示す模式図である。
【図７】複数の網を相互接続した一般的な通信システム（１）における呼出音の送出動作例を示すシーケンス図である。
【図８】複数の網を相互接続した一般的な通信システム（２）における呼出音の送出動作例を示すシーケンス図である。
【図９】複数の網を相互接続した一般的な通信システム（３）における呼出音の送出動作例を示すシーケンス図である。
【図１０】複数の網を相互接続した一般的な通信システムにおいて呼出音の提供に支障が生じる場合の具体例を示すシーケンス図である。
【発明を実施するための形態】
【００６２】
本発明の実施形態について各図を参照しながら以下に説明する。
＜通信システムの構成および動作の概要＞
＜構成の説明＞
本発明の実施形態における呼出音提供装置を含む通信システムの構成および動作の概要を図１に示す。図１に示した通信システムは、発端末１１、発側網１０、ゲートウェイ（ＧＷ）装置３０、着側網２０、および着端末２１を備えている。また、ゲートウェイ装置３０はＲＢＴ音源３１および呼出音送出制御部３２を内蔵している。
【００６３】
発端末１１および着端末２１の各々は、例えば固定端末である固定電話機、携帯電話端末である携帯電話機やスマートフォン等に相当する端末であり、音声通話機能を備えている。図１に示した例では、固定端末である発端末１１が発側網１０に接続され、携帯電話端末である着端末２１が着側網２０に接続されている。
【００６４】
また、この例では発側網１０および着側網２０が、それぞれ異なる通信事業者によって所有または管理される場合を想定している。したがって、互いに独立している発側網１０と着側網２０との間で通信できるように、これらの間は、ゲートウェイ装置３０を用いて相互接続されている。なお、図１に示したゲートウェイ装置３０については、発側網１０の設備の一部分として配備することを想定しているが、着側網２０の設備の一部分としてゲートウェイ装置３０を配備してもよい。
【００６５】
図１に示したゲートウェイ装置３０が、本発明の呼出音提供装置の機能を搭載している。また、このゲートウェイ装置３０にはＲＢＴ音源３１が接続されている。ＲＢＴ音源３１は、着信側の呼出中であることを表す呼出音ＲＢＴ、例えば「プルルッ・・・」のような音響に相当する信号を生成する装置である。
【００６６】
図１に示した通信システムの各部は、ＩＰ（Internet Protocol）網として構成されている。発側網１０および着側網２０のそれぞれは、ＶｏＩＰ(Voice over Internet Protocol)通信サービスを提供するための機能を備えている。このように、ＩＰ網同士が公衆交換網（ＰＳＴＮ）を介さずに直接相互接続される場合には、呼出音ＲＢＴの提供の際に図１０に示したような問題が生じる可能性がある。そこで、問題を回避するためにゲートウェイ装置３０に呼出音提供装置の機能を搭載している。
【００６７】
＜動作の説明＞
発端末１１のユーザが着端末２１のユーザとの間で通話するために発端末１１の発信操作を行うと、図１に示す一連のシーケンスが所定の手順で実行される。すなわち、セッション確立プロトコルＳＩＰを利用して、発端末１１と着端末２１との間で通話するための通信路を確立し、その後で通話が開始される。図１に示した一連のシーケンスは、通信路が確立する前の呼出の動作を示している。
【００６８】
発端末１１のユーザが着端末２１を呼び出すための発呼の操作を行うと、最初のシーケンスＱ１で、発端末１１がＳＩＰのリクエスト「INVITE with SDP(offer，preconditionなし)」を発側網１０に送出する。発側網１０は、シーケンスＱ２で、このリクエスト「INVITE with SDP(offer，preconditionなし)」をゲートウェイ装置３０に中継する。
【００６９】
ゲートウェイ装置３０は、発側網１０を介して発端末１１からリクエストを受信すると、呼出先の着端末２１が接続されている着側網２０に向けて、シーケンスＱ３でリクエスト「INVITE with SDP(offer，preconditionなし)」を送信する。着側網２０は、受信したリクエストによって指定された電話番号に該当する着端末２１に対して、シーケンスＱ４でリクエスト「INVITE with SDP(offer，preconditionなし)」を中継する。これにより着端末２１は、発端末１１からのリクエスト「INVITE with SDP(offer，preconditionなし)」を受信する。
【００７０】
着端末２１は、受信したリクエストに対して、呼出中であることを表すＳＩＰのレスポンス「183 with SDP(answer)」をシーケンスＱ５で着側網２０に送出する。着側網２０は、シーケンスＱ６で、このレスポンス「183 with SDP(answer)」をゲートウェイ装置３０に中継する。
【００７１】
ゲートウェイ装置３０は、着側網２０を介して着端末２１からのレスポンスを受信すると、シーケンスＱ７でレスポンス「183 with SDP(answer)」を発側網１０に向けて送出する。発側網１０は、シーケンスＱ８で、このレスポンス「183 with SDP(answer)」を発端末１１に中継する。これにより発端末１１は、着端末２１からのレスポンス「183 with SDP(answer)」を受信する。
【００７２】
また、ゲートウェイ装置３０は、特徴的な制御として、着側網２０からのシーケンスＱ６のレスポンスを受信すると、次のシーケンスＱ９で呼出音ＲＢＴの送出が必要か否かの判定を行う。この判定結果に応じて、必要がある場合は次のシーケンスＱ１０で、ＲＢＴ音源３１の生成した呼出音ＲＢＴをメディアパケットとしてゲートウェイ装置３０から発側網１０に向けて送出する。この呼出音ＲＢＴのメディアパケットは、発側網１０を経由して発端末１１に届けられる。したがって、発端末１１は受信したメディアパケットを音響として再生し、呼出音ＲＢＴがユーザに聞こえるように出力できる。
【００７３】
シーケンスＱ９でゲートウェイ装置３０は、レスポンス「183 with SDP(answer)」の受信時に、着側網２０の方向からメディアパケットが流れてくるか否かを判定する。具体的な判定方法については、複数の種類があり、複数種類のうちいずれか１つの方法を用いる。判定方法の詳細は後述する。
【００７４】
図１に示した動作においては、着端末２１は、シーケンスＱ１１でレスポンス「180 without SDP」を着側網２０に送出している。このレスポンスは着端末２１が呼出中であることを意味している。着側網２０は、シーケンスＱ１２で、このレスポンス「180 without SDP」をゲートウェイ装置３０に中継する。
【００７５】
ゲートウェイ装置３０は、着側網２０を介してシーケンスＱ１２のレスポンスを受信すると、シーケンスＱ１３でレスポンス「180 without SDP」を発側網１０に向けて送出する。発側網１０は、シーケンスＱ１４で、このレスポンス「180 without SDP」を発端末１１に中継する。これにより発端末１１は、着端末２１からのレスポンス「180 without SDP」を受信する。
【００７６】
但し、発端末１１はシーケンスＱ８で受信したレスポンス「183 with SDP(answer)」により事前にメディアパケットが送られてくることを認識している。そして、発端末１１はシーケンスＱ１０で届けられる呼出音ＲＢＴのメディアパケットを受信し、この呼出音ＲＢＴを音響として不図示のスピーカで再生してユーザに提供する。
【００７７】
図１に示した通信システムにおいては、シーケンスＱ１０により発端末１１が受け取った呼出音ＲＢＴのメディアパケットを用いて、発端末１１は呼出音ＲＢＴをユーザに提供することができる。しかし、もしもゲートウェイ装置３０が特別な制御を実施しない場合には、図１０に示した動作と同様の結果となり、発端末１１は呼出音ＲＢＴを音響として再生できない。つまり、ゲートウェイ装置３０が図１のシーケンスＱ９，Ｑ１０の制御を実施することにより、問題の発生を回避し、発端末１１のユーザに呼出音ＲＢＴを提供できる。
【００７８】
＜動作の詳細の説明＞
＜動作例（１）＞
図１に示した通信システムに含まれるゲートウェイ装置３０の特徴的な動作（１）を図２に示す。また、ゲートウェイ装置３０が図２の動作（１）を実施する場合のシステムの動作手順を図３に示す。
【００７９】
図２の制御を実行する場合のゲートウェイ装置３０の動作について以下に説明する。
ゲートウェイ装置３０は、着側網２０からのＳＤＰ付の「18x」応答を受信すると、図２のステップＳ１１からステップＳ１２に進む。ここで「18x」応答とは、呼び出し中を示す「180 Ringing」、転送中を示す「181 Call Is Being Forwarded」、処理待ち中を示す「182 Queued」、セッションが進行したことを示す「183 Session Progress」のうち何れかをいう。そして、ゲートウェイ装置３０は内部タイマを用いて経過時間Ｔｘの計測を開始した後、次のステップＳ１３に進む。
【００８０】
ゲートウェイ装置３０はステップＳ１３で、着側網２０から到来するメディアパケットを監視する。そして、メディアパケット受信を検知するとステップＳ１４からステップＳ１５に進み、メディアパケットを受信しない場合はステップＳ１４からステップＳ１７に進む。
【００８１】
ゲートウェイ装置３０は、ステップＳ１５では、着側網２０から受信したメディアパケットをそのまま発側網１０に向けて転送する。また、ゲートウェイ装置３０は呼出音送出の終了条件が成立したか否かをステップＳ１６で識別し、この終了条件が成立するまでステップＳ１５の処理を継続する。
【００８２】
ステップＳ１７では、ゲートウェイ装置３０はステップＳ１２を実行した時からの経過時間Ｔｘを事前に定めた時間長の閾値Ｔｗと比較し、経過時間Ｔｘが閾値Ｔｗを超えると、すなわちタイムアウトを検知すると次のステップＳ１８に進む。経過時間Ｔｘが閾値Ｔｗ以内の場合は、ステップＳ１７からステップＳ１３に戻って同じ処理を繰り返す。なお、閾値Ｔｗの具体例としては、１秒〜５秒程度の値が想定されるが、この値は必要に応じて変更できる。
【００８３】
ステップＳ１８では、ゲートウェイ装置３０は、それ自身の内部で、ＲＢＴ音源３１が生成した呼出音ＲＢＴのメディアパケットを、発側網１０に向けて送出する。ゲートウェイ装置３０は、呼出音送出の終了条件が成立したか否かをステップＳ１９で識別し、この終了条件が成立するまでステップＳ１８の処理を継続する。例えば、発端末１１と着端末２１との間の通信路の確立に成功した場合や、発端末１１が呼出をキャンセルしたような場合に、呼出音送出の終了条件が成立する。
【００８４】
図３に示した動作においても、図１に示した動作と同様に、各シーケンスＱ２，Ｑ３，Ｑ６，Ｑ７が実行される。そして、図３に示すシーケンスＱ９ａで、ゲートウェイ装置３０が図２に示した処理を実行する。
【００８５】
すなわち、シーケンスＱ９ａにおいて、ゲートウェイ装置３０は一定の監視期間に亘り、着側網２０から到来するメディアパケットの有無を監視する。つまり、ゲートウェイ装置３０は、図２に示した閾値Ｔｗに相当する長さの監視期間に亘り、図２のステップＳ１３でメディアパケットの有無を監視する。
【００８６】
着側網２０からのメディアパケットを受信した場合は、ゲートウェイ装置３０はこのメディアパケットをそのままステップＳ１５で発側網１０に転送する。監視期間の間にゲートウェイ装置３０が着側網２０からのメディアパケットを受信しなかった場合は、ステップＳ１８でゲートウェイ装置３０が呼出音ＲＢＴを生成する。したがって、図３のシーケンスＱ１０で呼出音ＲＢＴのメディアパケットがゲートウェイ装置３０から送出される。
【００８７】
＜動作例（２）＞
図１に示した通信システムに含まれるゲートウェイ装置３０の特徴的な動作（２）を図４に示す。また、ゲートウェイ装置３０が図４の動作（２）を実施する場合のシステムの動作手順を図５に示す。
【００８８】
図４の制御を実行する場合のゲートウェイ装置３０の動作について以下に説明する。
ゲートウェイ装置３０は、着側網２０からのＳＤＰ付の「18x」応答を受信すると、図４のステップＳ２１からステップＳ２２に進む。そして、ゲートウェイ装置３０は受信した応答に含まれるＳＤＰヘッダまたはＳＤＰ情報に基づいて、それ自身の呼出音ＲＢＴ送出要否を判定する。
【００８９】
ステップＳ２２でゲートウェイ装置３０が「送出要」と判定した場合は、ステップＳ２３からステップＳ２４に進む。そして、ゲートウェイ装置３０は内部のＲＢＴ音源３１が生成した呼出音ＲＢＴのメディアパケットを、発側網１０に向けて送出する。ゲートウェイ装置３０は、呼出音送出の終了条件が成立したか否かをステップＳ２５で識別し、この終了条件が成立するまでステップＳ２４の処理を継続する。例えば、発端末１１と着端末２１との間の通信路の確立に成功した場合や、発端末１１が呼出をキャンセルしたような場合に、呼出音送出の終了条件が成立する。
【００９０】
なお、ステップＳ２２でゲートウェイ装置３０が「送出不要」と判定した場合は、着側網２０側から呼出音ＲＢＴのメディアパケットが入力される可能性がある。呼出音ＲＢＴのメディアパケットが入力された場合には、ゲートウェイ装置３０は、図２に示したステップＳ１５と同様に、入力されたメディアパケットをそのまま発側網１０に向けて転送する。
【００９１】
図５に示した動作においても、図１に示した動作と同様に、各シーケンスＱ２，Ｑ３，Ｑ６，Ｑ７が実行される。そして、図５に示すシーケンスＱ９ｂで、ゲートウェイ装置３０が図４に示した処理を実行する。
【００９２】
すなわち、シーケンスＱ９ｂにおいて、ゲートウェイ装置３０は図４のステップＳ２２を実行するので、直前のシーケンスＱ６で受信したレスポンス「183 with SDP(answer)」のＳＩＰヘッダまたはＳＤＰ情報の内容に基づいて、それ自身が呼出音ＲＢＴを送出することの要否を判定する。
【００９３】
ゲートウェイ装置３０は、シーケンスＱ９ｂで「ＲＢＴ送出要」と判定した場合には、図４のステップＳ２４を実行するので、図５に示すシーケンスＱ１０で、ＲＢＴ音源３１が生成した呼出音ＲＢＴのメディアパケットを発側網１０に向けて送出する。
【００９４】
＜動作例（２）における判定方法の具体例＞
ゲートウェイ装置３０が図４の動作（２）を実施する場合に転送されるＳＩＰメッセージの具体例およびゲートウェイ装置３０の判定動作を図６に示す。
【００９５】
図１に示した通信システムのように、複数の事業者の網を相互接続し、ＳＩＰを利用して発端末１１と着端末２１との間の通信路を確立する場合に、現在のＳＩＰの標準仕様だけでは、図５に示したシーケンスＱ９ｂで判定するために必要な情報が得られない。したがって、シーケンスＱ９ｂを実現するためには、発側網１０、着側網２０の事業者間で事前に新たな取り決めを行い、特別な通信仕様を追加する必要がある。
【００９６】
図６に示したＳＩＰメッセージ４０には、上記の特別な通信仕様を具体化した情報が含まれている。図６のＳＩＰメッセージ４０は、シーケンスＱ２０で着側網２０から送出され、ゲートウェイ装置３０に入力される。このシーケンスＱ２０は、図５におけるシーケンスＱ６に相当する。
【００９７】
図６に示すＳＩＰメッセージ４０は、シーケンスＱ２０で転送されるレスポンス「183 with SDP(answer)」である。このＳＩＰメッセージ４０は、図６に示すようにヘッダ部４１とボディ部（ＳＤＰ）４２とで構成されている。
【００９８】
図６に示したＳＩＰメッセージ４０のヘッダ部４１には、Ｐアーリーメディアヘッダ指定行４３として「P-Early-Media:sendonly」の記述が含まれている。通信システムは、このＰアーリーメディアヘッダ指定行４３を、呼出音ＲＢＴを制御するための新たな取り決めの１つとして利用できる。例えば、着側網２０に呼出音ＲＢＴをアーリーメディアとして送出する意思がある場合には、着側網２０または着端末２１がＰアーリーメディアヘッダ指定行４３をヘッダ部４１に含めたＳＩＰメッセージ４０を送出する。一方、着側網２０に呼出音ＲＢＴをアーリーメディアとして送出する意思がない場合には、Ｐアーリーメディアヘッダ指定行４３をヘッダ部４１に記述しない。
【００９９】
上記のＰアーリーメディアヘッダ指定行４３の取り決めを採用した場合には、図６に示した［判定例１］の処理を、ゲートウェイ装置３０が図４のステップＳ２２および図５のシーケンスＱ９ｂで実行する。つまり、ゲートウェイ装置３０は、着側網２０から受信したレスポンスのＳＩＰメッセージ４０のヘッダ部４１に、Ｐアーリーメディアヘッダ指定行４３が存在するか否かを判定する。そして、Ｐアーリーメディアヘッダ指定行４３が存在する場合は着側網２０に呼出音ＲＢＴを提供する意思があるものと判定する。Ｐアーリーメディアヘッダ指定行４３が存在しない場合はゲートウェイ装置３０自身が呼出音ＲＢＴを生成する必要があると判定する。
【０１００】
一方、図６に示したＳＩＰメッセージ４０のボディ部（ＳＤＰ）４２の中には、ＣＡＴ指定行４４として、「a=content:g.3gpp.cat」の記述が含まれている。ここで、「3gpp.cat」は、「Customized Alerting Tones」を意味している。通信システムは、このＣＡＴ指定行４４を、呼出音ＲＢＴを制御するための新たな取り決めの１つとして利用できる。例えば、着側網２０に呼出音ＲＢＴをアーリーメディアとして送出する意思がある場合には、着側網２０または着端末２１がＣＡＴ指定行４４をボディ部（ＳＤＰ）４２に含めたＳＩＰメッセージ４０を送出する。一方、着側網２０に呼出音ＲＢＴをアーリーメディアとして送出する意思がない場合には、ＣＡＴ指定行４４をボディ部（ＳＤＰ）４２に記述しない。
【０１０１】
上記のＣＡＴ指定行４４の取り決めを採用した場合には、図６に示した［判定例２］の処理を、ゲートウェイ装置３０が図４のステップＳ２２および図５のシーケンスＱ９ｂで実行する。つまり、ゲートウェイ装置３０は、着側網２０から受信したレスポンスのＳＩＰメッセージ４０のボディ部（ＳＤＰ）４２に、ＣＡＴ指定行４４が存在するか否かを判定する。そして、ＣＡＴ指定行４４が存在する場合は着側網２０にＣＡＴ（Customized Alerting Tones）、すなわち呼出音ＲＢＴを提供する意思があるものと判定する。ＣＡＴ指定行４４が存在しない場合は、ゲートウェイ装置３０自身が呼出音ＲＢＴを生成する必要があると判定する。
【０１０２】
したがって、上述のようなＰアーリーメディアヘッダ指定行４３またはＣＡＴ指定行４４の取り決めを事前に行った場合には、図５に示したシーケンスＱ６でゲートウェイ装置３０が受信するレスポンスに図６に示したＳＩＰメッセージ４０のような情報が含まれる。そのため、ゲートウェイ装置３０が図５のシーケンスＱ９ｂを実行する際に、図６の［判定例１］または［判定例２］に必要な情報をＳＩＰメッセージ４０から取得できる。
【０１０３】
実際には、図６の［判定例１］、［判定例２］のいずれか一方を必要に応じて採用して、事業者間で取り決めればよい。また、ゲートウェイ装置３０は、図６に示したＰアーリーメディアヘッダ指定行４３、ＣＡＴ指定行４４以外の取り決めにより呼出音ＲＢＴの制御を実施してもよい。
【０１０４】
＜上記以外の動作例：動作例（３）＞
例えば図１に示した通信システムにおいて、シーケンスＱ６で着側網２０からゲートウェイ装置３０に向かって呼出音ＲＢＴのメディアパケットが流れてくるか否かは、着端末２１自体の特性や、着端末２１のユーザが契約した通信事業者が管理する着側網２０の特性等により定まる。したがって、図１のシーケンスＱ９でゲートウェイ装置３０がＲＢＴ送出要否を判定する際に、該当する着端末２１の特性を表す特定の情報が既知であれば、ＲＢＴ送出要否は着端末２１毎に事前に推定可能である。
【０１０５】
具体的には、着端末２１毎の電話番号に対応付けて、該当する着端末２１が接続された着側網２０が呼出音ＲＢＴのメディアパケットをゲートウェイ装置３０に向けて送出するか否かを表す情報Ｄｘの一覧を事前に登録したデータベースを用意しておく。そして、このデータベースをゲートウェイ装置３０が参照可能な箇所に設置する。この場合、ゲートウェイ装置３０は図１のシーケンスＱ９で呼出先の着端末２１の電話番号から前記データベースを参照し、該当する情報Ｄｘを取得できる。したがって、取得した情報Ｄｘの内容に基づき、ゲートウェイ装置３０は図１のシーケンスＱ９でＲＢＴ送出要否を直ちに判定できる。
【０１０６】
＜呼出音提供装置の利点＞
図１に示した通信システムに含まれるゲートウェイ装置３０は、「呼出音提供装置」の機能を搭載している。すなわち、ゲートウェイ装置３０は、呼出音を生成するＲＢＴ音源３１と、呼出音送出制御部３２とを備えている。呼出音送出制御部３２は、図２に示した制御や、図４に示した制御を実施することにより、呼出音送出の要否を判定し、呼出音送出が必要な場合には発端末１１に向けて呼出音ＲＢＴを送出する。したがって、例えば図１０に示した通信システムにおける発端末８３の状態のように、着端末８４の呼出中に無音状態になるのを避けることができる。しかも、端末や網内装置に大幅な改修を加える必要がない。したがって、異なる事業者間で複数の網を相互接続する場合に、接続にかかるコストを低減し、接続作業に要する期間も短縮できる。
【０１０７】
また、もしもゲートウェイ装置３０が常に呼出音ＲＢＴを送出する状態であると、図８に示すように着側網６２が呼出音ＲＢＴを送出する場合に、着側網６２の送出する呼出音ＲＢＴとゲートウェイ装置３０の送出する呼出音ＲＢＴとが重複する状況になる。しかし、図１に示したゲートウェイ装置３０は、呼出音送出の要否を判定し、呼出音送出が必要な場合には発端末１１に向けて呼出音ＲＢＴを送出するので、複数の呼出音ＲＢＴが重複して送出される状況は生じない。
【０１０８】
また、ゲートウェイ装置３０が呼出音送出要否を判定する際に、図２に示した制御を実施する場合には、実際に流れてくる呼出音ＲＢＴのメディアを直接監視しているので、例えば事業者間の取り決めと実際の網の動作との間に不整合があるような状況においても、誤動作が生じるのを避けることができる。
【０１０９】
また、ゲートウェイ装置３０が呼出音送出要否を判定する際に、図４に示した制御を実施する場合には、実際のメディアの流れを監視する必要がないため、呼出音ＲＢＴの送出を開始するまでの待ち時間を短縮できる。
【０１１０】
また、ゲートウェイ装置３０が呼出音送出要否を判定する際に、呼出先の着端末２１に関する情報を保持する所定のデータベースを利用する場合にも、実際のメディアの流れを監視する必要がないため、呼出音ＲＢＴの送出を開始するまでの待ち時間を短縮できる。
【０１１１】
また、ゲートウェイ装置３０は、呼出音送出が不要と認識した場合に、例えば図２のステップＳ１５で着側網２０から入力されるメディアパケットを、そのまま発側網１０に送出するので、着側網２０から送出される呼出音ＲＢＴも有効に活用できる。例えば着側網２０にて呼出音ＲＢＴに、所定のメロディなどが使われているときに、このメロディをそのまま発端末１１に送出可能である。
【符号の説明】
【０１１２】
１０，５１，６１，７１，８１  発側網
１１，５３，６３，７３，８３  発端末
２０，５２，６２，８２  着側網
２１，５４，６４，８４  着端末
３０  ゲートウェイ（ＧＷ）装置
３１  ＲＢＴ音源
３２  呼出音送出制御部
４０  ＳＩＰメッセージ
４１  ヘッダ部
４２  ボディ部（ＳＤＰ）
４３  Ｐアーリーメディアヘッダ指定行
４４  ＣＡＴ指定行
７２  ＰＳＴＮ
ＲＢＴ  呼出音
【図１】
0006530336.tif 000002
【図２】
0006530336.tif 000003
【図３】
0006530336.tif 000004
【図４】
0006530336.tif 000005
【図５】
0006530336.tif 000006
【図６】
0006530336.tif 000007
【図７】
0006530336.tif 000008
【図８】
0006530336.tif 000009
【図９】
0006530336.tif 000010
【図１０】
0006530336.tif 000011