JP2005303343A - 電話機 - Google Patents
電話機 Download PDFInfo
- Publication number
- JP2005303343A JP2005303343A JP2004112032A JP2004112032A JP2005303343A JP 2005303343 A JP2005303343 A JP 2005303343A JP 2004112032 A JP2004112032 A JP 2004112032A JP 2004112032 A JP2004112032 A JP 2004112032A JP 2005303343 A JP2005303343 A JP 2005303343A
- Authority
- JP
- Japan
- Prior art keywords
- telephone
- call
- telephone set
- user
- identifier
- 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.)
- Withdrawn
Links
Images
Landscapes
- Telephone Function (AREA)
Abstract
【構成】 発信者から送信されてきた“INVITE”リクエストに記述され、発信者を特定することができる識別アドレスが送信されてきた場合、その識別アドレスを検出し、あらかじめ電話機に記憶させておいた識別アドレスと比較する。その結果、これらの識別アドレスが一致する場合、“INVITE”リクエストの着信を拒否する。
【効果】 “INVITE”リクエストに記述され、かつ発信者の特定が可能な識別アドレスを利用することにより、“INVITE”リクエストの着信を拒否して、いたずら電話を確実に防止する。
【選択図】 図1
【効果】 “INVITE”リクエストに記述され、かつ発信者の特定が可能な識別アドレスを利用することにより、“INVITE”リクエストの着信を拒否して、いたずら電話を確実に防止する。
【選択図】 図1
Description
この発明は、電話機に関し、特にたとえば、いたずら電話を防止できるIP電話機に適用され、呼の確立に必要なセッション情報を含む接続要求を受信する、電話機に関する。
従来のこの種のIP(Internet Protocol)電話機では、ユーザは、いたずら電話を受信すると、番号登録ボタンを押して“INVITE”リクエストのヘッダに含まれる発信元情報(“From”部分)や返信先情報(“Contact”部分)からユーザID、ユーザホストなど、いたずら電話の発信者の特定が可能な情報をIP電話機に登録しておく。そして、登録された情報と同じ情報を有する“INVITE”リクエストを再度受信したとき、IP電話機はいたずら電話であると判断して、その着信を拒否する。
しかし、IP電話の規格であるdraft-ietf-sip-privacy-01やRFC3325によると、発信者は電話をするたびに、発信元情報や返信先情報を任意の情報に書き換えた“INVITE”リクエストを送信することができる。このため、発信者がいたずら電話をかけるたびに、これらの情報を書き換えた“INVITE”リクエストを送信すると、IP電話機は登録された情報に基づいていたずら電話の着信を拒否することができないという問題がある。
それゆえに、この発明の主たる目的は、いたずら電話を確実に防止することができる、電話機を提供することである。
請求項1の発明は、呼の確立に必要なセッション情報を含む接続要求を受信する電話機において、セッション情報に記述されたかつ発信者を識別する識別子を検出する検出手段、任意の識別子を保持するメモリ手段、および検出手段によって検出された識別子がメモリ手段によって保持された識別子と一致するとき呼の確立を拒否する拒否手段を備えることを特徴とする、電話機である。
請求項1の発明によれば、セッション情報に記述され、かつ発信者を識別できる識別子を検出する。一方、あらかじめ任意の識別子を記憶しておく。そして、検出された識別子と任意の識別子とが一致した場合、呼の確立を拒否する。つまり、発信者から送信されてきたセッション情報に記述され、発信者を特定することができる識別子が送信されてきた場合、その識別子を検出し、あらかじめ電話機に記憶させておいた識別子と比較する。その結果、これらの識別子が一致する場合、呼の確立を拒否する。このように、セッション情報に記述され、かつ発信者の特定が可能な識別子を利用することにより、呼の確立を拒否して、いたずら電話を確実に防止する。
請求項2の発明は、請求項1に従属し、検出手段によって検出された識別子がメモリ手段によって保持された識別子と一致しないとき呼確立操作に応答して呼を確立する確立手段をさらに備える、電話機である。
請求項2の発明によれば、検出された識別子と、あらかじめメモリに記憶させておいた識別子とが一致しない場合、いたずら電話ではないと判断して呼を確立することにより、通話が可能になる。
請求項3の発明は、請求項1または2に従属し、呼が確立された後に接続拒否操作を受け付けたとき検出手段によって検出された識別子をメモリ手段に設定する設定手段をさらに備える、電話機である。
請求項3の発明によれば、呼を確立して通話が可能になった後、いたずら電話であるとして接続拒否操作を受け付けると、セッション情報に記述された識別子を検出して、メモリに記憶させる。この結果、同じ識別子を有するセッション情報を含む接続が再び要求されても、いたずら電話であると判断して呼の確立を拒否する。
請求項4の発明は、請求項1ないし3のいずれかに従属し、検出手段によって検出された識別子は、セッション情報に記述されたIPアドレスおよびドメイン名のいずれかを含む識別子である、電話機である。この場合、セッション情報に記述されるIPアドレスおよびドメイン名はいずれも発信者の特定が可能な識別子であるため、いたずら電話を確実に防止できる。
請求項5の発明は、請求項1ないし3のいずれかに従属し、検出手段によって検出された識別子は、電話機の製造時に与えられるかつ互いに異なる識別子である、電話機である。この場合、セッション情報に記述される電話機の製造時に与えられるかつ互いに異なる識別子は、発信者の特定が可能な識別子であるため、いたずら電話を確実に防止できる。
この発明によれば、セッション情報に記述され、かつ発信者を識別できる識別子を利用して呼の確立を拒否するので、いたずら電話を確実に防止することができる。
この発明の上述の目的、その他の目的、特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
図1を参照して、この発明の実施例である電話機Bのユーザが電話機Aのユーザに電話をかける場合の全体構成を説明する。ここで、電話機Aおよび電話機BはいずれもIP電話機(以下、単に“電話機”と表記する)であり、IP網に接続されている。IP網上には、プロキシサーバ40および42が存在しており、電話機Bはプロキシサーバ40およびプロキシサーバ42を介して“INVITE”リクエストを電話機Aに送信する。その結果、電話機Aと電話機Bとの間でRTP(Real-time Transport Protocol)と呼ばれる通信プロトコルによるセッションが確立されると、電話機Aは音声を変換した音声パケットを送受信することができる。したがって、電話機Aのユーザは電話機Bのユーザと通話することができる。
図2を参照して、この発明の実施例である電話機10は、CPU12を含む。CPU12には、DSP14、ディスプレイ16、キーパッド18、フラッシュメモリ20、ネットワークコントローラ22が接続されている。DSP14は、D/A変換器26を介して受話器34に設けられたスピーカ28と接続され、A/D変換器30を介して受話器34に設けられたマイク32と接続されており、スピーカ28に出力する音声やマイク32から入力された音声の処理を行っている。
ネットワークコントローラ22は通信コネクタ24に接続されており、通信コネクタ24は所定のケーブルによってIP網と接続されている。したがって、CPU12はネットワークコントローラ22および通信コネクタ24を介してIP網との間でデータを送受信することができる。
図3を参照して、電話機Bのユーザが電話機Aのユーザに電話をかける場合に、電話機Bから電話機Aに対して送信される“INVITE”リクエストについて説明する。“INVITE”リクエストは、電話機Aと電話機Bとの間の発着信をコントロールするシグナリング技術であるSIP(Session Initiation Protocol)のメッセージの一種である。“INVITE”リクエストは、ヘッダと発着信をコントロールするボディとを含む。ヘッダは発信元情報AIおよび返信先情報BIを含み、ボディのcラインおよびiラインはそれぞれ他の情報を含む。発信元情報AIおよび返信先情報BIの各々には、ユーザIDおよびユーザホストが記載されている。図3に示す“INVITE”リクエストの場合、ユーザIDとして“moto”、ユーザホストとして“10.0.0.1”が記載され、ボディはSDP(Session Description Protocol)形式で記載されている。
この場合、電話機Bのユーザが電話機Aのユーザに対していたずら電話をかけようとするとき、電話機Bのユーザが図3に示すような“INVITE”リクエストを送信すると、電話機Aのユーザはヘッダに含まれるユーザIDおよびユーザホストからいたずら電話をかけてきたのは電話機Bのユーザであることを知ることができる。
このため、電話機Bのユーザは、ユーザIDおよびユーザホストを任意のユーザIDおよびユーザホストに書き換えることによって、いたずら電話が電話機Bから発信されていることをわからなくすることができる。例えば図4に示すように、電話機Bのユーザは、ユーザIDを“moto”から“koto”に、ユーザホストであるIPアドレスを“10.0.0.1”から“10.5.1.0”にそれぞれ書き換えることにより、電話機Bからいたずら電話をしていることをわからなくすることができる。
しかし、規格draft-ietf-sip-privacy-01またはRFC3325によれば、ヘッダのユーザIDを“moto”から“koto”に、およびユーザホストを“10.0.0.1”から“10.5.1.0”に書き換えても、ボディのcラインに記載されたユーザホストを“10.0.0.1”から“10.5.1.0”に書き換えることはできない。このため、いたずら電話の“INVITE”リクエストを受信した電話機Aは、cラインからユーザホストを取得し、フラッシュメモリ20に設けた着信拒否テーブル20aに登録しておく。その後、着信拒否テーブル20aに登録されたユーザホストと同じユーザホストを有する“INVITE”リクエストが再び送信されてきたとき、電話機Aは着信拒否テーブル20aに同じユーザホストがあることを確認して、“INVITE”リクエストの着信を拒否する。なお、cラインに記載されるユーザホストは、電話機BのIPアドレスに限られず、ドメイン名でもよい。この実施例の以下の説明では、IPアドレスおよびドメイン名を含めて識別アドレスCIという。
ここで、電話機Aに送信される“INVITE”リクエストのユーザIDおよびユーザホストを任意のユーザIDおよびユーザホストに書き換える処理は、電話機Bからプロキシサーバ42に送信される“INVITE”リクエストに含まれる情報に基づいて、プロキシサーバ42が行う。このとき、“INVITE”リクエストのcラインに含まれる識別アドレスCIは書き換えられていない。このため、RTPの確立後、電話機Aは、プロキシサーバ40および42を介さず、電話機Bと直接音声パケットを送受信することができる。
次に、図5を参照して、電話機Aが識別アドレスCIを含む“INVITE”リクエストを受信したとき、そのCPU12が実行する処理フローを説明する。
ステップS1で電話機Bからの“INVITE”リクエストを受信するまで待機し、“INVITE”リクエストを受信すると、ステップS3で“INVITE”リクエストのボディのcラインに含まれる識別アドレスCIを取得する。
ステップS5では、取得した識別アドレスCIが、着信拒否番号として着信拒否テーブル20aに登録されている識別アドレスCIと一致するか否かを判定する。その結果、YESと判定した場合はいたずら電話と判断し、ステップS7に進む。ステップS7では、“INVITE”リクエストの着信を拒否することを示す“603 Decline”レスポンスを電話機Bに送信し、後述するステップS27に進む。一方、NOと判定した場合はステップS9に進む。
ステップS9では、“INVITE”リクエストを転送中であることを示す“100 Trying”レスポンスを電話機Bに送信する。ステップS11では、電話機Bに対して電話機Aのユーザを呼び出し中であることを示すため、“180 Ringing”レスポンスを送信する。電話機Aで呼び出し音が発生し、電話機Aのユーザが受話器34を上げると、ステップS13で、“INVITE”リクエストが成功したことを伝える“200 OK”レスポンスを電話機Bに送信する。ステップS15では、電話機Bが“200 OK”レスポンスを受信したことを示す、“ACK”リクエストを受信するまで待機する。“ACK”リクエストを受信すると、電話機Bとの間で直接RTPが確立される。
電話機Bとの間でRTPが確立されると、ステップS17で音声パケットの送受信が開始され、電話機Aのユーザは電話機Bのユーザと通話することができる。電話機Aのユーザは、電話機Bのユーザと通話した結果、いたずら電話と判断すると、キーパッド18に設けられた番号登録ボタン18aを押す。
ステップS19では、CPU12は、番号登録ボタン18aが押されたか否かを判定する。YESと判定したときは、いたずら電話と判断したので、ステップS21に進む。ステップS21では、ステップS3で取得した識別アドレスCIを着信拒否アドレスとしてフラッシュメモリ20に設けられた着信拒否テーブル20aに登録する。登録が完了すると、ステップS27に進む。
一方、ステップS19でNOと判定したときは、ステップS19で10秒経過した否かを判定する。その結果、NOと判定した場合にはステップS19に戻る。また、YESと判定した場合には、いたずら電話ではなかったと判断したので、ステップS25で通話が終了して受話器34が置かれるまで音声パケットの送受信を行う。通話が終了して受話器34が置かれると、ステップS27で電話機Bとの通信を切断して終了する。
このように、電話機Bのユーザがヘッダの発信元情報AIおよび返信先情報BIを書き換えていたずら電話をかけてきたときは、“INVITE”リクエストの中の書き換えることができない識別アドレスを着信拒否アドレスとして着信拒否テーブル20aに登録する。そして、電話機Bのユーザが再びいたずら電話をかけてきたとき、電話機Aは着信拒否テーブル20aに登録された識別アドレスCIに基づいてその着信を拒否することにより、いたずら電話を確実に防止することができる。
次に、図6を参照して、この発明の他の実施例である電話機Bのユーザが電話機Aのユーザに電話をかける場合の全体構成について説明する。ここで、図1の場合と同様に、電話機Aおよび電話機BはいずれもIP電話機であり、IP網に接続されている。IP網上には、プロキシサーバ40および42が存在しており、電話機Bはプロキシサーバ40およびプロキシサーバ42を介して“INVITE”リクエストを電話機Aに送信する。
電話機Aと電話機Bとはまた、アノニマイザ(Anonymizer)44を介しても接続されている。このため、図1の場合と異なり、電話機Aが“INVITE”リクエストを受信すると、電話機Aと電話機Bとの間でアノニマイザ44を介してRTPが確立される。この結果、電話機Aは、アノニマイザ44を介して音声パケットを送受信することができ、電話機Aのユーザは、電話機Bのユーザと通話することができる。この実施例においても、電話機AおよびBの発着信をコントロールするシグナリング技術として、SIPが採用され、そのボディはSDP形式で作成されている。
この実施例に使用される電話機の構成は、図1のIP電話機10の構成と同一であるため、電話機の構成を示す図およびその説明を省略する。
この実施例では、電話機Bから送信されてくる“INVITE”リクエストのボディに含まれるiラインを利用する。通常iラインには、接続に関する情報が格納されているが、発着信を制御するための必須の情報ではない。このため、電話機を製造するときに、メーカが電話機毎に異なる識別番号DIを記載する場所として使用することができる。識別番号DIは、各電話機に固有の番号であるので、いたずら電話の防止に識別番号DIを利用することができる。
通常の通話の場合、電話機Bから電話機Aに送信される“INVITE”リクエストは、の図3およびその説明と同一であるので、図およびその説明を省略する。次に、この実施例で電話機Bのユーザがいたずら電話をかけるとき、電話機Aに送信する“INVITE”リクエストを図7に示す。図7を参照して、ヘッダのユーザIDおよびユーザホストである“moto”および“10.0.0.1”は、それぞれ“anonymous”および“anonymizer”に書き換えられている。このため、電話機Aのユーザは、アノニマイザ44を介して送信されてきたことを知ることはできるが、電話機Bのユーザを特定できる情報を全く知ることができない。ここで、ユーザIDおよびユーザホストをそれぞれ“anonymous”および“anonymizer”に書き換える処理は、電話機Bからプロキシサーバ42に送信される“INVITE”リクエストに含まれる情報に基づいて、プロキシサーバ42が行う。
また、図4の場合と異なり、ボディのcラインにも“anonymizer”が記載されているので、電話機Aは電話機Bとの間で直接RTPを確立することができない。したがって、電話機Aはアノニマイザ44を介して電話機Bとの間でRTPを確立する。このため、電話機Bのユーザは、ヘッダおよびボディに記載されたユーザIDおよびユーザホストを、それぞれ“anonymous”および“anonymizer”に書き換えても、自分のユーザIDおよびユーザホストを電話機Aのユーザに知られることなく、いたずら電話をかけることができる。
そこで、電話機Aのユーザは、電話機Bのユーザがかけてきたいたずら電話を受けたとき、電話機Bから送信されてきた“INVITE”リクエストのボディのiラインに記載された識別番号DIを着信拒否テーブル20aに登録しておく。そして、電話機Bから電話機Aに再びいたずら電話がかかってきたとき、電話機Aは着信拒否テーブル20aを参照して、電話機Bに対し着信拒否を通知することができる。
なお、この実施例では識別番号DIを記載する場所はiラインとしたが、iラインに限られず、例えばsラインなど発着信を制御するための必須の情報が記載されている場所以外の場所であってもよい。
次に、図8を参照して、電話機Aが識別番号を含む“INVITE”リクエストを受信したとき、そのCPU12が実行する処理フローを説明する。
ステップS31で電話機Bからの“INVITE”リクエストを受信するまで待機し、“INVITE”リクエストを受信すると、ステップS33で“INVITE”リクエストのボディのiラインに含まれる識別番号DIを取得する。
ステップS35では、取得した識別番号DIが、着信拒否番号として着信テーブル20aに登録されている識別番号と一致するか否かを判定する。その結果、YESと判定した場合はいたずら電話と判断し、ステップS37に進む。ステップS37では、“INVITE”リクエストの着信を拒否することを示す“603 Decline”レスポンスを電話機Bに送信し、後述するステップS57に進む。一方、NOと判定した場合はステップS39に進む。
ステップS39では、“INVITE”リクエストを受信したことを示す“100 Trying”レスポンスを電話機Bに送信する。ステップS41では、電話機Bに対して電話機Aのユーザを呼び出し中であることを示すため、“180 Ringing”レスポンスを送信する。電話機Aで呼び出し音が発生し、電話機Aのユーザが受話器34を上げると、ステップS43で、“INVITE”リクエストが成功したことを伝える“200 OK”レスポンスを電話機Bに送信する。ステップS45では、電話機Bが“200 OK”レスポンスを受信したことを示す、“ACK”リクエストを受信するまで待機する。“ACK”リクエストを受信すると、電話機Bとの間でアノニマイザ44を介してRTPが確立される。
その結果、ステップS47で音声パケットの送受信が開始され、電話機Aのユーザは電話機Bのユーザと通話することができる。電話機Aのユーザは、電話機Bのユーザと通話した結果、いたずら電話と判断すると、キーパッド18に設けられた番号登録ボタン18aを押す。
ステップ49では、CPU12は、番号登録ボタン18aが押されたか否かを判定する。YESと判定したときは、いたずら電話と判断したので、ステップS51に進む。ステップS51では、ステップS33で取得した識別番号DIを着信拒否アドレスとしてフラッシュメモリ20に設けられた着信拒否テーブル20aに登録する。登録が完了すると、ステップS57に進む。
一方、ステップS49でNOと判定したときは、ステップS53で10秒経過した否かを判定する。その結果、NOと判定した場合にはステップS49に戻る。また、YESと判定した場合には、いたずら電話ではない判断したので、ステップS55で通話が終了して受話器34が置かれるまで音声パケットの送受信を繰り返し行う。通話が終了して受話器34が置かれると、ステップS57で電話機Bとの通信を切断して終了する。
このように、電話機Bのユーザが、ヘッダおよびボディに含まれるユーザIDおよびユーザホストを、それぞれ“anonymous”および“anonymizer”に書き換えていたずら電話をかけてきたとき、“INVITE”リクエストのiラインに含まれる識別番号を着信拒否アドレスとして着信拒否テーブル20aに登録する。そして、電話機Bのユーザが再びいたずら電話をかけてきたとき、電話機Aは着信拒否テーブル20aに登録された識別番号DIに基づいてその着信を拒否することにより、いたずら電話を確実に防止することができる。
以上の説明から分かるように、セッション情報である“INVITE”リクエストに記述され、かつ発信者を識別できる識別アドレスを検出する。一方、あらかじめフラッシュメモリ20の着信拒否テーブル20aに任意の識別アドレスを記憶しておく。そして、検出された識別アドレスと任意の識別アドレスとが一致した場合、“INVITE”リクエストの着信を拒否する。つまり、発信者から送信されてきた“INVITE”リクエストに記述され、発信者を特定することができる識別アドレスが送信されてきた場合、その識別アドレスを取得し、あらかじめ電話機に記憶させておいた識別アドレスと比較する。その結果、これらの識別アドレスが一致する場合、“INVITE”リクエストの着信を拒否する。このように、“INVITE”リクエストに記述され、かつ発信者の特定が可能な識別アドレスを利用することにより、いたずら電話を確実に防止する。
10…電話機
12…CPU
18a…番号登録ボタン
20a…着信拒否テーブル
40、42…プロキシサーバ
44…アノニマイザ
12…CPU
18a…番号登録ボタン
20a…着信拒否テーブル
40、42…プロキシサーバ
44…アノニマイザ
Claims (5)
- 呼の確立に必要なセッション情報を含む接続要求を受信する電話機において、
前記セッション情報に記述されたかつ発信者を識別する識別子を検出する検出手段、
任意の識別子を保持するメモリ手段、および
前記検出手段によって検出された識別子が前記メモリ手段によって保持された識別子と一致するとき前記呼の確立を拒否する拒否手段を備えることを特徴とする、電話機。 - 前記検出手段によって検出された識別子が前記メモリ手段によって保持された識別子と一致しないとき呼確立操作に応答して前記呼を確立する確立手段をさらに備える、請求項1記載の電話機。
- 前記呼が確立された後に接続拒否操作を受け付けたとき前記検出手段によって検出された識別子を前記メモリ手段に設定する設定手段をさらに備える、請求項1または2記載の電話機。
- 前記検出手段によって検出された識別子は、前記セッション情報に記述されたIPアドレスおよびドメイン名のいずれかを含む識別子である、請求項1ないし3のいずれかに記載の電話機。
- 前記検出手段によって検出された識別子は、前記電話貴の製造時に与えられるかつ互いに異なる識別子である、請求項1ないし3のいずれかに記載の電話機。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004112032A JP2005303343A (ja) | 2004-04-06 | 2004-04-06 | 電話機 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004112032A JP2005303343A (ja) | 2004-04-06 | 2004-04-06 | 電話機 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005303343A true JP2005303343A (ja) | 2005-10-27 |
Family
ID=35334401
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004112032A Withdrawn JP2005303343A (ja) | 2004-04-06 | 2004-04-06 | 電話機 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005303343A (ja) |
-
2004
- 2004-04-06 JP JP2004112032A patent/JP2005303343A/ja not_active Withdrawn
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5332544B2 (ja) | 呼制御装置、呼制御システム、呼制御方法及びコンピュータプログラム | |
KR101123519B1 (ko) | 통신 방법 및 무선 통신 단말기 | |
US20080112390A1 (en) | Apparatus to override the redirect or reject feature at an SIP end point | |
JP2008236470A (ja) | Ip電話端末及びip電話システム | |
JP2005303343A (ja) | 電話機 | |
JP2009049559A (ja) | メッセージ中継装置、メッセージ中継システム及びプログラム | |
KR20060010590A (ko) | 얼리 미디어 서비스 제공 방법 및 시스템 | |
JP4560530B2 (ja) | 通知システム、情報処理装置、通知システムの通知方法、情報処理方法、情報処理プログラム、及び記録媒体 | |
JP3976712B2 (ja) | 発信元端末識別情報通知システム、着呼装置、サーバ装置、発呼装置、登録装置、端末装置、及びゲートウェイ装置 | |
JP3993206B2 (ja) | 音声通信サーバ装置 | |
JP2005094224A (ja) | 発信元端末識別情報通知システム、着呼装置、発呼装置、サーバ装置、登録装置、端末装置、およびゲートウェイ装置 | |
KR100636279B1 (ko) | 브이오아이피 시스템의 자원정보를 이용한 호제어 시스템및 그 방법 | |
JP3732155B2 (ja) | 音声通信システムおよび音声通信方法 | |
JP4177433B2 (ja) | 通信端末の通信方法 | |
JP3993208B2 (ja) | 音声通信システムおよび音声通信方法 | |
JP4347405B2 (ja) | サーバ装置 | |
JP4347406B2 (ja) | サーバ装置 | |
JP4177429B2 (ja) | 通信端末の音声通信方法 | |
JP4130670B2 (ja) | 音声通信サーバ装置 | |
JP4347401B2 (ja) | 音声通信方法 | |
KR20060029020A (ko) | Sip 기반 패킷 통신 망에서의 멀티미디어 발신자 정보서비스 방법 및 그 시스템 | |
JP4177428B2 (ja) | 音声通信サーバ装置の音声通信方法 | |
JP4177427B2 (ja) | 音声通信サーバ装置の音声通信方法 | |
JP3993207B2 (ja) | 音声通信システムに用いる通信端末 | |
JP4177430B2 (ja) | 音声通信サーバ装置のプログラム記憶媒体 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Withdrawal of application because of no request for examination |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20070703 |