JP4746102B2 - メディア適応を備えたメディアセッションの確立 - Google Patents

メディア適応を備えたメディアセッションの確立 Download PDF

Info

Publication number
JP4746102B2
JP4746102B2 JP2008527340A JP2008527340A JP4746102B2 JP 4746102 B2 JP4746102 B2 JP 4746102B2 JP 2008527340 A JP2008527340 A JP 2008527340A JP 2008527340 A JP2008527340 A JP 2008527340A JP 4746102 B2 JP4746102 B2 JP 4746102B2
Authority
JP
Japan
Prior art keywords
media
terminal
nsis
session
router
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.)
Expired - Fee Related
Application number
JP2008527340A
Other languages
English (en)
Other versions
JP2009506601A (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.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
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 Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JP2009506601A publication Critical patent/JP2009506601A/ja
Application granted granted Critical
Publication of JP4746102B2 publication Critical patent/JP4746102B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/765Media network packet handling intermediate

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するために、メディアフォーマット適応リソースを記録するための方法および端末に関する。本発明はさらに、端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するために、メディアフォーマット適応リソースを記録するための方法およびNSISルータに関する。
NSISフレームワーク
NSISは、ネクストステップインシグナリング(Next Steps in Signaling)の略語である。NSISは、シグナリングフレームワークのためのモジュール手法を定義することを目的としており、NSISトランスポートレベルプロトコル(NTLP:NSIS Transport Layer Protocol)と一般に呼ばれるシグナリングメッセージを搬送するためのプロトコルと、NSISシグナリング層プロトコル(NSLP:NSIS Signaling Layer Protocol)と一般に呼ばれるシグナリングアプリケーションのそれぞれに関して指定されなければならない別のプロトコルと、からなる(RFC4080、「Next Steps in Signaling(NSIS):Framework」参照、これは、参照によって本願明細書に援用されるものとし、http://www.ietf.orgで利用可能である)。
NTLPプロトコルに関する一例は、シュルツリン(Schulzrinne)らによるインターネットドラフト「GIMPS:General Internet Messaging Protocol for Signaling」(draft−ietf−nsis−ntlp−07.txt)に明記されているGIMPSプロトコルであり、これは、参照によって本願明細書に援用されるものとし、http://www.ietf.orgで利用可能である。
NSLPプロトコルの例は、マナー(Manner)らによるインターネットドラフト「NSLP for Quality−of−Service signaling」(draft−ietf−nsis−qos−nslp−07.txt)またはスティマリング(Stiemerling)らによるインターネットドラフト「NAT/Firewall NSIS Signaling Layer Protocol(NSLP)」(draft−ietf−nsis−nslp−natfw−07)に明記されている。(いずれの文書も、参照によって本願明細書に援用されるものとし、http://www.ietf.orgで利用可能である)。
NSIS QoS NSLPプロトコルは、インターネットにおけるQoS確保に関する長期にわたる問題を扱っており、NAT/FWトラバーサルコンフィギュレーションシグナリングを用いて、それを拡張している。したがって、本発明の以下の詳細な説明から明白となるように、メディアデリバリがネットワークのQoS機能(帯域幅、遅延、...)と、オーバレイノードにおけるネットワーク側の処理(メディア適応)機能の両方に適合しなければならない場合には、QoS NSLPは、特に関連性がある可能性がある。
NSLPデータオブジェクトは、GIMPSメッセージなどのNTLPメッセージのペイロードであってもよい。GIMPS QUERYメッセージの基本構造は、以下の通りである。
GIMPS-Query = Common-Header
Message-Routing-Information
Session-Identification
Network-Layer-Information
Query-Cookie
[ Stack-Proposal Stack-Configuration-Data ]
[ NSLP-Data ]
一般的なマルチメディアシナリオおよびその欠点
一般的なマルチメディアシナリオでは、第1のステップとして、セッションに関与している通信ピアの機能(サポートされるコーデック、有効なリンク、有効なバッファリング機能など)を調べるために、シグナリング交換が要求される。現在、対話型のシナリオの場合には、セッション開始プロトコル(SIP:Session Initiation Protocol)(RFC3261、「SIP: Session Initiation Protocol」参照、これは参照によって本願明細書に援用されるものとする)は通常、RFC 3264、「An Offer/Answer Model with the Session Description Protocol(SDP)」(参照によって本願明細書に援用されるものとする)に明記されているように、オファー/アンサーモデル(Offer/Answer Model)により、SDP用の機能交換意味論と共に用いられる。ストリーミングサービスの場合には、機能交換は、RTSP(RFC 2326、「Real Time Streaming Protocol(RTSP)」、これは参照によって本願明細書に援用されるものとする)またはSDPを用いて行われてもよい。
SIPは、照会/応答プロトコルであり、確立されるマルチメディアセッションの詳細のほか、エンドホストの機能情報の交換を協議することができる。SDPは、通信ピアのパラメータ、フロー数、接続の詳細などを表現するためのプロトコルである。SDPはまた、セッション接続またはコーデックの機能を表現し、詳細を協議することも可能である。
両方の通信当事者(エンドホスト)が共通の機能を有する場合には、マルチメディアセッションを直接的に確立することができる。しかし、エンドホストのメディア機能に不適合がある場合には、セッションは確立されない。
セッションが確立されることができるか、または許容されることができる状況下で、サービスを要求するユーザが対応するノード(別のユーザ、サービスプロバイダなど)と通信することができない場合には、セッションは通常、確立されることはできない。セッションにおいて用いられるメディアストリームのフォーマットにおける不適合を克服することができるネットワークにおいて利用可能なメディア適応リソースがあるとしても、必要なメディア適応を決定して記述するための方法論は見当たらず、適切なメディア適応リソースを検索して確保することが可能な手順のフレームワークもない。
本発明の目的は、端末の機能に不適合が検出される場合に、メディアセッションに関与している端末にメディア適応リソースの利用を可能にするシグナリングフレームワークを提供することである。
本発明の目的は、独立請求項の主題によって克服される。好都合な実施形態は、従属請求項に対する主題である。
本発明の一実施形態は、メディアセッションに関与する端末の動作に関する。この実施形態によれば、パケット交換型通信ネットワークを介して第1の端末と第2の端末との間に少なくとも1つのメディアストリームを備えるメディアセッションを確立するための方法が、提供される。本発明のすべての実施形態において、少なくとも1つのメディアストリームが、メディアトランスポートプロトコルを用いて通信される。
第1の端末は、セッションを開始するために、セッション管理プロトコルを用いて、第2の端末にセットアップメッセージを送信する。このセットアップメッセージは、メディアフォーマットを提示するセッション記述を含んでもよく、任意に、メディアセッションにおいて通信される各メディアストリームに関する対応するパラメータおよび属性を含んでもよい。
第1の端末はさらに、セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信する。この応答は、メディアセッションの少なくとも1つのメディアストリームに関する代替メディアフォーマットを提示する修正セッション記述を含んでもよく、この場合には、第2の端末によってサポートされていないメディアフォーマットが、第1の端末によって送信されるセットアップメッセージに含まれるセッション記述に提示されている。
第1の端末は、それぞれの代替メディアフォーマットが第1の端末によってサポートされる場合には、セットアップメッセージに対する応答に含まれるセッション記述において、各代替メディアフォーマットに関する決定に進む。これが当てはまらない場合には、すなわち、修正セッション記述に提示されたすべての代替メディアフォーマットが、第1の端末によってサポートされるとは限らない場合には、第1の端末は、第1の端末によってサポートされていない各代替メディアフォーマットに関して、ネクストステップインシグナリング(Next Step in Signaling)NSISフレームワークを用いて、少なくとも1つのNSISルータを検出し、(それぞれの)検出されたNSISルータは、セットアップメッセージにおけるセッション記述において第1の端末によって提示されるメディアフォーマットから、セットアップメッセージにおける応答のセッション記述において第2の端末によって提示されるそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換することができる。
第1の端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも1つのNSISルータが、検出される場合には、第1の端末は、提示されたメディアフォーマットにおけるパケットデータを、第1の端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出された少なくとも1つのNSISルータで、それぞれの代替メディアフォーマットに変換するためのリソースの確保に進む。メディアフォーマット変換のためのリソースを首尾よく確保したときには、メディアセッションが開始される。メディアセッションの少なくとも1つのメディアストリームのパケットデータが、メディアトランスポートプロトコルを用いて、第1の端末によってサポートされていない各代替メディアフォーマットに関して、メディアフォーマット変換のためのリソースが確保されている少なくとも1つのNSISルータを介して、第1の端末から第2の端末に提供される。
他の実施形態によれば、NSISシグナリングフレームワークを用いた少なくとも1つのNSISルータの検出は、以下の機構によって実行されてもよい。第1の端末は、パケット交換型ネットワークを介した第1の端末から第2の端末へのメディアセッションの少なくとも1つのストリームのパケットデータのパスに沿って、NSISトランスポートレベルプロトコルNTLPを用いて照会メッセージを送信する。メッセージは、セットアップメッセージに対する応答におけるセッション記述において、第1の端末によってサポートされていない提示されたメディアフォーマットから、第2の端末によって提示されたそれぞれの代替メディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信する各NSISルータに照会する。照会メッセージに対する応答において、第1の端末は、NSISトランスポートレベルプロトコルNTLPを用いて、提示されたメディアフォーマットからそれぞれの代替のメディアフォーマットに、メディアセッションのストリームのパケットデータを交換することができる第1の端末から第2の端末へのパケットデータのパスにおける少なくとも1つのNSISルータを表す応答メッセージを受信する。NSISルータが照会されたメディアフォーマット変換を行うことができない場合には、応答メッセージにおいて表されるNSISルータはない。
他の変形において、照会メッセージはまた、第1の端末によってサポートされていない提示されたメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたはメディアセッションのそれぞれのメディアストリームに関するそれぞれの代替メディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換する機能に関する照会メッセージを受信する各NSISルータに照会する。したがって、提示されたメディアフォーマットから第1の端末によってサポートされていない代替メディアフォーマットへのメディアデータの直接変換が照会されることができるだけでなく、適切に「組み合わせられた」場合に、提示されたメディアフォーマットから第1の端末によってサポートされていない代替メディアフォーマットへのメディアデータの変換を生じうる適応リソースも照会されることができる。
したがって、応答メッセージはさらに、第1の端末から第2の端末へのパスにおける少なくとも1つのNSISルータが、提示されたメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたはそれぞれの代替のメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換することができるかどうかを示してもよい。
他の実施形態によれば、NSISルータにおけるパケットデータを変換するためのリソースの確保は、以下のように行われてもよい。第1の端末は、提示されたメディアフォーマットから第2の端末によってセットアップメッセージに対する応答におけるセッション記述によって提示される代替メディアフォーマットに、メディアセッションのストリームのパケットデータを変換するためのメディア適応リソースの確保を要求するリソース確保要求メッセージを、NSISトランスポートレベルプロトコルNTLPを用いて、少なくとも1つのNSISルータに送信する。それに対する応答において、第1の端末は、NSISトランスポートレベルプロトコルNTLPを用いて、NSISルータが変換用のリソースを確保したかどうかを表す応答メッセージを受信する。
本発明の他の実施形態において、セットアップメッセージに含まれるセッション記述はさらに、第2の端末がセッション記述においてメディアストリームの提示されたメディアフォーマットをサポートしない場合には、メディアセッションの少なくともメディアストリームに関して、第1の端末がメディアフォーマット変換を自発的に行うかどうかを示す。
本発明の別の実施形態において、セットアップメッセージに含まれて送信されるセッション記述はさらに、第2の端末に対し、メディアセッションのそれぞれのメディアストリームの受信が、メディアセッションの確立のために必須であるかどうかを示す。
この実施形態の変形において、セットアップメッセージに含まれて送信されるセッション記述はさらに、第2の端末が提示されたメディアフォーマットをサポートしない場合には、メディアセッションのメディアストリームに関する別のメディアフォーマットへの提示されたメディアフォーマットの変換が、メディアセッションの確立のために任意であるか、または必須であるかを示す。
さらに、本発明の別の実施形態において、それぞれのメディアストリームに関して提示されたフォーマットが第2の端末によってサポートされない場合には、修正セッション記述は、第2の端末が、代替メディアフォーマットにおけるメディアストリームのパケットデータを提示されたメディアフォーマットにおけるメディアストリームのパケットデータに変換するために、少なくとも1つのNSISルータにおいてリソースを自発的に検出して確保するかどうかを示す。もしそうであるならば、修正セッション記述はまた、セットアップメッセージに対する応答の送信時に、第2の端末がメディアフォーマット変換リソースの検出および確保を開始したことを示す。
本発明の別の実施形態によれば、第1の端末によって送受信されるサービス記述は、セッションに関連するサービスの品質制約条件を含んでもよく、セットアップメッセージに対する応答における修正セッション記述は、セットアップメッセージのセッション記述に含まれるサービスの品質制約条件に対する代替のサービスの品質制約条件を提示することを含む。
後者の場合には、本発明の別の実施形態は、第1の端末が、代替のサービスの品質(QoS)制約条件が、第1の端末のユーザに関して許容可能であるかどうかを決定することを提示する。これが当てはまる場合には、第1の端末は、第2の端末のセッション記述において示された代替のサービスの品質制約条件に基づき、パケット交換型通信ネットワークを介した第1の端末から第2の端末へのパスに沿ってリソースを確保してもよく、メディアセッションの少なくとも1つのメディアストリームのパケットデータは、上記のパスに沿って第1の端末から第2の端末に供給される。
本発明の別の実施形態において、セットアップメッセージに対する応答において受信されたセッション記述において提示された各代替メディアフォーマットに関して、検出されるNSISルータがない場合、それぞれのNSISルータでメディアフォーマットを変換するために確保されることができるリソースが十分でない場合、またはパケット交換型通信ネットワークを介したパスに沿って、セットアップメッセージに対する応答において受信されたセッション記述において提示された代替のサービスの品質制約条件を満たすために確保されることができるリソースが十分でない場合には、メディアセッションは、中断される。
本発明の別の実施形態によれば、メディアセッションの開始は、メディアセッションのそれぞれのストリームに関する適応ノードにおいてメディアフォーマット変換を記述する更新されたセッション記述を含む更新メッセージを第1の端末によって第2の端末に送信するステップを含んでもよく、この場合には代替メディアフォーマットが、パケット交換型通信ネットワークを介して第1の端末から第2の端末にパスに沿って提示された。メディアセッションの少なくとも1つのメディアストリームのパケットデータは、上記のパスに沿って第1の端末から第2の端末に供給される。
この実施形態の変形において、送信された更新メッセージはさらに、第1の端末から第2の端末へのパスに沿って、第1の端末によって確保されるリソースに関する情報を含む。
他の変形によれば、第1の端末は、メディアセッションのそれぞれのストリームに関する適応ノードにおいてメディアフォーマット変換を記述する更新されたセッション記述を含む更新メッセージを第2の端末から受信してもよく、この場合には代替メディアフォーマットが、パケット交換型通信ネットワークを介して第2の端末から第1の端末にパスに沿って提示され、メディアセッションの少なくとも1つのメディアストリームのパケットデータは、上記のパスに沿って第2の端末から第1の端末に供給される。
実施形態のさらに他の変形において、受信された更新メッセージはさらに、第2の端末から第1の端末へのパスに沿って、第1の端末によって確保されるリソースに関する情報を含む。
メディアトランスポートプロトコルは、たとえば、リアルタイムトランスポートプロトコル(Real−time Transport Protocol)RTPであってもよく、セッション記述は、セッション記述プロトコル(Session Description Protocol)SDPフォーマットまたはリアルタイムストリーミングプロトコル(Real−Time Streaming Protocol)RTSPフォーマットで、提供される。
本発明の別の実施形態によれば、セッション管理プロトコルは、セッション開始プロトコルSIPであり、セットアップメッセージは、SIPプロトコルの招待(Invite)メッセージである。したがって、セットアップメッセージに対する応答は、第2の端末がメディアフォーマット変換リソースの検出および確保のための第1の端末の意思を承認することと、第2の端末が第1の端末によってサポートされていない代替メディアフォーマットにおけるメディアセッションのメディアストリームを第1の端末によってサポートされるそれぞれの提示されたメディアフォーマットに変換するために、少なくともNSISルータでメディアフォーマット変換のためのリソースの検出および確保を開始したことを第1の端末に示すSIPプロトコルのセッション進行(Session Progress)メッセージである。
セッション進行メッセージに含まれるセッション記述において提示された代替メディアフォーマットが、第1の端末によってサポートされていない場合には、第1の端末は、第1の端末が、セッション記述において提示された各代替メディアフォーマットに関して、NSISルータでメディアフォーマット変換のためのリソースの検出および確保を開始したことを第2の端末に示す暫定応答承認(Provisional Response Acknowledgement)メッセージを送信してもよく、メディアフォーマット変換のためのリソースが第2の端末によって確保された適応ノードが検出され、代替メディアフォーマットから第1の端末によって提示されたメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するように構成される。さらに、第1の端末は、この暫定応答承認メッセージの応答における暫定応答承認を受信してもよい。
本発明の別の態様は、メディア適応リソースの検出をサポートする動作NSISルータである。本発明の別の実施形態によれば、要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースを記録するための方法が提供される。メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末にパケット交換型ネットワークを介して移送されるメディアデータパスにおけるNSISルータによって行われる方法ステップは、照会メッセージは、パケット交換型ネットワークを介してNSISトランスポートレベルプロトコルNTLPを用いて、オンパス(on−path)NSISルータによって受信されてもよい。照会メッセージは、第1のメディアフォーマットから第2の異なるメディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するNSISルータに照会する。
受信された照会メッセージに対する応答において、オンパスNSISルータは、NSISトランスポートレベルプロトコルNTLPを用いて、要求中の端末に対して、NSISルータが、第1のメディアフォーマットから第2のメディアフォーマットに、メディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す応答メッセージを送信する。
メディアデータパスのオンパスNSISルータの位置に応じて、照会メッセージが照会端末から直接的に受信され、照会中の端末または隣接するNSISルータにNTLP機能性を提供するそのプロキシを形成することができることを留意すべきである。したがって、照会メッセージが受信されたという応答メッセージは、それぞれのエンティティに返される。
実施形態の変形において、照会メッセージはさらに、第1のメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたは第2の代替のメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するための機能について照会する。したがって、応答メッセージはさらに、NSISルータが、照会されたメディアフォーマット変換の少なくとも1つを提供することができるかどうかを示す。
本発明の他の実施形態において、照会メッセージは、適応機能が照会される1つまたは複数のメディアフォーマット変換を示すメディアフォーマット適応記述を含む。
本発明の別の実施形態において、オンパスNSISルータは、NSISトランスポートレベルプロトコルNTLPを用いて、リソース確保要求メッセージを受信してもよく、このメッセージは、リソースが割り当てられるように要求されるNSISルータによって行われるメディアフォーマット変換の記述を含む。オンパスNSISルータは、記述によって示されるメディアフォーマット変換のためのリソースが、NSISルータで割り当てられることができるかどうかを決定し、そうである場合には、変換のためのリソースを確保してもよい。したがって、オンパスNSISルータによって送信される応答メッセージは、NSISルータが変換のためにリソースを(首尾よく)確保したかどうかを示す。
本発明の別の実施形態において、オンパスNSISルータは、メディアデータパスに位置する別のNSISルータで確保されるメディアフォーマット変換の記述を含むNTLPを用いて、リソース確保要求メッセージを受信してもよい。リソース確保要求メッセージを処理するNSISルータは、メディアデータパスに位置する他のNSISルータに対するトンネルを確立し、メディアセッションの開始時に、変換のためにメディアデータパスに位置するNSISルータに変換されるメディアストリームのパケットデータを転送する。
本発明の他の実施形態において、オンパスNSISルータは、NSISトランスポートレベルプロトコルNTLPを用いて、メディアデータパスに位置しないNSISルータで、確保されるメディアフォーマット変換の記述を含むリソース確保要求メッセージを受信する。オンパスNSISルータは、リソース確保要求メッセージをメディアデータパスに位置しないNSISルータ(オフパス(off−path)NSISルータ)に転送し、オフパスNSISルータへのトンネルを確立する。メディアセッションの開始時に、オンパスNSISルータは、変換のために、変換されるメディアストリームのパケットデータをオフパスNSISルータに転送する。
本発明の別の実施形態によれば、オンパスNSISルータは、NSISルータで利用可能なメディアフォーマット適応機能の記述を照会メッセージに追加し、追加した記述を含む受信した照会メッセージを次のNSISルータ、メディアデータパスまたは宛先端末に転送する。転送された照会メッセージに対する応答において、オンパスNSISルータは、メディアデータパスにおける次のNSISルータまたは宛先端末から応答メッセージを受信してもよい。照会されたメディアフォーマット適応機能が利用可能である場合には、応答メッセージは、メディアデータパスに位置するNSISルータで利用可能であるメディアフォーマット適応機能の少なくとも1つの記述を含む。さらに、照会されたメディアフォーマット適応機能が利用可能である場合には、送信された応答メッセージは、メディアデータパスに位置するNSISルータで利用可能であるメディアフォーマット適応機能の少なくとも1つの記述を含む。
実施形態の変形において、オンパスNSISルータはまた、照会メッセージを少なくとも1つのメディアデータパスに位置しないNSISルータに転送し、少なくとも1つのメディアデータパスに位置しないNSISルータから、メディアパスに位置しない少なくとも1つのNSISルータで利用可能であるメディアデータ適応機能の記述を含む応答メッセージを受信する。
他の変形において、オンパスNSISルートは、受信された照会メッセージをメディアデータパスにおける次のNSISルータに転送する前に、メディアパスに位置しない少なくとも1つのNSISルータで利用可能なメディアデータ適応機能の記述を、上記の受信された照会メッセージに追加する。
本発明の別の実施形態において、要求中の端末に対して送信される応答メッセージはさらに、メディアパスに位置するか、または位置しない少なくとも1つのNSISルータで利用可能なメディアデータ適応機能の記述を含む。
本発明の別の実施形態によれば、パケット交換型通信ネットワークを介して端末と第2の端末との間で、少なくとも1つのメディアストリームを含むメディアセッションを確立するための端末が設けられる。端末は、セッションを開始するために、セッション管理プロトコルを用いて、セットアップメッセージを第2の端末に送信するための送信器を備え、メッセージは、メディアセッションにおいて送信されるメディアフォーマットと、各メディアストリームに関する対応するパラメータおよび属性と、を提示するセッション記述を含む。端末はまた、セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信するための受信器を備え、セットアップメッセージに対する応答は、修正セッション記述を含み、修正セッション記述は、メディアセッションの少なくとも1つのメディアストリームに関する代替メディアフォーマットを提示し、この場合には、第2の端末によってサポートされていないメディアフォーマットがセットアップメッセージに含まれるセッション記述において提示されている。
端末は、セットアップメッセージに対する応答に含まれるセッション記述において、各代替メディアフォーマットに関してそれぞれの代替メディアフォーマットが端末によってサポートされるかどうかを決定するための処理装置を備える。処理装置はさらに、それぞれの代替メディアフォーマットが端末によってサポートされていない場合には、ネクストステップインシグナリングNSISフレームワークを用いて、各代替メディアフォーマットに関して、少なくとも1つのNSISルータを検出するように構成される。それによって、検出されたNSISルータは、セットアップメッセージにおけるセッション記述において、第1の端末によってサポートされるメディアフォーマットから、セットアップメッセージにおける応答のセッション記述において、第2の端末によって提示されるそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換することができる。
さらに、端末は、第1の端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも1つのNSISルータが検出されている場合には、第1の端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出される少なくとも1つのNSISルータで、提示されたメディアフォーマットにおけるパケットデータをそれぞれの代替メディアフォーマットに変換するためのリソースを確保するための確保ユニットを備える。さらに、端末は、メディアフォーマット変換のためのリソースを首尾よく確保したときに、メディアセッションを開始し、メディアトランスポートプロトコルを用いて、メディアフォーマット変換のためのリソースが、端末によってサポートされていない各代替メディアフォーマットに関して確保されている少なくとも1つのNSISルータを介して端末から第2の端末に、メディアセッションの少なくとも1つのメディアストリームのパケットデータを提供するように適合される。
本発明の別の実施形態は、上記の種々の実施形態および変形の1つに基づき、メディアセッションを確立するための方法を行うように適合される手段を備える端末を提供する。
他の実施形態は、要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースを記録するために、NSISルータを提供する。NSISルータ(オンパスNSISルータ)は、メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末までパケット交換型ネットワークを介して移送されるメディアデータパスに位置する。NSISルータは、パケット交換型ネットワークを介してNTLPを用いて照会メッセージを受信するための受信器を備え、照会メッセージは、第1のメディアフォーマットから第2の異なるメディアフォーマットにメディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するNSISルータに照会する。
オンパスNSISルータはまた、受信された照会メッセージに対する応答において、NSISトランスポートレベルプロトコルNTLPを用いて、要求中の端末に対して応答メッセージを送信する送信器を備え、応答メッセージは、NSISルータが、第1のメディアフォーマットから第2のメディアフォーマットにメディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す。
別の実施形態は、上記の種々の実施形態およびその変形の1つに基づき、メディアフォーマット適応リソースを記録するための方法を行うように適合された手段を備えるNSISルータを提供する。
さらに、本発明の別の実施形態は、上記の種々の実施形態およびその変形の1つに基づき、端末のプロセッサによって実行されるときに、メディアセッションを確立するための方法のステップを端末に行わせる命令を格納するコンピュータ読み出し可能メディアを提供する。
本発明の別の実施形態は、上記の種々の実施形態および変形の1つによれば、オンパスNSISルータのプロセッサによって実行されるときに、メディアフォーマット適応リソースを記録するための方法をオンパスNSISルータに実行させる命令を格納するコンピュータ読み出し可能メディアに関連付けられる。
以下において、本発明は、添付の図および図面を参照してさらに詳細に記載される。図における類似の詳細または対応する詳細は、同一の参照符号で表記される。
本発明をよりよく理解するために、本文書で頻繁に用いられるいくつかの用語が、最初に明記される。
エンドポイントは、特定のサービスに関する要求を発行する(または処理する)ユーザまたはユーザエージェントを示す。サーバおよびクライアントは、エンドポイントであってもよい。エンドポイントはまた、ユーザエージェントおよびプロキシインスタンス、すなわちユーザの代わりに作用し、ユーザのサービス要求の詳細、機能および好みを承知しているソフトウェアエンティティであってもよい。エンドポイントの一例は、SIPユーザエージェントである。
NSISルータまたはプロキシは、経路指定機能の提供に加えて、パケット処理を行う可能性を有するネットワークノードを示す。パケット処理は、たとえば、メディアデータフローのトランスコーディング、メータリング、バッファリング、分割または同期であってもよい。パケット処理リソースは、メディア(フォーマット)適応リソースとも呼ばれ、NSISルータに必ずしも位置しなくてもよいが、それを介してアクセスされることが可能である。NSISルータは、QoSの根底にある基盤、すなわちQoS技術分野への入口点:DiffServ入口ルータ、MPLS Label出口ルータなどを認識するネットワークノードと同じ場所に配置されてもよい。提案された解決策は、必要なメディア適応リソースの確保のために、NSISシグナリングフレームワークを用いることから、NSISルータまたはプロキシは、NSIS操作可能である。
オーバレイネットワークは、同一の仮想トポロジの一部を形成するNSISルータ(およびプロキシ)の集合によって形成される。トポロジは、根底にある経路指定から抽出するという意味で仮想である。通常、オーバレイネットワークにおけるノードは、OSPF経路指定またはRIP経路指定などの根底にある経路指定を認識していない。
図1は、パケット交換型ネットワークの概略図を示し、この概略図に基づいて、本発明の例示の実施形態が以下に説明される。説明の目的だけのために、本願明細書で定義されるシグナリング拡張を理解するNSIS操作可能ルータ103〜108、いわゆるNSISルータが、ネットワークの中心部分に示される。しかし、ここで関心のあるNSIS機能性を実現しない2つの隣接するNSISルータの間に、別のルータまたはネットワークノードが存在してもよいことは明白である。したがって、NSISプロトコルレベルで、NSISルータ103〜108によって「見られる」ネットワークは、図2に示されるオーバレイネットワークに類似しており、このことから、NSISを実現していないルータは、NSISプロトコルレベルでNSISルータに対して透過的であることを認識されることができる。
NSISルータ108はまた、NSISルータ108に接続される端末110〜112用のプロキシとして機能する。同じことが、移動体通信ネットワークにおけるワイヤレス端末116〜123用のプロキシサーバとして作用するNSISルータ103に当てはまる。図1に示される実施例において、移動体通信ネットワークは、UMTSネットワークである。端末116〜123(UMTS用語におけるユーザ機器UEを示す)は、エアインターフェイスを介してノードB124または125に接続される。ノードB124、125および付属の無線ネットワーク制御装置(Radio Network Controller)RNCは、UMTSネットワークのいわゆる無線アクセスネットワーク(Radio Access Network)RANを形成する。RNCは、サービングGPRSサポートノード(Serving GPRS Support Node)SGSNおよびゲートウェイGPRSサポートノード(Gateway GPRS Support Node)GGSNを介して、パケット交換型ネットワークのNSISルータ103および107に連結される。同様に、移動体通信ネットワークにおける中間ノード(GGSN、SGSN、RNC、ノードB)は、特に移送およびアドレス指定の機能性を提供するNSISプロトコルレベルでOSI参照モデルの下位プロトコル層を実現するのに対し、NSISプロトコル層のような高位の層は中間ノードに対して透過的である。
一般に、端末は、メディアセッションを確立して関与するために、十分な機能を装備したデスクトップコンピュータ、ラップトップ、PDA、携帯電話、タブレットPCなどの任意の種類の固定またはワイヤレス端末であってもよい。たとえば、端末は、メディアセッションの確立時に、NSISルータ/プロキシ(NSISルータ103または108など)、パケット交換型ネットワークの他のノードまたは通信当事者と通信するためのトランシーバを装備してもよい。メディアサービスは、たとえば、マルチキャストまたはブロードキャストメディアストリーミング、ボイスオーバIP(VoIP)のようなエンドツーエンド指向の会話メディアサービス、ビデオ会議またはビデオ/オーディオストリーミングなどのストリーミングサービスなどを含んでもよい。
図3は、図1のパケット交換型ネットワークにおいて、エンドツーエンドメディアセッションを提供するために用いられることができる例示のプロトコルスタックを示す。
一般に、1つまたは複数のメディアストリームにおいて、メディアセッションのメディアデータが、提供される。メディアデータは、メディアトランスポートプロトコルを用いて、パケット化された形で移送される。たとえば、リアルタイムトランスポートプロトコルRTPは、メディアトランスポートプロトコルとして用いられてもよい。セッション開始および管理のために、セッション管理プロトコルが用いられてもよい。たとえば、セッション管理プロトコルの適切な選択は、セッション開始プロトコルSIPである。SIPの別法として、リアルタイムストリーミングプロトコルRTSPが用いられてもよい。通常、RTSPは、クライアントサービスへのマルチメディアサーバの場合に用いられ、TCPプロトコルを介して接続指向の通信方式で移送されるのに対して、SIPメッセージは、コネクションレスUDPプロトコルを介して行われる。また、RTPは、トランスポート層でUDPを介して一般に提供される。しかし、TCPの使用もまた、可能である。セッション管理プロトコルは、セッションの記述、いわゆるセッション記述を搬送する。この目的のために、セッション記述プロトコルSDPのようなプロトコルが、用いられてもよい。たとえば、SIPプロトコルメッセージにおいてカプセル化されたSDPデータが、搬送されてもよい。
本発明の異なる実施形態によれば、NSISフレームワークは、セッション開始および管理、メディアデータトランスポートおよびセッション記述のほか、拡張機能を実現するために用いられる。
NSISシグナリングフレームワークは、2つのプロトコル、すなわちNSISシグナリング層プロトコル(NSLP)と一般に呼ばれるシグナリングアプリケーション層およびNSLPデータのための根底にあるトランスポート機構と、NSISトランスポートレベルプロトコル(NTLP)と、に分割されてもよい。NTLP層において、NSLPデータをカプセル化するために、ジェネラルインターネットメッセージングプロトコルフォーシグナリング(General Internet Messaging Protocol for Signaling)(GIMP)が用いられてもよい。NTLP層においてカプセル化されたNSLPデータは、トランスポート層におけるUPD接続またはTCP接続を介して、提供されてもよい。
以下にさらに詳細に説明されるように、本発明の1つの態様は、メディアセッションにおいて用いられるメディアコーディクのメディアフォーマットにおける非互換性を克服するために、メディアセッションにおいて強化した機能性を備えたNSISルータに対応するメディアフォーマット適応ノードを含むことができる新たなメディア適応NSLPプロトコルの実現である。さらに、メディア適応NSLPプロトコルは、適切なメディアフォーマット適応ノードの検出およびメディアフォーマット適応ノードにおけるリソースの確保を可能にする。
図3において、ネットワークおよびリンク層(層3および2)は、アドレス指定のためのIPプロトコルおよびMACプロトコルによって具体化される。しかし、ネットワークおよびリンク層プロトコルの実現は、ネットワークまたはその異なる部分に用いられるネットワーク基盤に左右される。
図4は、本発明の実施形態による2つの端末間のメディアセッションの例示の確立を示す。図4に基づき、本発明の主な態様のいくつかが、以下においてさらに詳細に説明される。
プロキシAを用いることができる端末A(エンドポイントA)は、第一に、プロキシBを用いることもできる別の端末ノードB(エンドポイントB)に対するメディアセッションを最初に開始する。端末Aから端末Bに送信されるセットアップメッセージは、セッション管理プロトコルを用いて移送され、セッション記述を含む。セットアップメッセージに含まれるセッション記述は、メディアフォーマット、セッションにおいて搬送される各メディアストリームに関するパラメータおよび属性を識別することによって、メディアセッションを記述する。ストリームのそれぞれは、単方向ストリームまたは双方向ストリームのいずれであってもよい。これに関連して、双方向は、2つのストリームがそれぞれ、共通のメディアフォーマットで端末Aから端末Bにおよび端末Bから端末Aに提供されることを意味するのに対し、単方向は、1つのストリームが記載したメディアフォーマットで端末Aから端末Bにまたは端末Bから端末Aの一方に提供されることを意味する。たとえば、ビデオ会議セッションは、PCMフォーマットにおける双方向のオーディオストリームと、MPEGフォーマットにおける双方向のビデオストリームと、からなってもよい。この実施形態の変形において、強化されたSDPプロトコルは、確立されるメディアセッションの内容を記述するために用いられる。
セッション記述のパラメータおよび属性は、メディアセッション、たとえば、セッションの各個別のストリームに関するQoS必要条件を任意に含んでもよい。さらに、パラメータおよび属性はまた、メディアセッションのストリームが、セッションに関して任意であるか、または必須であるかを示してもよい。
さらに、パラメータおよび属性はまた、端末Aがその提案されたセッション記述に対する変更、たとえば、異なるQoS必要条件の使用、個別のメディアストリームに関して提示されたメディアフォーマット(たとえば、フォーマットのディスプレイサイズ、コーデック、ビット速度、フレーム速度など)などの変更を承認することに同意することを端末Bに示してもよい。したがって、セッション記述におけるパラメータおよび属性は、メディアフォーマットにおける非互換性が端末Aおよび端末Bで利用可能な有効リソースを用いて解決されることができない場合には、端末Aがまた、メディアフォーマット適応ノードの使用に同意するという信号を端末Bに送ってもよい。
端末Bは、セットアップメッセージを受信し、セッション記述を評価する。この評価手順において、端末Bは、十分な機能が、メディアセッションを確立するために端末で利用可能であるかどうかを決定する。たとえば、ビデオストリームがメディアセッションに含まれる必要があるが、端末Bは、セッション記述において端末Aによって提示されたメディアフォーマットにおけるビデオデータを符号化および/または復号化するための適切なコーデックを有していない場合、またはたとえば、適切なディスプレイサイズが利用可能でない場合には、端末Bは、確立されることができるようにセッション記述を変更することを決定してもよい。
セットアップメッセージに対する応答において、端末Bは、端末Aにセッションに関して端末Bが提案する変更を認識させるために、修正セッション記述を含む暫定承認を端末Aに送り返す。
たとえば、端末Aは、ビデオ会議セッションを確立することを望み、640×400ピクセルのサイズで双方向のMPEGビデオストリームを用いることを提示する。しかし、端末Bは、わずか320×200ピクセルのディスプレイサイズを装備しており、DivXビデオフォーマットでしか符号化および復号化することができない。端末Bが、ディスプレイサイズを局所的に変換可能なリソースを装備しており、640×400ピクセルの提示されたサイズのビデオを符号化することができる場合には、ビデオに関する640×400ピクセルのサイズの提示が端末Bには許容可能であってもよい。適切なリソースが利用可能でない場合には、端末Bは、320×200ピクセルでDivX符号化されたビデオを用いることを提案することを示すように、セッション記述を修正してもよい。
端末Bからの応答の受信時に、端末Aは、セッション記述に対する変更を認識し、新たな記述が利用可能なリソースが許容可能であるか、および/またはセッションに関するメディアフォーマット適応を用いる可能性を決定してもよい。
実施例に戻ると、端末Aがまた320×200ピクセルのフォーマットでビデオストリームを作成して復号化することができるDivX符号変換器を有する場合には、セッション記述に対する修正が許容可能であることを暫定承認メッセージにおいて、端末Bに示してもよい。DivXコーデックが端末Aで利用可能ではないが、セッションに関するメディアフォーマット適応ノードの使用が端末Aによって許容される場合には、端末Bに暫定承認の信号を送ってもよい。この暫定承認は、ネットワークにおけるメディアフォーマット適応が、ビデオストリームを移送するパケットがそれぞれ端末Aから端末Bにおよび端末Bから端末Aに供給される両方のパスで可能であるという前提条件下で、メディアセッションが開始されることができることを端末Bに示してもよい。
ネットワークのパケット交換性のために、メディアトランスポートプロトコルを用いて、メディアセッションのそれぞれのメディアストリームのデータを搬送するパケットの移送は、端末Aから端末Bにおよび端末Bから端末Aのいずれかの方向においてそれぞれ、異なるパスで経路指定されてもよいことを認識することが重要である。したがって、ビデオセッションのパケットデータが、端末Aと端末Bとの間の両方向における1つのパスを介して供給されることを保証することができない場合には、双方向のストリームが関連しているのであれば、端末Aから端末Bにおよび端末Bから端末Aへのいずれかのパスで独立に、メディアフォーマット適応機能が検出される必要がある。
QoS制約条件がメディアセッションの確立のための前提条件として満たされなければならない場合において、ネットワークリソースは、所与のQoS制約条件(たとえば、保証される待ち時間、保証される最小帯域幅など)で、メディアトランスポートプロトコルを用いてメディアデータを移送するために、いずれかのパスに沿って確保されてもよい。この実施形態の変形において、NSISシグナリングフレームワークのQoS−NSLPプロトコルが、この目的のために用いられる。
本発明の異なる実施形態によれば、パスに沿ったメディアフォーマット変換機能の検出および確保は、図5〜図13を参照して以下にさらに詳細に説明される。簡単に言えば、機構は、NSISルータを検出するために、新たなメディア適応NSLPを提供することによって、NSISシグナリングフレームワークを用いる。このフレームワークは、インターフェイスをとり、たとえば、トランスコーディング/変換によって、セッションに関してメディアフォーマットの不適合を克服することができるメディア適応リソースと共に用いることができ、これらのNSISルータのメディア適応機能のリソースを確保することを可能にする。実施例に戻ると、端末Aは、640×400ピクセルのMPEGビデオを320×200ピクセルのDivXビデオに変換(トランスコード)することを可能にするビデオトランスコーダとインターフェイスをとるNSISルータに関して、NSISオーバレイネットワークにおいてNSISルータに照会してもよい。
この照会に対する応答において、端末Aは、所望のメディアフォーマット適応機能性を提供することができるNSISルータを識別する情報を受信する。次に、端末Aは、識別されたNSISルータで、メディア適応のためのリソースを確保する。
類似の手順が、パケット交換型ネットワークを介して端末Bから端末Aにパスに沿って、メディア適応リソースを検出して確保するために、端末Bによって行われる。したがって、実施例において、端末Bは、640×400ピクセルのMPEGビデオを320×200ピクセルのDivXビデオに変換(トランスコード)することを可能にするビデオトランスコーダとインターフェイスをとるNSISルータに関して、NSISオーバレイネットワークにおいてNSISルータを照会してもよい。
ネットワークにおいてメディア適応リソースを十分に確保したときに、端末Aは、更新されたセッション記述を含むメッセージを送信することによって、端末Bに通知してもよい。更新されたセッションは、端末Aが所望のメディアフォーマット変換を提供するNSISルータを見つけることが可能であったことと、それについてリソースを確保することが可能であったことと、を端末Bに示す。任意に、QoS制約条件が満たされる場合には、メッセージはまた、ネットワークにおいて端末Aによって確保されることが可能であったQoS制約条件を示してもよい。端末Bは、端末Bによって確保されたメディア適応リソースおよび任意にネットワークにおいて確保されたQoSリソースを反映するように、セッション記述を「補正する」さらに更新されたセッション記述を含む別のメッセージを送信することによって、メッセージに応答する。
更新されたセッション記述に基づくセッションが端末Aおよび端末Bにとって許容可能である場合には、メディアセッションが開始される。たとえば、端末AまたはBのいずれかのポリシーに基づき、メディアフォーマット適応が可能でない場合、メディア適応リソースは検出されない場合、または確保されることができない場合には、セッションの確立は、中断されてもよい。
次に、本発明の例示の実施形態によるメディア適応リソースの検出および確保が、さらに詳細に記載される。図5は、メディアセッションの確立を可能にするために、所望のメディアフォーマット変換に関与することができるNSISルータを識別するために適した本発明のこの実施形態によるオンパスNSISルータ検出機構を示している。例示の実施形態において、端末110(端末A)が端末122(端末B)とメディアセッションを確立しようとすると仮定される。
例示だけのために、端末110から端末122へのメディアデータの伝送のために、メディアフォーマット適応ノードの検出および確保が示される。類似の検出および確保のプロセスが、端末122から端末110へのメディアデータの伝送のために、端末122によって用いられる。
第一に、端末110(または端末100によって用いられるプロキシ)は、次のNSISルータ108へのメディア適応ノード検出照会を作成して、送信する。照会メッセージは、端末122に達するまで、ホップバイホップ方式で、1つのNSISルータから次の隣接するNSISルータに経路指定される。それによってパスに沿って照会メッセージは、経路指定され、メディアトランスポートプロトコルにおいてカプセル化されるメディアデータは、セッションの開始時に送られる。NSISシグナリングフレームワークにおいて、NTLPプロトコルは、メディアストリームのパケットデータが、ネットワークを介して端末110から端末122にとるルート(パス)を検出することが可能である。したがって、このルートに沿ったすべての中間NSISルータは、パスに沿って隣接するNSISルータを知っており、NSLPプロトコルに基づいて、それらのNSISルータが照会メッセージを転送することを可能にする。メディアストリームのパケットデータが、ネットワークを介してとる実際のパスの知識により、パスに沿ってメディア適応リソースを検出することを可能にする。メディアフォーマット適応リソースを照会するために、それぞれのノードは、NTLPおよびNSLPの下層を含むNSISシグナリングフレームワークを実現する必要があり、メディアトランスポートプロトコルにおいてカプセル化されるメディアデータは、それぞれのノードに送って、ネットワークノードでメディアデータ適応を実行する必要がある。
照会メッセージは、端末110によって必要とされるメディアフォーマット適応の記述を含む。したがって、通常、端末110(または端末110のプロキシ)は、端末110によってサポートされるが、端末122によってサポートされないフォーマットXにおけるメディアデータを、端末122によってサポートされるが、端末110によってサポートされないフォーマットYに変換することができるメディア適応リソースとインターフェイスをとるNSISルータを探索する。端末自体が必要な機能性、たとえば、この文書において提示されるNSISメディアフォーマット適応NSLPを実現していない場合には、プロキシは通常、サービスにおいて端末をサポートするために用いられる。以下の節でさらに詳細に説明されるNSISメディアフォーマット適応NSLPに関連して、これは、端末がプロキシで「記載する」ことができ、プロキシがネットワークにおいてメディアフォーマット適応リソースを検出して確保するために、これらの端末にサービスを提供することを意味する。
この例示の実施形態によれば、照会メッセージが端末122に達するときに、端末122(または端末122のプロキシ)は、照会が端末122(またはそのプロキシ)に達するまでNSISルータからNSISルータに行われるパスと同一のパスに沿ったホップバイホップ方式で応答を返す。同じことが照会に適合する場合には、NSISルータはそれぞれ、応答に対するメディアフォーマット変換機能を含む。
端末110(または端末110のプロキシ)における応答受信時には、同じように応答を解析して、メディアフォーマット変換のためのNSISルータを選択する(所望のメディア適応機能を備えた候補のNSISルータが2つ以上ある場合)。メディアフォーマット変換のために選択されたNSISルータでリソースを確保するために、端末110(または端末110のプロキシ)は、NSLPプロトコルに基づいて、ホップバイホップ方式で選択されたNSISルータに確保メッセージを送信し、選択されたNSISルータは、所望のリソースが十分に確保されたかどうかを示す応答メッセージを返す。
上述したように、QoS制約条件がメディアセッションによって満たされなければならない場合において、図5に示されているような類似の機構が、端末110から端末122に(またはそれらのプロキシ間で)メディアデータのパスに沿ってネットワークリソースを確保するために用いられてもよい。実施形態の変形において、NSISシグナリングフレームワークがネットワークリソース確保のために用いられる場合には、ネットワークリソースの照会および確保およびメディアフォーマット適応の照会および確保が、組み合わせられてもよい。
結果として生じるシグナリングは、以下の相違を除き、図5に示されるシグナリングと類似である。照会メッセージが、端末110によって所望のQoS制約条件および所望のメディアフォーマット適応を指定する。さらに、照会メッセージに対する応答はまた、QoSにNSISルータが提供することができる情報も含む。確保メッセージはさらに、QoSにメディアデータのパスに沿ったNSISルータが確保するために要求されるほか、上述したメディアフォーマット適応要求の情報を含む。さらに、ネットワークリソースが、端末110から端末122への完全なメディアデータパスに沿って確保されなければならないため、確保メッセージは、端末122に送られる必要がある。同様に、確保メッセージに対する応答が、端末122(またはそのプロキシ)で作成され、応答メッセージはさらに、すべてのNSISルータが要求に基づきネットワークリソースを確保することができたかどうかと、要求に基づきメディアフォーマット適応リソースが確保されたことと、を示す。
この実施形態の別の変形において、メディアフォーマット適応は、ソースフォーマットXからターゲットフォーマットYにパケットデータを直接的に変換するために必要としなくてもよい。メディアフォーマット適応はまた、ネットワークにおいて2つ以上のメディアフォーマット適応ノードを検出して用いることを可能にしてもよい。たとえば、第1のNSISルータは、ソースフォーマットXにおけるメディアデータをフォーマットY’に変換してもよく、第2のNSISルータは、フォーマットY’におけるメディアデータをターゲットフォーマットYに変換してもよい。
照会は、たとえば、変換のソースフォーマットおよびターゲットフォーマットを指定してもよく、変換のために適切であれば、端末Bに対して照会を転送するときに、すべてのNSISルータは、照会に対する適応機能を含んでもよい。
たとえば、第1のNSISルータは、640×400ピクセルから320×200ピクセルのみにMPEGビデオのサイズをトランスコーディングすることができることを示す情報を照会に追加してもよいが、端末Bに向かう次のNSISルータに対して照会を送る前に、コーデックフォーマットを変換することはできない。端末Bへのパスにおける別のNSISルータが320×200ピクセルのMPEGビデオから320×200ピクセルのDivX符号化ビデオへの欠けている変換を提供することができる場合には、このルータは、照会において同じことを示してもよい。したがって、応答は、いずれのNSISルータが、中間/ソースメディアフォーマットから中間/ターゲットメディアフォーマットへの変換を提供することができるかを示してもよい。また、メディアフォーマット適応機能の検出および確保とネットワークリソースの検出および確保を組み合わせることが、可能である。
以下の節において、メディアフォーマット適応の検出および確保機構の本発明の異なる実施形態によるさらに詳細な実現が、記載される。以下の節において、例示のために、SDPプロトコルがメディアセッション(セッション記述)を記述するために用いられることと、SIPプロトコルがSDPフォーマットにおいてカプセル化されたセッション記述を搬送し、端末110と端末122との間のメディアセッションの開始および制御を行うために用いられることと、が仮定される。さらに、セッションのメディアストリームが、RTPプロトコルを用いて移送されることが仮定される。
よりよい理解のために、メディアセッションの確立は、2つの段階に分割されてもよい。
・段階I:必要なメディア適応が確認され、探索され、見つかった場合には、確保される。メディア適応リソースが確保された後、この段階が終了し、次の段階に進む。
・段階II:エンドポイント(端末110および122)の間の最後のセッションの詳細の通信および既に確保されたリソースを用いることによる通信の開始
メディアセッションの記述に関して従来のSDPプロトコルを用いて、メディアセッション(サービス)を要求するエンドポイントは、セッションのそれぞれのストリームがセッションの必須または任意のいずれの構成要素であるか、および/またはセッションの要求されたストリームのいくつかが利用可能でない場合には、セッションが許容可能であるかを指定するための手段を持たない。ユーザが、受信を望むストリームに関して、ネットワークにおいてエンドポイントまたはメディアフォーマット適応ノードで局所的に利用可能であるメディア適応リソースを前向きに実行または利用することができない。
本発明の一実施形態によれば、既存のSDPプロトコルに対する拡張が提案され、これらの欠点の克服を可能にする。この実施形態によれば、新たな前提条件タグは、ストリームのそれぞれまたはセッションに関して導入され、ストリームのそれぞれが、セッションの必要な部分であるかどうかを指定可能であるか、または適応が見つからない場合(「必須」または「任意」のいずれであっても、「強度タグ」であり、以下参照のこと)には、いくつかのストリームを残すことができる。
特に、SDPの前提条件フレームワークを新たなメディア適応前提条件を有するように拡張することが提示される。既存の“qos”トークンのほかに、前提条件タイプに関する新たなトークン値、すなわち“adaptation”が定義される。この新たな前提条件に加えて、2つの新たなSDP属性、すなわちターゲット“a=target:”および“a=source:”属性が定義される。これらの属性は、メディア適応のターゲット/ソース、たとえば、ソースメディアフォーマットにおけるメディアデータがいずれのターゲットメディアフォーマットにトランスコードされるかを示す。任意に、また、送信器(端末110)と受信器(122)との間の各中間ノードの“footprint”を示すための新たな属性も定義される。footprintは、“a=intermediate:”の行におけるメディアフォーマットパラメータによって記載されるフォーマットにおける値のセミコロンで分離されたリストに提供されてもよい。
新たな定義パラメータの例示の定義が、以下に示される。
target-tag = "a=target:" media-format
source-tag = "a=source:" media-format
intermediate-tag = "a=intermediate:value-type value-list

where
media-format = payload type number
value-type = format of the footprint, e.g., RTP SSRC.
value-list = list of footprint identifiers
前提条件フレームワークにおいて、新たなトークンが、前提条件タイプに導入される。
precondition-type = "qos" | "adaptation" | token
前提条件フレームワークの残りの定義は、http://www.ietf.orgで利用可能なRFC3312に明記されているように、再使用される。
セッションを確立するために、端末110のユーザは、上記の新たなSDP定義に基づき、セッションの1つまたは複数のストリームに関して適応のための前提条件を設定するメディアセッションのセッション記述を含むSIPプロトコルの招待(INVITE)メッセージを送信する。この例示の実施形態によれば、前提条件属性は、端末110が指定(提示)されたメディアフォーマットにおける対応するストリームを受信することができるが、別のメディアフォーマットでは受信することができないことを端末122に通知する。したがって、要求されたように、端末122によって指定されたメディアフォーマットで提供されることができる場合には、メディア適応は必要ではない。
同時に、前提条件属性は、端末110が端末122に前提条件付きのストリームが利用可能である、すなわちメディア適応リソースが見つかって確保されるまで、端末110が端末122に入ってくるセッションについて警告したくないことを端末122に示してもよい。
段階Iの例示のステップごとの手順が、以下に示される。端末122は、セッション記述の以下の例示の抜粋を含む招待メッセージを送信してもよい。
m=audio 20000 RTP/AVP 0
a=rtpmap:0 iLBC/8000
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=curr:adaptation e2e none
a=des:adaptation mandatory e2e sendrecv
これらの行は、セッションが、ポート番号20000でRTPプロトコルを用いて移送され、ペイロードタイプ0を有する双方向のオーディオストリームを含む必要があることを指定する。第2行は、ペイロードタイプ0のオーディオストリームが、サンプリング周波数8000Hzを用いてiLBC符号化されたオーディオストリームであることを明記する。残りの行は、他のストリームは承認されないため、要求されたストリームが利用可能でない場合に限り、適応が必須であることを明記する。すなわち、このストリームが(適応または他の方法のいずれかによって)提供されない場合には、セッションは確立されないことになる。a=curr:は、適応の現在の状態を示し、“none”は、このセッションオファを発行する瞬間に、エンドポイント(端末)が適応、すなわちエンドツーエンド(「e2e」)適応を確保していないことを意味する。a=des:の行は、提案されたメディアフォーマットが承認されない場合における所望の適応を示す。メディア適応は、双方向のストリームが通信されている場合には、両方向(端末110から122へおよび端末122から110へ)においてエンドツーエンド適応でなければならない。
以下において、NSISメッセージの送信者または受信者として、使用端末110および端末110のプロキシ(NSISルータ108)は、等価である。端末110自体がNSISメディアフォーマット適応NSLPをサポートするかどうか、または端末110が検出および確保のシグナリングのために提供するプロキシに付属しているかどうかに応じて、NSISメッセージを送信する端末110またはプロキシ108であってもよいためである。プロキシがセッションにおいてシグナリングのために用いられる場合には、必要とされるメディア適応の設定が、SIPメッセージを交換することによって検出されることができるため、両方の端末110および122におけるSIPユーザエージェントは、プロキシの存在を認識してもよい。したがって、SIPとメディアフォーマット適応NSLPとの間のインターフェイスもまた、設けられてもよい。
端末122が、ストリームの指定されたメディアフォーマットをサポートしないことを(たとえば、指定されたコーデックが存在しない)検出する場合には、SIPプロトコルの暫定応答メッセージ(コード183)を端末110に送信する。必要なコーデックが端末122で利用可能でないために、それぞれのメディアストリームが指定されたメディアフォーマットで端末110によって受信のみが可能であることを前提条件属性が示すときには、端末122は、セッションを確立するためにメディアフォーマット適応が必要であることを認識する。したがって、端末122がまた、“adaptation”前提条件をサポートするため、端末122から端末110にネットワークを介してメディアデータパスに沿って、メディアフォーマット適応リソースの検出および確保を直ちに開始してもよい。
さらに詳細には、端末122は、上記で示された例示のセッション記述を含む招待メッセージを受信し、iLBCコーデックをサポートせず、代替のメディアフォーマットPCM符号化オーディオとしてサポートすることができることを認識する。代替のメディアフォーマットとしてPCMコーデックの存在を示すために、端末122は、ポート番号をゼロ(“0”)に設定し、PCMコーデックのための新たなペイロードタイプ、“1”を追加することによって、セッション記述を修正する。したがって、端末122は、オーディオストリームに関してサポートするメディアフォーマットを含むようにセッション記述を修正し、セッションを確立するために、準備としてメディア適応を用いることを示している。
暫定応答において端末122によって送信されたセッション記述の例示の修正の抜粋は、以下のようであってもよい。
m=audio 0 RTP/AVP 0 1
a=rtpmap:0 iLBC/8000
a=rtpmap:1 PCM/8000
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
a=curr:adaptation e2e unknown
a=des:adaptation mandatory e2e sendrecv
a=conf:adaptation e2e recv
メディアフォーマット適応リソースの検出および確保のために、端末122がNSISシグナリングフレームワークを用いるため、上記で既に概略を述べたように、ネットワークからその照会メッセージへの応答メッセージに基づいて、その「送信」方向(端末122から端末110に)において利用可能なメディア適応を提供するためのリソースを検出してもよい。しかし、他の方向、すなわちメディアデータが端末110から端末122に経路指定されるパスで、確保の状態を認識しない。したがって、端末122は、その暫定応答を送信することによって、端末110へのその「受信」方向においてリソースの確保のための確認の要求に進んでもよい。
さらにおおざっばに言えば、暫定応答メッセージは、端末122に対して「了解、こちらはメディア適応を行おうとしている。必要なリソースを確保するまで、そちらに警告を発しない」と宣言することと等価である。ストリームが双方向である場合には、端末122は、「了解、こちらはメディア適応を行おうとしている。必要なリソースを確保するまで、そちらに警告を発しない。そちらがメディア適応を行おうとすることは可能であり、そちらがすべての必要なリソースを確保する前に、こちらに警告を発さないで欲しい」ことを示す。
実施例において、SDP記述の「m行」によって指定されたストリームが双方向である、すなわち、方向性に関する属性を持たない(“a=sendrecv”属性がないか)または前提条件において“sendrecv”値を有するかのいずれかが仮定されている。
応答メッセージを送信した後、端末122は、メディアストリームのためにメディア適応リソース(および適用可能である場合には、ネットワークQoSリソース)の確保を開始してもよい。端末110は、PRACK(暫定応答承認)によって応答メッセージを承認し、端末110から端末122へのメディアデータパスでメディアフォーマット適応リソースの検出および確保を開始する。
両方の端末110および122は、NSISシグナリングフレームワークおよび提案されたメディアフォーマット適応NSLPプロトコルを用いる。図5を参照して、上記で概略を述べたように、端末110は、端末122に対する照会メッセージを送信し、端末122は、端末110に対する照会メッセージを送信する。
端末122がメディア適応リソース(およびネットワークQoSリソース)の確保を確認する応答メッセージを受信する場合には、端末122は、確認を受信しておらず、前提条件が依然として満たされていないため、他の方向におけるリソースも確保されるまで待機する。
端末110は、応答メッセージを受信すると、更新されたセッション記述において、何がメディア適応処理に対する入力および出力であるかを明確に示す。入力は“a=source:<media format>”属性(この場合にはiLBC)によって示され、ターゲットとされる出力(“a=target:<media format>”によって示される)は、返答において要求されるコーデック(PCM)である。次に、端末110は、更新されたセッション記述の以下の例示の抜粋を含むSIPプロトコルの更新メッセージ(更新オファ)を端末122に送信する。
m=audio 20000 RTP/AVP 0 1
a=rtpmap:0 iLBC/8000
a=rtpmap:1 PCM/8000
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
a=curr:adaptation e2e send
a=source:0
a=target:1
a=des:adaptation mandatory e2e sendrecv
端末122は、メディア適応(および任意にネットワーク)リソース確保の現在の状態に関して更新されたセッション記述もまた含む返答メッセージを用いて応答し、セッション記述は特に、以下の部分を含む。
m=audio 30000 RTP/AVP 0 1
c=IN IP4 192.0.2.4
a=rtpmap:0 iLBC/8000
a=rtpmap:1 PCM/8000
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
a=curr:adaptation e2e sendrecv
a=des:adaptation mandatory e2e sendrecv
a=source:1
a=target:0
各“a=rtpmap”属性で、セッション記述において指定されたさらにコーデック特有の(iLBCまたはPCM)パラメータであってもよいことを留意されたい。これは、NSISルータ(メディア適応ノード)において行われている正確なメディア処理をさらに高度な詳細で指定可能であってもよい。
必要なメディア処理の記述
次に、本発明の例示の実施形態による利用可能なメディアフォーマット適応リソースを検出するために、端末110および122によって送信される照会の内容が、さらに詳細に記載される。候補のメディア適応ノードを見つけるために、機構は、必要な処理を指定するために必要とされる。
たとえば、セッション記述オファは、以下のようであってもよい。
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 99
a=rtpmap:99 iLBC/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
a= pkt_rate=20; bw=20000
このセッション記述は、ポート49180におけるRTPを介して移送されるiLBCフォーマットにおけるオーディオストリームと、RTPを介して移送されるポート51372でH261符号化ビデオストリームと、を含むセッションを「オファする」。上述の実施例において、パラメータpkt_rateおよびbwは、例示のために示されているに過ぎない。これらのパラメータは、簡略化した表現として示される。
このセッション記述(オファ)に対する応答において、開始端末は、以下の修正セッション記述を受信してもよい。
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 99
a=rtpmap:99 iLBC/8000
m=video 0 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=pkt_rate=10; bw=150000
それによって返答する端末は、ペイロードタイプ32を有するMPEG2(MPV)フォーマットにおけるビデオストリームのために、代替のコーデックを提案する。
修正セッション記述から生じるメディア適応に関する一般的な定義は、以下のフォーマットに基づいてもよい。
Figure 0004746102
このフォーマットに基づいて、上記で与えられた実施例において、必要とされるメディア適応の記述は、以下のように見える。
{(media_type =video, media_format= 31), (media_subtype =H261), (parameter_set: rate=90000; pkt_rate=20; bw=20000)} <-> {(media_type= video, media_format= 32), (media_subtype= MPEG2 (MPV)), (parameters: rate= 90000; pkt_rate=10; bw=150000)}
上記の返答端末のセッション記述において、方向性は、メディアストリーに関してsendrecv/sendonly and recvonly属性によって決定されてもよく、“m=”の行は通常、各メディアの行に関する“a=”の行に存在する。存在しない場合には、sendrecvが仮定され、存在する場合には最初のnタプルが必要なメディア変換に対する入力を記述し、第2(および以下)のnタプルが所望の出力(または複数の出力)を記述する。上述の必要なメディア適応の表現に関する実施例において、双方向性は、“<−>”によって示される。
必要な変形の階層順のnタプルは、データパケットの経路指定に影響を及ぼさず、通常は層4までのプロトコルヘッダにおける変更であり、UDPまたはTCPは経路指定に影響を及ぼしうるが、これは以下で説明される。この階層リストは、メディアタイプ(オーディオ/ビデオ/テキストなど)から始まり、次に、メディアのサブタイプ(コーデック)およびペイロードタイプ番号(RTPの場合)および任意の不適合のメディアストリーム属性へと続いてもよい。
必要な変形の階層順のnタプルは、“m=”の行を属性“a=”の行に存在する“m=”の行およびそれらの関連属性と比較することによって、得られる。“m=”の行を比較することによって、メディアタイプおよびペイロードタイプ(またはSDPにおいて定義されるように「メディアフォーマット」)の不適合が、確認されてもよい。上記の実施例において(ボールド体の“m=”の行)、返答側がペイロードタイプ32を有することを望んでいるように、メディアフォーマットに不適合がある。順に並んだnタプルにおける次の項目は、“a=”の行から得られるメディアサブタイプおよびメディアストリームパラメータ設定である。これらの属性は、機能(メディアサブタイプ(コーデック)、コーデックなど)と、言語またはストリームの定格、たとえば、言語の場合には“a=lang”などのユーザの好みを表現してもよい。
適応の必要性を生じうる可能な属性のリストは、属性フィールドリスト“att−field”に基づき、http://www.iana.org/assignments/sdp−parametersのIANAから得られることができる。さらに、各コーデックはそれ自体のパラメータを定義するため、すべてのパラメータの不適合が、1つまたは複数の必要な適応を意味するわけではない。どのパラメータが適応を起動するかを割り当てるために、端末において見られるか、ネットワークにおいてメディア適応リソースで利用可能な変形が割り当てられる一連の規則および制約条件を合わせたすべてのコーデックおよびコーデックパラメータおよびそのすべての可能な変形の対照表があってもよい。残念なことに、変換が有効であるか、場合によって有効でないかを確認することは、自動的に行われない場合がよくある。したがって、一連の規則および制約条件が、提供されてもよい。
たとえば、すべてのオーディオコーデックが同一のパラメータを有するとは限らず、一部は可変ビット速度であり、一部は一定のビット速度である。したがって、一定のビット速度構成に対する可変ビット速度コーデックの所与の構成の直接的な変換は、ない。等価な(または十分に良好な)適応を生じるパラメータの設定は、ユーザによって手動で設定されなければならない。そのような規則および制約条件のリストは、メディア適応記述に含まれるか、またはURIによってそれに関連付けられることが提案される。
メディア適応の記述は、SDPngなどの拡張されたセッション記述プロトコルを用いて実現されてもよい。特に、以下に列挙されるsdpng−rtp−video−txcodecパッケージリストは、規則および制約条件のそのようなコンテナであってもよい。SDPngは、機能および制約条件を表現可能なより洗練された拡張された文法を有する。SDPngはまた、外部リソース(用いられる属性が定義されるいわゆるパッケージ)に対する参照も可能である。したがって、SDPngにおける異なる単方向トランスコーダ機能性の別の実施例の表現は、以下の通りである。
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/sdpng \
sdpng-base.xsd
http://www.iana.org/sdpng/rtp/sdpng-rtp-pkg.xsd
http://www.iana.org/sdpng/video/\
sdpng-rtp-video-txcodec\
pkg.xsd"
owner="txcoding-service@example.com" id="98765432" \
version="1">
<cap>
<rtp:udp name="rtpudpip6">[...]</rtp:udp>
</cap>
<cfg>
<video:txcodec name="h263plus-mpg-txcodec">
<video:input-encoding>H.263+</video:encoding>
<video:input-resolution>QCIF</video:resolution>
<video:input-framerate max="30"/>
<video:ouput-encoding>MPEG-4</video:output-format>
<video:output-resolution>QCIF</video:resolution>
<video:output-framerate max="30"/>
</video:txcodec>
</cfg>
<def>
<rtp:udp name="rtp-def" ref="rtp:rtpudpip6">
<rtp:pt-in>31</rtp:pt-in>
<rtp:pt-out>32</rtp:pt-out>
</rtp:udp>
</def>
<constraints>
[where applicable]
</constraints>
</sdpng>
上記の記述は、この記述を作成したメディア適応リソースが、H263、同一の解像度およびフレーム速度でMPEG−4ビデオに対して最大毎秒30フレームのQCIF解像度に基づくトランスコーディングをサポートすることを示す。また、コーデックのコーデック特有のパラメータを理解するために、別のパッケージが必要とされることを留意されたい。これは、http://www.iana.org/sdpng/video/sdpng−rtp−video−txcodec−pkg.xsdから検索される。また、ペイロードタイプ(メディアフォーマット)は、返答側の要求に適合させるために、31から32に変更しなければならないことも留意されたい。
リソースの検出および確保の別の態様
リソース確保のためのトリガは、ネットワークにおいてであってもよく、またはクライアント自体からであってもよく、クライアントがNSISメッセージングを実現するか、またはNSISプロキシに付属しているかに左右される。いずれの場合でも、SIPユーザエージェントは、NSISエンティティに対する必要な処理ステップを通信するために、端末またはネットワーク(プロキシ)においてNSISエンティティに対するインターフェイスを用いる。したがって、セッションに関して必要なメディア適応を決定したときには、SIPユーザエージェントは、必要なメディア適応の記述を含む本願明細書で提案されたNSISメディアフォーマット適応NSLPの照会メッセージをそれ自身に送信することによって、またはプロキシにそれを実行することを示すことによって、リソースの検出および確保を始動させてもよい。
QoS前提条件がセッション記述に存在する場合には、ネットワークQoSリソースの検出および確保の後に、たとえば、メディアフォーマット適応リソースの探索および確保が、始動されてもよい。これは、必要なネットワークQoSリソースが確保することができない場合には、検出および確保を中止するという利点を有する。
あるいは、メディアフォーマット適応およびネットワークQoSは、並列でまたは共に始動(および実行)されてもよい。すなわち、NSLPメッセージま本願明細書に記載されるメディアフォーマット適応NSLPシグナリング情報に加えて、QoS−NSLPシグナリング情報を含む。
ネットワークにおいてメディア適応機能を探索するときに遭遇されることができる複数の場合がある。望ましい場合において、必要とされるすべての適応リソースは、端末110から端末122への(および端末122から端末110への)メディアパスで見つけられる。しかし、それは、一部がメディア適応リソースを必要とする場合であってもよく、またはそれらのすべてが、端末110から端末122への(および端末122から端末110への)メディアデータパスで検出されない場合であってもよい。
一部のリソースが欠けている場合には、NSISメディアフォーマット適応NSLPアプリケーションは、メディア適応リソースの探索を「オフパス」、すなわち、端末110から端末122へのメディアデータパスでNSISルータに(たとえば、ホップ、待ち時間などに関して)「近い」NSISルータで可能であってもよい。本発明の他の実施形態によって提案されたこの強化はまた、利用可能なメディア適応機能を交換可能にするNSISルータに関する情報交換方式を含み、NSISルータが「付近の」NSISルータのメディア適応機能も認識するようになっていてもよい。たとえば、XMLが、機能記述を定義するために用いられてもよい。この情報交換方式を提供することによって、利用可能なメディアフォーマット適応リソースの検出における待ち時間が、削減されてもよい。
一旦、すべてのメディア適応(およびネットワークQoS)リソースが、端末110によって見つけられて確保されると、既に説明したように、端末110は、SIPプロトコルの更新メッセージを端末122に送信する。端末122は、セッションに関するすべての前提条件がその端部でも満たされたことを示す更新メッセージに関する200(OK)応答を返してもよい。時間におけるこの時点で、端末122は、ユーザへの警告を開始し、SIPプロトコル仕様に基づき、セッション確立が終了する。
メディアフォーマット適応NSLPのためのメッセージ
以下において、ネットワークにおいてメディア適応リソースの検出および確保のために、交換されるNSLPメッセージの例示の定義を示す。メッセージは、詳細に記載されておらず、その機能性のみを記載している。
照会メッセージ
照会メッセージは、必要なメディア適応リソースに関してネットワークを「精査する」ために、端末(またはそれらのプロキシ)によって用いられ、必要なメディアフォーマット適応の記述を含む。
確保メッセージ
確保メッセージは、NSISルータまたはその関連プロセッサで、状態を修正する。確保メッセージは、NSISルータでメディア適応リソース確保の現在の設定を保存し、任意に変更するために用いられてもよい。
応答メッセージ
応答メッセージは、照会(照会メッセージ)またはリソース確保要求(確保メッセージ)の結果に関する情報を提供するために用いられてもよい。
通知メッセージ
通知メッセージは、情報をNSIS−ルータに搬送するために用いられてもよい。通知メッセージは、非同期で送信され、具体的な状態または前に受信されたメッセージに関連付ける必要がないと言う点で、応答メッセージとは異なる。通知メッセージによって搬送された情報は、通常、エラー状態に関連付けられる。例は、分解される状態について、または確保の実行権が取り上げられたときを示すための上流ピアへの通知である。
加入メッセージ
このメッセージは、メディア適応リソースの「オフパス」検出および確保が実現される場合に、任意に定義されてもよい。このメッセージは、隣接するピアNSISルータで利用可能なメディア機能に関する通知を受信するために、ピアNSISルータに加入するために用いられる。
MediaSpec
以下の節は、上記のNSISメディアフォーマット適応NSLPメッセージの個別のフォーマットを定義する。本願明細書において定義されるNSISメディアフォーマット適応NSLPのフォーマット定義はまた、以下では、MediaSpecとも呼ばれる。
本願明細書において定義される例示のメッセージのMediaSpec内容フィールドにおけるデータのフォーマットは、以下のMediaSpecテンプレートに基づいている。
+----------------------+-----------------+-----------------+
| MediaSpec/Ctrl.Inf. | Mandatory |Optional |
| Object ID |MediaSpec Params.|MediaSpec Params.|
+----------------------+-----------------+-----------------+
たとえば、確保メッセージは、以下のようであってもよい。
RESERVE = COMMON_HEADER
RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
[ POLICY_DATA ] [QSPEC][ MediaSpec ]
確保メッセージの代替定義は、以下のフォーマットおよび内容を有する。
RESERVE = COMMON_HEADER
RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
[ POLICY_DATA ] [ *QSPEC including the MediaSPEC data]
これらのメッセージは、NSISトランスポート層プロトコルNTLPを用いて、NSISルータ間で移送される。NTLPプロトコルに関する現在の定義は、上述したIETFインターネットドラフト「GIMPS:General Internet Messaging Protocol for Signaling」に定義されている。
制御情報オブジェクト
制御情報オブジェクトは、オブジェクトID(Object ID)(たとえば、Object ID=0)によって定義され、この実施形態によれば、各NSLPメッセージに関して必須である。このオブジェクトは、制御情報を搬送するために用いられる。
メディア適応所望オブジェクト
第1のオブジェクトは、メディア適応所望オブジェクトであり、たとえば、Object ID=1を有してもよい。このオブジェクトは、必要なメディア適応処理の記述に関する少なくとも1つのパラメータを含む。簡単にするため、唯一の適応が必要とされると仮定される。しかし、たとえば、ストリームが最初にトランスコードされ、次に暗号化されなければならない場合には、複数のメディア適応ステップが必要とされる場合がある。必要なメディア適応処理の記述が、上述したように得られてもよい(「必要なメディア適応処理の記述」の節参照)。
このメディア適応処理の1つのきわめて重要な特徴は、シグナリングパケットがデータパケットと同一のルートに従うものとすることである。これは、メッセージ経路指定情報(MRI、IETFインターネットドラフト「GIMPS:General Internet Messaging Protocol for Signaling」、5.8.1.1節参照)を見つけ出すことによって保証される。これは、パケットの経路指定を決定するプロトコルヘッダの設定を定義し、シグナリングが実際に「オンパス」であるように、シグナリングおよびデータパケットで等しいものとする。したがって、データパケットは、MRIフィールドのいずれにおいても一切変更を受けることはできない。
MRI = { network-layer-version, source-address, prefix-length, destination-address, prefix-length, IP-protocol, diffserv-codepoint, [ flow-label ], [ ipsec-SPI / Layer 4-ports]}
上記の定義において、括弧はパラメータの任意の存在を示す。
MRI情報は、パケットの経路指定を決定するものであるため、したがって、メディア適応処理記述は、データパケットのnetwork−layer−version、source−address、prefix−length、destination−address、prefix−length、IP−protocol、diffserv−codepoint or port numbers、flow labelsまたはIPSec SPIの値における詳細を修正してはならない。
メディア適応所望オブジェクトおよび必要なメディア適応処理の記述は、照会メッセージまたは確保メッセージに含まれてもよい。たとえば、ストリーミングの場合には、タイプ(ビデオ)およびサブタイプ名(たとえばH261ビデオトランスコーダの場合には“H261txcoder”)の仕様およびサポートされるために必要なパラメータは、十分である。さらに、照会メッセージは、さらに一般的であってもよく、ビデオトランスコーティング機能性について尋ねるだけであってもよく、オーバレイノードがメディア適応利用可能オブジェクトにおいて利用可能なすべての利用可能なトランスコーダを列挙するものとする。
メディア適応所望オブジェクトが確保メッセージに含まれる場合には、確保メッセージが定められる特有のメディア適応構造およびNSISルータにおけるリソースを要求する。複数の処理ステップが、メディア適応のために必要とされる場合には、複数のメディア適応所望オブジェクトが、有意の順でカスケード化されてもよい。同一のIDを有する定義を処理することは、別法を表す。
メディア適応利用可能オブジェクト
第2のオブジェクトは、メディア適応利用可能オブジェクトであり、Object ID=2によって識別されることが可能である。このオブジェクトが配置されるメッセージに応じて、このオブジェクトは、配置され、中間NSISルータによる修正を受けてもよく、受けなくてもよい。オブジェクトが応答メッセージに含まれる場合には、オブジェクトによって搬送される情報は修正されない。オブジェクトが照会メッセージに含まれる場合には、各NSISルータがメディア適応利用可能オブジェクトにおいて利用可能なリソースをオブジェクトに追加してもよい。たとえば、追加された情報は、SDPngが用いられる場合には、<cap>タグおよび<cfg>タグに含まれてもよい。代替のメディア適応構成、範囲およびパラメータのリストは、オブジェクトに含まれることができる。SDPngの実施例に戻ると、有意の別法は、たとえば、SDPngにおける<cfg>タグおよび<alt>タグを用いて表現されてもよい。
メディア適応確保済みオブジェクト
第3のオブジェクトは、メディア適応確保済みオブジェクトであり、Object ID=3によって識別されてもよい。このオブジェクトは、メディア適応所望オブジェクトと類似のフォーマットを有し、確保メッセージに対する応答において送信される応答メッセージにおいて実現される。その機能性は、メディアセッションに関して確保されたそれぞれのNSISルータにおけるリソースのメディア適応記述(パラメータID=4)を含むことによって、確保されたリソースを確認することである。
MediaSpecオブジェクトおよびパラメータ記述
以下の節は、本発明の異なる実施形態によるMediaSpec記述フィールドに含まれる異なるオブジェクトのさらに詳細な定義を提供する。
制御情報オブジェクト
MediaSpec制御情報オブジェクトは、オブジェクトID(Object ID)(たとえば、Object ID=0)によって識別され、この実施形態によれば、各NSLPメッセージに関して必須である。
本発明の実施形態によれば、制御情報オブジェクトの異なるフォーマットが提供され、それらのパラメータIDに基づいて識別されてもよい。
第1のフォーマットは、<MediaSpec Hops>フォーマット(パラメータID=1)と呼ばれる。この制御情報オブジェクトに含まれるデータは、本願明細書に定義されるNSISメディアフォーマット適応NSLPメッセージを理解するNSISエンティティ、本願明細書の用語によればNSISルータの数を示す。この数は、MediaSpec Hopsフィールドに含まれる。各メディア適応可能NSISルータは、このカウンタを1つずつ増大する。
<MediaSpec Hops>フォーマットは、以下のように定義されてもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=0 | Parameter ID=1| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MediaSpec Hops //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
別のフォーマットは、<Inspect Neighborhood>フォーマット(パラメータID=2)であり、NSISルータが制御情報オブジェクトを含むメッセージをオンパスでない(たとえば、「探索するためのホップ距離」が(“0”)に等しい場合にはいいえであり、他の場合には、はいである)他のNSISルータに転送するべきかどうかを指定する。このパラメータを含む照会メッセージは、“Decreasing count of hops”カウンタが訪れたNSISルータごとに1ずつ減少される点を除き、NSISルータのすべてのインターフェイスで(それを受信する1つを除き)複製可能であってもよく、変更されないまま送信されてもよい。このメッセージは、以下のフォーマットを有する。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=0 | Parameter ID=2| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Hop distance to explore //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Decreasing count of hops //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
さらに具体的に言えば、<Length>フィールドは、上記の両方の例において、このフィールドの後に、ペイロードのバイトで、パラメータの長さを示す。<Hop Distance to explore>フィールドは、メッセージを受信するホップまたはNSISエンティティの数を示し、別のメディア適応機能を検査するものとする。この数は、減少されない。
さらに、ホップの数を制限するために、メッセージは、「オフパス」で伝搬され、減少される<Decreasing count of hops>フィールドが含まれる。2つのカウンタに関する理由は、制御情報オブジェクトを含むメッセージを受信するNSISルータの転送挙動の制御である。両方のカウンタ値が同一である(0とは異なる)場合には、NSISルータは、2つのインターフェイス、すなわちメッセージが受信されたインターフェイスと、他の端末に対してオンパスであるインターフェイス以外のすべてにメッセージを転送する。そうでない場合には、NSISルータは、メッセージを受信したインターフェイス以外のNSISルータのすべてのインターフェイスにメッセージを転送する。
メディア適応所望オブジェクト
メディア適応所望オブジェクト(ID=3または4を有するパラメータの少なくとも1つを含む)は、(照会または確保のために)所望のメディア適応機能の記述を含む。各NSISルータは、オブジェクトを検証し、メディア適応利用可能オブジェクトにおいて適合する機能を含む。このオブジェクトに含まれる少なくとも2つのパラメータがある。照会メッセージにおいてメディア適応機能を照会するためのID=3を有するパラメータと確保メッセージにおけるオブジェクトを含む場合に、リソースを確保するためのID=4を有するパラメータである。
フォーマットは、たとえば、以下のようであってもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=1 | Parameter ID=3| Length (bytes) | MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID=3| Length (bytes)| MAID=2 | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+- //
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
このパラメータ(ID=3)を含むメディア適応所望オブジェクトは、オブジェクトを含むメッセージを受信する各NSISルータによって解析され、照会メッセージにおけるメディア適応利用可能オブジェクトの含有を始動してもよく、メディア適応利用可能オブジェクトは、応答メッセージにおいて照会メッセージの開始プログラムに返す。
パラメータID=4を有するメディア適応所望オブジェクトは、以下の例示のフォーマットを有してもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=1 | Parameter ID=4| Length (bytes) | MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Parameter ID=4| Length (bytes)| MAID=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
上述したように、ID=4を有するパラメータを含むメディア適応所望オブジェクトは、Media Adaptation Descriptionフィールドに記載されているように、端末(またはそれらのプロキシ)が要求されたメディア適応リソースを確保することを可能にする。確保が成功した場合には、確保の詳細(すなわち、いずれのリソースが確保されたかに関するメディア適応の正確な記述)を含むID=4を有するパラメータが、以下のメディア適応確保済みオブジェクトの中で、応答メッセージに返される。そうでない場合には、パラメータID=6を含むメディア適応所望オブジェクトが、返され、リソースの確保の失敗の原因を示してもよい。
確保メッセージにおいて、メディア適応所望オブジェクトに含まれるID=4を有するパラメータは、「ポップオフ」される、すなわち、一旦、確保が成功すると、オブジェクトから除去される。メディア適応に関して順が重要であるため、ID=4を有するパラメータは、確保メッセージにおいてメディア適応所望オブジェクトの中で順序付けがなされる。
上記で定義したフィールドの意味は、以下の通りである。<MAID>フィールドは、メディア適応IDを示す。MAIDは、いずれのメディア適応記述が言及されるかを識別する。照会メッセージに対する応答のために、照会に適合し、自発的にリソースを許可する2つ以上のメディア適応リソースがあってもよい。すなわち、メディア適応利用可能オブジェクトにおいて、同じMAIDを有し、ID=5を有する複数のパラメータが存在してもよい。しかし、確保メッセージにおいて、MAID値ごとにID=4を有するパラメータは1つのみであってもよい。
<Network ID>フィールドは、メディア適応リソースがアドレス指定可能であるノードを識別する全体にわたって一意のネットワークIDを含む。これは、たとえば、一連のメディア適応リソースの集合のホストであるノード(たとえば、NSISルータ)に対する識別子であってもよい。含まれるネットワークIDは、必ずしもリソース自体のIDでなければならないわけではなく、それを管理するNSISルータのネットワークIDであってもよい。たとえば、IPv6アドレスまたは他の種類のグローバル識別子、http://www.ietf.orgで利用可能なIETFインターネットドラフト「Host Identity Protocol Architecture」(draft−ietf−hip−arch−03.txt)に基づくHITタグなどが、ネットワークIDとして用いられてもよい。いくつかの場合には、たとえば、現在開発中のVPN(仮想プライベートネットワーク)技術などのIP−in−IPトンネルを介して仮想化の場合には、このIDはグローバルな一意性を必ずしも有していなくてもよい。これらの場合には、ネットワークID(たとえば、IPアドレス)はトンネリングを介して形成された「仮想ネットワーク」内で一意であれば十分である。リソースがオンパスで見つけられず、他の手段、IPトンネルまたは他の手段などの可能なオフパス通信を介して達しなければならない場合には、ネットワークIDもまた、有用であってもよい。
<Media Adaptation Resource ID>フィールドは、アプリケーションIDを含む。アプリケーションIDは、たとえばトランスコーダ、フロースプリッタなどのネットワークIDによって識別されるノードにおけるメディア適応リソースを識別する。メディア適応リソースIDは、たとえば、SIP URIであってもよい。
さらに、<Media Adaptation Resource Session ID>フィールドは、現在のメディア適応パスにおけるリソースによって用いられるすべてのセッション識別子の中で一意のセッション識別子を含む。この識別子は、メディア適応ノード(NSISルータ)が提示するリソース、たとえば、一定の入力/出力パラメータを有するトランスコーディングアプリケーションの特定のセッションをアドレス指定するために用いられる。要求時に、メディア適応リソースは、この識別子を発行し、この識別子は、セッションの構造が変更または調整されなければならない場合には常に用いられる。これは、複数のメディアデータパスが同一のメディア適応リソースを同時に用いることを可能にする。Media Adaptation Resource Session IDは、メディア適応リソースがサービス中であるすべてのセッションの中で一意であってもよい。Media Adaptation Resource Session IDフィールドは、その利用可能なメディア適応機能が照会の機能に適合し、セッションに自発的に割り当てられる訪れたNSISルータにおいて、メディア適応リソースによって発行される。
<Media Adaptation E2E Session Footprint>フィールドは、任意に含まれてもよく、パケットを実際に処理するエンドポイントノードを貸すためにメディア適応リソースによって挿入される識別子を含む。たとえば、この“footprint”は、識別されるContributing Synchronizing Sourceまたはhttp://www.ietf.orgで利用可能なCSRC of the Real−time Transport Protocol、RFC3550であってもよい。
RTCPパケットは、この場合には確保されるメディア適応リソースである寄与ソースを含む各同期ソースから受信されるパケットの数を記録するため、この情報は、経路指定またはメディア適応ノードの失敗を検出するために有用である。確保される異なるメディア適応リソースによって用いられるフットプリントは、いずれのノードが受信されるデータを処理するかをエンドポイントに明示的に通知するために、エンドポイントに通信されてもよい。このフットプリントの通信は、前提条件フレームワークに対する提案された拡張、“a=intermediate:”を用いて、SIPにおいて更新メッセージを介して行われる。
<Media Adaptation Description>フィールドは、探索される機能性の記述を含む。
説明の目的のために、トランスコーディング処理のために所望の必要な構成は、以下のようにSDPngにおいて表現されることができる。
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/\
sdpng sdpng-base.xsd
http://www.iana.org/sdpng/rtp/sdpng-rtp-pkg.xsd
http://www.iana.org/sdpng/video/sdpng-rtp-video-\
txcodec-pkg.xsd"

owner="txcoding-service@example.com" id="98765432" \
version="1">
<cap>
<rtp:udp name="rtpudpip6">[...]</rtp:udp>
</cap>
<def>
<rtp:udp name="rtp-def" ref="rtp:rtpudpip6">
<rtp:pt-in>31</rtp:pt-in>
<rtp:pt-out>32</rtp:pt-out>
</rtp:udp>
</def>
<cfg>
<video:txcodec name="h263plus-mpg-txcodec">
<video:input-encoding>H.263+</video:encoding>
<video:input-resolution>QCIF</video:resolution>
<video:input-framerate max="30"/>
<video:ouput-encoding>MPEG-4</video:output-format>
<video:output-resolution>QCIF</video:resolution>
<video:output-framerate max="30"/>
</video:txcodec>
</cfg>
<constraints>
[...where applicable...]
</constraints>
</sdpng>
複数のリソースの確保が必要である場合には、メディア適応は順番が必要である場合があるため、オブジェクトは、確保順にID=4を有する複数のパラメータを含む。たとえば、最初に、ビデオおよびオーディオを分離することなく、ビデオをトランスコードすることを可能ではないと思われる。
メディア適応リソースが、1つの端末から別の端末へのメディアデータパス上にない場合には、「デフォルトのメディアデータパス」からのずれが必要とされることを暗示する所望のメディアフォーマット適応に関して必要なリソースを管理する「オフパス」のNSISルータに対するトンネルを確立するために、Network IDが用いられる。NSISルータが、要求されたメディア適応リソースがそれ(Network IDアドレスは、自身のアドレスとは異なる)によってホストとならないことを検出する場合には、示されたNSISルータに対するトンネルを確立されてもよく、Media Adaptation Resource IDおよびMedia Adaptation Session IDを用いて、メディア適応処理を要求してもよい。
メディア適応利用可能オブジェクト
上記で示したように、このオブジェクトは、照会メッセージおよび確保メッセージに対する応答に含まれてもよい。このオブジェクトは、照会メッセージに含まれ、また開始プログラムに返される応答メッセージにも含まれる。メディア適応利用可能オブジェクトは、以下の構造を有してもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=2 | Parameter ID=5 | Length (bytes)| MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nr hops | Nr hops | |
| to source | away from path| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Cost //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Parameter ID=5 | Length (bytes)|MAID=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nr hops | Nr hops | |
| to source | away from path| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Cost //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
上記で分かるように、オブジェクトは、特定のNSISルータまたは一連のルータで確保のために利用可能である1つまたは複数の利用可能なメディア適応アプリケーションセッション、たとえばID=5を有する複数のパラメータを含む。これらのリソースの利用可能性は、一過性の状態を有する。リソースが所与の時間後に確保されない場合には、割り当てられたリソースおよび特別に作成された識別子であるMedia Session IDおよびE2E Session Footprintが期限切れとなる。これは、不必要な確保を回避することである。
このような態様で、<Media Adaptation ID>は、メディア適応所望オブジェクトにおいて適合するパラメータ(ID=4)を識別するために必要とされ、メディア適応利用可能オブジェクトにおけるこの(これらの)パラメータ(ID=5)が応答する。同一のMedia Adaptation IDを有するそのようなパラメータは、代替である。
以下のフィールドは、訪れたノード、すなわちそれらの機能が照会の機能と適合し、自発的にリソースに割り当てられるとき、オブジェクトを含むメッセージが通過するそれらのNSISルータによって満たされている。<Nr hops to source Count>フィールドは、メッセージが開始NSISエンティティ(たとえば、端末110または122またはそれぞれにそれらのプロキシ)から転送されるホップの数を指定する。<No Hops away from path>フィールドは、リソースがデフォルトのメディアデータパスで見つからない場合に用いられ、メディア適応リソースがデフォルトのメディアパスから離れるホップの数を記述する。
<Media Adaptation Resource Cost>フィールドは、このノードでこの処理を確保するコストを示す。コストは、任意の種類のコスト距離であってもよい。別のパラメータが定義されてもよく、それぞれが異なるコストモデルを含む。
<Network ID>フィールド、<Media Adaptation Resource ID>フィールド、<Media Adaptation Resource Session ID>フィールドおよび<Media Adaptation E2E Session Footprint>フィールドは、上述したように、類似の機能性を有する。
<Media Adaptation Description>フィールドは、見つかったメディア適応リソースで利用可能な機能性の記述を含む。以下は、上記のSDPngの例を再使用する。
<sdpng xmlns="http://www.iana.org/sdpng"
xmlns:audio="http://www.iana.org/sdpng/audio"
xmlns:rtp="http://www.iana.org/sdpng/rtp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.iana.org/\
sdpng sdpng-base.xsd
http://www.iana.org/sdpng/rtp/sdpng-rtp-pkg.xsd
http://www.iana.org/sdpng/video/sdpng-rtp-video-\
txcodec-pkg.xsd"

owner="txcoding-service@example.com" id="98765432" \
version="1">
<cap>
<rtp:udp name="rtpudpip6">
<rtp:pt-in>31 34</rtp:pt-in>
<rtp:pt-out>32 35</rtp:pt-out>
</rtp:udp>
</cap>
<cfg>
<video:txcodec name="h263plus-mpg-txcodec">
<video:input-encoding>H.263+</video:encoding>
<video:input-resolution>QCIF</video:resolution>
<video:input-framerate max="30"/>
<video:ouput-encoding>MPEG-4</video:output-format>
<video:output-resolution>QCIF</video:resolution>
<video:output-framerate max="30"/>
</video:txcodec>
</cfg>
<constraints>
[...where applicable...]
</constraints>
</sdpng>
上記の記述は、この記述を作成したメディア適応リソースが、H263、同一の解像度およびフレーム速度でMPEG−4ビデオに対して最大毎秒30フレームのQCIF解像度に基づくトランスコーディングをサポートすることを示す。また、コーデックのコーデック特有のパラメータを理解するために、別のパッケージが必要とされることを留意されたい。これは、http://www.iana.org/sdpng/video/sdpng−rtp−video−txcodec−pkg.xsdから検索されることができる。
類似の態様において、SDPng規則に基づいて、他のトランスコーディングパラメータが表現されてもよい。記述のみが機能および1つの構成について言及することを留意されたい。また、いくつかの代替構成と、適用可能であれば制約条件とがあってもよい。しかし、これは、単なるメディア適応利用可能オブジェクトであるため、定義はなく、確保が行われないため、構成タグ(または要素)もない。SDPngが<cfg>タグおよび<alt>タグの下での代替構成を列挙する可能性があることもまた、留意されたい。また、範囲およびパラメータリストも可能であることを留意されたい(RTPペイロードタイプの範囲は、rtp:ptで明示的に列挙されてもよい)。
メディア適応確保済みオブジェクト
このオブジェクトは、確保されたリソースを確認する。通常の動作において、そのパラメータは、確保メッセージにおいて送信されたパラメータID=4を有するメディア適応所望オブジェクトと同一の情報を含む。しかし、ローカルポリシーのために、NSISルータまたはそのリソースは、リソースが利用可能であるポートなど、セッションの詳細を変更することが可能であってもよい。
メディア適応確保済みオブジェクトは、メディア適応確保が失敗したことを示すために、新たなパラメータであるパラメータID=6を必要とする。これは、エラーコードを用いて確保の失敗および十分な確保のための提案について知らせる。以下の実施例は、第1の確保が成功し、第2の確保が成功しなかったことを示す確保メッセージを発行した端末(またはそのプロキシ)を知らせるパケット構造を示す。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=3 | Parameter ID=4| Length (bytes) | MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Parameter ID=6| Length (bytes)| MAID=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Session ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation E2E Session Footprint //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Failed Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Error Code (reason of failure //
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Proposed New Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NSISルータにおけるメッセージ処理
任意に、上記で提案されたNSISメディアフォーマット適応NSLPのシグナリングメッセージは、認証手順が成功して達成された(通常、POLICY_DATAオブジェクトがメッセージにおいて実行される)後、NSISルータで処理されるだけであってもよい。
照会メッセージの処理
メディア適応所望オブジェクトを含む照会メッセージが、照会が通過した各NSISルータによって解析される。要求される各メディア適応処理およびその関連パラメータが、解析される。ID=1を有するパラメータのメディア適応記述に含まれる要求処理が利用可能である場合には、メディア適応利用可能オブジェクトは、それぞれのNSISルータによって照会メッセージに含まれる。この照会メッセージは、メディア適応処理の機能、定義、構成および情報を反映するパラメータ(ID=5)を含む。メディア適応利用可能オブジェクトおよびメディア適応所望オブジェクトに含まれるパラメータは、MAIDによってリンクされる。同じMAIDを含む複数のパラメータは、等価な機能または類似の機能を提供する異なる代替のNSISルータを表す。
確保の照会端末は、一方または他方の利用可能な処理を選んでもよい。利用可能な代替がある場合には、いずれのメディア適応リソースを利用するかに関する端末の決定は、たとえば、利用可能なリソースのそれぞれの1つへのホップの数、それぞれのリソースを利用するために必要なコスト(たとえば、待ち時間)または他の測定基準に左右されてもよい。トランスコーダ(および一般に任意の適応)は、RTPペイロードタイプなどのパケットペイロードにおけるいくつかの属性を変更する可能性があるため、利用可能なメディア適応リソースに関する詳細の情報が必要である場合もある。たとえば、フォーマットXからYへの変化のために必要な2つの適応処理ステップ(X→Y’→Y”→Y)がある場合には、確保が各メディアストリーム(“m=”の行)における“a=”の行に関する正確な入力および出力ペイロードタイプ数を含むように、Y’およびY”は、記述において利用可能なペイロードタイプの範囲を含む必要がある。処理機能の正確な仕様は、確保状態をメディアストリームに関連付けることができるように拡張するために重要である。処理機能の正確な仕様はさらに、確保メッセージ要求の送信者側の場合には、後に与えられたリソースの確保を可能にしてもよい。
リソースが要求中の端末によって確保されることができないか、または要求されたメディア適応処理がサポートされない場合には、メッセージは、NTLP経路指定によって決定されるように、変更することなく、次のオンパスNSISルータに転送される。
確保メッセージの処理
確保メッセージは、照会メッセージとして処理される。照会メッセージとは対照的に、確保メッセージは実際に、各MAIDに関するメディア適応リソースを確保する。さらに、確保メッセージにおいて、ID=4を有するパラメータにおけるメディア適応記述は、任意の値範囲を含むではなく、リソース確保に関する一定値のみが明示される必要がある。各NSISルータで、1入力および1出力のパラメータが、各メディア適応処理に関してインスタンスを作成されなければならない。確保メッセージは、一連の順番で並べられたメディア適応ステップを含むため、確保メッセージにおいて、確保されるメディア適応処理を表すパラメータID=4を有するメディア適応所望オブジェクトの各パラメータは、一旦処理されると除去される。
たとえば、フォーマットY’への変換の出力ペイロードタイプおよびフォーマットY” への変換の入力ペイロードタイプが同一の値をとるように、続くNSISルータにおけるメディア適応確保に関するパラメータ設定が適合される。この適合は、次の確保の設定(パラメータID5または6)を搬送する応答メッセージによって確認(または拒否)される。
応答メッセージの処理
応答メッセージは、2つの主な用途を有し、
・照会メッセージへの応答として作用する場合には、開始プログラムに戻す利用可能なメディア適応リソースに関する情報を搬送し、
・確保メッセージへの応答として作用する場合には、次のNSISルータにおける確保の成功を確認する。
メディア適応機能探索
前述したように、オーバレイネットワークにおいてメディア適応機能を探索するための2つの可能性が可能である。
・オンパス探索‐この探索オプションは、所望のメディア適応機能を提供するメディアデータパスにおけるNSISルータを検出するために、NSISシグナリングのためのオンパスオプションを利用する。照会メッセージを受信するメディアデータパスにおける各NSISルータは、メディア適応所望オブジェクトおよびメディア適応利用可能オブジェクトを検査し、それらの利用可能性に基づいて、それらのオブジェクトを修正する。この単純化した手法の欠点は、メディアデータパスにおけるすべてのリソースがピアに遭遇する確率がきわめて低い恐れがあることである。
・オフパス探索(近接探索)‐この探索オプションによれば、各NSISルータは、その機能に関してメディアデータパス上以外にある隣接する「近隣の」NSISルータにも照会する。
オンパス探索
オンパス探索は、既に上述しており、そのメッセージの流れもまた、図5において示されたものと類似である。照会端末は、セッションを確立するために、ピア端末にメディアデータパスに沿って照会メッセージを送信する。オンパス上のNSISルータは、照会を処理し、照会が適合する場合にはメディア適応機能に関する記述に照会を追加する。次に、記述は、照会端末に送り返され、選択されたNSISルータにおける照会リソースおよび確保リソースのメディア適応必要条件を満たすNSISルータを選択する。
近接探索
オフパス探索の場合には、異なる実現が、以下で提案される。
基本動作Modus−Pull動作
基本動作モーダス(modus)において、近接探索のための挙動は、オンパスにあるNSISルータに対して「近隣の」NSISルータの利用可能な機能を照合することである。近隣のNSISエンティティ(NE)またはNSISルータは、NSISメッセージを現在処理中であるNSISルータから1つまたは複数のホップであるNSISエンティティとして定義される。たとえばGIMPSにおけるように標準的なNTLPプロトコルにおいて、各NEは、いわゆる近隣のGIMPSノードから1回のホップで他のNEを認識している。GIMP経路指定状態維持のためのこの機構は、既に上述したIETFインターネットドラフト「GIMPS:General Internet Messaging Protocol for Signaling」において、GIMPSピア発見機構に記載されている。
基本モーダスにおいて、新たに提案されたNSISメディアフォーマット適応NSLPの近接探索のために、動作は、「プル(pull)」モデルに基づいて行う。すなわち、NSISルータ(またはNE)は、要求に応じて、近隣のNSISルータから情報を検索する。
本発明の実施形態によれば、この機構は、以下のように実現されてもよい。
・照会メッセージの局所処理:照会が適合され、NSISルータが自発的にリソースを割り当てられる場合には、訪れた各NSISルータは、メディア適応利用可能オブジェクトに機能記述(ID=5を有するパラメータ)を含む。
・各オンパスNSISルータは、制御情報オブジェクトにおけるパラメータ“Hop distance to explore”が0でないことを示す照会メッセージを受信したときには、メッセージをメディアデータパスにはない(オフパスの)近隣NSISルータに転送する。
・さらに、照会メッセージが通過される各オフパスNSISルータは、メッセージの転送時に“Decreasing count of hops”を1つずつ減少させる。
・照会メッセージを受信する各オフパスNSISルータは、照会を照会メッセージが受信されたインターフェイスを除くそのインターフェイスに転送する。
・オフパスNSISルータに照会した各NSISルータは、オンパスNSISルータにさらに照会メッセージを転送する前に、各照会メッセージに関して利用可能なメディア適応機能を含む応答メッセージが到着するまで待機する。
オフパスで次の近隣のNSISルータからの応答メッセージの到着時には、オフパスNSISルータは、1つの応答メッセージにおけるメディア適応利用可能オブジェクトのすべてのパラメータをコンパイルする。
・このコンパイルされた応答メッセージを受信する各オンパスNSISルータは、メディア適応利用可能オブジェクトを抽出し、そのオブジェクトを照会メッセージに含み、「更新された」照会メッセージをメディアデータオンパスに位置する次のNSISルータに向かって転送する。
・最終的には、所与の“hop distance to explore”のオンパスルータおよびオフパスルータの利用可能なすべての機能に関する応答メッセージは、探索の開始プログラムに到着する。
この基本アルゴリズムループにおいて、照会メッセージの伝搬パスにおけるループが回避されるのではなく、カウンタが0の値に達するか、または他のNSISルータが配されないとき、応答メッセージが始動され、それによって、照会メッセージの伝搬を終了することからループは有害ではないと思われることを留意されたい。
本発明の説明のための実施形態によれば、照会メッセージを転送し、それに対する応答メッセージを受信するこの動作は、セッションが、端末110と122との間で確立されると仮定する図10〜図12において示される。パケット交換型ネットワークにおけるメディア適応リソースの検出は、端末110から端末122へのメディアパスに関して示される。図10において、端末110のSIPユーザエージェントは、プロキシ108とインターフェイスをとり、それぞれのネットワークノードを接続する太線によって示される端末110から端末122へのデフォルトのメディアパスから3回以上のホップを行う(Hop distance to exploreフィールドは、値2に設定)メディア適応リソースに関する近接探索をプロキシ108に開始させる。
プロキシ/NSISルータ108は、オンパスで唯一の隣接するNSISルータ105を有し、照会が適合され、NSISルータがリソースに自発的に割り当たられる場合には、プロキシ/NSISルータ108は、そのメディア適応機能の記述を照会メッセージに追加し(たとえば、メディア適応利用可能オブジェクトを追加する)、「更新された」照会メッセージをNSISルータ105に転送する。NSISルータ105はまた、オフパスの近隣ルータに隣接していないため、そのメディア適応機能の記述を照会メッセージに追加し、照会メッセージを次のオンパスNSISルータ104に転送する。
NSISルータ104は、2つの近隣オフルータ、すなわちNSISルータ106および102を有する。照会メッセージを次のオンパスNISルータ103にさらに送る前に、NSISルータ104はそのオフパス近隣NSISルータ106および102に照会し、照会に対するそれらの応答メッセージを待ち受ける。NSISルータ102は、(Hop distance to exploreフィールドにおいて)ホップカウンタを照合し、2から1に値を減算する。カウンタ値が0でないとき、NSISルータ102は、照会メッセージをNSISルータ103だけであるその近隣のNSISルータに転送する。NSISルータ103は、減算後、ホップカウンタが0に等しいことを検出すると、照会メッセージは、さらに伝搬される必要がなくなる。NSISルータ102は、NSISルータ103からの応答メッセージを待ちうけ、その応答メッセージを評価し、NSISルータ104への応答メッセージを形成するためにその中に情報を集める。
NSISルータ104は、NSISルータ102および106から受信された応答メッセージを評価する。NSISルータ103がそのメディア適応機能の記述を追加した場合には、NSISルータ104は、NSISルータ102から受信された応答メッセージにおける情報およびNSISルータ103が次のオンパスNSIS使用可能ノードであるという知識のために、オーバレイネットワークにおけるループを検出してもよい。さらに、NSISルータ104は、受信された応答メッセージにおいてメディア適応機能を解析し、したがって、そのメディア適応機能もまた考慮する照会メッセージを更新する。続いて、更新された照会メッセージをメディアデータパス(図示せず)における次のNSISルータ103に転送する。
今度は図11に目を向けると、動作は、NSISルータ104の1つに本質的に類似しているため、NSISルータ103の動作が簡単に説明される。また、NSISルータ103は、近接探索が行われることを検出し、したがって、照会メッセージを最初にNSISルータ101および102に転送する。NSISルータ101および102は、ホップカウンタを2から1に減算し、照会メッセージに対する応答メッセージを作成する前に、更新された照会メッセージをNSISルータ104および107にさらに転送する。NSISルータ104および107にはいずれも応答メッセージを返す。それぞれ、NSISルータ101および102におけるこれらの応答メッセージの受信時に、これらのNSISルータ101および102は、NSISルータ103に返される応答メッセージに対して、その中の情報と、自身のそれぞれのメディア適応機能の知識と、を集める。NSISルータ103はまた、NSISルータ101および102からの応答メッセージを評価し、続いて(この実施例では)NSISメディアフォーマット適応NSLP使用可能な端末122に送信される更新された照会メッセージに情報を集める。図12に示されているように、端末122は、照会メッセージにおいて検出され、示されたメディア適応機能に関する情報を抽出し、ホップバイホップ方式で応答メッセージにおいて端末110に返される情報を提供する。
基本動作‐オフパスメディア適応リソースの利用
既に上述したように、たとえば、メディアデータパスで利用可能に位置していない要求されるメディア適応リソースのために、デフォルトのメディアデータパスからのずれが必要である場合において、Network IDがそれらのリソースを管理するそれらのNSISルータへのトンネルを確立するために用いられてもよい。
それ(たとえば、Network IDはそれ自体のIDとは異なること)によって、確保されるメディア適応リソースがホストになっていないことをNSISルータが検出すると、NSISルータは、そのNSISルータへオフパスにおけるトンネルを確立し、Media Adaptation Resource IDおよびMedia Adaptation Session IDを用いて、その処理を要求してもよい。たとえば、いくつかのメディア適応リソースが、最も近いオンパスNSISルータから遠くに配置されている場合には、デフォルトのメディアデータパスから離れたNSISルータのメディア適応リソースをどのように利用するかについて、一般に2つのオプションがある。メディアデータパスがメディア適応リソースが利用される必要がある元来はオフパスのNSISルータも組み込むように変更されるか、または、オフパスNSISルータの機能を利用するために、少なくとも1つのトンネルがデフォルトのメディアデータパスにおける1つまたは複数のNSISルータから確立されることができるかのいずれかである。後者のオプションを用いると、デフォルトのメディアデータパスは、変更されなくても済む。
図13に目を向けると、NSISルータ102におけるメディア適応リソースの例示の確保が、示される。上記の図10〜図12に対して説明したように、端末110は、オンパスおよびオフパスで用いられることができるメディア適応リソースを記述する応答メッセージを受信した。NSISルータ102のみが、端末122とのセッションに必要とされるメディア適応を提供することができると仮定すると、端末110は、NSISルータ102にメディア適応リソースを確保しようとする。したがって、端末122は、NSISルータ102への確保メッセージの送信を開始する。確保メッセージが中間NSISルータ103で処理されると、中間NSISルータ103は、確保メッセージをNSISルータ102に転送し、利用されるメディア適応リソースがデフォルトのメディアパスから離れることを検出する。したがって、この例示の実施形態によれば、NSISルータ103は、それ自体とNSISルータ102との間のトンネルを設定する。セッション中に適応されるメディアデータストリームの受信時に、NSISルータ103は、確立トンネルによる変換のために、ストリームをフィルタリングし、そのメディアデータをNSISルータ102に通過させる。NSISルータ102は、端末122に対してメディアパスに沿って次に転送される変換されたメディアストリームを戻す。
トンネリングを用いて、確保において、オフパスのリソースを含むことができるようにするために、NSISルータはトンネリング機能を実現することが必要であり、経路を記録し、トンネル確保を要求するために、以下で2つの別のパラメータをさらに実現してもよい。
確保を開始する端末(たとえば、端末110または122)は、それ自体と宛先端末との間の経路指定パスの周囲に、“network graph”を構築する。したがって、端末は、それが照会メッセージによってネットワークを既に探った範囲(Hop distance to exploreフィールド)に対するNSISルータによって形成されるオーバレイネットワークのトポロジを認識する。したがって、端末は、ネットワークトポロジにおいて、オンパスおよびオフパスでNSISルータのそれぞれまでの距離の知識(ホップにおいて測定される)もまた有する。
本発明の実施形態によれば、パスの周囲のトポロジを求めるために、NSLPの意味論をさらに強化することが提案される。必要なメディア適応に関する照会のほかに、照会メッセージを受信した(オンパスおよびオフパスの両方における)すべてのNSISルータの少なくともNetwork IDが、照会されたメディア適応機能に適合するかどうかに関係なく、記録される。
したがって、新たなパラメータが、照会メッセージ、たとえば上記で指定したメディア適応所望オブジェクトの中に含まれ、応答メッセージにおいて照会メッセージを受信したそのようなNSISルータのネットワークIDを含めることを始動してもよい。したがって、ネットワークIDを搬送する別のパラメータが、応答メッセージ、たとえば上記で指定したメディア適応利用可能オブジェクトの中で提供されてもよい。
照会メッセージに関して、新たなパラメータ(たとえばID=7を有する)は、例示の以下のフォーマットを有してもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=1 | Parameter ID=7| Length (bytes) | MAID=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0に設定されたMAIDは、照会メッセージを処理中であるNSISルータに対して、メディア適応記述がメッセージに含まれないことを示す。照会メッセージにおいてこのパラメータを受信する各NSISルータは、メディア適応利用可能オブジェクトにおいて以下の例示のパラメータ(たとえば、ID=8を有する)を含む。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=2 | Parameter ID=8 | Length (bytes)| MAID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nr hops | Nr hops | |
| to source | away from path| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Record Route //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
“Record Route”フィールドは、探索方向において、訪れたノードのNetwork IDを含んでもよく、メッセージを処理した最も新しいNSISルータは、そのネットワークIDを、たとえば、リストの最後に追加する。経路の設定および照会メッセージを開始する端末へのホップの数を相関させることによって、端末は、照会されたネットワークノードのネットワークトポロジを構築することができる。任意に、このネットワークトポロジは、必要なメディア変換のほか、最適な全体的QoS性能をも提供するメディア適応リソースを選択するために、端末に用いられてもよい帯域幅または遅延などのQoS測定基準(単なるホップの数ではなく)を用いて、強化されてもよい。
一旦、ネットワークトポロジが周知となると、端末は、所望のメディア適応機能を提供するオフパスNSISルータへの必要なトンネルのためにトンネルエンドポイントをアサートしてもよい。上述したように、トンネリングは、メディア適応パスにおいてオフパスノードを「含む」ために用いられる。
オフパスNSISルータを含むために確立されるトンネルを示すために、新たなパラメータが、確保メッセージに追加される。パラメータは、カスケードおよび順序付き形式で、確立すべきトンネリングおよび必要な適応を記述する。
図13に示される実施例に戻ると、NSISルータ102は、デフォルトのメディアデータパス(太い実線で示される)の外側に配置されるが、必要なメディア適応機能を提供する。NSISルータ102(トンネル宛先/ソースA’)を含めるために、NSISルータ104→NSISルータ102→NSISルータ103という三角形の経路指定が所望であると考えられ、その結果、メディアデータはNSISルータ104の間でパスから離れ、NSISルータ103へのパスに再び組み込まれる。この目的のために、2つのトンネル(NSISルータ104→NSISルータ102とNSISルータ102→NSISルータ103)が、確立される。
したがって、確保メッセージは、必要なメディアフォーマット適応(通常通り、前の照会において収集する)を示すNSISルータ102に関して、メディアフォーマット適応記述(パラメータID=4)と、確立すべきトンネルの記述と、を含む。NSISルータ104、102および103(それぞれ)の中で確立するためのトンネルを記述し、NSISルータ102におけるメディアフォーマット適応記述(パラメータID=4)を含む新たなパラメータ、たとえば、ID=9を有するパラメータが、定義されてもよい。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=3 | Parameter ID=9| Length (bytes) | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID of 1st Tunnel Source = NSIS router 104) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID of 1st Tunnel Destination= NSIS router 102 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
## media format adaptation description (parameter ID=4) for ##
## the necessary Media Adaptation to be reserved at A’ ##
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID=3 | Parameter ID=8| Length (bytes) | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID of 2nd Tunnel Source = NSIS router 102) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID of 2nd Tunnel Destination= NSIS router 103 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
任意に、トンネリングは、NSISルータ103からNSISルータ102に確立され、所望であるようなメディアフォーマットに適切に適合された後で、同様に、NSISルータ102からNSISルータ103に戻るように確立されることができる。これは、第1および第2のトンネルのTunnel DestinationおよびTunnel Sourceを同一であるように、すなわちNSISルータ102に変更することであろう。
任意に、複数のオフパスNSISルータは、確保メッセージのペイロードにおいて、カスケードの形態で含まれることが可能である。
拡張動作‐Push動作
本発明の別の実施形態において提案されたオフパスメディア適応リソースを検出して確保するための別の手法が、この節に記載される。実施形態によれば、オーバレイネットワークにおけるNSISルータは、隣接するNSISルータのほか、2回以上のホップで進むNSISルータのローカルデータベースを維持する。NSISルータにおけるデータベース内容の作成は、NSISルータが他のNSISルータに加入し、加入するNSISルータの機能について知らせるいわゆる「プッシュ(push)」通信モデルに基づいていてもよい。この動作は、RFC1058、ヘドリック(Hedrick)による「Routing Information Protcol」(http://www.ietf.orgにおいて利用可能)に記載されたようなベクトル経路指定アルゴリズムに若干類似しており、このアルゴリズムによれば、各ノードは、その周知の経路を近隣のノードに送信し、全体的な経路指定ベクトル(この場合には、NSISルータおよびそれらの機能の全体マップ)が、ある期間の時間の後、いわゆる収束時間後に獲得される。
本発明のこの実施形態によって提案された機構は、以下のように作用する。本願明細書に記載されるNSISメディアフォーマット適応NSLPをサポートするピアNSISルータの設定を求めた後、各NSISルータは、各NSISルータの機能および現在のリソース状態(たとえば、負荷、利用可能な格納機能など)の定期的な更新を受信するために加入するかどうかを決定する。加入は、加入メッセージをそれぞれのNSISルータに送信することによって、実行されてもよい。加入メッセージは、照会メッセージと本質的に同一の構造を有してもよく、加入メッセージを受信したNSISルータから通知メッセージの形で定期的な応答を始動する。
通知メッセージは、NSISルータによって定期的に送信され、それらの機能および任意に他のパラメータ、現在の負荷特性、利用可能なCPU性能または格納機能などを反映する。通知メッセージは、NSISルータが利用可能なメディア適応リソースに関する情報および任意に、他のNSISルータにおけるQoSリソースを収集し、ローカルデータベースにおいてこの情報を維持することを可能にする。ローカルデータベースにおいて維持される情報のタイプおよび量は、通知周期に著しく左右されてもよい。「リフレッシュ」時間が長い場合には、格納能力または利用可能なCPU性能のように、次の「リフレッシュ」までに期限切れになる迅速に変化する情報を格納するために用いられることはできない。
「収束時間」後に、時間におけるいくつかの時点で、各NSISルータは、そのネットワークにおいて、利用可能なNSISルータおよび利用可能なその機能のリストを有する。メディアフォーマット適応NSLP照会メッセージがメディアデータパスにおけるNSISルータによって受信される場合には、NSISルータは、メディア適応機能を探るために、オフパスで照会を転送する必要はないが、今度は、そのデータベースを考慮することができ、それによって、近隣のNSISルータおよびそれを超えるルータで利用可能なメディア適応リソースを直ちに認識される。
以下は、通知メッセージが含みうる一連の機能および識別子を表す。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Network ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Resource Cost //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Media Adaptation Description //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Media Adaptation Session IDもFootprintも含まれる必要がないことを留意されたい。これは、確保の意図を反映する照会メッセージの受信時にインスタンスを作成されるだけに過ぎないためである。
メディア適応処理の検出および確保とQoSの検出および確保との組み合わせ
上述したものと類似の機構が、必要に応じて、ネットワークQoSリソースの照会(検出)および確保を行うために用いられてもよい。端末110と端末122との間のメディアデータパスで、NSISルータによって提供されることができる利用可能なQoSは、たとえば、その構造が本質的に類似であるQoS所望オブジェクトをメディア適応所望オブジェクトに追加することによって、上記の照会メッセージを拡張して照会されてもよく、満たさなければならないQoS制約条件の記述を含む。照会を処理中のNSISノードはそれぞれ、メディア適応利用可能オブジェクトと本質的に同一の機能を有し、メディアパスに沿った各NSISルータまたは提供されることができる全体的な最小のQoSのいずれかの機能を指定するQoS利用可能オブジェクトを追加してもよく、更新してもよく、照会に追加されるQoS利用可能オブジェクトは、照会中の端末110に戻すように伝搬される。端末110は、NSISルータにおいて適切なQoSおよびメディア適応リソースを選択してもよく、メディアデータパスに沿ってQoSリソースの確保を要求し、選択されたNSISルータでメディア適応処理の確保を要求する。いずれの確保も拡張される確保メッセージに組み合わせられてもよく、確保されるメディア適応リソースの記述に加えて、オンパスNSISルータにおいて確保されるQoS制約条件の正確な仕様を含む。
すべてのメディア適応がメディア適応オブジェクトから取り除かれた後、確保メッセージは、さらに処理する必要がないことから、確保の端末に返送されてもよい。
したがって、端末122から端末110へのパスでメディア適応リソース および/またはQoSリソースを確保するために、前の節で概略を述べたものと同一の手順が用いられてもよい。
一般的な課題および変形
異なる機構およびメッセージの提案された実現の主な利点の1つは、基礎となる経路指定(OSPF、RIP、...)に依存することかもしれない。これは、既存の基盤で必要とされる変更が最小であることを意味している。しかし、この依存のために、プロトコルヘッダは、経路指定に影響を及ぼすNTLPによって検出され、MRI(GIMPSドラフト参照)に反映されるように、ネットワークノードがデータを修正すると、受信器のためにアサートされることが困難となることから、修正されないものであることが望ましいと考えられる。
本発明の他の実施形態によって提案されたこの影響に対する解決策は、RTPミキサおよびトランスレータの原理の再使用、パケットを適合する中間RTPミキサおよびトランスレータによって含まれる同期ソース識別子(SSRC)または寄与SSRC(CSRC)の利用である。このSSRCまたは代替の識別子は、Media Adaptation Session IDにリンクしてもよく、この関係は、たとえば、セッション記述における提案された“a=intermediate:”属性を用いることによって、メディア適応に合意するエンドポイントに知らせてもよい。
本願明細書に記載される機構の別の改良は、メディア適応リソースが用いられるために必要と考えられる順序およびメディアデータパスにおけるそれらの位置に関する。すべてのメディア適応リソースがオンパスにあるが、必要なメディア変換を獲得するために、異なる順序で、何度も訪れなければならないことが起こりうる。いくつかの変換は、メディアデータが適応のために、メディアデータパスを行ったり来たりして通過される(たとえば、端末110→NSISルータ108→NSISルータ05→NSISルータ104→NSISルータ103(適応)→NSISルータ104(適応)→NSISルータ103→端末122)ことを必要とする場合もある。この問題はまた、必要なメディア適応リソースを用い、オフパスにあるメディア適応リソースを含むために用いられる同一のトンネリング機構を用いる正確な順序を保証するトンネルを確立することによって回避されてもよい。
さらに、これまで記載した実施例は、セッション開始および管理プロトコルとしてSIPの使用に大面に基づいていた。たとえば、メディアストリーミングが関連している場合には、類似のシナリオが、RTSPメッセージに関して仮定されることができる。SIPと同様に、RTSPは、HTTPのような構文を用いたプロトコルであり、セッションの詳細およびエンドホストの機能を搬送するために、SDP(または他のセッション記述プロトコル)を用いてもよい。SIPとは異なり、RTSPは、「遠隔制御」マルチメディアプレゼンテーションの機能性を満たす。
これまで記載した実施形態において、中心のエンティティ(確保の開始プログラム)は、本願明細書で指定したMediaSpecメッセージのペイロードにおいて、メディア適応記述の形で必要とされる正確な処理を含む。したがって、必要とされるメディア適応ステップを決定するための論理は、中心に集められる。あるいは、本発明の別の実施形態によれば、分散手法も可能である。この変形において、NSISルータは、必要なメディア適応処理を複数のステップに分解することも可能であり、たとえば、2つのステップにおいてコーデックYへのコーデックXのトランスコーディングは、最初にX’にトランスコードし、次にYにトランスコードする。この分解は、照会要求中に必要とされ、所与のメディア適応記述(所与のIDによって識別される)を照会開始プログラムに戻るように供給される複数の中間記述に分割する新たなパラメータの定義をほのめかしてもよい。中間トランスコーディングのほかに、他の処理は、フローを個別のメディア(オーディオおよびビデオなど)に分割するような挙動を必要とする場合がある。
いくつかの実施形態は、フローの経路指定がセッションの持続に関して変更されないままであると仮定している。しかし、たとえば、ポリシーまたは管理的決定のために、または所定の場所におけるトラフィック技術手順のために、経路指定が変更される場合に当てはまる場合もある。そのような場合には、「バックアップ確保」を可能にするために用いられてもよく、このことは、経路指定が変化する場合の便宜を図るために、より低い利用可能率の別のリソースの確保を意味する。E2E Session Footprintsを解析することによって、経路の変更前または変更後に、NSISルータまたはエンドポイントで、経路の変更を検出してもよい。
さらに、本発明は、マルチキャストメディアセッションにおいて用いられてもよいことを留意されたい。たとえば、NSISルータ103は、移動体通信システムを介してそれに付属させる移動体端末116〜123に関するプロキシであってもよい。マルチキャストサービスを確立するために、プロキシ103は、移動体通信ネットワークにおいて関与している移動体端末のために、セッションの設定および制御を処理してもよい。プロキシ103は、たとえば、サポートされるメディアフォーマットに関して、移動体端末のメディア機能を認識していてもよく、または認識させられてもよい。したがって、マルチキャストセッションが確立される場合には、プロキシ103は、セッション記述において指定されたメディアフォーマットのサポートの欠如を認識しているか、または認識させられてもよい。プロキシ103は、セッション記述において提示されたメディアフォーマットをサポートしない移動体端末のグループを形成してもよく、本願明細書に述べるように、ネットワークグループ方式で、メディア適応リソースを検出および確保してもよい。
本発明の別の実施形態は、ハードウェアおよびソフトウェアを用いた上述の実施形態の実現に関する。上記の本発明の実施形態は、計算デバイス(プロセッサ)、たとえば、汎用プロセッサ、ディジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイスなどを用いて、実現または実行されてもよいことは認識されたい。本発明の種々の実施形態はまた、これらのデバイスの組み合わせによって実行または具体化されてもよい。
さらに、本発明の実施形態はまた、プロセッサによって実行されるソフトウェアモジュールによって、またはハードウェアにおいて直接実現されてもよい。ソフトウェアモジュールまたはハードウェア実装の組み合わせもまた、可能であってもよい。ソフトウェアモジュールは、任意の種類のコンピュータ可読格納メディア、たとえば、RAM、EPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD−ROM、DVDなどに格納されてもよい。
前述に記載したように異なる実施形態および変形は、説明のための実施例として表されているに過ぎないことを認識すべきである。特定の実施形態において示されているように、広範囲に記載されているような本発明の精神または範囲を逸脱することなく、種々の変形および/または修正は、本発明に対して行われることができると当業者には認識されよう。したがって、本実施形態は、すべての点において説明のためであり、限定するわけではないと考えるべきである。
パケット交換型ネットワークの概略図を示し、この概略図に基づいて、本発明の例示の実施形態が説明される。 NSIS操作可能ルータおよびNSISプロキシを含む図1のパケット交換型ネットワークに対するオーバレイネットワークを示す。 図1のパケット交換型ネットワークにおいて、エンドツーエンドメディアセッションを提供するために用いられることができる例示のプロトコルスタックを示す。 本発明の実施形態による2つの端末間のメディアセッションの例示の確立を示す。 メディアセッションの確立を可能にするために、所望のメディアフォーマット変換において、関与しうるNSISルータを識別するために適切な本発明の実施形態によるオンパスNSISルータ検出機構を示す。 本発明の例示の実施形態による2つの端末間で、図2のオーバレイネットワークを介した図5のオンパスNSISルータ検出機構のメッセージの交換を示す。 本発明の例示の実施形態による2つの端末間で、図2のオーバレイネットワークを介した図5のオンパスNSISルータ検出機構のメッセージの交換を示す。 本発明の例示の実施形態による2つの端末間で、図2のオーバレイネットワークを介した図5のオンパスNSISルータ検出機構のメッセージの交換を示す。 本発明の例示の実施形態による2つの端末間で、図2のオーバレイネットワークを介した図5のオンパスNSISルータ検出機構のメッセージの交換を示す。 2つの端末間で、図2のオーバレイネットワークを介した本発明の別の実施形態によるオフパスNSISルータ検出機構のメッセージの交換を示す。 2つの端末間で、図2のオーバレイネットワークを介した本発明の別の実施形態によるオフパスNSISルータ検出機構のメッセージの交換を示す。 2つの端末間で、図2のオーバレイネットワークを介した本発明の別の実施形態によるオフパスNSISルータ検出機構のメッセージの交換を示す。 2つの端末間で、図2のオーバレイネットワークを介した本発明の別の実施形態によるオフパスNSISルータ検出機構のメッセージの交換を示す。 2つの端末間で、図2のオーバレイネットワークを介した本発明の別の実施形態によるオフパスNSISルータ検出機構のメッセージの交換を示す。

Claims (32)

  1. パケット交換型通信ネットワークを介して第1の端末と第2の端末との間に少なくとも1つのメディアストリームを含むメディアセッションを確立するための方法であって、少なくとも1つのメディアストリームが、メディアトランスポートプロトコルを用いて通信され、第1の端末によって実行される以下のステップ、すなわち
    セッションを開始するために、セッション管理プロトコルを用いて、第2の端末にセットアップメッセージを送信するステップであって、メッセージは、メディアフォーマットを提示するセッション記述と、メディアセッションにおいて通信される各メディアストリームに関するパラメータおよび属性と、を含む、ステップと、
    セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信するステップであって、セットアップメッセージに対する応答は、修正セッション記述を含み、修正セッション記述は、メディアセッションの少なくとも1つのメディアストリームに関する代替メディアフォーマットを提示し、この場合には、第2の端末によってサポートされていないメディアフォーマットが、セットアップメッセージに含まれるセッション記述において提示されている、ステップと、
    セットアップメッセージに対する応答に含まれる修正セッション記述において各代替メディアフォーマットに関して、それぞれの代替メディアフォーマットが第1の端末によってサポートされているかどうかを決定するステップと、
    それぞれの代替メディアフォーマットが前記第1の端末によってサポートされていない場合には、第1の端末によってサポートされていない各代替メディアフォーマットに関して、ネクストステップインシグナリングNSISフレームワークを用いて、少なくとも1つのNSISルータを検出するステップであって、検出されたNSISルータは、セットアップメッセージにおけるセッション記述において第1の端末によって提示されるメディアフォーマットから、セットアップメッセージに対する応答の修正セッション記述において第2の端末によって提示されるそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換する、ステップと、
    第1の端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも1つのNSISルータが検出された場合には、第1の端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出された少なくとも1つのNSISルータで、第1の端末によって提示されたメディアフォーマットにおけるパケットデータをそれぞれの代替メディアフォーマットに変換するためのリソースを確保するステップと、
    メディアセッションを開始するメディアフォーマット変換のためのリソースが首尾よく確保されたときには、メディアセッションの少なくとも1つのメディアストリームのパケットデータが、メディアトランスポートプロトコルを用いて、第1の端末によってサポートされていない各代替メディアフォーマットに関して、メディアフォーマット変換のためのリソースが確保されている少なくとも1つのNSISルータを介して、第1の端末から第2の端末に提供される、ステップと、
    を含む方法。
  2. NSISシグナリングフレームワークを用いて、少なくとも1つのNSISルータを検出するステップは、
    パケット交換型通信ネットワークを介して第1の端末から第2の端末へのメディアセッションの少なくとも1つのストリームのパケットデータのパスに沿って、NSISトランスポートレベルプロトコルNTLPを用いて、照会メッセージを送信するステップであって、照会メッセージが、第の端末によってサポートされておらず、第1の端末によって提示されたメディアフォーマットから、セットアップメッセージに対する応答における修正セッション記述において、第2の端末によって提示されたそれぞれの代替メディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信する各NSISルータに照会する、ステップと、
    照会メッセージに対する応答において、NSISトランスポートレベルプロトコルNTLPを用いて、第1の端末によって提示されたメディアフォーマットからそれぞれの代替のメディアフォーマットにメディアセッションのストリームのパケットデータを変換することができる第1の端末から第2の端末へのパケットデータのパスにおける少なくとも1つのNSISルータを示す応答メッセージを受信するステップと、
    を含む、請求項1に記載の方法。
  3. 照会メッセージは、第の端末によってサポートされておらず、第1の端末によって提示されたメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたはメディアセッションのそれぞれのメディアストリームに関するそれぞれの代替メディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するための機能に関する照会メッセージを受信する各NSISルータにさらに照会し、
    応答メッセージは、第1の端末から第2の端末へのパスにおける少なくとも1つのNSISルータが、第1の端末によって提示されたメディアフォーマットから中間メディアフォーマットに、中間メディアフォーマットから別の中間メディアフォーマットまたはそれぞれの代替メディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換することができるかについてさらに示す、請求項2に記載の方法。
  4. NSISルータでパケットデータを変換するためのリソースを確保するステップは、
    第1の端末によって提示されたメディアフォーマットから第2の端末によってセットアップメッセージに対する応答における修正セッション記述によって提示される代替メディアフォーマットに、メディアセッションのストリームのパケットデータを変換するためのメディア適応リソースの確保を要求するリソース確保要求メッセージを、NSISトランスポートレベルプロトコルNTLPを用いて、少なくとも1つのNSISルータに送信するステップと、
    リソース確保要求メッセージに対応する応答において、NSISトランスポートレベルプロトコルNTLPを用いて、NSISルータが変換のためのリソースを確保したかどうかを示す応答メッセージを受信するステップと、
    を含む、請求項2又は3に記載の方法。
  5. セットアップメッセージに含まれるセッション記述は、第2の端末がセットアップメッセージに含まれるセッション記述においてメディアストリームの第1の端末によって提示されたメディアフォーマットをサポートしない場合には、メディアセッションの少なくともメディアストリームに関して、第1の端末がメディアフォーマット変換を自発的に行うかどうかをさらに示す、請求項1から4のいずれか一項に記載の方法。
  6. セットアップメッセージに含まれて送信されるセッション記述は、さらに、第2の端末に対し、メディアセッションのそれぞれのメディアストリームの受信が、メディアセッションの確立のために必須であるかどうかを示す、請求項1から5のいずれか一項に記載の方法。
  7. セットアップメッセージに含まれて送信されたセッション記述はさらに、第2の端末が第1の端末によって提示されたメディアフォーマットをサポートしていない場合には、メディアセッションのメディアストリームに関して、別のメディアフォーマットへの第1の端末によって提示されたメディアフォーマットの変換が、メディアセッションの確立のために任意であるか、または必須であるかを示す、請求項6に記載の方法。
  8. それぞれのメディアストリームに関して第1の端末によって提示されたメディアフォーマットが、第2の端末によってサポートされていない場合には、修正セッション記述は、さらに、代替メディアフォーマットにおけるメディアストリームのパケットデータを第1の端末によって提示されたメディアフォーマットにおけるメディアストリームのパケットデータに変換するために、少なくとも1つのNSISルータにおいてリソースを自発的に検出して確保するかどうかを示し、
    そうである場合には、修正セッション記述はさらに、セットアップメッセージに対する応答の送信時に、第2の端末がメディアフォーマット変換リソースの検出および確保を開始したことを示す、請求項1から7のいずれか一項に記載の方法。
  9. 第1の端末によって送受信されるセッション記述は、さらに、セッションに関連するサービスの品質制約条件を含み、セットアップメッセージに対する応答における修正セッション記述は、セットアップメッセージのセッション記述に含まれるサービスの品質制約条件に対して、代替のサービスの品質制約条件を提示することを含む、請求項1から8のいずれか一項に記載の方法。
  10. 代替のサービスの品質制約条件が、第1の端末のユーザによって許容可能であるかどうかを決定するステップと、
    そうである場合には、第2の端末の修正セッション記述において示される代替のサービスの品質制約条件に基づき、パケット交換型通信ネットワークを介した第1の端末から第2の端末へのパスに沿ってリソースを確保するステップであって、メディアセッションの少なくとも1つのメディアストリームのパケットデータは、前記パスに沿って第1の端末から第2の端末に供給されるステップをさらに含む、請求項9に記載の方法。
  11. セットアップメッセージに対する応答において受信されたセッション記述において提示された各代替メディアフォーマットに関して、検出されるNSISルータがない場合、それぞれのNSISルータでメディアフォーマットを変換するために確保されることができるリソースが十分でない場合、またはパケット交換型通信ネットワークを介したパスに沿って、セットアップメッセージに対する応答において受信されたセッション記述において提示された代替のサービスの品質制約条件を満たすために確保されることができるリソースが十分でない場合には、セッションを中断するステップをさらに含む、請求項1から10のいずれか一項に記載の方法。
  12. メディアセッションを開始するステップは、メディアセッションのそれぞれのストリームに関する適応ノードにおいてメディアフォーマット変換を記述する更新されたセッション記述を含む更新メッセージを第2の端末に送信するステップを含み、この場合には代替メディアフォーマットが、パケット交換型通信ネットワークを介して第1の端末から第2の端末にパスに沿って提示され、メディアセッションの少なくとも1つのメディアストリームのパケットデータは、前記パスに沿って第1の端末から第2の端末に供給される、請求項1から11のいずれか一項に記載の方法。
  13. 送信された更新メッセージはさらに、第1の端末から第2の端末へのパスに沿って、第1の端末によって確保されるリソースに関する情報を含む、請求項12に記載の方法。
  14. メディアセッションのそれぞれのストリームに関する適応ノードにおいてメディアフォーマット変換を記述する更新されたセッション記述を含む更新メッセージを第2の端末から受信するステップであって、この場合には代替メディアフォーマットが、パケット交換型通信ネットワークを介して第2の端末から第1の端末にパスに沿って提示され、メディアセッションの少なくとも1つのメディアストリームのパケットデータは、前記パスに沿って第2の端末から第1の端末に供給される、請求項12または13に記載の方法。
  15. 受信された更新メッセージはさらに、第2の端末から第1の端末へのパスに沿って、第1の端末によって確保されるリソースに関する情報をさらに含む、請求項14に記載の方法。
  16. メディアトランスポートプロトコルは、リアルタイムトランスポートプロトコルRTPである、請求項1から15のいずれか一項に記載の方法。
  17. セッション記述は、セッション記述プロトコルSDPフォーマットまたはリアルタイムストリーミングプロトコルRTSPフォーマットで提供される、請求項1から16のいずれか一項に記載の方法。
  18. セッション管理プロトコルは、セッション開始プロトコルSIPであり、セットアップメッセージは、SIPプロトコルの招待メッセージであり、セットアップメッセージに対する応答は、第2の端末がメディアフォーマット変換リソースの検出および確保のための第1の端末の意思を承認することと、第2の端末が第1の端末によってサポートされていない代替メディアフォーマットにおけるメディアセッションのメディアストリームを第1の端末によってサポートされると共に、第1の端末によって提示されたメディアフォーマットに変換するために、少なくともNSISルータでメディアフォーマット変換のためのリソースの検出および確保を開始したことを第1の端末に示すSIPプロトコルのセッション進行メッセージであって、前記方法は、
    セッション進行メッセージに含まれるセッション記述において提示された代替メディアフォーマットが、第1の端末によってサポートされていない場合には、第1の端末が、セッション記述において提示された各代替メディアフォーマットに関して、NSISルータでメディアフォーマット変換のためのリソースの検出および確保を開始したことを第2の端末に示す暫定応答承認メッセージを送信するステップであって、メディアフォーマット変換のためのリソースが第2の端末によって確保された適応ノードが検出され、代替メディアフォーマットから第1の端末によって提示されたメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するように構成される、ステップと、
    暫定応答承認を受信するステップと、
    をさらに含む、請求項1から17のいずれか一項に記載の方法。
  19. 要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースを報告するための方法であって、メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末にパケット交換型ネットワークを介して移送されるメディアデータパスにおけるNSISルータによって行われる以下のステップ、すなわち、
    パケット交換型通信ネットワークを介してNSISトランスポートレベルプロトコルNTLPを用いて、照会メッセージを受信するステップであって、照会メッセージは、第1のメディアフォーマットから第2の異なるメディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するNSISルータに照会する、ステップと、
    受信された照会メッセージに対する応答において、NSISトランスポートレベルプロトコルNTLPを用いて、要求中の端末に対して、NSISルータが、第1のメディアフォーマットから第2のメディアフォーマットにメディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す応答メッセージを送信するステップと、
    を含む方法。
  20. 照会メッセージはさらに、第1のメディアフォーマットから中間メディアフォーマットに、または中間メディアフォーマットから別の中間メディアフォーマットまたは第2の代替のメディアフォーマットに、メディアセッションのメディアストリームのパケットデータを変換するための機能について照会し、
    応答メッセージはさらに、NSISルータが、照会されたメディアフォーマット変換の少なくとも1つを提供することができるかどうかを示す、請求項19に記載の方法。
  21. 照会メッセージは、適応機能が照会される1つまたは複数のメディアフォーマット変換を示すメディアフォーマット適応記述を含む、請求項19または20に記載の方法。
  22. NSISトランスポートレベルプロトコルNTLPを用いて、リソース確保要求メッセージを受信するステップであって、メッセージは、リソースが割り当てられるように要求されるNSISルータによって行われるメディアフォーマット変換の記述を含む、ステップと、
    前記記述によって示されるメディアフォーマット変換のためのリソースが、NSISルータで割り当てられることができるかどうかを決定するステップと、
    割当可能である場合には、NSISルータで、変換のためのリソースを確保するステップと、
    をさらに含み、
    応答メッセージは、NSISルータが変換のためにリソースを確保したかどうかを示す、請求項19から21のいずれか一項に記載の方法。
  23. NSISトランスポートレベルプロトコルNTLPを用いて、リソース確保要求メッセージを受信するステップであって、メッセージは、メディアデータパスに位置する別のNSISルータで確保されるメディアフォーマット変換の記述を含む、ステップと、
    メディアデータパスに位置する他のNSISルータへのトンネルを確立するステップと、
    メディアセッションの開始時に、変換のためにメディアデータパスに位置するNSISルータに変換されるメディアストリームのパケットデータを転送するステップと、
    をさらに含む、請求項19から22のいずれか一項に記載の方法。
  24. NSISトランスポートレベルプロトコルNTLPを用いて、リソース確保要求メッセージを受信するステップであって、メッセージは、メディアデータパスに位置しないNSISルータで、確保されるメディアフォーマット変換の記述を含む、ステップと、
    リソース確保要求メッセージをメディアデータパスに位置しないNSISルータに転送するステップと、
    メディアデータパスに位置しないNSISルータへのトンネルを確立するステップと、
    メディアセッションの開始時に、変換のためにメディアデータパスに位置しないNSISルータに変換されるメディアストリームのパケットデータを転送するステップと、
    をさらに含む、請求項19から23のいずれか一項に記載の方法。
  25. NSISルータで利用可能なメディアフォーマット適応機能の記述を照会メッセージに追加するステップと、
    追加した記述を含む受信した照会メッセージをメディアデータパスにおける次のNSISルータまたは宛先端末に転送するステップと、
    転送された照会メッセージに対する応答において、メディアデータパスにおける次のNSISルータまたは宛先端末から応答メッセージを受信するステップであって、照会されたメディアフォーマット適応機能が利用可能である場合には、応答メッセージは、メディアデータパスに位置するNSISルータで利用可能であるメディアフォーマット適応機能の少なくとも1つの記述を含む、ステップと、
    をさらに含み、
    照会されたメディアフォーマット適応機能が利用可能である場合には、送信された応答メッセージは、メディアデータパスに位置するNSISルータで利用可能であるメディアフォーマット適応機能の少なくとも1つの記述を含む、請求項19から24のいずれか一項に記載の方法。
  26. 少なくとも1つのメディアデータパスに位置しないNSISルータに照会メッセージを転送するステップと、
    少なくとも1つのメディアデータパスに位置しないNSISルータから、メディアパスに位置しない少なくとも1つのNSISルータで利用可能であるメディアデータ適応機能の記述を含む応答メッセージを受信するステップと、
    をさらに含む、請求項25に記載の方法。
  27. 受信された照会メッセージをメディアデータパスにおける次のNSISルータに転送する前に、メディアパスに位置しない少なくとも1つのNSISルータで利用可能なメディアデータ適応機能の記述を、上記の受信された照会メッセージに追加するステップをさらに含む、請求項26に記載の方法。
  28. 要求中の端末に対して送信される応答メッセージは、さらに、メディアパスに位置するか、または位置しない少なくとも1つのNSISルータで利用可能なメディアデータ適応機能の記述を含む、請求項23または27に記載の方法。
  29. パケット交換型通信ネットワークを介して端末と第2の端末との間で、少なくとも1つのメディアストリームを含むメディアセッションを確立する端末であって、少なくとも1つのメディアストリームは、メディアトランスポートプロトコルを用いて通信される、端末であって、前記端末は、
    セッションを開始するために、セッション管理プロトコルを用いて、セットアップメッセージを第2の端末に送信するための送信器であって、メッセージは、メディアセッションにおいて送信されるメディアフォーマットと、各メディアストリームに関する対応するパラメータおよび属性と、を提示するセッション記述を含む、送信器
    セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信するための受信器であって、セットアップメッセージに対する応答は、修正セッション記述を含み、修正セッション記述は、メディアセッションの少なくとも1つのメディアストリームに関する代替メディアフォーマットを提示し、この場合には第2の端末によってサポートされていないメディアフォーマットがセットアップメッセージに含まれるセッション記述において提示される、受信器と、
    セットアップメッセージに対する応答に含まれる修正セッション記述において、各代替メディアフォーマットに関してそれぞれの代替メディアフォーマットが端末によってサポートされるかどうかを決定するための処理装置と、
    を備え、
    前記処理装置はさらに、それぞれの代替メディアフォーマットが端末によってサポートされていない場合には、ネクストステップインシグナリングNSISフレームワークを用いて、端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも1つのNSISルータを検出するように構成され、
    前記処理装置は、NSISルータとして、セットアップメッセージにおけるセッション記述において、端末によって提示されるメディアフォーマットから、セットアップメッセージに対する応答における修正セッション記述において、第2の端末によって提示されたそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換することができるNSISルータを検出するように構成され
    端末は、さらに、
    端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも1つのNSISルータが検出されている場合には、端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出される少なくとも1つのNSISルータで、端末によって提示されたメディアフォーマットにおけるパケットデータをそれぞれの代替メディアフォーマットに変換するためのリソースを確保するための確保ユニットを備え、
    前記端末は、メディアフォーマット変換のためのリソースを確保したときに、メディアセッションを開始するように適合され、メディアセッションの少なくとも1つのメディアストリームのパケットデータは、メディアトランスポートプロトコルを用いて、メディアフォーマット変換のためのリソースが、端末によってサポートされていない各代替メディアフォーマットに関して確保されている少なくとも1つのNSISルータを介して端末から第2の端末に提供される、端末。
  30. 要求中の端末に対してパケット交換型通信ネットワークを介して端末間で確立されるメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースを報告するためのNSISルータであって、
    NSISルータは、メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末まで、パケット交換型ネットワークを介して移送されるメディアデータパスに位置し、
    パケット交換型通信ネットワークを介して、NSISトランスポートレベルプロトコルNTLPを用いて、照会メッセージを受信するための受信器であって、照会メッセージは、第1のメディアフォーマットから第2の異なるメディアフォーマットに、メディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するNSISルータに照会する、受信器と、
    受信された照会メッセージに対する応答において、要求中の端末に対してNSISトランスポートレベルプロトコルNTLPを用いて、NSISルータが、第1のメディアフォーマットから第2のメディアフォーマットに、メディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す応答メッセージを送信するための送信器と、
    を備える、NSISルータ。
  31. 端末のプロセッサによって実行されるときに、パケット交換型通信ネットワークを介して端末と第2の端末との間で、少なくとも1つのメディアストリームを含むメディアセッションを端末に確立させる命令を格納するコンピュータ読み出し可能メディアであって、前記命令は、メディアトランスポートプロトコルを用いて、少なくとも1つのメディアストリームを通信するためのステップとして、
    セッションを開始するために、セッション管理プロトコルを用いて、セットアップメッセージを第2の端末に送信するステップであって、メッセージは、メディアセッションにおいて送信されるメディアフォーマットと、各メディアストリームに関するパラメータおよび属性と、を提示するセッション記述を含む、ステップと、
    セッション管理プロトコルを用いて、セットアップメッセージに対する応答を受信するステップであって、セットアップメッセージに対する応答は、修正セッション記述を含み、修正セッション記述は、メディアセッションの少なくとも1つのメディアストリームに関する代替メディアフォーマットを提示し、この場合には第2の端末によってサポートされていないメディアフォーマットがセットアップメッセージに含まれるセッション記述において提示される、ステップと、
    セットアップメッセージに対する応答に含まれる修正セッション記述において、各代替メディアフォーマットに関して、それぞれの代替メディアフォーマットが端末によってサポートされるかどうかを決定するステップと、
    そうでない場合には、端末によってサポートされていない各代替メディアフォーマットに関して、ネクストステップインシグナリングNSISフレームワークを用いて、少なくとも1つのNSISルータを検出するステップであって、NSISルータとして、セットアップメッセージにおけるセッション記述において端末によって提示されるメディアフォーマットから、セットアップメッセージに対する応答の修正セッション記述において第2の端末によって提示されるそれぞれの代替メディアフォーマットに、メディアストリームのパケットデータを変換することができるNSISルータを検出する、ステップと、
    端末によってサポートされていない各代替メディアフォーマットに関して、少なくとも1つのNSISルータが、検出された場合には、端末によってサポートされていないそれぞれの代替メディアフォーマットに関して検出された少なくとも1つのNSISルータで、端末によって提示されたメディアフォーマットにおけるパケットデータをそれぞれの代替メディアフォーマットに変換するためのリソースを確保するステップと、
    を含み、
    メディアセッションを開始するメディアフォーマット変換のためのリソースが確保されたときには、メディアセッションの少なくとも1つのメディアストリームのパケットデータが、メディアトランスポートプロトコルを用いて、端末によってサポートされていない各代替メディアフォーマットに関して、メディアフォーマット変換のためのリソースが確保されている少なくとも1つのNSISルータを介して、端末から第2の端末に提供される、コンピュータ読み出し可能メディア。
  32. メディアトランスポートプロトコルによってカプセル化されたセッションのメディアストリームのパケットデータが、要求中の端末から確立されるメディアセッションに関与している宛先端末に、パケット交換型通信ネットワークを介して移送されるメディアデータパスにおけるNSISルータのプロセッサによって実行されるとき、要求中の端末に対してメディアセッションのメディアストリームのメディアフォーマットを変換するためのメディアフォーマット適応リソースをNSISルータに報告させる命令を格納するコンピュータ読み出し可能メディアであって、前記命令は、NSISルータによって実行される以下のステップ、すなわち
    パケット交換型通信ネットワークを介してNSISトランスポートレベルプロトコルNTLPを用いて、照会メッセージを受信するステップであってし、照会メッセージは、第1のメディアフォーマットから第2の異なるメディアフォーマットにメディアセッションのストリームのパケットデータを変換するための機能に関する照会メッセージを受信するNSISルータに照会する、ステップと、
    受信された照会メッセージに対する応答において、NSISトランスポートレベルプロトコルNTLPを用いて、要求中の端末に対して、NSISルータが、第1のメディアフォーマットから第2のメディアフォーマットにメディアセッションのストリームのパケットデータを変換する機能を有するかどうかを示す応答メッセージを送信するステップと、を実行させる命令を格納する、コンピュータ読み出しメディア。
JP2008527340A 2005-08-26 2006-08-10 メディア適応を備えたメディアセッションの確立 Expired - Fee Related JP4746102B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP05018623.8 2005-08-26
EP05018623A EP1758334A1 (en) 2005-08-26 2005-08-26 Establishment of media sessions with media adaptation
PCT/EP2006/007937 WO2007022875A1 (en) 2005-08-26 2006-08-10 Establishment of media sessions with media adaptation

Publications (2)

Publication Number Publication Date
JP2009506601A JP2009506601A (ja) 2009-02-12
JP4746102B2 true JP4746102B2 (ja) 2011-08-10

Family

ID=35589597

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008527340A Expired - Fee Related JP4746102B2 (ja) 2005-08-26 2006-08-10 メディア適応を備えたメディアセッションの確立

Country Status (5)

Country Link
US (1) US7958242B2 (ja)
EP (1) EP1758334A1 (ja)
JP (1) JP4746102B2 (ja)
CN (1) CN101273607A (ja)
WO (1) WO2007022875A1 (ja)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE522068T1 (de) 2003-09-02 2011-09-15 Nokia Corp Übertragung von informationen, die sich auf eine dienstgüte beziehen
WO2007141840A1 (ja) * 2006-06-05 2007-12-13 Hitachi Communication Technologies, Ltd. 中継ネットワークシステム及び端末アダプタ装置
US8520687B2 (en) * 2007-07-06 2013-08-27 Alcatel Lucent Method and apparatus for internet protocol multimedia bearer path optimization through a succession of border gateways
US8296443B2 (en) * 2007-07-10 2012-10-23 Telefonaktiebolaget Lm Ericsson (Publ) Method of discovering operator-provided network-services using IMS
KR101421587B1 (ko) * 2007-08-23 2014-07-22 삼성전자주식회사 무선 영상 전화 단말간의 선호 영상 규격을 결정하는 방법및 장치
GB2452535A (en) * 2007-09-07 2009-03-11 Ericsson Telefon Ab L M Optimising packet switched networks
US8201188B2 (en) 2007-09-20 2012-06-12 Microsoft Corporation Device-hosted services over media transfer protocol
US9479967B1 (en) * 2007-10-26 2016-10-25 Genband Us Llc Enhanced media gateway
US20090136016A1 (en) * 2007-11-08 2009-05-28 Meelik Gornoi Transferring a communication event
KR100940183B1 (ko) * 2007-12-11 2010-02-04 한국전자통신연구원 저전력 센서망에서 다중 라우팅 기법에 적용 가능한 공용 패킷 블록 구성 장치 및 그 제공 방법
KR100928998B1 (ko) * 2007-12-12 2009-11-26 한국전자통신연구원 사용자 단말기에 멀티미디어 컨텐츠와 코덱을 제공하는적응적 멀티미디어 시스템 및 그 방법
JP5006452B2 (ja) * 2007-12-19 2012-08-22 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Publish/subscribeネットワーク
EP2274891B1 (en) * 2008-01-11 2011-11-09 Telefonaktiebolaget L M Ericsson (publ) Method and apparatus for establishing a streamed media session
CN101540970B (zh) * 2008-03-19 2013-08-28 华为技术有限公司 一种终端处理主叫信息的方法和装置
JP5199719B2 (ja) * 2008-04-07 2013-05-15 キヤノン株式会社 ネットワークシステム
JP5336920B2 (ja) * 2008-05-08 2013-11-06 パナソニック株式会社 記録装置
US20100017516A1 (en) * 2008-07-16 2010-01-21 General Instrument Corporation Demand-driven optimization and balancing of transcoding resources
US8307422B2 (en) * 2008-08-14 2012-11-06 Juniper Networks, Inc. Routing device having integrated MPLS-aware firewall
US8713627B2 (en) 2008-08-14 2014-04-29 Juniper Networks, Inc. Scalable security services for multicast in a router having integrated zone-based firewall
US9392437B2 (en) * 2008-10-17 2016-07-12 Alcatel Lucent Method and system for IP multimedia bearer path optimization through a succession of border gateways
US20100149301A1 (en) * 2008-12-15 2010-06-17 Microsoft Corporation Video Conferencing Subscription Using Multiple Bit Rate Streams
WO2010090454A2 (en) * 2009-02-05 2010-08-12 Samsung Electronics Co., Ltd. Communication system and method for media adaptation therein
US8488632B2 (en) * 2009-03-11 2013-07-16 Xcast Labs, Inc. Optimizing VoIP for satellite connection
US8605594B2 (en) 2009-05-18 2013-12-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangements for dynamic resource reservation
US8291107B1 (en) * 2009-06-08 2012-10-16 Sprint Spectrum L.P. Dynamic multimedia content change based on sector loading
US20120144056A1 (en) * 2009-08-12 2012-06-07 Nederlandse Organisatie Voor Toegepast- Natuurwetenschappelijk Onderzoek Tno Dynamic RTCP Relay
CN102055741B (zh) * 2009-11-06 2013-08-14 华为终端有限公司 媒体会话协商的方法、设备及系统
GB2479180B (en) 2010-03-31 2016-06-01 Skype System of user devices
GB201005454D0 (en) 2010-03-31 2010-05-19 Skype Ltd Television apparatus
WO2011153475A1 (en) * 2010-06-04 2011-12-08 Skype Ireland Technologies Holdings Limited Server-assisted video conversation
US8947492B2 (en) 2010-06-18 2015-02-03 Microsoft Corporation Combining multiple bit rate and scalable video coding
CN102959531B (zh) * 2010-06-29 2016-01-06 中兴通讯(美国)公司 用于云基媒体自适应和代码转换服务的方法和系统
FR2963861B1 (fr) * 2010-08-10 2014-09-12 Thales Sa Procede et architecture de systeme d'ouverture de canaux sur etablissement de communication volp en mode clair p bgan, swiftbroad et fleetbroadband
US10291660B2 (en) 2010-12-31 2019-05-14 Skype Communication system and method
US10404762B2 (en) 2010-12-31 2019-09-03 Skype Communication system and method
US8963982B2 (en) 2010-12-31 2015-02-24 Skype Communication system and method
US9717090B2 (en) 2010-12-31 2017-07-25 Microsoft Technology Licensing, Llc Providing notifications of call-related services
WO2012175227A1 (en) * 2011-06-23 2012-12-27 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatus for identifying rtp media streams containing related media data
EP2730073B1 (en) * 2011-07-07 2019-09-04 Telefonaktiebolaget LM Ericsson (publ) Media stream grouping in multimedia communication networks
US9712891B2 (en) * 2011-11-01 2017-07-18 Nokia Technologies Oy Method and apparatus for selecting an access method for delivery of media
US9019336B2 (en) * 2011-12-30 2015-04-28 Skype Making calls using an additional terminal
WO2013117211A1 (en) * 2012-02-06 2013-08-15 Nokia Siemens Networks Oy Customer experience management interaction with caching
GB2501080A (en) * 2012-04-11 2013-10-16 Sca Ipla Holdings Inc Telecommunication apparatus and methods
CN103841086B (zh) * 2012-11-23 2018-03-27 中兴通讯股份有限公司 一种数据传输方法、装置及终端
CN103856397B (zh) * 2012-12-07 2018-08-14 中兴通讯股份有限公司 多链路透明互连网络中组播转发方法及装置、路由桥
US9172604B1 (en) 2013-02-25 2015-10-27 Google Inc. Target mapping and implementation of abstract device model
US9166912B2 (en) 2013-02-25 2015-10-20 Google Inc. Translating network forwarding plane models into target implementation using sub models and hints
US9912623B2 (en) * 2015-01-16 2018-03-06 General Electric Company Systems and methods for adaptive context-aware control of multimedia communication sessions
EP3318008B1 (en) * 2015-06-30 2022-09-07 British Telecommunications public limited company Negotiating quality of service for data flows
CN107423307B (zh) * 2016-05-24 2020-11-17 创新先进技术有限公司 一种互联网信息资源的分配方法及装置
CN108809921B (zh) * 2017-07-31 2021-08-06 视联动力信息技术股份有限公司 一种音频处理方法、视联网服务器和视联网终端
US11089078B2 (en) * 2019-09-13 2021-08-10 Microsoft Technology Licensing, Llc Model-based parameter selection for media sessions
CN111193941B (zh) * 2020-01-07 2021-09-17 北京东土科技股份有限公司 一种媒体数据的传输方法、装置、设备及存储介质
CN113473162B (zh) * 2021-04-06 2023-11-03 北京沃东天骏信息技术有限公司 一种媒体流的播放方法、装置、设备和计算机存储介质
CN115426335B (zh) * 2021-05-13 2023-10-27 中移(上海)信息通信科技有限公司 一种信息交互方法、装置、设备及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001117809A (ja) * 1999-10-14 2001-04-27 Fujitsu Ltd メディア変換方法及び記憶媒体
JP2003152820A (ja) * 2001-11-19 2003-05-23 Nec Corp シグナリング中継システムおよびシグナリング中継方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1089517B1 (en) * 1999-10-01 2005-12-14 Nortel Networks Limited Establishing connections accross a communications network
US7191236B2 (en) * 2000-05-02 2007-03-13 Canon Kabushiki Kaisha Transparent telecommunications system and apparatus
DE60203779T2 (de) * 2002-01-23 2006-03-09 Sony International (Europe) Gmbh Ein Verfahren zur Übertragung von End-to-End QoS durch Anwendung des end-to-end negotiation protocols (E2ENP)
JP2003309664A (ja) * 2002-04-17 2003-10-31 Sony Corp 端末装置、データ送受信システム及びデータ送受信開始方法
US7451229B2 (en) * 2002-06-24 2008-11-11 Microsoft Corporation System and method for embedding a streaming media format header within a session description message
GB0230301D0 (en) * 2002-12-30 2003-02-05 Nokia Corp Streaming media
US6888821B2 (en) * 2003-02-10 2005-05-03 Nokia Corporation Dynamic media authorization in mobile networks
BR0302755A (pt) * 2003-08-25 2003-11-25 Eduardo Moreno Marques Sistema concentrador de acesso aos serviços de telefonia fixa e móvel
JP4343626B2 (ja) * 2003-09-02 2009-10-14 キヤノン株式会社 画像通信制御方法、画像通信制御プログラム、および画像通信装置
US20050060411A1 (en) * 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001117809A (ja) * 1999-10-14 2001-04-27 Fujitsu Ltd メディア変換方法及び記憶媒体
JP2003152820A (ja) * 2001-11-19 2003-05-23 Nec Corp シグナリング中継システムおよびシグナリング中継方法

Also Published As

Publication number Publication date
EP1758334A1 (en) 2007-02-28
CN101273607A (zh) 2008-09-24
US7958242B2 (en) 2011-06-07
WO2007022875A1 (en) 2007-03-01
JP2009506601A (ja) 2009-02-12
US20090172170A1 (en) 2009-07-02

Similar Documents

Publication Publication Date Title
JP4746102B2 (ja) メディア適応を備えたメディアセッションの確立
JP5312594B2 (ja) Rfc3313に対する帯域内dpiメディア予約修正
EP2060077B1 (en) Indicating or remarking of a dscp
US8301744B2 (en) Systems and methods for QoS provisioning and assurance for point-to-point SIP sessions in DiffServ-enabled MPLS networks
KR102073836B1 (ko) 다수의 오디오 비디오 브리징 네트워크를 통한 스트림을 위한 서비스 품질
US20160173581A1 (en) Method and Apparatus for Providing Relevant Service Levels
US20080165787A1 (en) Method for negotiating about the media stream packet time length
JP2006518948A (ja) マルチメディア・ストリーミングにおけるストリーミング品質適合と制御機構のシグナリング方法
US9332561B1 (en) Hybrid communications system using peer-to-peer and centralized architecture
Thomas et al. Enhancing MPEG DASH performance via server and network assistance
US20180131672A1 (en) Method and system for enabling media optimization in a cloud conference
Loreto et al. How far are we from webrtc-1.0? an update on standards and a look at what's next
US20120166659A1 (en) Node and Method for Quality of Service (QoS) Control
CN104518908A (zh) 用于提供网络管理的方法和系统
WO2006093221A1 (ja) 伝送制御装置およびその方法
WO2009082908A1 (fr) Procédé, dispositif et système de traitement d&#39;un protocole de flux en temps réel
US20090241157A1 (en) Content distribution system, band control mediating apparatus, and band control method
WO2007019777A1 (fr) Méthode d’établissement de session et nœud de contrôle de session
JP2013510477A (ja) メディアセッションのネゴシエーションのための方法、機器およびシステム
Volkert et al. Hierarchical routing management for improving multimedia transmissions and QoE
US20120144013A1 (en) Discovery of on-path services for media flows
US20110158102A1 (en) Method and system for routing data streams in an ip network by flooding of a subscriber search message
Ahsan et al. Multipath RTP (MPRTP) draft-ietf-avtcore-mprtp-03
Nandakumar RFC 8859 A Framework for Session Description Protocol (SDP) Attributes When Multiplexing
WO2009095069A1 (en) Methods, apparatuses, system, and related computer program product for session initiation

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090610

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110118

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110318

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110412

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110512

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

Free format text: PAYMENT UNTIL: 20140520

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees