(57)【要約】  装置が提供される。装置は、少なくとも１つのＤＥＣＴ端末及びピアの間のＤＥＣＴチャネルを介してビデオ通信ストリームの音声データを通信するためのＶｏＩＰゲートウェイと、少なくとも１つのＷｉＦｉビデオ端末及び前記ピアの間のＷｉＦｉチャネルを介してビデオ通信ストリームのビデオデータを通信するためのＷｉＦｉアクセスポイントとを有する装置である。
2014520438.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのＤＥＣＴ端末及びピアの間のＤＥＣＴチャネルを介してビデオ通信ストリームの音声データを通信するためのＶｏＩＰゲートウェイと、
少なくとも１つのＷｉＦｉビデオ端末及び前記ピアの間のＷｉＦｉチャネルを介してビデオ通信ストリームのビデオデータを通信するためのＷｉＦｉアクセスポイントと
を有する装置。  
【請求項２】
ＳＩＰネットワークにおいて前記ピアと前記ビデオ通信ストリームを通信する請求項１に記載の装置。
【請求項３】
当該装置がＤＥＣＴベースである、請求項１又は２に記載の装置。
【請求項４】
前記少なくとも１つのＤＥＣＴ端末が、前記ＤＥＣＴベースに登録されたＤＥＣＴハンドセットである、請求項３に記載の装置。
【請求項５】
前記少なくとも１つのＷｉＦｉビデオ端末が、ＤＥＣＴを利用するモバイル端末であって前記ＤＥＣＴベースに登録されている、請求項３に記載の装置。
【請求項６】
前記少なくとも１つのＷｉＦｉビデオ端末が、ＷｉＦｉを利用するマルチメディアモバイル端末であって前記ＤＥＣＴベースに登録されている、請求項３に記載の装置。
【請求項７】
前記ＤＥＣＴベースが前記ＳＩＰネットワークのＳＩＰサーバに登録されている、請求項２に記載の装置。
【請求項８】
STUN(Simple  Traversal  of  User  Datagram)及びセッションボーダコントローラ(SBC)がネットワークアドレス変換(NAT)を行うＶｏＩＰに使用される、請求項２に記載の装置。
【請求項９】
音声リアルタイム転送プロトコル（ＲＴＰ）の通信が、セッションボーダコントローラ（ＳＢＣ）と当該装置との間で行われ、ビデオＲＴＰの通信がＳＢＣと前記ＷｉＦｉビデオ端末との間で行われる、請求項８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に無線通信に関連する。特に、本発明はディジタルエンハンストコードレス通信(Digital  Enhanced  Cordless  Telecommunications：DECT)方式に基づくビデオ電話システム等に関連する。
【背景技術】
【０００２】
この欄は本発明の様々な形態の適切な理解を促す背景情報を読者に提供するためのものである。この欄に記載された事項は必ずしも従来技術として理解されるべきではない。
【０００３】
DECTはコードレス電話システムを形成するために主に使用されるディジタル通信の標準規格又は標準仕様である。DECT電話システムは普及している。DECT電話システムのDECT電話親機は、システムの外部回線におけるSIP通信と内部回線におけるDECT通信とを行うためにVoIPゲートウェイと共に一体化されてもよい(SIP(Session  Initiation  Protocol)はインターネットプロトコルを介した音声通信及びビデオ通信等のような通信セッションを制御するために広く使用されているシグナリングプロトコルである)。しかしながら、DECTはビデオ転送の機能を有していないので(サポートしていないので)、外部のSIPビデオ通信(ビデオコール)はDECT電話システムに参加することができない。
【０００４】
一方、DECT電話システム内の電話機(電話セット)は、WiFiを使用する機能を有し(サポートしており)、DECTではなくSIP上でビデオ通信を直接的に処理できる。従って、ビデオSIP通信の媒体通信はWiFi上で行われることになる。しかしながら、家庭用のWiFiネットワーク(ホームWiFiネットワーク)は、通常、DECTと比較して少ない容量のリアルタイム媒体通信しかできず、その結果、WiFiにおけるSIPビデオ通信の最中に貧弱な音声パフォーマンスとなってしまう。  
【発明の概要】
【発明が解決しようとする課題】
【０００５】
開示される実施の形態の課題は、改善されたビデオ通信を実行できるようにすることである。
【課題を解決するための手段】
【０００６】
実施の形態による装置は、
少なくとも１つのＤＥＣＴ端末及びピアの間のＤＥＣＴチャネルを介してビデオ通信ストリームの音声データを通信するためのＶｏＩＰゲートウェイと、
少なくとも１つのＷｉＦｉビデオ端末及び前記ピアの間のＷｉＦｉチャネルを介してビデオ通信ストリームのビデオデータを通信するためのＷｉＦｉアクセスポイントと
を有する装置である。
【図面の簡単な説明】
【０００７】
【図１】本発明の実施の形態によるビデオ電話システムの構造の一例を示す図。
【図２】本発明の実施の形態によるDECT親機におけるビデオ信号に関する状態遷移(状態マシン)の一例を示す図。
【図３】本発明の実施の形態による着信呼に関する状態遷移の一例を示す図。
【図４】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図５】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図６】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図７】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図８】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図９】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図１０】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図１１】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図１２】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図１３】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【図１４】本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図。
【発明を実施するための形態】
【０００８】
＜実施の形態の概要＞
本発明の一形態により提供される装置は、
少なくとも1つのDECT端末及びピアの間のDECTチャネルを介してビデオ通信ストリームの音声データを通信するためのVoIPゲートウェイと、少なくとも1つのWiFiビデオ端末及び前記ピアの間のWiFiチャネルを介してビデオ通信ストリームのビデオデータを通信するためのWiFiアクセスポイントとを有する装置である。
【０００９】
本発明に関する多くの形態及び利点は本発明に関する以下の詳細な説明により更に明らかになるであろう。
【００１０】
＜添付図面＞
本願に包含されている添付図面は、本発明の原理を説明するための詳細な説明と共に本発明の実施の形態を示して理解を促す。本発明はそのような実施の形態に限定されない。
【００１１】
＜実施の形態の詳細な説明＞
以下、本発明の実施の形態を図面と共に詳細に説明する。以下の説明において、簡明化のため、従来の機能及び構成等に関する詳細な説明は省略されているかもしれない。
【００１２】
本発明の実施の形態によれば、ビデオ電話システムが提供され、着信したビデオ呼(ビデオ通信)に関し、ビデオ電話システムの中でビデオ通信の音声データとビデオデータとが別個のチャネルで通信される。特に、音声データはDECTチャネルで通信され、ビデオデータはWiFiチャネルで通信される。
【００１３】
DECTはWiFiよりもかなり優れた音声パフォーマンスを有するので、一実施形態ではDECTチャネルが音声データ通信に使用される。通常、人々は電話通信の際にビデオよりも音声の方に敏感になっているという事実があるので、音声データをDECTチャネルで通信させることは有意義である。また、WiFiはDECTよりも優れたビデオパフォーマンスを有するので、WiFiチャネルがビデオデータ通信に使用される。
【００１４】
次に、本発明の実施の形態によるビデオ電話システムを詳細に説明する。このビデオ電話システムにおいて、DECTベース(又はDECT親機)は、制御局(又はコントロールセンタ)となり、外部SIPネットワークからSIPビデオ呼を受信しかつDECT及びWiFiチャネルで音声データ及びビデオデータをそれぞれ送信するビデオ電話機能を発揮する。音声データは、DECTベースに登録されたDECTハンドセットで再生できる。ビデオデータは、WiFi及びDECTを利用することが可能であり(サポートし)かつDECTベースに登録されているマルチメディアモバイル端末において再生可能である。例えば、そのようなモバイル端末はワイヤレスタブレット又は無線タブレットとすることが可能である。
【００１５】
図1は本発明の実施の形態によるビデオ電話システムのネットワーク構造の一例を示す図である。
【００１６】
図1に示されているように、ビデオ電話システムはDECT電話機と1つ以上のタブレット(図1では1つのタブレットしか示されていない)とを有する。DECT電話機はDECTベースとDECTベースに登録されている1つ以上のDECTハンドセット(図1では1つのハンドセットしか示されていない)とを有する。タブレットがSIPスタックを有することは必須ではない。図1に示す実施の形態は、タブレットがSIPスタックを有していない場合を示す。DECTベースにはVoIPゲートウェイ及びWiFiアクセスポイント(AP)が設けられ、従ってDECTベースはSIPネットワークとの間のSIP通信に加えて、SIP及びDECT間のプロトコル変換を行う責務を有する。DECTベース及びタブレット間の通信は、タブレットにおけるビデオに関するいくつもの処理を制御し、かつ通知に対するタブレットからの応答を形成し、この点については後述する。
【００１７】
図1に示すネットワークには、ローカルIPサブネットワークを構築する責務を有するルータが存在する。ルータのWANポートはADSLとのSIPネットワークに接続され、このポートを介してSIPピアとの通信を設定することができる。VoIPゲートウェイを備えたDECTベースは、外部ラインポートを介してルータに接続される。また、DECTベースのWiFiAPはWANポートを介してルータに接続できる。DECTハンドセット及びタブレットはDECTベースに登録されている。
【００１８】
図1に示すネットワークにおいて、リモートSIPピアとDECTベースとの間にSIP呼(SIPコール)が設定される場合、DECTベースは、DECTベースとDECTハンドセット及びタブレットとの間にDECT方式に基づくビデオコールを設定するブリッジの役割を果たす。DECTベースはSIPクライアント及びリモートビデオコントローラとして機能し、タブレットは、ビデオ通信を拡張したDECT電話機として見える。
【００１９】
図1に示されているようなビデオ電話システムの場合、タブレットはSIPスタックを有していないので、1つ以上のDECTハンドセット及びタブレットが1つのSIPアカウントを共有する可能性があり、その場合DECTベースはIP及びDECT間のプライベート自動ブランチ交換部(Private  Automatic  Branch  Exchange：PABX)の役割を演じる。SIP着信呼がシステムに到来すると、全てのハンドセット及びタブレットが鳴り、最初にオフフックしたものがその着信を受ける。
【００２０】
タブレットに自身のSIPスタックが備わっていてもよく、その場合タブレットはアドバンストDECTハンドセットと考えることが可能でありかつDECTベースから音声データを受信できることが、理解できるであろう。すなわち、DECTベース及びタブレットの双方が各自のSIPアカウントを有することが可能であり、SIPサーバはSIPの分岐(sip-forking)に対応する必要がありかつ同じアカウントの複数の装置の登録を許容する必要がある。本発明に関し、この例についての更なる詳細な説明は行われない。
【００２１】
本発明の実施の形態によるビデオ電話システムの実際の例に関し、DECTベース及びタブレットは以下の機能を有することを要求してもよい：
タブレット：
プライベート通信プロトコル用の端末；
メディア処理部；
ネットワークアドレス変換部(Network  Address  Translation：NAT)。
【００２２】
更に、タブレットは、ビデオコールに対応したカメラ、表示部、エンコード部、デコード部及びビデオミキサ(好ましくは、ジーストリーマ(Gstreamer))を備えた軽量ビデオ好悪図を実現してもよい。これは、DECTベースからのビデオ情報に従ってパイプラインを構築することが可能である。
【００２３】
DECTベース：
プライベート通信プロトコル用の端末；
端末にSIPスタックの機能を備えること；
SIPアプリケーションによるビデオを利用できること。
【００２４】
この実施の形態では、タブレットにSIPスタックが備わっていないので、DECTベースは、SIPシグナリングのためのビデオをサポートしかつタブレットにおけるリモートビデオの状態マシン(state  machine)を維持する必要がある。
【００２５】
ビデオ制御(又はビデオコントロール)が、タブレット及びDECTベース双方におけるビデオデータの送受信に必要である。
【００２６】
DECTベース及びタブレットから送信されたビデオデータに関するビデオコントロールを行う目的に関し、DECTベース及びタブレットの間の通信に関する標準規格が存在する。通信はネットワークに依存せず、DECT通信チャネル上又はWiFi上で実現可能である。
【００２７】
図2は本発明の実施の形態によるDECTベースにおけるビデオの状態マシンの一例を示す図である。
【００２８】
DECTベースは、発呼、ネゴシエーション及び全体的なビデオコールの最中にタブレットにおけるリモートビデを制御するために状態マシンを管理する。初期状態は「ストップ(STOP)」である。SIPビデオコールが開始された場合(sip-INVITEの場合)、DECTベースは、IP、ポート及びコーデック等のようなビデオ情報を記述したセッション記述プロトコル(Session  Description  Protocol：SDP)を送る。SDPを形成するために、DECTベースはプライベートプロトコルを通じてタブレットからビデオ情報を取得する必要がある。この手順自体は従来のフローで実行することが可能であり、図3に示されているように、以後ビデオは対応する状態に移り、成功すると最終的には「スタート(START)」になる。呼が終了すると(sip-BYE)、DECTベースはタブレットにおけるビデオを切断し、状態は「ストップ」になる。
【００２９】
「スタート」の中に二次的な状態が存在する。例えば、ユーザがタブレット上で呼をアクティブに維持することを希望している場合、DECTベースは「sendrecv」から「send」に状態を変更し、sip-reINVITEをリモートピアに送信する。ユーザが呼を復元した後、状態は「send」から「sendrecv」になる。
【００３０】
呼の最中に、制御は、呼の維持(コールホールド)、呼の転送(コールトランスファ)又はその他の処理が生じた場合を取り扱う。例えば、ユーザがビデオを一時的に閉じることを希望した場合、DECTベースはリモートビデオを「sendrecv」から「ストップ(stop)」へ変更する。
【００３１】
図3は本発明の実施の形態による着信呼の状態遷移の一例を示す図である。
【００３２】
着信音がなると、SMがタブレットからコーデックを取得する。SIPネゴシエーションの後に、DECTベースはビデオの送信及び受信を開始するようにタブレットを制御する。
【００３３】
図3に示されているように、開始状態(START)は通常呼及びホールド/リカバー(Recv)に関する3つのサブ状態を有している。
【００３４】
図4-14は本発明の実施の形態によるビデオ電話システムの各要素の動作を例示的に示すシーケンス図である。
【００３５】
図4-14を通じて以下の参照符号が使用されている：
「EXT」：DECTベース及びタブレット間のビデオ制御に関する拡張されたプライベートシグナリング。
【００３６】
「DECT」：DECTシグナリング。
【００３７】
「Active(アクティブ)」：タブレットがダイアログ又は対話を始める。
【００３８】
「Passive(パッシブ)」：リモートピアにより開始されたダイアログをタブレットが受信する。
【００３９】
図4は登録手順を示す。
【００４０】
ホームネットワークにおいて、タブレット及びDECTハンドセットの全てがDECTによりDECTベースに登録され、DECTベースはSIPによりSIPサーバに登録される。
【００４１】
図5は音声着信呼のための手順を示す。
【００４２】
図5に示されているように、DECTベースがインバイト(INVITE)を受信すると、タブレットの着信呼のタイプを通知し、その後にタブレットが対応する呼び出し音を再生する。
【００４３】
図5はDECTベース宛の着信呼を示し、タブレット及びDECTハンドセットの全てがDECTにより鳴り出す。最初にオフフックしたものがその着信呼を処理し、残りの装置の鳴音は止まる。音声ストリームが、SIP及びDECT間のブリッジであるDECTベースを通じて伝送される。
【００４４】
DECTベースは、呼のタイプが音声であることをタブレットに通知する。タブレットは、呼が音声であることを知り、音声用の着信音を選択する。この手順は様々な着信音でユーザに通知を行うためのものである。
【００４５】
図6はビデオ着信呼のための手順を示す。
【００４６】
着信音を鳴らした後、DECTベースはビデオコーデックのリストをタブレットから取得し、リモートピアとの間でネゴシエーションを行う。ネゴシエーションに成功すると、DECTベースはビデオ状態を「開始(START)」にし、特定のコマンドをタブレットに送信する。コマンドを待機しているタブレットの端末は、ビデオの表示を開始し、タブレット上でカメラがビデオを取得し始める。このコマンドにより、DECTベースはビデオの詳細なパラメータをタブレットに通知する。
【００４７】
ビデオ呼の最中に、音声ストリームがDECTベースを通じて送信されるが、ビデオストリームは、DECTベースを介するのではなくWiFiにより、リモートピア及びタブレット間で送信される。
【００４８】
図7は音声呼として受け入れられたビデオ着信呼に関する手順を示す。
【００４９】
タブレットは「ビデオコーデックなし」をベースに返すことで着信呼を音声呼として受け入れることが可能である。
【００５０】
着信呼はビデオ呼であるが、タブレットのユーザはそれを音声呼として受け入れる機会を有する。この場合、DECTベースがタブレットからコーデック(codec)を取得すると、タブレットは「コーデックなし(no  codec)」を返す。そして、DECTベースは音声呼に関してリモートピアとネゴシエートする(又は交渉する)。
【００５１】
図8はDECTハンドセットでオフフックされたビデオ着信呼の手順を示す。
【００５２】
図8に示されているように、最初のオフフックがDECTハンドセットでなされた場合、DECTベースはタブレットに対するDECT呼をキャンセルする。
【００５３】
図9は音声呼を発信する(outgoing  voice  call)手順を示す。
【００５４】
図9に示されているように、DECTベースがダイアルしていることをタブレットが検出すると、DECTベースはビデオコーデックのリストを取得し、タブレットは音声呼をダイヤルアウトするために「コーデックなし(no  codec)」を提供することができる。
【００５５】
図10はビデオ呼を発信する(outgoing  video  call)手順を示す。
【００５６】
上記の図9及び図10は、DECTベースがどのようにしてタブレットからダイヤルアウト又は発信するかを示す。タブレットはDECTを介してダイヤルアウトし、DECTベースはビデオ情報をタブレットから取得し、音声又はビデオのSIP呼をダイヤルアウトすることを選択する。手順は図5及び図6を参照しながら上述したダイヤルイン(着信)の手順に類似している。
【００５７】
図11はタブレットの再インバイト(Re-invite)に関する手順を示す。
【００５８】
タブレットがコーデックの変更を希望する場合、「通知」をDECTベースに送信し、コーデックを取得し、SIPにより再インバイトを送信する。
【００５９】
以下のような4つの状況が図11に示されている。
【００６０】
リモートピアからの再インバイト(ReINVITE)(タブレットの観点からパッシブ)がビデオを音声にする必要がある場合。
【００６１】
リモートピアからの再インバイト(ReINVITE)が音声をビデオにする必要がある場合。
【００６２】
ローカルタブレットからの再インバイト(ReINVITE)(タブレットの観点からアクティブ)がビデオを音声にする必要がある場合。
【００６３】
ローカルタブレットからの再インバイト(ReINVITE)(タブレットの観点からアクティブ)が音声をビデオにする必要がある場合。
【００６４】
図11に示されているように、DECTベースはビデオの状態を維持し、タブレットを制御する。再インバイトがアクティブであった場合、タブレットはDECTベースにビデオの変更を通知する。
【００６５】
図12はタブレットのホールド(維持)/リカバー(復元)に関する手順を示す。
【００６６】
この場合、タブレットはDECTベースからのコマンドに従ってビデオの方向を制御する必要がある。
【００６７】
呼のホールド(維持)及びリカバー(復元)は電話に関する従来の状況と同じである。SIPは、ストリーム方向を記述するSDPと共に再インバイト(reINVITE)を送信することでこれらの状況を確保する。DECTベース及びタブレット間の状態マシン及びコマンドはこれらの特徴を利用する(サポートしている)。例えば、タブレットに関するホールドオンは、再インバイトにおける「送信のみ(send  only)」を意味し、ビデオの状態は「send(送信)」であり、DECTベースはタブレットへのビデオのダウンロードを止める。
【００６８】
図13はビデオ呼通信のための手順を示す。
【００６９】
2種類の呼の通信が存在している。第1のものはタブレットとハンドセットとの間の家庭におけるDECT通信である。DECTベースとリモートピアとの間に設定されたSIP呼は変更されない。ビデオ(の機能)を有するタブレットからビデオ(の機能)を有しないDECTハンドセットへn個の呼が転送される場合、DECTベースはビデオを停止し、DECT通信を開始する。第2のものはタブレットとリモートピアとの間のSIP通信である。DECTベースはSIP通信を開始し、DECTベースは転送ターゲットがビデオ(の機能)を有していなかった場合、タブレットにおけるビデオを止める。
【００７０】
図14はテレビ会議呼又はビデオ会議呼のための手順を示す。
【００７１】
タブレットはテレビ会議呼のためのビデオミキサを備えている必要がある。
【００７２】
図14はアドホックSIP会議呼の様子を示す。図14に示す手順はホールド(維持)、リカバー(復元)及びミキシング(混合)の手順を簡単に示している。具体的には、先ず、最初の呼をホールドし、そして2番目の呼を開始する。最後に、最初の呼が復元され、第1及び第2の呼が混合される。
【００７３】
VoIPの場合、ネットワークアドレス変換(NAT)を経由することが重要である。NATを行うために使用されてよい技術がいくつか存在する。そのような技術は例えば非特許文献1に記載されている。これらの技術は以下のように要約できる：
NATを修正する：アプリケーションレイヤゲートウェイ(ALG)
クライアントを修正する：片側セルフアドレス決定(Unilateral  Self  Address  Fixing：UNSAF)
ユーザデータのシンプル処理(STUN：Simple  Traversal  of  User  Datagram)
NAT付近のリレーを用いた処理(Traversal  Using  Relays  around  NAT：TURN)
相互接続設定(Interactive  Connectivity  Establishment：ICE)
サーバを修正する：NATナビゲーションによるサーバ関与(Server  Involvement  in  NAT  Navigation：SINN)
セッションボーダコントローラ(Session  Border  Controller：SBC)
NAT及びクライアントを修正する：領域固有インターネットプロトコル(Realm  Specific  Internet  Protocol：RSIP)、シグナリングの次のステップ(Next  Step  in  Signaling：NSIS)
NAT及びサーバを修正する：ミドルボックス通信(Middlebox  Communications：IDCOM)
クライアント及びサーバを修正する：プロトコルアップデート
全てを修正する：IPv6
本発明の実施の形態によるビデオ電話システムにおけるNATを処理するようにSTUN及びSBCをVoIPに利用することが可能である。
【００７４】
SBCの場合、音声RTP(リアルタイム転送プロトコル)通信はSBCとDECTベースとの間でなされるが、ビデオRTPはSBCとタブレットとの間でなされる。NAT処理の場合のタブレットの処理においては、(タブレットの「recvonly」でさえ)通常のRTPからSBCが最初に開始され、その後にNATバインディングがなされる。NATのバインディングは生かしておく必要がある。
【００７５】
STUNの場合、タブレットにSTUNクライアントが存在し、NATにおけるバインディングが生かされていなければならない。
【００７６】
本発明の実施の形態によれば、音声及び映像のデータが異なるチャネルで送信及び/又は受信される。SIP-DECTがブリッジを行うので(橋渡しを行うので)、DECTベースは大きな遅延を導入せず、従ってAVの同期のための別途の処理は不要である。
【００７７】
本発明の実施の形態によるビデオ電話システムによれば、音声データがDECTチャネルで伝送されかつビデオデータがWiFiチャネルで伝送されるので、音声及びビデオのデータ双方にとって優れた品質が期待される。DECTの音声呼は、WiFiよりも、長い通話時間及び室内外(屋内外)の広いカバレッジを有する。更に、本システムは、DECTベース間において、WiFiのハンドオーバの場合よりもシームレスなハンドオーバを行うことが可能である。
【００７８】
複数の家庭装置を「同時に」鳴らす要求に関し、本解決手段はオペレータのプロキシサーバにおけるSIP分岐(SIP-forking)を要しない。
【００７９】
本発明は単なる一例を用いて説明されてきたこと、及び具体的な詳細についての修正が本発明の範囲から逸脱することなく可能であることが、理解されるであろう。明細書、特許請求の範囲及び/又は図面に示された特徴の各々は、単独で使用されてもよいし、或いは適切な任意の仕方で組み合わせられてもよい。適切である限り、開示された特徴はハードウェア、ソフトウェア又はそれら2つの組み合わせにより実現されてよい。
【先行技術文献】
【非特許文献】
【００８０】
【非特許文献１】“Considerations  for  Selection  of  Techniques  for  NAT  Traversal,”draft-iab-nat-traversal-considerations-00,  J.  Rosenberg
【図１】
2014520438.tif 000003
【図２】
2014520438.tif 000004
【図３】
2014520438.tif 000005
【図４】
2014520438.tif 000006
【図５】
2014520438.tif 000007
【図６】
2014520438.tif 000008
【図７】
2014520438.tif 000009
【図８】
2014520438.tif 000010
【図９】
2014520438.tif 000011
【図１０】
2014520438.tif 000012
【図１１】
2014520438.tif 000013
【図１２】
2014520438.tif 000014
【図１３】
2014520438.tif 000015
【図１４】
2014520438.tif 000016
【手続補正書】
【提出日】平成25年12月11日(2013.12.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも１つの端末及びピアの間の音声チャネルを介してビデオ通信ストリームの音声データを通信するためのゲートウェイと、
少なくとも１つのビデオ端末及び前記ピアの間のデータチャネルを介して前記ビデオ通信ストリームのビデオデータを通信するためのアクセスポイントと
を有する装置。  
【請求項２】
ＳＩＰネットワークにおいて前記ピアと前記ビデオ通信ストリームを通信する請求項１に記載の装置。
【請求項３】
前記ゲートウェイが少なくとも１つのＤＥＣＴ端末及び前記ピアの間のＤＥＣＴチャネルを介して前記音声データを通信するためのＶｏＩＰゲートウェイであり、
前記アクセスポイントが、少なくとも１つのＷｉＦｉビデオ端末及び前記ピアの間のＷｉＦｉチャネルを介して前記ビデオデータを通信するためのＷｉＦｉアクセスポイントである、請求項２に記載の装置。
【請求項４】
当該装置がＤＥＣＴベースである、請求項３に記載の装置。
【請求項５】
前記少なくとも１つのＤＥＣＴ端末が、前記ＤＥＣＴベースに登録されたＤＥＣＴハンドセットである、請求項４に記載の装置。
【請求項６】
前記少なくとも１つのＷｉＦｉビデオ端末が、ＤＥＣＴを利用するモバイル端末であって前記ＤＥＣＴベースに登録されている、請求項４に記載の装置。
【請求項７】
前記少なくとも１つのＷｉＦｉビデオ端末が、ＷｉＦｉを利用するマルチメディアモバイル端末であって前記ＤＥＣＴベースに登録されている、請求項４に記載の装置。
【請求項８】
前記ＤＥＣＴベースが前記ＳＩＰネットワークのＳＩＰサーバに登録されている、請求項４に記載の装置。
【請求項９】
STUN(Simple
Traversal of User Datagram)及びセッションボーダコントローラ(SBC)がネットワークアドレス変換(NAT)を行うために前記ＶｏＩＰゲートウェイに使用される、請求項３に記載の装置。
【請求項１０】
音声リアルタイム転送プロトコル（ＲＴＰ）の通信が、セッションボーダコントローラ（ＳＢＣ）と当該装置との間で行われ、ビデオＲＴＰの通信がＳＢＣと前記ＷｉＦｉビデオ端末との間で行われる、請求項９に記載の装置。
【国際調査報告】
2014520438.tif 000017
2014520438.tif 000018
2014520438.tif 000019