[go: up one dir, main page]

CN101090475A - 会议布局控制和控制协议 - Google Patents

会议布局控制和控制协议 Download PDF

Info

Publication number
CN101090475A
CN101090475A CNA2007101067456A CN200710106745A CN101090475A CN 101090475 A CN101090475 A CN 101090475A CN A2007101067456 A CNA2007101067456 A CN A2007101067456A CN 200710106745 A CN200710106745 A CN 200710106745A CN 101090475 A CN101090475 A CN 101090475A
Authority
CN
China
Prior art keywords
node
video
meeting
visual telephone
network
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.)
Granted
Application number
CNA2007101067456A
Other languages
English (en)
Other versions
CN101090475B (zh
Inventor
理查德·E·休伯
阿伦·蓬伊
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.)
Ericsson Inc
Original Assignee
Ericsson Inc
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 Ericsson Inc filed Critical Ericsson Inc
Publication of CN101090475A publication Critical patent/CN101090475A/zh
Application granted granted Critical
Publication of CN101090475B publication Critical patent/CN101090475B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/141Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/147Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals
    • 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
    • H04L65/1104Session initiation protocol [SIP]
    • 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/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4038Arrangements for multi-party communication, e.g. for conferences with floor control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103Selection of coding mode or of prediction mode
    • H04N19/114Adapting the group of pictures [GOP] structure, e.g. number of B-frames between two anchor frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/141Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/148Interfacing a video terminal to a particular transmission medium, e.g. ISDN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems
    • H04N7/152Multipoint control units therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供一种包括网络的电话会议系统。所述系统包括多个节点,其彼此通信以形成会议。每个节点具有带有显示布局的视频显示器,所述节点中的至少一者个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。本发明提供一种用于提供电话会议的方法,其包括以下步骤:利用通过网络彼此通信的多个节点形成会议。每个节点具有带有显示布局的视频显示器。存在以下步骤:利用所述节点中的至少一者个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。本发明提供一种电话会议节点。本发明提供一种包括网络的电话会议系统。所述系统包括多个节点,其通过网络彼此通信以形成会议。当发生改变时,每个节点仅将所述改变传达到其它节点。一种用于在至少三方之间进行电信会议的方法包括在所述方之间建立会议的步骤。存在对所述会议作出改变的步骤。存在仅将所述改变传达到参与方的步骤。

Description

会议布局控制和控制协议
相关申请案的交叉参考
本申请案与以下同时期申请的美国临时专利申请案相关:Richard E.Huber、Arun Punj和Peter D.Hill的题为“Intelligent Audio Limit Method”且代理人案号为FORE-119的第60/814,477号美国临时专利申请案;Arun Punj、Richard E.Huber和Gregory H.Smith的题为“Associating Independent Multimedia Sources Into a Conference Call”且代理人案号为FORE-121的第60/814,491号美国临时专利申请案,所述两个申请案均以引用方式并入本文中。
技术领域
本发明涉及控制电话会议的视频显示。更明确地说,本发明涉及控制电话会议的视频显示,其中所述电话会议的节点中的至少一者个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
本发明涉及多个节点之间的电话会议,其中当发生对于所述会议的改变时,每个节点仅将所述改变传达到其它节点。更明确地说,本发明涉及多个节点之间的电话会议,其中当发生对于所述会议的改变时,每个节点仅将所述改变仅传达到受所述改变影响的节点。
背景技术
在显示布局方面,在常规的基于MCU的电话会议中,MCU控制每个参与者上的视频流的布局。事实上,MCU向所有参与者发送相同的图像。举例来说,在具有10个参与者的电话会议中,MCU将选取任何四者(比如说,B、C、D、E),且用B、C、D和E形成合成图像(可能如同好莱坞框框(Hollywood squares)),并将其发送到所有参与者。
在ViPr中,此模式已扩展到每个参与者可个别地独立选择布局。因此,A可将两者作为大视频来观看(例如,B和C)且将其他七者作为小视频来观看。B可选取一个大视频、三个小视频和TV频道作为其显示。
在协议方面,考虑具有10个参与者的电话会议。在传统信令协议中,当在会议状态中存在改变时,举例来说,如果P1禁用其视频,过去会发送针对所有参与方P1到P10的具有信息的消息;这造成严重的可扩展性问题。本发明提供一种以有效方式控制非常大规模的电话会议(具有几百参与者)的技术。凭借所述技术,仅需要发送差异,举例来说,在上文提及的情况下,发送带有信息(P1已关闭其发射器)的小NOTIFY事件。
发明内容
本发明涉及一种电话会议系统。所述系统包含网络。所述系统包含多个节点,其彼此通信以形成优选地在每个节点处的实况场景的会议。每个节点具有带有显示布局的视频显示器,所述节点中的至少一者个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
本发明涉及一种用于提供电话会议的方法。所述方法包含以下步骤:用通过网络彼此通信的多个节点形成优选地在每个节点处的实况场景的会议。每个节点具有带有显示布局的视频显示器。存在以下步骤:用所述节点中的至少一者个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
本发明关于一种用于具有其它节点的网络的电话会议节点。所述节点包含网络接口,其与所述其它节点通信以形成优选地在每个节点处的实况场景的会议。所述节点包含控制器,其个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
本发明关于一种电话会议系统。所述系统包含网络。所述系统包含多个节点,其通过所述网络彼此通信以形成优选地在每个节点处的实况场景的会议。当发生改变时,每个节点仅将所述改变传达到其它节点。
本发明关于一种用于在至少三个节点(举例来说,参与方)之间进行电话会议的方法。所述方法包含以下步骤:在所述节点之间建立优选地在每个节点处的实况场景的会议。存在对所述会议作出改变的步骤。存在仅将所述改变传达到优选地在每个节点处的实况场景的节点的步骤。
本发明关于一种用于具有其它节点的网络的电话会议节点。所述节点包含网络接口,其与所述其它节点通信以形成优选地在每个节点处的实况场景的会议。所述节点包含控制器,当发生改变时,所述控制器仅将所述改变传达到其它节点。
有效控制大量会议参与者的能力是非常需要的。对于低带宽链路来说,可能尤其是这样的。另外,这还减少了中间节点处理,因为只需要交换小得多的消息。
附图说明
在附图中说明本发明的优选实施例和实践本发明的优选方法,其中:
图1是用于本发明的系统的示意性表示。
图2是用于本发明的网络的示意性表示。
图3是连接到PC和网络的视频电话的示意性表示。
图4是用于本发明的系统的示意性表示。
图5a和图5b是视频电话的前视图和侧视图的示意性表示。
图6是视频电话的连接面板的示意性表示。
图7是用于视频电话的多屏幕配置的示意性表示。
图8是视频电话的方框图。
图9是视频电话结构的方框图。
图10是系统的示意性表示。
图11是系统的示意性表示。
图12是本发明系统的示意性表示。
图13是本发明另一系统的示意性表示。
图14是本发明音频混合器的示意性表示。
图15是混合器结构的方框图。
图16是SBU的方框图。
图17是视频电话会议中的视频电话UAM的示意性表示。
图18是双向电话呼叫中的视频电话UAM的示意性表示。
图19是用于混合器的网络的示意性表示。
图20是本发明的方框图。
图21是展示若干节点的本发明的方框图。
图22是本发明的方框图。
具体实施方式
现参看附图,其中在所述若干视图中相同参考符号始终指代相似或相同部分,且更特定地参看图20和21,其展示电话会议系统10。所述系统10包含网络40。所述系统10包含多个节点,其彼此通信以形成优选地在每个节点处的实况场景的会议。每个节点具有带有显示布局的视频显示器54,所述节点中的至少一者个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
优选地,迫使每个节点以所述特定格式显示视频。每个节点优选地被锁定到所述特定格式。优选地,迫使每个节点在显示器上的特定位置处显示来自所述会议的其它节点的特定视频流。每个节点优选地控制在屏幕中不由所述节点中的所述一者控制的任何部分上显示什么。优选地,所述节点中的所述一者完全控制每个节点的显示布局。
本发明涉及一种用于提供电话会议的方法。所述方法包含以下步骤:用通过网络40彼此通信的多个节点形成优选地在每个节点处的实况场景的会议。每个节点具有带有显示布局的视频显示器54。存在以下步骤:用所述节点中的至少一者个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
本发明关于一种用于具有其它节点的网络40的电话会议节点。所述节点包含网络接口42,其与所述其它节点通信以形成优选地在每个节点处的实况场景的实况会议。所述节点包含控制器19,其个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
在本发明的操作中,本发明提供一种用以从会议参与者中的一者控制个别会议参与者屏幕的布局的技术。举例来说,如果在电话会议中存在参与者P1到P10,那么所述参与者中的一者可成为主持者,且迫使P2以大视频观看(P1和P5)且迫使其余参与者以小视频观看每个参与者的各别实况场景。以此方式,可个别地控制每一方的显示。
此布局控制可在个别窗口而并非整个屏幕上执行,以提供对屏幕上非管理窗口的个性化控制。
远程方可控制每个会议参与者的屏幕布局。通常,主持者将迫使所有方与所述主持者使用相同的布局。然而,可能存在这样的情况,其中细粒度控制可能准许对会议参与者的子部分实施次级主持者控制。
布局控制机制产生布局消息,所述布局消息含有会议参与者的所需屏幕布局。所述布局消息还含有应接收此消息的参与者的列表。接着经由SIP NOTIFY事件将此布局消息发送到会议中心(conference focus)或主机。所述会议中心接着将把此消息添加到此列表中含有的每一方的传出消息队列。所述中心接着将在处理每一方的所有排队事件时发送此消息。当所述消息被发送至特定方及由特定方接收时,所述方将修改其屏幕布局以与所述消息中含有的请求匹配。如果屏幕布局的改变要求所述参与方连接到新媒体流或与其断开,那么所述参与方将发布恰当事件以作出所请求的改变。
在本发明中,已添加了允许用户或一组用户(主持者/多个主持者)个别地控制会议中每个ViPr视频电话上的显示布局的功能性。此控制可以是部分的或完全的。在完全控制显示布局格式中,迫使会议中的每个参与者以特定格式显示视频。这有点像MCU,然而,不同之处是每个参与者可锁定于不同格式。但一旦参与者被锁定于给定格式,其便不能对会议呼叫的显示布局进行控制。举例来说,A可锁定为显示来自C、D和E的实况场景的3个大视频和来自F、G、H、I、J、K的6个小视频。
在部分控制显示格式中,指令每个参与者在特定位置处显示特定流。但其对于在屏幕的剩余部分上显示什么具有控制。举例来说,可指令A在其左边的大视频中显示B。然而,A可选择显示1、2还是3个大视频。类似地,所述方案可用于音频/小视频。
布局控制消息被作为SIP/NOTIFY消息来发送,尽管其“可”经由其它SIP或HTTP方式来发送。
在“典型”ViPr电话会议中,每个终端被提供来自通话中每个其它参与者的所有可用音频和视频流。位于每个终端处的每个用户通常会让本地终端自动地将每个视频依次放置在屏幕上。接着,用户能够手动地进行挑选以选择所述参与方视频中的哪些在屏幕上被展示为大视频或小视频窗口。
如果通话参与者想要主持所述通话,那么他们可使用“布局控制”特征来向其它终端中的一些或所有设置限制。这些限制可包括哪些参与者显示为大视频窗口。它们还可控制将所述小视频窗口中的哪些锁定到特定参与者。可将所述限制规定为强制或可选的,其又规定参与者是否可推翻主持者的选择。布局控制还可用于控制次要图像在屏幕上的布置。布局控制还可控制屏幕上任何次要图像的大小。布局控制还可控制远程参与方的音频无声和远程参与方在希望获得发言权且不再静默时请求发言权的能力。
含有布局控制选项的SIP/NOTIFY消息被发送到会议主机,且接着会议主机将此消息分发到所有其他参与方。
会议主持者使用标准SIP/SDP“a=Rx-List:A B C”机制来规定会议主持者正显示哪些参与方,其中“A B C”代表正被观看的远程参与方的识别符。当以会议主持模式进行操作时,这些均被处理为“可选”布局位置,除非“m”被附加到所述参与方,例如“AmBm Cm”。所述“m”是强制标记,且告知远程用户接口“必须”将哪些参与方锁定到屏幕上的位置中。如果用户接口希望启用此,那么可选参与方仍然可由每个远程终端独立改变。用户接口可对会议执行“所有强制”模式,在此情况下,当在有主持会议中操作时,所有参与方被处理为强制的。
将名为“主持者布局”的事件用于识别用来控制屏幕的其它方面的布局控制消息。用于控制次要视频和图像大小的可选字符串关键字分别是“chan_size”和“col_size”。名为“发言权请求”和“发言权撤消”的事件用于告知主持者:一方想要获得发言权或希望撤消其请求。名为“发言权准予”的事件由主持者发送到参与方,以通知他们:他们已被解除静默且现在可以说话。终端用户接口将注意这些事件中的每一者,并根据会议主持者的指引来控制屏幕。
以下申请案均以引用方式并入本文中:
题为“VIDEOPHONE AND METHOD FOR A VIDEO CALL”的第10/114,402号美国专利申请案
题为“AUDIO MIXER AND METHOD”的第10/871,852号美国专利申请案
题为“METHOD AND APPARATUS FOR CONFERENCING WITH STREAM”的第11/078,193号美国专利申请案
节点可包括会议的成员、参与方、终端或参与者。会议通常包含至少三个节点,且可具有10或20或者甚至50或100或150或更多节点。
现参看附图,其中在所述若干视图中相同参考符号始终指代相似或相同部分,且更特定地参看图22,其展示一种电话会议系统10。所述系统10包含网络40。所述系统10包含多个节点,其经由所述网络40彼此通信以形成优选地在每个节点处的实况场景的会议。当发生改变时,每个节点仅将所述改变发送到其它节点。
优选地,每个节点仅将所述改变仅发送到受所述改变影响的参与方。
本发明关于一种用于在至少三个节点(例如,参与方)之间进行电话会议的方法。所述方法包含以下步骤:在所述节点之间建立优选地在每个节点处的实况场景的实况会议。存在对会议作出改变的步骤。存在仅将所述改变传达到所述节点的步骤。
优选地,所述传达步骤包括以下步骤:仅将所述改变仅传达到受所述改变影响的节点。所述改变步骤优选地包括以下步骤:对所述节点中的一者的状态作出改变。优选地,所述改变步骤包括以下步骤:对会议状态作出改变。优选地存在以下步骤:将来自所述节点中的一者的定向消息仅发送到并非全部的某些节。优选地,所述建立步骤包括以下步骤:基于SIP NOTIFY/OK技术来建立会议。
对会议的所述改变优选地包括对所述节点中的一者的状态的改变。优选地,对会议的所述改变包括对会议状态的改变。所述节点中的一者将定向消息仅发送到少于全部的某些节点。优选地,所述多个节点基于SIP NOTIFY/OK技术来建立会议。每个节点优选地具有控制器19和网络接口42,所述网络接口42与控制器19和网络40通信。控制器19对其节点作出任何改变且通过网络接口42且接着通过网络40将所述改变发送到所述会议的其它节点。
本发明关于一种用于具有其它节点的网络40的电话会议节点。所述节点包含网络接口42,其与所述其它节点通信以形成优选地在每个节点处的实况场景的实况会议。所述节点包括控制器19,当发生改变时,控制器19仅将所述改变传达到其它节点。
在优选实施例的操作中,大型会议控制机制使用会议控制消息来管理受到呼叫的所有参与方。参与者产生会议控制消息,其含有所传输流性质和来自其它会议参与者的接收流的所需列表。此会议控制消息接着经由SIP NOTIFY事件而被发送到会议中心或主机。所述会议中心接着将把此消息添加到受此消息影响的每一方的传出消息队列。所述中心接着将在处理每一方的所有排队事件时发送这些消息。当所述消息被发送到特定方及由特定方接收时,所述参与方将把请求方添加到其传出流列表。也可发送会议控制消息以指示将视频流设为“保持”或解除“保持”的需要以控制仅语音操作。
大型会议信令创造
ViPr会议先前是基于提供/应答模型。在此模型中,在会议参与者之间交换的每个消息中携带会议的完全状态。举例来说,考虑5个参与者P1到P5之间的会议。在此情况下,这五方将经由称为主机的中心点而连接成会议。所述主机将形成含有会议的完全状态的表格。例如,如果参与方P1到P3发射/接收视频/音频,且参与方P2和P3仅发射/接收仅音频,那么此表格会指示所述完全状态。每当在会议中发生任何改变时,主机将重新计算所述表格并将所述消息发送给每一方。举例来说,如果P3停止发射视频,那么其会将表格1改变为表格2,且将所述整个表格发送到每一方。
P1 视频(发射=开,接收=开),音频(发射=开,接收=开)
P2 视频(发射=开,接收=开),音频(发射=开,接收=开)
P3 视频(发射=开,接收=开),音频(发射=开,接收=开)
P4 视频(发射=关,接收=开),音频(发射=开,接收=开)
P5 视频(发射=关,接收=开),音频(发射=开,接收=开)
表格1
 P1 视频(发射=开,接收=开),音频(发射=开,接收=开)
视频(发射=开,接收=开),音频(发射=开,接收=开)
视频(发射=开,接收=关),音频(发射=开,接收=开)
P4 视频(发射=关,接收=开),音频(发射=开,接收=开)
视频(发射=关,接收=开),音频(发射=开,接收=开)
表格2
此方案可很好地起作用,因为其符合现存SIP标准且允许向基本SIP协议添加扩展来实现ViPr风格会议。
如果会议中的参与者的数目小于15左右,那么此方案可很好地起作用,但超过此数目时,含有所有参与方的所述表格会变得太大而不能被有效地分发。另外,并非每一方均受会议状态中的每个变化的影响——且使其淹没在其不需要处理的消息中是不必要的。此模式的另一问题在于其不提供在两个SIP对等体之间发送应用层非媒体相关消息的能力。
为了补救以上问题,我们发明了此新方案。在此新方案中,已作出以下关键改变:
$会议状态可在两个方面改变。即,参与者之一请求其状态的改变(参与方本地),或参与方之一请求整个会议状态的改变(全局改变)。每当作出任何此类改变时,在会议参与者之间仅传达特定针对被改变的参与方或全局会议状态的信息。为了使用来自表格2的实例,将仅发送对应于P3的信息,而并非整个表格。[因此,仅将涉及p3的行重新发送到其它参与者]。全局事件的实例:
-->会议名称改变
-->会议主持者状态改变
-->发言权请求状态改变
-->会议类型改变
-->会议状态消息(一方被拒绝加入会议等)
参与方事件的实例
-->参与方开关相机
-->参与方切换保持状态
-->参与方删除
-->参与方添加
-->参与方状态改变(成为主持者/放弃主持者身份)
-->参与方请求接收媒体流的改变
$只有受所述改变影响的参与方接收已改变的信息。
$能够从参与方P1将定向消息发送到任何数目的参与方。举例来说,P1可请求主机将消息转继到P2、P3和P4。但不转继到P5。这最后一个功能性对于在会议中实现基于群组的信令是重要的。
所述新设计是基于SIP NOTIFY/OK方法,且定义新事件包。RFC 3261和RFC 3264标准为SIP定义基础规范。RFC 3265定义使用事件的框架,其两者均以引用方式并入本文中。
举例来说,对于ViPr会议,总是需要主机。事实上,会议中各方并非一直相互直接发信号。举例来说,如果在A、B和C之间存在电话会议。就存在三个SIP呼叫支路
--主机到A
--主机到B
--主机到C
媒体直接在A、B和C之间流动。
在本发明中,B目前正从A接收视频,且现希望还从C接收视频。可以两种方式中的任一者来传达此改变。
-B向主机发送NOTIFY,其中NOTIFY中的一个字段[称为目标方列表:C]指示此消息仅可发送到C。
-或者,主机可检测到此消息仅影响C且可将所述消息仅发送到C,尽管B尚未被明确地放置在任何此类字段中。
视频电话
参看图8、9、10和11,成像装置30(例如由Sony提供的具有S视频的常规模拟相机32)将来自成像装置30的场景图像转换为电信号,所述电信号沿着导线发送到视频解码器34(例如Philips SAA7114 NTSC/PAL/解码器)。视频解码器34将所述电信号转换为数字信号,并将其作为场景的像素流发送出去(例如在BT 656格式下)。所述像素流被从视频解码器34中发送出去,且被分裂成第一流和与第一流相同的第二流。编码器36(优选地,IBM eNV 420编码器)接收第一像素流,对所述第一流进行操作,且产生MPEG-2格式的数据流。与在相机中产生时的数据相比,由视频编码器36产生的数据流的大小被压缩约1/50。MPEG-2流是经编码的数字流,且在随后被分包之前不受到帧缓冲以便最小化任何延迟。使用RTP通过现场可编程门阵列(FPGA)38和向其提供MPEG-2流的软件来对经编码的MPEG-2数字流进行分包,且使用网络接口42经由PLX 9054 PCI接口44以155兆位每秒的速率将所述MPEG-2数字流传输到网络40(例如以太网802.p或ATM)上。如果需要,可由解码器34接收与VCR或电视节目(例如CNN或电影)相关联的视频流,且将其直接提供到显示器控制器52以供显示。位于FPGA 38中且连接到解码器34的解码器控制器46控制解码器34的操作。
或者,如果使用数码相机47,那么由所述相机产生的所得流已经是数字格式且不需要提供到解码器34。来自数码相机47的数字流(其具有BT 656格式)被分裂成第一和第二流,所述第一和第二流直接来自相机而不穿过任何视频解码器34。
在另一替代方案中,火线相机(fire wire camera)48(例如1394接口火线相机48)可用于将数字信号直接提供到FPGA 38。所述火线相机48提供以下优点:如果数据流的产生将在距FPGA 38非常短的距离以外的任何地方,那么可在此较长距离上通过(例如)从火线相机48布电缆来支持所述数字信号。FPGA 38将来自火线相机48的数字信号提供到编码器36以进行处理(如上文所述),且还创建低帧速率流(如下文所述)。
将第二流提供到FPGA 38,其中FPGA 38和软件产生低帧速率流(例如运动JPEG流),与第一流相比,这需要低带宽。FPGA 38和具有软件的主控制器50对此低帧速率流执行编码、压缩和分包,并将其提供到PCI接口44,所述PCI接口44又将其通过网络接口卡56传送到网络接口42以供传输到网络40上。经编码的MPEG-2数字流和低帧速率流是两个基本相同但独立的数据流,不同之处只是与MPEG-2数据流相比,所述低帧速率数据流被按比例缩小,以提供相对于MPEG-2数据流的相同场景的较小视图,且要求网络40的较少资源。
在网络40上,每个数字流被载送到所需的接收器视频电话15,或如果涉及具有两个以上参与方的会议,那么载送到多个接收器视频电话15。使用SIP来路由所述数据。接收视频电话15的网络接口卡56接收与第一和第二数据流相关联的包,且将来自所述包的数据和由主控制器选择的视频流(第一或第二)提供到接收存储器。具有软件的接收视频电话15的主控制器50对所选择的所接收数据流进行解码和扩展,并将其传送到显示器控制器52。显示器控制器52使用标准缩放硬件在VGA数字平板显示器上显示重建的图像。接收视频电话15处的用户可用触摸屏74选择观看所述两个数据流中的哪个流,或如果需要的话,选择两者,以便显示所述场景的大图像和小图像,尽管一般不会发生显示来自发射视频电话15的两个流的情况。下文论述用于显示的协议。通过具有选择场景的较大视图或场景的较小视图的选择权,用户能够分配系统10的资源,以便可选择此刻对于观看者来说以较大且较清楚图片进行观看较为重要的个别图像;同时,仍然可以看到用户仍想看但在那时不重要的那些图像。
如果存在一个以上图像(如果发生电话会议),那么显示器控制器52造成每个独特视频流并排呈现在显示器54上。对并排形成在显示器54上的图像进行裁剪而并非按比例缩小,所以场景中对象的尺寸本身没有受到改变,只是移除了与每个数据流相关联的场景的每一侧上的外部范围。如果需要,可在显示器54屏幕的右下角并排显示来自与较小场景图像相关联的流的图像。显示器控制器52向LCD控制器72提供标准数字视频,如图9所示。由ATI或Nvidia生产的显示器控制器52是标准VGA控制器。LCD控制器72自显示器控制器52获得标准化数字视频,且使得图像适合于所使用的特定面板(例如用于Fujistu面板的Philips)。
为了进一步增强图像的裁剪,代替简单地从外部边缘开始且朝向中心移动来移除图像的若干部分,裁剪图像的不展示相关信息的部分。如果正在讲话的个人出现在图像的左侧或右侧上,那么需要在所述个人在图像右侧时从左侧向内进行裁剪,或者在所述个人在图像左侧上时从右侧向内进行裁剪,而并非仅从每个外部边缘向内进行裁剪,从每个外部边缘向内进行裁剪会造成丢失所述个人的一部分。对视频追踪的使用可查看所形成的图像,并分析在图像哪处发生改变以识别个人位于图像的哪处。假定所述个人将相对于图像的其它区域较多地进行移动,且通过识别所述相对移动,可确定所述个人在图像中的位置。根据此视频追踪,可使得裁剪发生在存在最少量改变的边缘处。或者,或结合视频追踪,也可使用音频追踪来引导所发生的图像裁剪。由于视频电话15具有麦克风阵列,基于给定声音到达麦克风阵列的不同元件所花费的不同时间的标准三角测量技术可用于确定所述个人相对于所述麦克风阵列位于何处,且由于知道麦克风阵列相对于正被成像的场景的位置,因而得知所述个人在图像中的位置。
视频电话15的功能性由监视器上的触摸屏74控制。所述触摸屏74(其为标准玻璃触摸屏)向触摸屏控制器76提供原始信号。当用户在给定位置处触摸玻璃时,由在玻璃上产生的超声波感测所述原始信号,正如此项技术中众所周知。触摸屏控制器76接着获取原始信号,并将其转换为关于在显示器上的X和Y位置的有意义信息,且将此信息传递到主控制器50。
如果电视或VCR连接可用,那么将电视或电影的馈入信号提供到解码器34,其中如同由视频电话15接收的任何其它视频信号那样来控制所述馈入。电视或电影可在显示器54上呈现在来自与另一视频电话15的视频连接的场景的旁边。
所述场景的音频流基本上沿着与音频视频流平行及相似的路径,不同之处只是从音频接收器58(所述音频接收器58例如麦克风、声卡、耳机(headset)或手持话机(handset))提供音频流到CS晶体4201音频接口60或例如执行信号的模拟到数字和数字模拟转换以及控制音量和混合的编解码器,其对音频信号进行数字化并将其提供到TCI 320C6711或6205 DSP 62。DSP 62接着对数字化音频流进行分包,且将所述数字化音频流传送到FPGA38。FRGA 38又将其提供到PCI接口44,在所述PCI接口44处接着将其传递到网络接口卡56以在网络40上进行传输。由接收视频电话15接收到的音频流被传递到FRGA 38且继续传递到DSP 62上,且接着传递到音频接口60,所述音频接口60将所述数字信号转换为模拟信号以供在扬声器64上进行播放。
网络接口卡56对传输到网络40的每个音频包和视频包印时戳。处理由视频电话15接收到的音频和视频的速度较快,足以使人眼和人耳在听到其时不能分辨出音频与所述场景的在时间上相关联的视频的任何未对准。对于场景的音频和视频信息的处理设置小于20-30毫秒的限制,以维持所述场景的视频与音频的此关联性。为了确保当在接收视频电话15处接收到时场景的音频和视频是同步的,检查每个包的时戳,且相应的基于音频的包和基于视频的包由接收视频电话15对准并相应地基本上同时进行播放,所以接收器视频电话15处不存在用户可辨别的场景的视频和音频的不对准。
ENC-DSP板含有IBM eNV 420 MPEG-2编码器和支持电路、用于音频编码和解码的DSP 62,和PCI接口44。在具有高性能PC 68平台和显示器54系统10时,其含有实现全部视频电话15终端功能性所必须的硬件。这是适应全尺寸PCI 2.2的设计。相机、麦克风和扬声器64介接到此板。DSP 62将执行音频编码、解码、混合、立体声布置、电平控制、间隙填补、分包和其它音频功能,例如立体AEC、射束控制、噪声消除、键盘敲击声消除和去混响。EPGA 38通过使用Celoxia(Handel-C)工具来开发,且是完全可重配置的。布局支持在1-3百万个门电路范围内的零件。
此板包括数码相机47芯片接口、硬件或基于“视频DSP”的多通道视频解码器34接口,使用DVI输入和输出连接器的视频叠加,视频叠加具有高达完全无音帧(full dumbframe)缓冲能力。
使用NTSC或PAL视频信号,编码器36应产生640×480且优选地720×480或更佳分辨率的高质量视频流。应控制位速率,以使得限制每帧的最大位数,以便防止经由网络40的传输延迟。解码器34必须在接收到第一数据宏区块时开始对片段进行解码。需要某种缓冲来适应微小抖动且从而改进图片。
广泛使用并部署MPEG-2,这是DVD和VCD编码、数字VCR和时间移位装置(例如TiVo)以及DSS和其它数字TV推广的基础。其通常被认为是对于4到50兆位/秒视频传输的最适合选择。因为它的广泛使用,现在市场上可购买到相对较低成本且高度集成的解码和(最近些年来)编码解决方案。
应将MPEG-2考虑作为用于编码视频的句法而并非标准压缩方法。尽管本说明书定义所述句法和编码方法,但在使用所述方法中存在非常宽的自由,只要遵循所定义的句法便可。出于此原因,关于MPEG-2的概括通常是令人误解的或不准确的。必须深入到特定编码方法和预期应用的较低细节水平,以便针对特定应用估计MPEG-2的性能。
对视频电话15项目有意义的是低延迟编码和解码的问题以及与网络40有关的问题。在MPEG-2算法中存在三个主要问题需要理解以在网络40上达成低延迟高质量视频:
Figure A20071010674500161
GOP(图片群组)结构和其对延迟的作用
Figure A20071010674500162
位速率、编码帧大小变化和VBV缓冲器对延迟和网络40要求的影响
GOP结构对具有包损失的质量的影响
GOP结构和延迟:
MPEG-2定义三种编码帧:I、P和B。使用中最常见的GOP结构为16帧长:IPBBPBBPBBPBBPBB。此结构的问题在于由于B帧是从先前和随后帧估计得到的运动,每个连续B帧需要在可开始编码所述B帧之前俘获随后帧。当每个帧为33毫秒时,这(与没有B帧的结构相比)为GOP结构添加了最少66毫秒的额外延迟。这导致仅含有I和/或P帧的低延迟GOP结构,这在MPEG-2规范中界定为SP@ML(简单轮廓)编码。
位速率、编码帧大小和VBV
一旦消除B帧以最小化编码延迟,GOP就由I帧和与I帧相关的P帧组成。因为I帧完全是帧内编码的,所以使用大量位来做此事,且对于随后P帧使用较少位。
应注意到I帧可为P帧的8倍大,且为标称位速率的5倍。这对网络40要求和延迟具有直接影响:如果存在带宽限制,I帧将在网络40限制下受到缓冲,从而导致对经由受限区段的传送增加多个帧时间的延迟。此缓冲必须在接收器处匹配,因为播放速率由视频设置,而并非由网络40带宽设置。用于以上数据的样本为低运动办公室场景;在具有场景改变的高运动内容中,取决于内容而定,帧将被分配更多或更少的位,其中在场景改变处发生一些较大的P帧。
为控制此特性,MPGE-2实施VBV缓冲器(视频缓冲验证器),其允许对最大编码帧大小与标称位速率之间的比率进行某程度的控制。通过严密约束VBV使得将I帧限制为小于由标称位速率指示的大小的2倍,可将添加的缓冲延迟限制为1个额外帧时间。限制VBV大小的代价是图片质量:引入较大I帧的原因是为随后P帧提供良好基础,且当I帧的大小受到约束时,在较低位速率(<4兆位)下图片质量受到严重降级。考虑在2兆位下,平均帧大小为8千字节,且甚至此大小的2倍也不足以用优良质量来编码320×240JPEG图像,其类似于I帧受到DCT压缩。
借助于仅I帧编码可实现更一致的编码帧大小,但会进一步降级质量。低位速率的仅I帧编码没有利用MPEG-2算法的大部分压缩能力。
MPEG-2规范定义了CBR(固定位速率)和VBR(可变位速率)模式,且允许流内的可变GOP结构。定义CBR模式以针对每个GOP产生一致数目的位,必要时使用填充。期望将VBR用以通过允许编码带宽的变化,从而准许所述流向难以编码的区域分配较多位(只要这可由较简单区段中的较低位速率进行补偿)来实现一致质量。VBR可由两次通过或单次通过技术实施。可变GOP结构允许(例如)将I帧放置在场景过渡边界处来消除可见的压缩假像。由于低延迟要求和对向前查看少许位以便实施VBR或可变GOP的需要,这些模式对于视频电话15应用具有很少利益。
因为典型GOP结构中的P和B帧依赖于I帧和在前的P和B帧,所以数据损失影响错误之后且直到下一I帧的所有帧。这还影响启动等待时间,例如当在DSS系统10上变换通道时所发生的,其中解码器34在能开始显示图像之前等待I帧。出于此原因,必须针对应用和传递系统10对GOP长度、结构和位速率进行调节。在使用IP的实时协作的情况下,使用不可靠的传送协议(例如RTP或UDP),因为必须将迟到的包视为丢失的,这是由于无法承受处理可靠协议握手和重传输所需的延迟。已对包损失对视频质量的影响作了各种分析,结果展示,对于典型IPB GOP结构,1%的包损失导致30%的帧损失。较短的GOP结构且最终仅I帧流(具有质量损失)对此有些帮助,且FEC(前向错误校正)技术可在发生损失时具有很少帮助,但当然MPEG-2的一个问题在于它对数据损失的容许度不高。
被称为连续P帧编码的GOP结构解决了所有前述问题,且以相对较低的位速率为视频电话15提供极佳的视频质量。连续P编码在P帧内利用了帧间编码帧的宏区块的能力。通过编码每个帧中的16×16像素宏区块的伪随机组且运动编码其它,I帧的位的等效物分布在每个帧中。通过实施伪随机宏区块选择来确保频繁地更新所有块,可以合理的方式处理启动和场景改变。
IBM已针对S420编码器实施了此算法,将整个帧DCT更新速率设置为8个帧(每秒3.75次)。用于典型办公室和会议内容时的结果给人的印象非常深刻。对于视频电话15来说,编码延迟、编码帧大小变化和包损失特性几乎是理想的。对编码样本的检查展示,对于场景改变和高动态内容,编码器36假像是明显的,但对于典型讲话者协作内容,质量非常好。
高质量音频是有效通信的基本先决条件。高质量被定义为全双工、7kHz带宽(电话为3.2kHz)、>30dB信噪比、没有可感知回声、切断或失真。安装将非常简单,涉及尽可能少的电缆。板上诊断将指示所述问题和如何解决其。来自扬声器64的声音将不会有高声砰响和轰鸣以及过高或过低的音量。
可基于先前音频信号对来自丢失或迟到的包的音频信号进行“填补”。由于网络40抖动与向音频添加延迟之间的平衡,音频缓冲器应为约50ms。可减少320样本或20ms的当前包大小来减小编码和解码等待时间。然而,20ms是RTP包的标准数据长度。
在商品中可使用下文描述的某些过程。然而,出于成本和集成原因,它们将在DSP 62上进行实施。在另一实施例中,第二DSP 62也可执行声响回声消除,而并非仅一个DSP62执行此功能。
音频系统10具有发射和接收部分。发射部分由以下各项组成:
麦克风
扬声器电话的主要不足之一是在远端处听到的有回响的声音。此有回响的声音是由于室内混响的缘故,且最好被认为是反射(混响)声音功率与直接声音功率的比率。目前,改进拾音的最好方法是将麦克风定位在靠近讲话者处且因此增加直接声音功率。在办公室环境下,麦克风可定位在PC 68监视器处、在视频电话15终端上和在白板处。
自动增益控制
自动调节每个麦克风的前置放大器的增益,以使得完全使用ADC范围。将必须把前置放大器增益发送到其它音频过程,例如AEC和噪声降低。
编解码器
在其最简单形式中,这是ADC装置。然而,若干公司(例如Texas Instruments andAnalog Devices Inc)具有带有模拟放大器和模拟多路复用器的编解码器。并且,驻留在芯片上的是具有类似控制的DAC。在先前部分中描述的自动增益控制在所述编解码器中实施且由DSP 62控制。
噪声降低
可使用两种噪声降低方法来改进SNR。第一种方法通常被称为噪声选通,其依据存在的信号电平来接通和断开通道。第二种方法是自适应噪声消除(ANC)且从麦克风信号中减去不想要的噪声。在办公室环境中,可能会使用ANC来移除PA通知、风扇噪声,且在某些情况下,甚至移除键盘敲击声。
可使用在商业音频编辑插件(例如Cold Edit和Goldwave)中的噪声降低或选通算法,其可施加特定效果、从记录中移除刮划和砰响噪声且还从磁带录音中移除嘶声。
声响回声消除
当讲话者的语音在超过50ms之后返回到讲话者时,听到回声。回声是非常令人分心的,且因此必须将其移除。两个回声源是线路回声和声响回声。线路回声是由于双线电话系统10的特征引起的。PSTN通过使用线路回声消除器(LEC)来移除此回声。当使用扬声器电话系统10时,在电话扬声器与麦克风之间发生声响回声。来自远程扬声器的声音由远程麦克风拾取并返回到讲话者。声响回声消除(AEC)比LEC困难,因为对室内声响进行建模是较为复杂的,且室内声响可随着人们移动而突然改变。存在多种AEC产品,从例如ASPI EF1210的独立装置到经优化以在DSP 62平台上运行的信号工作目标模块(Signal Works object modules)。
自动混合
自动混合选择将哪些麦克风信号混合在一起且将混合器的单耳输出发送到编码器36。选择标准是基于使用最高音量源附近的麦克风或使用接收高于阈值水平的声音的麦克风。自动混合器可从各个销售商处购得,且用于电话会议和电话教学系统。
编码
为降低数据传输带宽,通过利用典型的信号特征和我们对语音的感知来将音频信号压缩为较低位速率。目前,G.722编解码器以64千位/秒的合理位速率提供最佳音频质量(7kHz带宽@14位)。
RTP传输
将经编码的音频数据分割成20毫秒片断且作为实时协议(RTP)包发送。RTP是针对VoIP和电话会议应用所需的实时数据交换而特别设计的。
接收部分是:
RTP接收
将含有来自一个或一个以上远程位置的音频流的RTP包放置在其各自缓冲器中。检测到丢失或迟到的包,且将所述信息传递到间隙处理器。次序紊乱的包是迟到的包的特殊情况,且相同迟到的包有可能被丢弃。替代方案是用缓冲器来将音频信号的播放延迟至少一个包长度。将必须约束缓冲器的大小,以使得端到端延迟不长于100ms。
解码
将G.722音频流解码为用于编解码器的PCM样本。
间隙处理
经由任何网络,  RTP包将被丢失或破坏。因此,间隙处理器将基于先前包的频谱和统计数据来“填补”丢失数据。在最小程度上,应在数据流中填充零以组成数据,但可使用用以填补数据的频谱内插或外推算法。
缓冲
网络抖动将需要缓冲,以实现连续的音频播放。此缓冲器将可能基于短期抖动统计数据与等待时间影响之间的折衷来调节其大小(且因此,等待时间)。
速率控制
视频电话15终端的标称样本速率是16kHz。然而,将存在微小差异且需要对其进行处理。举例来说,假定视频电话15北端以正好16,001Hz进行取样,而视频电话15南端以15,999Hz进行取样。因此,南终端将每秒累积比其输出到扬声器的样本多的1个样本,且北终端将具有相等量的不足。关于接收缓冲器的长期统计数据将能够确定样本速率微分是多少,且可计算恰当的内插(对于视频电话15北端)或消去(对于视频电话15南端)因数。
音量控制
调节来自扬声器64的音量通常由远程收听者进行。较好的方式可能是基于其对于房间中的麦克风来说有多响来自动调节来自扬声器64的声音。可考虑其它因素(例如背景噪声和收听者的自身偏好)。
立体声布置
可将来自不同位置的远程讲话者布置在听觉域中。因此,来自位置A的个人将始终来自左边,来自位置B的个人始终来自中间,且来自位置C的个人始终来自右边。此布置使得更易于追踪谁正在讲话。
扬声器
声音的质量在某种程度上是由扬声器64和外壳的质量决定的。在任何情况下,将自动放大扬声器64用于视频电话15终端。
微分
本会议系统(例如PolyCom Soundstation)提供令人满意但带宽受限的全双工音频质量。然而,带宽被限制为3500Hz,且所得声音质量使听觉负担很重,且特别是辨别摩擦音时。
视频电话15将带宽延伸到7kHz,且自动混合多个麦克风,以最小化室内混响。当三人或三人以上正在讲话时,将远程参与者中的每一者放置在立体声音领域的唯一位置中。结合高质量音频拾取和增大的带宽,经由网络40的会议将非常近似于亲临其境的会议。
音频系统10使用多个麦克风来获得较好的声音拾取,且使用宽带编码器(G.722)来获得比当前由tollgrade系统提供的保真度好的保真度。另外,对于多方会议,将实施远程讲话者的立体声布置,且声响回声消除系统10用以实现自动操作。房间内的音量调节将由用于末端用户的单个控件自动控制,以调节整体声音水平。
在视频电话15网络40中,网关70将某些非SIP设备连接到SIP环境。通常存在电气差异以及协议差异。大多数网关70将其它电话或视频会议装置连接到视频电话15系统10。
网关70可由接口辨别;一侧是网络40,对于视频电话15来说,这是以太网或ATM。外侧可以是模拟电话线或RS-232端口。端口的类型、数目和特征将网关70彼此区分。在网络40侧,存在传送协议(例如RTP或AAL2)和信令协议(例如SIP、Megaco或MGCP)。
在外侧,可存在各种各样的协议,这取决于所提供的接口。某些实例将是ISDN(Q.931)或POTS信令。PSRN网关70将PSTN线路连接到现场的视频电话15系统10中。PBX网关70允许视频电话15系统10模仿专有电话来向现场的现有PBX提供兼容性。POTS网关70将无音模拟电话连接到视频电话15系统10。H.323网关70将H.323系统10连接到基于SIP的视频电话15系统10。这是仅信令网关70——媒体服务器66进行H.261到MPEG的转换。
三种用于实现视频电话15的技术是会话起始协议(SIP)、会话描述协议(SDP)和实时传送协议(RTP),所有这些协议以引用方式并入本文中。
SIP是用于起始、管理和终止经由包网络的语音和视频会话的信令协议。
SDP是用于出于会话通知、会话邀请和其它形式的多媒体会话起始目的来描述多媒体会话。SIP使用SDP来描述媒体会话。
RTP提供适用于经由多播或单播网络40服务而传输实时数据(例如音频、视频或模拟数据)的应用的端到端网络40传送功能。SIP使用RTP来进行媒体会话传送。
视频电话15可执行具有三方或三方以上的会议,而不使用任何会议桥或MCU。这通过使用由SIP建立的ATM点对多点流来完成。更明确地说,当MPEG-2流和低帧速率流经分包以传输到网络40上,每个包的标头信息识别会议的所有接收视频电话15的地址,正如此项技术中众所周知。根据此信息,当将包传输到网络40时,SIP为不同包建立必要连接性以到达它们所要达到的视频电话15目的地。
作为不使用任何会议桥的会议的实例,假设在考虑周到的位置处存在10个视频电话15(其是会议的参与方)。每个视频电话15产生基于音频的流、基于MPEG-2的流和基于低帧速率的流。然而,每个视频电话15将不把这些流中的任一者发送回到其本身,因此实际上,在视频电话15的10方会议中,每一者与其它九个视频电话15进行通信。情况可能是视频电话15与其本身进行通信来最大化带宽利用,但由任何视频电话15产生的视频且(如果需要的话)由视频电话15产生的音频可如同其实质上呈现于其它视频电话15一般被展示或听到(但通过内部通道),其将在下文中描述,因而不需要利用网络40的任何带宽。
在会议中,每个视频电话15接收九个基于音频的数据流、三个基于MPEG-2的数据流和六个基于低帧速率的数据流。如果需要的话,接收器可选择基于低帧速率的流中高达九个流,所以显示器54仅展示每个视频电话15的较小图像,或选择所述基于MPEG-2的流中的高达四个流,其中显示器54由来自所述会议的四个视频电话15的四个图像来填满,而不展示基于低帧速率的流的图像,这是由于如果显示四个基于MPEG-2的流,那么在显示器54上就没有用于基于低帧速率的流的空间。通过展示三个基于MPEG-2的流,这允许展示六个基于低帧速率的流。如上文解释的那样形成所述流中的每一者,且在各个视频电话15处如上文解释的那样接收所述流中的每一者。
如果需要显示会议的四个以上大图像,那么用以完成此的方式是将额外视频电话15连接在一起,使得并排排列不同视频电话15的显示器,如图7中展示。一个视频电话15可为主装置,且当添加每个额外视频电话时,其将成为所述主视频电话15的从属装置,所述主视频电话15控制所述不同视频电话15上的大图像和小图像的显示54。
在用以确定在会议的视频电话15的显示器上将谁展示为大图像和将谁展示为小图像的协议的方面,一个优选协议是将三个最近期讲话者显示为大图像,且将其它参与方显示为小图像。也就是说,将当前讲话的参与方和两个先前讲话者展示为大图像。由于会议的每个视频电话15接收会议的所有基于音频的流,因而具有其主控制器50的每个视频电话15可确定在给定时刻在何处发生讲话,并致使网络接口卡56接受与发生讲话的视频电话15相关联的MPEG-2流,而不接受相关联的低帧速率流。在另一协议中,将一个视频电话15建立为领导或主持者视频电话15,且所述领导视频电话15选择每个其它视频电话15看到的是大图像还是小图像。在又一协议中,关于谁是大且谁是小的图像选择是固定的,且在整个会议中始终保持相同。所述协议可以是每个视频电话15可挑选它们想如何展示它们接收到的图像。将基于MPEG-2的流和低帧速率流都传输到网络40上,以传输到会议的接收视频电话。因此,两种基于视频的流均可供每个接收视频电话15使用,以依据所选择的显示器54协议来展示。
就由每个视频电话15传输的基于音频的流来说,为了进一步有效使用带宽且通过减少对于任何发射视频电话15或接收视频电话15的处理需要来辅助音频处理,仅当有高于发射视频电话15处的预定分贝阈值的音频时,视频电话15才可传输基于音频的流。通过仅传输具有足够响的声音的基于音频的流,同时假定将把阈值校准为在发生讲话时得以满足或超过,这不仅消除了传送和接收外部背景噪声的必要(所述噪声基本上不起任何作用,但使用带宽),而且有助于选择与讲话相关联的MPEG-2流,因为仅接收具有讲话的音频流。
如上文提及,如果给定视频电话15需要看到其自身的图像(其正被发送到其它视频电话15),那么由FPGA 38形成的低帧速率流在没有任何压缩的情况下被发送到所述视频电话15中的本地存储器,如同将被分包并从视频电话15发送到网络40的低帧速率流的情况。从此本地存储器开始,具有软件的主处理器将对其进行操作,且将其在显示器54上展示为小图像。
此外,视频电话15提供对将听到或看到从网络40接收到的哪些音频或视频流的控制。在会议中除视频电话15的用户外还有其他参与方希望看见或听到的情况下,视频电话15的用户可选择只看见或只听见构成整个会议的视频流或音频流的一子组。举例来说,在100方会议中,对于可被展示的可能的100张图片中的总共23张图片,用户选择将所述视频流中的三者在屏幕上作为大图片观看,且将所述视频流中的20者在屏幕上作为小图像观看。视频电话15的用户选择将三个最大声的讲话者呈现为大图片,且接着通过触摸屏74选择会议中的参与方(其列出在触摸屏的页面上),将其也显示为小图片。可选择其它协议,例如展示为小图片的20个图片可以是从会议开始且每一方进行介绍起所述会议中的最近20个讲话者。通过控制所展示的视频流的数目,可赋予会议组织性,且视频电话15的资源利用得到更好的分配。
就展示在屏幕上的不同图片而言,选择可与每个图片相关联。举例来说,一个图片可由电话会议的主持者来选择,所述图片中的两者可基于在会议当前时间的最近/最响讲话者,且其它图片可与用户从会议的所有其他参与者中选出的个人相关联。以此方式,会议的每个参与者或用户可能看到自会议中的全部参与者选出的不同图片选择。那么需要的最大带宽是用于将一个视频流发送到网络和从网络接收四个视频流的带宽,而不管会议的参与者数目。
就音频流来说,可对视频电话15设定限制,使得仅将与三个最大声讲话者相关联的音频流选择为被听到,且同时将其各自图片展示在屏幕上。DSP 62可分析接收到的音频流,并仅允许播放与所述最大声讲话者相关联的三个音频流,且同时,指导网络接口42仅接收与具有最大声讲话者的三个音频流相关联的具有大图片的第一视频流。一般来说,同时讲话的人越多,就会发生越多混乱和越少理解。因此,用户对音频流实行控制,以给予其一定程度的组织性。
作为关于音频流的控制的一部分,如上文提及,每个视频电话15将仅在视频电话15周围的噪声高于阈值的情况下发送音频流。优选地,阈值是动态的,且基于在给定时间处与三个最大声讲话者相关联的三个最大声音频流的噪声水平。因为为了获得将被考虑为具有三个最大声讲话者的音频流中的一者的音频流,故接着必须在噪声水平方面监视和识别其它音频流的噪声水平。DSP 62在通过网络40从网络接口42接收音频流时检查音频流并识别具有最大噪声的三个流,且还将所述被识别为具有三个最大声讲话者的三个接收音频流的噪声水平与视频电话15周围的场景的噪声水平进行比较。如果来自视频电话15周围的场景的噪声水平高于接收到的任何一个音频流,那么视频电话15将其音频流发送到网络40。由DSP 62进行的此类型的独立分析发生在会议中的每个视频电话处,且因此是整个会议中的分布式分析。每个视频电话独立于所有其它视频电话而关于其接收到的音频流作出其自己的分析,所述音频流根据定义仅在各自视频电话15已确定其场景周围的噪声足够响来证明在给定时间其是三个最大声之一之后才由各自视频电话15发送出去。每个视频电话15接着获取此接收到的音频流信息,并将其用作比较其自身噪声水平的基础。每个视频电话15因此自己确定阈值。
执行此分布式分析的替代方式是每个视频电话在使用其DSP 62确定其认为阈值应为多少之后可将此阈值发送到会议的所有其它视频电话,所以所有视频电话均可检查所有其它视频电话认为阈值是多少,且可(例如)对所述阈值求平均值以识别其将应用于其场景的阈值。
通过使用选择三个最大声讲话者的视频流的技术,可存在各方均立即开始大声讲话并产生混乱和难以理解的时刻,但通过这样做,其提高了噪声的阈值水平,从而立即导致消除不与其它流产生一样多的噪声的音频流,以使得将再次仅选择和听到所述三个最大声讲话者的音频流而不选择其它,且因此移除其它音频流可能提供的某些噪声。这暗示着可存在由视频电话15接收到三个以上音频流的机会,因为三个以上视频电话可在给定时刻具有高于阈值的噪声水平,从而允许此类视频电话中的每一者在那时产生音频流且将其发送到网络40。然而,如刚才解释,一旦阈值发生改变,所述情况将停止。此关于音频流的分布式分析不限于本文描述的视频电话15,而是还可应用于任何类型的音频会议,无论是否也存在视频流。
与强调节约带宽使用相一致,且为了节约带宽而仅发送所必须的内容,裁剪图像发生在编码器36处而并非接收视频电话15处。在发射视频电话15知道其图像将如何呈现在接收视频电话15处的情况下,编码器36在传输场景的大图像之前对其进行裁剪,所以少得多的图像要被传输且利用到带宽。如果将在接收器视频电话15处发生剪裁,那么在将接收到的图像提供到显示器控制器52之前,具有软件的主处理器将对接收到的图像进行操作。
第二相机可连接到视频电话15以提供所述场景的替代性视图。举例来说,在房间内,可将第一相机或主要相机设置为聚焦在观看者或讲话者的脸部。然而,可在房间内存在额外个体,所述额外个体是在房间内控制视频电话15的个人希望展示给在接收视频电话15处的其他观看者的个体。举例来说,可将第二相机设置在所述房间的上角落中,使得所述第二相机可基本上比主要相机观看到所述房间的大得多的部分。可将第二相机的馈入信号提供到解码器34。解码器34具有若干端口来接收视频馈入。或者,如果来自第二相机的流已经被数字化,可通过与主要相机类似的通道将其提供到视频电话15的处理元件。优选地,每个视频电话15控制从其发送出去的任何内容,所以对将传输哪个相机馈入的选择由控制视频电话15的观看者决定。或者,可能向远程接收视频电话15提供控制和选择在给定视频电话15处来自哪个相机的哪个流将被传输的能力。来自控制视频电话15的控制信号将经由网络40传输,且由个别视频电话15接收,所述个别视频电话15接着将提供所选择的流以供传输。除了第二相机外,还可通过视频电话15提供任何其它类型的视频馈入,例如来自DVD、VCR或白板相机的视频馈入。
在优选实施例中,视频电话15以窥视模式进行操作。在所述窥视模式中,视频电话15相机拍取在其之前的场景的静止图像,且将此图像传输到其它视频电话15,所述其它视频电话15已先前被识别来接收所述图像,例如在其快速拨号菜单上的那些视频电话15。或者,在所述窥视模式中,将所拍取的静止图像维持在视频电话15处,且在请求时将其提供到希望呼叫所述视频电话15的任一者。理想地,如与视频电话15的优选使用一致,每个视频电话15用户控制从视频电话15发送出去的任何内容,且可简单地选择关闭所述窥视模式,或控制发送出什么图像。当发生有效呼叫时,关闭窥视模式,所以在窥视模式与相机拍取连续图像流的有效呼叫之间并不存在任何冲突。窥视模式可使得以预定时间间隔拍取场景的静止图像,例如以一分钟增量、五分钟增量、30分钟增量等。在窥视模式中,在拍取静止图像之前的预定时间(例如拍取图像之前的五或十秒)处,可提供可听队列来警告相机前面的任一者将要拍取图片且其应表现得体。可听队列可以是嘟声、咻声或其它记录的噪声或消息。以此方式,当使用窥视模式时,使得其它视频电话15可得到对视频电话15的相机之前的场景的窥视图像,且向其它视频电话15提供关于相机的人物存在的指示。
作为存在传感器的另一实例,在相机可充当存在传感器之前,相对于相机前的视场而定位相机的自动镜头。当在相机前面没有任何人时,那么相机的自动镜头将聚焦在位于其视场中的物体或墙壁上。当有人位于相机前面时,自动镜头将聚焦在所述人上,这将导致镜头位于与人不在镜头前面时不同的位置中。来自相机的指示镜头焦点的信号可从相机发送到FPGA 38,所述FPGA 38接着导致将焦点信息发送到预定列表的视频电话15接收器(例如在发射视频电话15的快速拨号列表上的那些),以告知接收视频电话15观看者是否在视频电话15前面以指示某人存在。
视频电话15还提供视频邮件。在所述情况下,试图从一个视频电话15向另一视频电话15进行视频呼叫,且接收视频电话15在预定时间(例如4次响铃)之后不应答所述视频呼叫,那么与接收视频电话15相关联的视频服务器66将对所述视频呼叫作出回应。视频服务器66将应答来自发射视频电话15的视频呼叫,且向发射视频电话15发送已记录的音频消息或来自未应答的接收视频电话15的具有已记录视频图像的音频消息,所述音频消息先前已被记录。视频服务器66将播放所述消息,并向呼叫者提供音频或音频及视频队列,以在预定指示(例如嘟声)之后留下它们的消息。当预定指示发生时,呼叫者接着将留下消息,所述消息将包括音频陈述以及呼叫者的视频图像。所述视频和音频消息将存储在视频服务器66处的存储器中。所述消息可如需要的那么长,或限制到消息被定义为的预定时间段。在所述预定时间段已过去或呼叫者已完成并终止呼叫之后,视频服务器66保存所述视频消息,且向未应答最初呼叫的接收视频电话15发送信号,所述信号指示存在等待接收视频电话15的观看者关注的视频消息。此消息可以是呈现在接收视频电话15的显示器54上的文本或视频图像,或仅仅是经激活以警告接收视频电话15的观看者他有视频邮件的消息灯。
当观看者希望观看视频邮件时,观看者可仅仅在触摸屏74上选择用来激活视频邮件的区域。向用户展现一系列邮件处理选项,包括阅读视频邮件,其向视频服务器66发送信号以在视频电话15显示器54上为观看者播放所述视频邮件。从视频服务器66发送的图像流遵循上文针对基于视频的流所解释的路径而到达并通过接收视频电话15以被显示。为了使视频电话15观看者在观看者不应答视频呼叫时将消息记录在视频服务器66上来回应视频呼叫,观看者触摸触摸屏74上的区域,其激活视频服务器66以在预定时间提醒观看者记录音频或音频及视频的消息,观看者接着将这样做来创建消息。
视频电话15提供了以预定水平操作扬声器64,而用户不必进行任何音量控制。视频电话15的扬声器64可用麦克风来校准,使得如果麦克风拾取太响的噪声,那么主控制器50和DSP 62会降低扬声器64的音频输出水平来减少噪声水平。通过设置预定和所需水平,视频电话15自动控制音量的大小而观看者不必做任何事。
视频电话15可经编程以辨认对特定个人说话的查询,且接着在接收视频电话15处将用于辨认的预定语言型式用作为音调或信号来通知在接收视频电话15处的观看者:正在向所述接收视频电话15请求呼叫。举例来说,短语“Hey Craig”可用于视频电话15来辨认将用发射视频电话15向Craig发起呼叫。观看者通过说“Hey Craig”而导致发射视频电话自动向Craig发起呼叫,其接着将短语“Hey Craig”发送到Craig的接收视频电话15。Craig的接收视频电话15不再响铃来指示正向Craig请求呼叫,而是在Craig的视频电话15处间歇地通知短语“Hey Craig”来代替一般将发生以引起Craig注意的响铃。用以执行此操作的功能性将由主控制器50和DSP 62执行。句子“Hey Craig”将由观看者通知且传输(如上文解释)到服务器66。服务器66在分析所述句子时将把所述短语辨认为一种命令,其用以向所述命令的指定方发起呼叫。服务器66将接着利用Craig的视频电话15的地址信息来发起向Craig的视频电话15的呼叫,且导致在Craig的视频电话15处产生的信号或音调为“Hey Craig”。
如此项技术中众所周知,编码器36能够识别每个帧的开始和结束。当编码器36接收到数据时,其编码用于帧的数据且将所述数据进行存储直到所述帧完成为止。由于编码器36所利用的算法的缘故,所存储的帧被用作形成下一帧的基础。所存储的帧用作下一待编码的帧的参考帧。本质上这是因为从一个帧到下一个帧的帧变化是编码的焦点,而并非从开始处的整个帧。接着直接发送经编码的帧来进行分包(如上文解释),而没有任何缓冲(除了用于分包目的之外),以便最小化任何延迟。或者,当编码器36编码用于帧的数据时,为了甚至进一步加快数据传输,经编码的数据被命令继续前进以用于分包目的,而不等待整个帧被编码。出于形成帧的目的也存储被编码的数据(原因在上文中解释),使得参考帧可由编码器36使用。然而,独立地,所述数据在编码后被继续发送以用于分包目的,且数据在被准备用于分包时形成为帧,虽然如果所述包准备进行传输且也那么发生了,那么只有所述帧的一部分被制成包的一部分,所述帧的剩余部分将与独立包一起传输,且直到在接收视频电话15处接收到具有帧信息的两个包时才可形成帧。
参看图1,视频电话15连接到网络40。视频电话15支持基于铜线或多模式光纤的10/100以太网连接和(视情况)ATM 155Mbps连接。每个视频电话15终端通常与用户PC 68相关联。视频电话15的角色在于提供电话(会议)的音频和视频方面。PC 68用于任何其它功能。经由视频电话15建立呼叫可在相关联的PC 68之间自动建立MicrosoftNetmeeting(微软网络会议)会话,使得用户可在基于Windows的程序(例如Power Point展示或电子数据表)中协作,在电子白板上交换图形,传送文件或使用基于文本的聊天程序等。PC 68可连接到以太网,而不管视频电话15终端是如何连接的。其当然还可连接到ATM LAN。PC 68和相关联的发射视频电话15通过网络40彼此进行通信。PC 68和相关联的发射视频电话15彼此进行通信,所以PC 68知道发射视频电话15正向谁讲话。PC 68可接着与发射视频电话15正对其讲话的接收视频电话15的PC 68进行通信。PC 68还可向视频电话15发出呼叫。
大多数系统10功能性是基于服务器的,且是运行在视频电话15代理服务器上的软件,所述代理服务器优选为SIP代理服务器。需要一个服务器66来传递基础功能性,需要第二个服务器来用于弹性操作,即在一个服务器66失效的情况下维持服务。在此情况下,服务器和视频电话15终端中的软件将自动切换到备份服务器66。通过此配置,视频电话15终端可向网络40上的任何其它视频电话15终端或在网络上注册的任何电话(优选地,SIP电话)发出呼叫或接收来自其的的呼叫。
媒体服务器在一组媒体流上向用户提供一组服务。媒体服务器66由特征服务器66(优选地,特征服务器66)控制。其经采用以提供媒体流的来源和接收器,作为各种用户可调用功能的一部分。媒体服务器66上提供的服务为:
会议桥接
记录和播放
代码转换
音调和通知
媒体服务器66是设置在LAN或WAN上的盒子。一般来说,没有其它连接连接到其。其优选地为SIP装置。特征服务器在源自视频电话15终端的信令路径中。然而,媒体路径将从媒体服务器66直接去往装置。
在操作中,用户可请求一功能(例如视频邮件)。特征服务器66将提供用户界面和信令功能,媒体服务器66将提供用于多媒体提示(如果使用的话)和消息记录及播放的机制。
为了使得视频电话15终端能够发出向任何非协议或标准(例如SIP)(视频)电话的呼叫或接受来自任何非协议或标准(例如SIP)(视频)电话的呼叫,添加网关70(例如SIP网关)。可将四模拟线网关70直接连接到PSTN或连接到本地PBX的模拟线。用于供应引出线的标准规则适用。通常,向每六个用户供应一个干线,即假定任何一个用户使用其电话来在任一小时中的10分钟中拨打外部连接。如果视频电话15终端将充当当前PBX上的扩展(当关注传入呼叫时),那么每个视频电话15需要一个模拟线。
TV来源(例如CNN)可供视频电话15用户使用。视频电话15视频服务器66实现此服务。服务器66支持接着可由网络40上的任何视频电话15用户访问的单个视频通道的连接。视频通道是两个正常会议会话的等效物。调谐器可设置可用的通道。应针对客户希望同时可用的每个不同通道而向所述配置添加新的视频电话15视频服务器66。
视频电话15服务器66(优选地,SIP)还含有用于用户数据的数据库,包括用户联系人信息的本地超高速缓存。此数据库可与用户主联系人数据库同步。举例来说,可与Outlook/Exchange用户同步,并用于Lotus Notes用户。将在任何基于NT的服务器66平台上运行的独立程序进行同步。不管所服务的场所的数目,仅需要一个服务器66。
如图2所示,通常多个视频电话15终端将分布在若干场所上,由广域网40连接。一个服务器66足以向单个校园中高达100+视频电话15提供服务。随着场所中视频电话15的总数目增加,到一定阶段时将需要安装更多的服务器。
在视频电话15分布在若干场所中的情况下,它们可能基于中心服务器进行操作,但因为所使用的WAN带宽和对WAN的依赖性的缘故,这并不是推荐配置。优选地,每个场所具有至少一个服务器66,当使用SIP时,所述服务器66优选地为SIP服务器66。出于更谨慎起见,最简单且最容易的配置是如果每个场所具有两套服务器,那么优选地每一者是SIP服务器。然而,使用中心服务器66作为远程场所服务器的替代物也将能起作用。
网络40中任何地方的视频电话15可从单个中心网关70进行基于PSTN或PBX的传出呼叫。然而,如果需要视频电话15也是本地PBX上的扩展以接受传入呼叫,那么需要在每个位置处提供PSTN网关70。网关70上需要有用于所述场所上的每个视频电话15的端口。
中心CNN服务器66可将TV通道分布到网络40上的任何视频电话50。尽管如此,可能优选地包括场所特定服务器,而非占用WAN上的所述带宽。
视频电话15可用于以155兆位/秒连接到10/100以太网网络40或ATM网络40(使用光纤和铜线)。ATM连接的视频电话15使用IP控制面板来建立用于呼叫的端点的ATM地址,且接着使用ATM信令来建立那些端点之间的载体通道。所述载体通道被建立成交换虚拟电路(SVC),其中规定了全部QoS要求。
每个视频流在2Mbps与6Mbps双工之间,其由设置和带宽协商决定。由于显示构件可展示超过单个的视频流,因而至每个视频电话的所需总连接带宽随着电话会议中的参与方数目增加而增加。发射端裁剪确保了最大所需带宽大约为使用中单个视频流带宽的2.5倍。如果场所中存在若干视频电话15,那么用户与干线之间的正常电话比率将适用于视频电话15会话。换句话说,预期视频电话15用户在每个呼叫中平均向两个其他人讲话(即,两个流),且在每小时内将平均使用视频电话15达10分钟。对于3Mbps的平均编码速率,这给出6Mbps的WAN带宽需要,可预期所述带宽能支持高达6个用户。
如图3所示,当存在低密度的视频电话15终端时,视频电话15在”p”启用的以太网网络40上进行操作。视频电话15系统10将在把两个视频电话15链接在一起的网络40的ATM部分上建立SVC,且使用所述”p”启用的以太网来确保经由所述连接的以太网部分传递足够的服务质量。
在图4中展示视频电话15系统10的基本元件。它们一起建立大大增强地理上分散的团体的交流能力的多媒体协作工具。此类团体在几乎每个大型企业中越来越常见,但用于帮助它们有效且高效工作的工具十年来没有发生多少改变且在很多方面令人不满意。视频电话15全面地解决了现存系统的许多问题,从而在远程协作领域产生了飞跃式的改进。这通过最新可用的技术实现,以服务质量和功能的正确混合为显著区别,极好的用户接口的开发使其便于使用,且通过使用基于标准的结构将其设计为可扩展的。
通过使用(例如)众所周知的SIP技术在网络上将音频和视频流(如上文解释)从起始视频电话15传输到终止视频电话15。可通过使用IP路由技术将SIP消息路由经过异质网络。需要异质网络中的媒体流具有更直接的路径。优选地,在会议的起始视频电话15连接到以太网且会议的终止视频电话15连接到ATM网络的情况下(如图15所示),会发生以下对跨越起始与终止视频电话之间的网络的包的寻址。起始视频电话15将包发送到以太网上,对于以太网,所述包是与所述起始视频电话的IP地址的通信。包到达起始网关80,所述起始网关80将以太网与ATM网络进行链接。在起始网关80处,从所述包处保存起始视频电话15的IP地址,且起始网关80向包添加起始网关80的ATM地址,并将所述包继续发送到终止视频电话15。当终止视频电话15接收到包时,其存储来自所述包的起始网关80的ATM地址,并向起始网关80发回一个返回包连同终止视频电话15的ATM地址,所述返回包指示其已接收到所述包。起始网关80在接收到返回包时保存终止视频电话15的ATM地址并将起始网关80的IP地址添加到返回包。接着将返回包从起始网关80发送回到起始视频电话15。
以此方式,起始视频电话15与终止视频电话15之间(且包括所述视频电话)的整个路径的每个关键节点的特定地址是所述路径的每个关键节点已知的。在最小程度上,路径上的每个节点知道路径的下一节点的地址,且如果需要的话,可在包沿着路径移动时将额外地址与各别包保持在一起,所以路径的每个节点可在关键节点的地址方面知道更多信息而不仅是知道所述包将去往的下一节点。这是因为当包从节点向节点移动时,且明确地说,在所述实例中,从起始视频电话15到起始网关80到终止视频电话15且接着回到起始网关80且接着到起始视频电话15时,每个节点保存从其接收各自包的先前节点的关键地址,并相对于下一节点作为其一部分的网络类型来介绍其自身地址。因而,每个节点将包发送到下一节点上所需的关键地址分布在整个路径上。
将包从以太网上的起始视频电话15传送到ATM网络上的终止视频电话15的此实例也可适用于相反情况,其中起始终端或视频电话15与ATM网络进行通信,且终止视频电话15与以太网进行通信。
类似地,路径可包含与以太网通信的起始视频电话15和与以太网通信的终止视频电话15,在其间存在包将要横越的ATM网络,如图16所示。在此情况下,将在每个边缘处存在两个网关,在所述边缘处存在以太网与ATM网络之间的接口。如上文解释,所述过程将仅仅向路径添加额外节点,其中起始网关80将其自身ATM地址引入到包,且将包发送到终止网关82,所述终止网关82保存所述起始网关的ATM地址并将终止网关的IP地址添加到包,接着将所述包发送到以太网上的终止视频电话15。对于返回包,以相反方式发生相同情况,且每个网关保存来自先前网关或终止视频电话15的各别地址信息,且将其自身地址添加到最终发送到起始视频电话15的返回包,其中起始网关80和起始视频电话15分别保存终止网关82或起始网关82的ATM地址,所以存储整个路径的每个链路中的各别地址,以更有效且快速地继续发送连接的后续包。
举例来说,视频电话15的主控制器50和网络接口42可使用将SIP路由信息(或所使用的任何标准路由信息)放在包中的领域的所属技术人员熟知的相同技术向发送到网络40的每个包添加视频电话15的地址。网络接口42还将从来自网络上节点的包接收到的地址信息存储在本地存储器中。类似地,对于网络40上的网关,可应用相同情况。如众所周知,网关具有控制构件和数据处理构件来将包移动到其最终目的地。网关的控制机制的网络接口42和主控制器50(其关于SIP路由信息以众所周知的技术进行操作)存储从包接收的地址信息,且其将相对于网络40(将在其中发送包)的自身地址信息与包放置在一起。举例来说,可将网关或视频电话15的地址信息放置在与包相关联的标头部分中的字段中。应注意,尽管所述实例谈及将视频电话15使用作为终止和起始源,但可使用产生和接收包的任何类型的装置作为此整个机制中的节点。
虚拟存在视频电话15是作为个人通信终端的桌上型网络40装置。其取代用户桌面上的电话,提供现代PBX终端的所有特征,及由视频电话15的大触摸屏74提供的用户界面的简单性和使用简易性。
视频电话15向所有人际通信添加视频方面,从而将通话体验改变为虚拟存在的体验。过去,视频会议系统上的视频质量不够高,不足以使该技术成为透明的。视频电话15是传递足够高的视频质量来建立正确体验的第一种个人视频电话。为进行有效的实时视频通信,不仅需要图片质量接近广播TV质量,而且等待时间必须保持得非常低。如果要进行自然的交谈,那么嘴唇同步也很重要。所有这些问题已在视频电话15视频子系统的设计中得以解决。视频电话15使用特别针对此应用配置的最新编码器36和解码器34技术。换句话说,视频电话15尽可能地接近于“身临其境”。
视频电话15还通过使用传递清晰语音的高保真度且接近CD质量的音频通道而大大改进常规扬声器电话性能。立体声音频通道提供了每个参与者音频的空间差异。高级立体声回声消除不仅消除来自单元扬声器64的所有声音,而且使得讲话者能以正常交谈音量进行交谈,即使在吵杂房间中也能这样。
视频电话15直接支持建立高达4个远程方(即,5向)视频电话会议和/或高达10方的音频电话会议。每个用户可以看到他/她的工作群组的所有其他成员的可用性。视频电话15优选地使用会话起始协议(SIP)作为建立、修改和清除多流多媒体会话的构件。视频电话15可经由网关70而建立到任何其它SIP电话或任何其它电话的音频呼叫。
视频电话15对其附接的网络40具有高要求。视频电话15的电话会议要求网络40能供应连续的高带宽,对带宽、等待时间和抖动有保证。Marconi plc专门研究提供可支持高服务质量应用的网络。也可获得视频电话15的会议室版本。
视频电话15是具有完全与用户的PC 68(计算平台)集成的能力的通信终端(平台)。用于PC 68的视频电话15应用在PC 68与相关联的视频电话15终端之间提供许多集成服务。这将包括出于共享例如白板或展示等应用的目的而自动建立视频电话15的电话会议中各方之间的NetMeeting会话(如果启用),还包括其它能力,包括在PC 68上进行视频电话15对号码的“拖放”拨号。
一组服务器(优选地,每一者为SIP服务器)向网络40装置提供呼叫控制和特征实施。这些是在标准计算平台上运行的软件服务器,能够实现冗余。这些服务器还运行用户联系人信息数据库和用户偏好数据库的本地副本。这些服务器上可用的应用程序提供访问公司或其它LDAP可访问目录的能力。
同步服务器66维持用户主联系人数据库与服务器66(优选地,SIP)上的本地副本之间的同步。支持Outlook Exchange或Lotus Notes同步。一组媒体网关70被用于模拟或数字PSTN网络40。一组媒体网关70介接到最常见的PABX设备,包括与那些PABX相关联的语音邮件系统。
媒体服务器66向视频电话15终端提供许多服务。其充当4方视频会议的桥接会议服务器66(如果需要的话)。其还可提供视频电话15标准与其它常见音频或视频格式(例如H320/H323)之间的代码转换。其可提供记录和播放工具,从而使得能记录和播放会话。其可提供音调和通知源。
需要根据正使用的标准的防火墙(例如SIP防火墙),以便在标准代理软件(例如SIP代理软件)的控制下安全传递经动态生成的RTP流。TV服务器66充当TV分布源,从而允许视频电话15用户选择所支持的任何通道(例如CNN)。
视频电话15用于以太网和ATM桌面。视频电话15终端将支持端到端ATM SVC且使用它们来建立具有必要服务质量水平的连接。视频电话15还将支持经由LANE服务的IP连接性。为使其保证所需的QoS,需要LANE 2。视频电话15向附接到ATM的桌上型PC 68提供ATM通过(passthrough),或提供ATM至以太网通过以便经由以太网附接PC 68。
视频电话15需要支持端到端QoS。对于附接到以太网的视频电话15,用户连接需要支持802.1p、DiffServ和/或IntServ或更好的协议。如果可经由ATM网络40到达目的地,那么将提供以太网到ATM的网关70。SIP代理服务器66和SIP信令将建立最靠近目标视频电话15终端的ATM端点,即,如果它是ATM附接的或最靠近的ATM以太网网关70,则为其ATM地址。信令将在网络40的ATM部分上建立具有恰当QoS的SVC。此SVC将链接到在远程端处产生恰当优先级指示的特定以太网流。
视频电话15产品系列由若干终端(装置)、一组服务器(其提供未内建到所述装置中的特征)和一组网关70(其将产品连接到现存设施和PSTN服务外部)组成。系统10提供的基本功能性为:
@电话服务,在所有“网上”呼叫上可使用视频,具有非常高质量的音频和视频
@多方会议服务,其为音频和视频的、专门或预调度的、完全自动服务并完全集成到电话服务中
@存在服务——具有多种工具来确定协作可用性
@共享表面服务——电子白板,应用程序共享,文档共享,演示广播
@其它附加值服务,例如广播视频(到达群组的Mikes消息)TV分布。在线互动培训等。如果需要的话,会话记录服务也是可用的。
视频电话15是具有大量新功能性的电话,而不是试图实现电话功能的电脑。这允许完全同时使用电脑来从事其擅长的工作,同时提供灵活而特定针对应用的装置来进行通信。可针对此应用调节用户界面和物理设计,从而提供一种如同当前电话的瞬时接通、高度可靠的通信装置,而PC 68将永远不会成为某种装置。此方法还对装置的操作环境提供控制,从而消除与PC 68硬件和软件配置问题相关的支持问题。
人为因素研究已反复表明,音频质量是进行有效和透明通信的单个最重要因素。尽管手持话机是必要的,但包括声响回声消除(AEC)、自动增益控制(AGC)、宽带音频能力(G.722 8kHz带宽或更好)、立体声输出和与PC 68声音输出的集成的极好质量的免提音频可提供全新水平的有效远程协作。还存在高质量麦克风阵列,其经设计和处理以限制罐头效应。
使用一种简单、清洁、直观、完全灵活的用于视频输出和按钮/选择输入的平台。在第一视频电话模型中,这是高质量TFT全色屏幕,  其为具有1260×768或更好分辨率的17”对角线16乘9屏幕,上面覆盖有中等分辨率的高寿命的触摸板。将明亮(>200尼特)且扩展视角(>+-60°)的有源矩阵面板用于显示全动视频以在办公室环境下获得舒适观看。可使用更大、更明亮、更快速、更大对比度和更高视角的屏幕。
视频电话15使用TFT彩色LCD,具有带有基于Intel Celeron/440 MMX和Lynx VGA控制器的VGA型显示器53接口的类似PC 68的结构。
高质量数字480逐行扫描相机用于提供30帧每秒的至少640×480视频。视频电话15利用用于机顶盒的视频编码器36技术来使用MPEG2编码。可产生各种不同位速率,从而允许视频质量适合一对一呼叫的可用资源,且适合一对多或多对多呼叫的最高质量参与者。集成的高质量相机模块被置于靠近屏幕处,其中提供外部视频输入(火线)来允许使用额外相机、VCR或其他视频源。
现存的10/100BaseT以太网桌面连接是与LAN、WAN、PC 68桌上型计算机和各种服务器、代理和网关70进行通信必需的仅有连接。使用802.1p将用于音频和视频的限时RTP流标记为具有优先级,从而在LAN的以太网域内提供用于QoS的机制。还支持DiffServ,同时RSVP为可选项。为了消除对到桌面的额外建造布线的需要,视频电话15将包括小型10/100以太网交换机,从而允许现存桌面端口可用于电话和PC 68两者。
视频电话15还支持ATM接口。所述接口是基于使用具有光纤或铜线接口的HE155兆位/秒卡。视频电话15提供ATM通过端口,以连接到连接ATM的桌面装置或将连接以太网的PC 68连接到连接ATM的视频电话15。
会议室环境的成本和性能权衡显著不同于桌面环境的成本和性能权衡。视频投影、具有远程摇摄/倾斜/缩放的多个相机、多个麦克风、多个视频通道、背投白板和其它适用于会议室环境的产品被集成到会议室视频电话15中。会议室环境与桌面的交互操作是无缝的且透明的。此环境将大量使用介接到相同基础架构和标准的OEM设备以代替桌面装置。硬件设计是基本相同的,具有对多个麦克风的额外音频支持和对多个相机和显示器的额外视频支持。或者,可使用链接到低成本SIP电话的PC 68应用程序,其由鼠标或触摸屏74(如果PC 68具有触摸屏74)驱动。对于不需要上文所述的协作能力的那些桌面和其它位置,可使用与系统10一起工作而不需要额外布线或PBX的标准电话。
通过使用SIP(会话起始协议)标准,终端装置由一个或一个以上提供注册、定位、用户概况、存在和各种代理服务的服务器支持。这些服务器是连接到LAN的廉价Linux或BSD机器。
视频电话15是电话,所以必须提供一组关键的PBX功能,包括传送、转发、3(和4、5、……)方会议、呼叫者ID+、呼叫历史等。这些特征中的某些可建立在称为“CPL”的SIP扩展机制上,所述CPL实际上是一种用于以安全、可扩展方式提供呼叫处理的语言。
视频电话15提供了有效存在和瞬间消息传送。存在(也许是改进每日分布式群组协作工作的最有革命性的工具)允许人们知道谁在且他们正在做什么。其为非常低的额外开销呼叫、消除电话标签和传统拨号、鼓励群组作为群组而并非通过现在常见的分离式一对一电话交谈来进行通信提供了基础。与瞬间消息传送(实时邮件)的集成提供了交换短文本消息的非延迟方式,其可能使用PC 68键盘进行输入。
视频电话15提供了分布式/冗余结构。这是电话系统10,且其必须是可靠的。其还应能够通过本地扩展来加以集中管理,其中分布式服务器向所有用户提供“瞬间”回应。举例来说,如果使用SIP,那么将部署不同SIP代理功能中的每一者,使得它们可任意组合成一组物理服务器,同时冗余版本位于网络40中。
Microsoft NetMeeting用于共享表面和共享应用程序功能性。可使用PC 68和PDA的计算机/电话接口(CTI),其具有例如集成的联系人列表、自动拨打选定电话号码或名称、呼叫历史的日历记录、自动输入联系人等特征。
SIP向防火墙提出挑战,因为RTP流使用动态分配的UDP端口,且在SIP消息中承载地址/端口信息。这意味着防火墙必须追踪SIP消息,且对于恰当的地址/端口组合在防火墙中打开“针孔(pin hole)”。此外,如果采用NAT,那么必须更改消息以具有恰当的转译地址/端口。存在两种用于完成此类任务的方式。一种是将所述性能内建到防火墙中。位居前三位的防火墙销售商(Checkpoint、Network Associates和Axxent)提供此功能。替代方案是具有专用防火墙,其与主防火墙并行且仅处理SIP。存在此类防火墙的商业版本,例如MicroAppliances的版本。应注意,SIP或NetMeeting是可用于实现其必要的各自功能性的优选实施例。如果提供了必要的功能性,那么可使用它们的替代方案。
图5展示视频电话15终端的主物理组件。架子提供易于调节主显示器54面板的高度和将面板紧固在所述高度的构件。高度调节范围为至少6英寸行程以适应不同用户高度。假定架子将搁在桌子上且桌面高度是标准的。架子与主单元之间的链接必须提供偏离垂直方向的有限倾斜度,以便匹配用户偏好且易于锁定在那个角度。所需的倾斜量为与垂直方向相距-0+15。主单元可直接进行墙式安装而不需要作为可选项的架子组合件。
主单元外壳提供用于视频电话15设计中的所有其它元件(包括图5中所示的所有那些元件)和所有内部电子元件的外罩。所述外壳提供了手持话机的左手或右手座架。用右手的人往往会用左手拾取手持话机(因为他们将用右手驱动触摸屏74和写字)且用左手的人正好相反。尽管左手定位将是正常模式,但必须能够将手持话机放置在右侧。在外壳上提供扬声器插孔,以允许扬声器64安装在远离视频电话15处。提供输入以处理来自相关联PC 68的扬声器输出,以使得视频电话15可控制PC 68和视频电话15音频。可使用到扬声器64的无线连接的实施方案(经由蓝牙或SONY标准)。
在所述单元处提供手持话机,且应使用标准RJ9卷绕电缆和连接器插孔连接。当搁置时,手持话机应易于拾取但为不碍事的。手持话机选项提供了手持话机上的标准键盘。可使用用以改进终端用户移动性的无线手持话机。
提供插孔以连接立体声耳机+麦克风。使用耳机来进行正常电话交谈正日益增加。用户应能够选择使用耳机+吊杆麦克风,或仅使用耳机,同时采用麦克风阵列作为输入装置。可选择使用无线耳机,以便改进终端用户的移动性。
在主外壳上某一位置中提供用以介接到PDA和其它IR装置的IR端口,以允许容易的连接。当前,电话和PDA上的IR接口是最常见的,且因此出于与需要蓝牙接口相同的原因,也需要IR接口。
阵列麦克风嵌入在外壳中。所述阵列必须不会由于终端的正常操作而产生附加噪声。明确地说,其应不能够检测到触摸面板上的用户动作。所述阵列麦克风允许用户在单元前方周围和水平面中110E的弧形(例如,6英尺)内且在存在预定分贝的背景噪声的情况下以正常交谈音量进行讲话。单元必须明确指示麦克风是有效的/无效的,即等同于“挂机”或“摘机”。视频电话15用户将需要再次确保,他不会在不知道的情况下被收听。这是机械相机快门的音频等效物。
主视频电话15单元可具有智能卡读取器选项以提供为获得个人特征对终端的安全使用。对视频电话15的使用将需要一系列使用控制特征,从屏幕上的简单密码登录到安全链(security fob)。智能卡读取器提供这些使用权控制方法中的一者。
如果可从屏幕控制倾斜和摇摄,且优选地,如果摇摄和倾斜仅仅是电子的且不需要任何机械机制,那么明显地存在优点。相机支架应当安装为尽可能靠近主屏幕的顶部,以改进视线接触。
相机应当是能够产生480p输出的数码相机47。相机输出馈入MPEG-2编码器36。应当能够动态地配置相机,使得相机输出得以优化而以选择的编码器36输出数据速率馈入编码器36。面部形成相机将接收到的大部分输入,且因此在各种各样光照条件下对肤色的准确捕捉是一项基本特征。
相机应在低至3勒克斯值的各种各样光照条件下进行操作。相机应提供自动白色平衡。白色平衡变化必须是缓慢的,以使得所俘获的图像上的瞬变现象不会造成不适当的图片扰动。只有持续超过5秒的改变才应改变白色平衡。相机的焦距应为18英寸到10英尺,即具有较大景深,且理想地焦距达20英尺。用户和信息(如果在其白板上存在的话)两者均需要被对焦。自动聚焦(其中当用户移动时相机不断搜寻最佳焦距)在接收器端处产生干扰图像,且必须加以避免。
相机应允许有限变焦能力,从一个用户在相机正前方的设置变到一些用户同时在一个视频电话15上的另一设置。作为替代方案,可提供不同镜头。可依据镜头视野来对此进行规定,从例如30E视野到75E视野。
相机应当能够输入比传输所需更大的图片,例如1280×960图像。这将允许以电子方式的有限的缩放和水平及垂直摇摄,从而消除对与相机相关联的电子-机械控制的需要。相机的物理尺寸应较小,以使得“屏幕上”安装不会简单地被相机大小取消。
中等分辨率长寿命触摸面板形成与视频电话15进行通信的主要方法,且形成主显示器54的正面。面板将受到大量手指接触,且因此必须经受频繁清洁以去除污点和其它指纹,否则所述污点和其它指纹将影响显示54质量。应当易于校准触摸面板,即确保在触摸面板上触摸的区域与在下面的显示器54之间的对准将导致满足“假触摸”要求。
触摸屏74表面必须最小化表面反射,以使得即使在面对窗户时显示器54也是清楚的。要求是“假触摸”为罕见事件。对触摸面板的分辨率要求因此很大程度上依赖于触摸屏设法区别的最小显示器54区域。组合的分辨率和视差误差应使得一般受训用户由于这些因素而产生“假触摸”的机会小于5%。(20次选择中存在一次假触摸)。理想的是,此假触摸比率小于2%,即在50次选择中存在一次假触摸。
在恰当情况下,必须给予用户成功触摸的可听和/或可见反馈。这些音调可依据当时触摸屏74显示器54上的内容而变化。举例来说,当使用键盘时,类似键盘的声音是恰当的,当使用拨号盘时,不同声音可能较为相关,等等。可听反馈可能不是在所有情况下都是需要的,尽管通常成功触摸的某种可听或可见指示对用户有帮助。用户应能够打开和关闭音调,并设置与某设置屏幕上的触摸相关联的音调、音调持续时间和音量水平。应提供默认值。触摸屏74也可与指示笔以及手指一起使用。
显示器54面板应为至少17″对角线平板(或更好的)全色显示器54技术,其中16×9纵横比是优选的,但16×10纵横比是可接受的。
屏幕分辨率应至少为1280×768。可视角度应在水平和垂直平面上至少离轴6E。屏幕对比率应当比典型的300∶1好。颜色分辨率应为至少6位/色彩,即能够显示262K种色彩,6位/色彩对于原型单元是可接受的。对于生产单元,8位/色彩是优选的,其中其它方面是相等的。显示器54面板应具有足够高的亮度,以便甚至在良好照明或自然照明的房间中也能舒适地观看。亮度应为至少300cd/m2。显示器54和解码电子设备应当能够显示来自图像的恰当网络40源的720P高分辨率图像。
到最小亮度的50%时,背光应具有至少25,000小时的最小寿命。如果背光由于视频电话15终端不活动的缘故而被关闭,那么其应当在有传入呼叫时和在用户触摸触摸屏上的任何地方时自动打开。不活动时段(一旦经过其以后就关闭接触屏)应当可由用户设置,可设置为“不关闭”。
图6中展示视频电话15的连接区域中所需的连接。下文将在多个段落中简要描述每个连接器要求。
两个RJ 45/100以太网连接器用于连接到网络40,且源自相关联的PC 68。
应提供ATM个性化模块中的可选插件,其使得视频电话15能够容易地支持用于光学和铜线接口两者的155兆位/秒接口。
应提供USB端口,以允许容易地连接各种可选外围设备,例如键盘、鼠标、低成本相机等。
应提供1394(火线)接口以准许连接到外部(火线)相机或其它视频源。接口应准许对火线接口进行完全的带内相机控制。在必要情况下,应使用外部转换器来从(例如)S视频转换到火线输入。应当能够使用此源来代替输出到会议的视频电话15中的主相机源。还应能够规定正常或“CNN”模式,即可对此视频源进行裁剪或不可对其进行裁剪。应提供XVGA视频输出,以使得视频电话15能够用反映在主显示器52上显示的图像的图像来驱动外部投影仪。
应针对PCAudio输出提供音频输入。为了确保PC 68音频和视频电话15音频的集成,将仅部署一组扬声器64。PC 68声音将穿过视频电话15的音频通道。应提供一插孔或一对插孔来连接到耳机和附接的悬挂式麦克风。仅耳机操作(使用内建的麦克风阵列)必须也是可能的。如果耳机插孔相对难以接近,那么应能够让耳机保持插入,且经由用户控制来选择是否在耳机上打开音频。提供到外部左扬声器和右扬声器64的连接。可能使用一个、两个或三个视频电话15单元就好像它们是单个功能单元,如图7中说明。
在具有一个以上视频电话15的配置中,只有一个单元充当主控制面板,其它单元显示视频和与所显示视频直接相关联的控件。对于这些配置中的任一者,将只需要一组扬声器64。
将考虑到麦克风输入和音频流而提供许多选项,从使用单个常见麦克风输入到将音频从每个麦克风阵列传输到所述视频电话15上的视频源。
应针对视频输入提供许多选项。默认的应是传输“控制面板”视频电话15的视图。如果可使用更多带宽,那么每个用户可从显示所述用户的屏幕处得到视频,从而产生更自然的体验。可经由LAN连接达成多个视频电话15终端的所有协调,即不需要任何特殊的单元间布线。
视频电话15视频电话向其用户提供许多主要功能:
——它是办公室电话
——它是用户电话
——它是视频电话
——它是会议电话
——它是视频会议电话
——它提供对联系人详细信息的容易的访问和管理
——它提供对语音/视频邮件的访问和管理
单元功能性分为两种类别,即用户功能和系统功能。
用户功能是用户将可以使用的任何功能。
系统10功能是I.T.需要用来设定监视器和维护视频电话15终端的那些功能,且所述功能是一般用户看不见的。实际上,整个设计的重要目的是确保向用户呈现非常简单的界面,在所述界面中他可在几乎没有受到培训的情况下使用视频电话15。
下文定义基本特征组,所述基本特征组是必须具有的最小的特征组。
当没有用户登录到终端上时,视频电话15视频电话充当常规电话。其功能性必须完全不取决于相关联的PC 68的存在。
下文描述视频电话15作为办公室中常规电话的功能性。
终端能够在服务所述场所的PABX上具有常规扩展号码。
终端能够从任何电话接受传入呼叫,所述电话可以在PABX上、在视频电话15网络40上或为任何外部电话,而没有任何区别对待。
视频电话15能够接受来自其它兼容SIP电话的呼叫。
传入呼叫将根据配置来产生响铃音调(见下文的设定屏幕要求)。明确地说,针对包括视频的视频电话15呼叫的响铃音调将可被选择成一种区别于仅音频呼叫的响铃,无论其是否来自视频电话15终端。
传入呼叫将在显示器54上的状态区中产生传入呼叫指示。此显示器54必须给出与由传入呼叫提供的呼叫者ID信息一样多的呼叫者ID信息,或指示没有一者是可用的。
有可能通过以下方式来接受传入呼叫:
a)按压传入呼叫状态显示器54上的呼叫接受按钮。
b)拾起手持话机——这将总是接受所有被提供的选项,即视频和音频。
用户能够容易地在一次呼叫之中在手持话机与免提(扬声器电话)操作之间进行切换。在呼叫之中拾起手持话机应自动从扬声器电话模式切换到手持话机模式。在不重新选择扬声器电话模式的情况下放回手持话机将断开所述呼叫。
屏幕上应给出关于所述模式(即手持话机或免提)的指示。
呼叫状态栏可显示呼叫持续时间。
能够通过主显示器54上轻易可得的控件来调节传入呼叫的音量。应可独立地调节耳机和扬声器音量。
当在扬声器电话模式中时,能够将手持话机放回到手持话机支架,而不断开呼叫。
在以下情况下终止呼叫:
$如果用户按压呼叫状态显示54上的清除呼叫按钮。
$如果在手持话机模式中且没有选择免提时用户放回手持话机。
$如果远程方挂断呼叫(假设这被可靠地指示给视频电话15)。
保持——应能够将呼叫置于保持状态且再次取消所述呼叫的保持状态。应在状态显示54上显示保持状态,同时具有一个允许拾起被保持的呼叫的按钮。
呼叫等待——额外传入呼叫必须在显示器54的状态区中产生传入呼叫指示。必须不产生呼叫音调,除非这已在设置菜单中启用。
能够在当前操作模式(即,手持话机或免提)中通过状态显示54上的呼叫接受按钮接受新的传入呼叫。
接受另一传入呼叫将自动将当前呼叫置于保持状态。
在任何呼叫时按压“取消保持”按钮必须自动将其它呼叫转换为保持。
可处理的同时传入呼叫的数目由状态显示54空间的可用性设置。必须不少于两个呼叫。
在当前呼叫的数目超过可处理的数目时,任何其它传入呼叫:
a)得到忙音或
b)立即转接到语音邮件
c)立即转接到经配置的转接号码
d)被发送一条记录消息。
这由用户“遇忙呼叫转接”设置确定。
如果在可接受限制内的传入呼叫在(可配置)时间间隔内未被应答,那么呼叫:
a)被转接到语音邮件
b)被转接到预先配置的转接号码
c)被发送一条记录消息。
这由用户的“无应答呼叫转接”设置确定。
呼叫转移——用户能够容易地将任何呼叫转移到任何其它号码。所述转移功能将把呼叫置于保持状态并允许拨打新号码。一旦听到响铃音调,用户便将具有完成转移的选项。或者,用户将能够对所述新号码讲话,且接着起始转移或首先加入电话会议中的所有(三个)参与方。如果在后者情况下,将向用户提供一种功能来退出所述电话会议。在没有来自被叫终端的回复或只有来自被叫终端的语音邮件的情况下,用户将具有返回到最初呼叫的选项。
呼叫转接——必须能够将电话设定为将传入呼叫自动转接到预先配置的号码。呼叫转接可为:
a)无条件的
b)遇忙转接
c)无应答转接
电话会议——能够将多个呼叫组成仅音频的会议,而不管语音呼叫的起源。能够将至少3个呼叫组成会议,即四向交谈。在任何一个时间仅需要支持单个会议,但仍能够接受一个其它传入呼叫(如在上文呼叫等待中所描述)。能够接受的是,原型仅能够接受对特定会议的一个传入呼叫,即对于非视频电话呼叫将需要外部桥接器。
与传入呼叫状态显示54相关联的选项将允许用户添加呼叫或从会议连接中移除呼叫。
能够向会议添加多个呼叫,而不管它们是传入呼叫还是传出呼叫。
如果远程会议用户挂断,那么必须自动清除所述呼叫支路(call leg)。
可使得呼叫成为免提的或有时使用手持话机。拾起手持话机应引出拨号盘(如果不在通话中的话)并将音频连接到手持话机。需要屏幕上音调拨号盘(即,数字1到0加上“*”和“#”)。另外,应存在暂停按钮来向拨号串插入暂停(以用于通过PABX,除非网关70可经编程以去除此要求)。应考虑添加+键,且布置为将所述+符号自动转译成所述位置的国际访问串。
还需要用以校正键入错误的键(例如[回格]键)和用以清除输入的清除键。短时间按下[退格]键应移除最后键入的数字,较长时间的按压继续移除多个数字,持续按压(pressover)应清除数字寄存器。
应将号码显示54自动格式化为本地号码格式。[这可能需要用户设置来选择操作国家,因为每个国家具有不同风格,或如果键入国际代码,那么所述代码应用作格式化所述号码的剩余部分的基础。]
当连接到使用音调数字盘来选择特征的服务时,在使用屏幕上键盘或手持话机键盘时,必须在所述服务的控制下产生正确音调。拨号盘必须能够提供此功能,而不管如何起始所述呼叫。
重拨——能够通过单次触摸经恰当识别的功能来重拨上次拨打的号码。
自动重拨——能够(例如)通过按住[重拨]按钮来触发自动重拨机制。自动重拨将在先前尝试返回占线信号的情况下自动重复所述呼叫若干次。
遇忙等待——当向支持遇忙等待的装置发出呼叫时,“遇忙等待”功能是可用的。一旦被叫方可用时,遇忙等待便向所述用户回电。如果被叫号码不能支持遇忙等待,那么应产生表明“此服务不可用”的消息。
当没有用户登录到视频电话15上时,可在显示的屏幕上存在恰当日志。
应将传入、传出的频繁和错过的呼叫的日志显示在集成拨号屏幕的恰当视图中。对“上次号码重拨”工具的单次触摸或两次触摸使用应一直在拨号屏幕上为可用的。下文给出这些日志的进一步定义。
为了访问视频电话15终端上可用的整组特征,用户必须登录到所述终端中。提供登录屏幕,在其中用户可键入其名字和密码。这可与他的正常网络40访问名称和密码相同。视频电话15终端将因此使用场所用户验证服务。必须提供使得IT人员能够将视频电话15配置为使用这些验证服务所需要的任何屏幕。识别用户的替代方法是可用的,例如使用智能卡或ID链。不要求用户在登录到视频电话15终端之前已经登录到PC 68上。
多个用户可登录到单个视频电话15上,且可提供用于每个用户的截然不同传入响铃音调。传入呼入指示还应识别被叫方名称以及主叫方名称。如果多个用户登录到单个视频电话15上,那么所有呼叫转接功能均专用于呼叫所针对的用户。
如果用户已经登录在其PC 68中,登录到视频电话15上的动作将创建用户已登录的PC 68与视频电话15终端之间的相关联性(倘若这从PC 68得到证实)。用户能够同时登录到多个视频电话15终端。有效视频电话15是最先应答所述用户的任何呼叫的视频电话。
主页屏幕含有在所有屏幕上可见的状态区(除了在全屏模式中)。状态包括登录用户的名称——或“无用户登录”。用户的“存在”状态、视频及音频传输的图标、语音邮件“消息”指示和日期及时间。
如果在用户语音邮件系统10上存在没听到的语音邮件,那么“消息”指示点亮并闪烁。按压所述指示符会引出语音邮件处理屏幕。
触摸日期时间区域允许访问日历功能。
主页具有在所有屏幕上可见的控制栏区域(除了在全屏模式中)。
控制栏允许直接访问最频繁使用的呼叫控制特征且访问所有其它功能。应在按钮上使用图标,但也可使用文本来强调功能用途。
控制面板还具有对麦克风、相机和扬声器64的全局控件。所述控件应清楚指示其操作状态(例如,打开或关闭),且在所述控件处应使用可能的图标。
可得到自我图像,其指示由相机拍取的图片和有效呼叫的远程端可见的部分。能够将自我图像打开及关闭,且能够确定其是一直被打开还是只是在已建立有效通话时才打开。
能够在任何时候(即在呼叫中、不在呼叫中等)在屏幕的主视频区中显示相机图像。图像应是针对单个视频呼叫的图像,且应覆盖任何其它存在的视频。应能够请求所述视频的全屏版本。可将此认为是数字镜像,且这允许用户确保他/她对相机将要或正在展示的内容感到满意。
出于诊断目的,需要用户还能看到在编码和解码之后的图像,以使得他知道将在远端处看到的图像的质量。如果支持此模式,那么相机直接图像和编码解码图像并排。用户可截取其自身图像,以用作为与其联系人信息相关联的图像。
将主屏幕的主要部分分配给集成拨号功能。存在四个主要子功能:快速拨号显示54、目录访问显示54、拨号盘,和对呼叫日志的访问。拨号盘和对呼叫日志的访问将占据不违背方便使用的最小屏幕区域,从而最大化可用于快速拨号/联系人页面的区域。首先详细说明快速拨号区域,所有主要子功能的任何共同要求仅在快速拨号部分下详细描述且暗示用于其它三个功能。拨号区域的功能在于选择将向其发出呼叫的用户。
与拨号屏幕的其它要求一致,快速拨号区域尽可能地大。大于20个快速拨号位置是足够的。每个位置应足够大,以便在与屏幕相距正常操作距离(例如3英尺)处能非常容易地阅读存储在所述位置处的个人详细识别信息。
存储在快速拨号位置中的用户信息包含个人名称、“存在状态”(如果知道的话)、在选择所述快速拨号时将被呼叫的号码和用以指示用户是否支持视频呼叫的图标。详细信息还存储视频电话15的兼容视频类别,例如,MPEG2、H261等。
所述区域提供经触摸以起始呼叫的空白区。如果可用的话,包括个人的缩略图。提供一种处理长名称(即,不能放入分配在快速拨号按钮上的空间中的名称)的方法。
具有标准国际格式的常规电话号码(即,“+国家代码区域代码号码”)被自动转译成向此号码发出呼叫所需的外部访问代码加上国际访问代码。
可获得与快速拨号页面上的个人相关联的全部联系人详细信息。所述联系人详细信息提供可借以联系所述用户的所有号码,并提供一种选择所述号码中的一者作为快速拨号页面上使用的默认号码的构件。能够经由这一到联系人页面的链接而选择并拨打所述用户的替代号码。
用户信息包括所述个人的最近期呼叫历史,例如最近10个呼叫(传入错过或传出)。仅仅提供“最近呼叫”信息将是可接受的最小功能性。
能够编辑与快速拨号条目相关联的联系人详细信息,和/或创建用于快速拨号页面的新联系人条目。能够将条目从联系人、目录或呼叫日志屏幕复制到快速拨号页面。能够将条目从快速拨号页面复制到联系人或目录屏幕。能够删除快速拨号条目或将所述条目移动到另一联系人页面(即,复制且接着删除原始条目)。
能够控制用户在快速拨号页面上的位置。还应能够以某种方式(彩色编码)区分不同类别的快速拨号用户,即商务、家庭、同事、销售商,客户。快速拨号页面同样可含有来自联系人信息中多个其它类别的名称。可使用某种形式的自动组织,例如姓、名、公司,或先按照类别然后是姓、名、公司等。
能够将一组用户定义为单个快速拨号条目。如果群组大小受限于最大电话会议的规模,那么这是可接受的。能够从快速拨号页面中选择目录视图。目录视图将占据与快速拨号页面相同的屏幕区域。能够从视频电话15可访问的在线目录范围中进行选择。默认的将是Outlook和/或Lotus Notes目录,其含有用户的主要联系人详细信息。应显示选定目录的名称。
由用户在其Outlook或Notes联系人列表中建立的类别可用作选择项。如果所述多个类别不能放入显示54区域,那么提供按钮以向上或向下滚动列表。应按字母顺序组织所述列表。
快速拨号类别是用于填充快速拨号页面的类别。当快速拨号页面是满的且不再能向此联系人类别添加其它名称(除非它们取代现存条目)时,会有某种指示。能够以最近期呼叫的次序来对快速拨号条目进行排序,即最少使用的快速拨号条目将位于底部。这将用于判断哪个条目是最佳的删除候选者,以允许键入更常用的号码。
能够容易地用最少的用户输入来从选定类别中寻找和选择条目。条目选择机制必须对于相对较短的列表和非常长的列表(10,000个名称)都起作用。所述机制必须包括键入文本串并按其进行搜索的能力。能够依据姓、名或组织来为展现的数据选择排序次序。存在一种校正条目错误且快速重新开始整个搜索的方法。
如果搜索关键字的每个次序是有意义的且可由用户改变,那么是理想的。换句话说,举例来说,按住最左边的搜索关键字使得用户能够选择按姓、名或公司来搜索(或按扩展的属性列表来搜索。这(例如)对于寻找在特定部门或特定位置处的某人是有用的——“谁在韩国”)。第二关键字接着限定第一关键字搜索,等等。因此,将关键字设置为公司、姓、名;例如Marconi,那么在Marconi处在多个姓内进行按字母次序的用户搜索。显然,当选择每个分类类别时,在所述类别域中存在具有相同值的条目的某种隐式子排序。因此,对于选择的姓,隐式子次序是名,接着是公司,对于公司,隐式分类次序是姓、名,且对于名,例如为姓、公司。
呼叫日志屏幕显示三个呼叫类别(传出、传入和错过的呼叫)的最近期条目,同时具有对哪个类别被选择的清楚指示。另外,应存在“频繁”类别,其对任何类型的最近(<200)呼叫依据使用频繁度来列出号码。应能从呼叫日志屏幕使用拨号盘。推迟对提供高得多程度的处理呼叫日志数据的值的分析。
在最小程度上,当触摸“消息”时,连接到用户语音邮件系统10,此用户的语音邮件被输入,且显示拨号盘以通过使用常规电话按键来控制语音邮件。“语音邮件”屏幕的较大部分应引出用以访问邮件系统10的每个特征的按钮,例如,下一消息、前一消息、播放消息、转发消息、回复消息、呼叫发送者等,同时所述按钮具有每个功能内的按键的所有等效物,例如开始记录、停止记录、检查记录、删除记录等。所有功能需要在按钮上,并转换为各自DMF音调。
需要可从快速拨号或目录视图中选择“转发到”号码或需要键入一列用户号码的任何语音邮件命令,且需要所述选择仅自动插入用户号码的恰当部分。这可在向群组转发语音消息中特别有用。使用者能够在视频电话15上设置时间和日期。通过恰当的网络40服务来自动设置时间和日期是希望的。
需要与用户的Outlook/Palm/Notes时间表/日历应用程序集成的日历功能性。最小要求将仅仅是按日、星期或月(按照Outlook或Palm屏幕)来查看在任何日期的约会,同时仅可经由Outlook或Palm数据库进行改变和添加新条目。
可能相当一些用户将不维持其自身的日历,且实际上可能在其桌上没有PC 68,但确实需要查看所述信息。触摸屏幕的状态部分的用户状态区会允许用户设置其状态。用户将具有一系列状态选项来进行选择,包括:
i)有空
ii)繁忙——在通话中,其中将不接受另一呼叫
iii)勿打扰——不在通话中,但不可被干扰
iv)五分钟后回来
v)离开办公室
vi)休假中
视频电话15终端上的单个呼叫实例支持从一个传入流到在一次会议中的最大数目的流。对于视频电话,终端将支持至少四个到其它方的连接作为单个电话会议的一部分。可能接受至少两个独立的仅音频呼叫,即使存在最大大小的视频电话会议也是这样,以使得音频呼叫可经协商保持转移。视频电话15能够支持至少三个同时“呼叫实例”,即高达三个独立呼叫。仅一个呼叫可以是活动的,即,呼叫控制一次仅可应用于一个呼叫。可接受一个以上呼叫(活动或不活动),即用户音频和视频在每个被接受呼叫上被传输。可将进行中的通话置于保持状态,此时用户音频和视频不被传输到处于保持状态的用户且来自所述用户的音频和视频也受到抑制。
在控制显示54区域中展示传入呼叫状态。在显示器54的主要部分中展示呼叫本身和呼叫中控制。
呼叫状态为:
i)传入呼叫
ii)接受且活动——用户的音频(和视频,如果为视频呼叫的话)(受到各种无音控制)连接到此呼叫。呼叫控制应用于此呼叫。
iii)接受但不活动——如同上述,但呼叫控制不应用于此呼叫。
iv)接受且保持——用户音频(和视频,如果为视频呼叫的话)不被传输到此呼叫。
v)接受且被转移
指示每个呼叫的呼叫状态。只有一个接受呼叫可以是活动的。通过触摸与一个呼叫相关联的呼叫显示54区域或控制面板中的呼叫状态来使得所述接受呼叫成为活动的。将任何先前活动呼叫设置为不活动的。第二次触摸将关闭活动状态。传入呼叫指示指示了呼叫是否提供视频连接。没有指示暗示仅音频呼叫。传入呼叫指示将展示与所述传入呼叫相关联的各方的名称。此立即展示了用户是被一对一呼叫还是被邀请加入会议。
用户具有以下选项来处理传入呼叫:
i)接受所述呼叫作为仅语音呼叫
ii)接受所述呼叫作为视频呼叫(暗示具有语音)
iii)发送到语音邮件
可使用设置来将视频电话15终端设置为自动应答传入呼叫,其中传入呼叫的数目可高达所支持呼叫的最大数目。自动应答生成音频和视频连接(如果提供的话)。一旦通话在进行中,用户状态便应自动改变为“通话中”。一旦没有呼叫是活动的,用户状态便将还原到其先前状态(通常为“有空”)。
用户能够配置是否还分配呼叫用户数据。如果用户已经接受了一个或一个以上呼叫,且如果所有呼叫均处于保持状态或不活动的,那么此呼叫在被接受时将创建一个新的呼叫实例。当用户处理此新呼叫时,所有被接受但不活动的呼叫将继续看到并听到所述用户。如果所述接受呼叫中的一者被接受且为活动的,那么所述新呼叫将加入所述通话,且所述通话的所有参与方将与所述新呼叫者组成会议(如果接受所述呼叫的话)。
如果用户在(>10)秒之后不接听,那么将如“无应答转接”设置所确定的那样对呼叫进行自动转接。如上述,所述转接特定用于所述呼叫所针对的用户。如果用户状态被标记为“勿打扰”或“繁忙”,或由于存在最大数目的呼叫正被处理而已设置了所述“繁忙”状态,那么如“遇忙转接”和“勿打扰时转接”设置所确定的那样“立即”对所述呼叫进行转接(如通过“展示转接呼叫”设置所修改,如果实施此功能的话)。
取决于“展示转接呼叫”设置,用户可选择在转接呼叫之前在(>5秒)时间中看到传入呼叫指示。(这意味着除非想接听所述呼叫,用户不需要采取行动,而并非上文中对于呼叫所需采取的积极行动。)如果繁忙状态是由于视频电话15已经处理最大数目的呼叫的缘故,那么这不会起作用。
产生与呼叫一起发送的(非常短的)文本消息的能力是传达关于呼叫重要性和其将花费多长时间的更多信息的有效方式。下文处理与产生消息并将其添加到传出呼叫相关联的要求。如果存在的话,应与传入呼叫相关联地展示传入呼叫文本消息。显示器54同时应付多个传入呼叫的文本消息显示。文本消息还存储在传入或错过呼叫日志中。
呼叫参数协商受限于在网络40政策参数和当前网络40使用情况的范围内建立呼叫所需的参数协商。提供设置以允许用户指定向其它视频电话15终端呼叫时使用的偏好,例如总是提供视频、从不提供视频、在每次呼叫询问是否我想要提供视频。
针对向其他视频电话15用户的呼叫,支持呼叫等待有空(Camp on Available)。一旦所述用户的状态改变为“有空”,这便将对所述用户起始呼叫。如果待被呼叫的用户是群组,那么仅在所述群组的所有成员“有空”时才将起始呼叫。
电话会议是当快速拨号或目录列表中的一个位置代表一群人(其每一者将是通话的参与者)时的情况。实施此特征的建议过程是轮流且一旦主动请求确认了应将所述呼叫添加到会议时发出每个呼叫。这在呼叫转至语音邮件的情况下提供了逸出路线。一旦完成关于第一呼叫者的行动(即,在通话中或拒绝),便处理下一个号码。
有可能创建半双工的传出呼叫,换句话说,其请求来自被叫方的音频和/或视频,但不在此类型的呼叫上传输任一者。这是拉模式。同样地,能够创建推模式,其中传出呼叫发送音频和/或视频,但不要求返回任何音频或视频。此模式可用于选择性地将内容广播到未被注意的终端或用户仅在会议中起被动角色的终端。
独立调节扬声器64、手持话机和耳机的总音量。可打开和关闭扬声器。关闭扬声器还将关闭麦克风。状态指示符展示扬声器和麦克风的状态。
麦克风可被关闭且再次打开。状态指示符展示麦克风无声的状态。
相机可被关闭且再次打开。状态指示符展示相机无声的状态。
在呼叫中,控制仅对活动呼叫起作用。如果某个呼叫是不活动的,那么通过触摸控制面板中的呼叫进行状态指示符或呼叫显示54区域中除特定通话控制功能区域的任何地方,可使所述呼叫成为活动的。任何其它当前活动呼叫被转换为不活动的。可通过随后按压相同区域来将活动呼叫转变为不活动。提供控制,其挂断所述活动呼叫。在电话会议中,其清除通话实例的所有要素。
呼叫必须被接受且为活动的以使得会议控制起作用。触摸会议控制将使当前活动呼叫实例加入下一变为活动的呼叫。会议控制将指示其是活动的,直到其再次被按压,使得其为不活动的,或使得另一呼叫实例为活动的为止。在当前活动通话中的所有呼叫加入会议通话实例之后,所述通话成为单个会议通话且发出会议控制有效指示。只是作为再次陈述,会议选择其它呼叫将加入的呼叫并接着选择所述呼叫来加入那个呼叫。
终止一方对电话会议的加入的方法是让那个方挂断。出于各种原因,用户可能希望能对通话实例的每个部分进行独立控制。这可由去会议(de-conference)能力实现。举例来说,通过在三秒以上时间中触摸所述通话实例,出现子菜单,其允许识别通话实例的个别成员并对其进行选择以进行去会议。接着从会议中移除此呼叫,且将其建立为单独的通话实例,其中所有正常控制都适用,特别是其可被清除。
转移功能转移活动呼叫。当触摸转移控制时,显示集成拨号屏幕且将活动呼叫置于保持状态,但指示其参与通话操作。转移控制指示其为活动的,直到其被第二次按压而取消转移为止,或直到用户选择并按压拨打他想要向其转移呼叫的号码为止。
一旦已起始了传出呼叫,转移控制便指示状态改变,以使得触摸所述控制造成“盲目”转移,且将所述通话实例从屏幕中移除。或者,用户可进行等待,直到被叫号码应答为止,此时创建新的通话实例,从而允许用户向被叫方讲话,且转移功能再次改变状态,以指示再次对其按压将完成转移并终止两个呼叫。否则,要求返回以对正被转移的呼叫者讲话,且重新开始转移过程或终止呼叫。转移是“管理员”借以设定呼叫且接着将其转移到“上司”的主要机制。在此情况下,管理员不能够继续“收听”所转移的呼叫是基本的。这在安全环境下将是特别正确的。
可通过触摸保持控件来将活动呼叫置于保持状态。在保持状态下,暂停传出视频和音频流,且向远程端提供其处于保持状态的指示。不再显示传入音频和视频流。在控制栏上,在呼叫状态显示54中指示所述保持状态。如果任何呼叫处于保持状态,那么保持控件指示保持是活动的。在活动呼叫处于保持状态时再次按压保持(HOLD)会解除保持状态且将所述呼叫返回到显示的状态。
在主控制面板上存在控件,其引出主屏幕且提供对所有其它非呼叫功能的访问。存在指示已选择了Main的指示。第二次按压Main会重新建立当前呼叫显示且接触选择Main。向通话内的每个被接受和被显示方和每个显示的呼叫提供单独控制。需要对来自每个特定用户的音频的音量进行调节。能够个别地消除屏幕上显示的每个用户的音频和/或视频的声音。存在状态指示符来指示音频或视频无声是否是打开的。
如果可在任何一个时间显示一个以上通话实例,例如与两个其他用户的电话会议加上对一个其他用户的新呼叫,那么有可能消除整个通话实例的音频和/或视频的声音,例如消除两方会议的音频,且同时对所述第二呼叫说话。
提供了对在能支持视频的仅音频连接上的视频的请求。提供对视频请求的接受或拒绝。如果同意连接,那么建立视频连接。设置页面项目使得用户能够总是接受或总是拒绝视频请求。
能够显示每个连接的载体通道参数,即视频(如果存在的话)和音频的传入和传出编码率。在通话中,控制仅对活动呼叫起作用。如果被接受呼叫是不活动的,那么使得所述呼叫成为活动的。
能够针对任何用户启用“载体通道质量监视器”。此监视器(有点像手机上的信号强度计)将(例如)当在音频和视频通道上不存在错误或丢失包时展示100%绿条,一旦损失率或等待时间超过预定比率则展示黄条,且一旦超过更高比率则展示红条。时间积分应为短的,例如50毫秒,因为此时间范围中的错误将影响用户视频。因而,举例来说,如果接收者看到视频假象,但同时看到监视器条变为黄或红色,他就知道这是网络40拥挤引发的。
提供了对呼叫内视频编码参数的变化(即增加或减少编码速率)的请求。提供对此请求的接受或拒绝和改变传出视频速率的方法。视频电话15对于所有参与者产生单个传出编码速率。它有可能接受所有传入流上的不同传入速率。
提供了对具有接受或拒绝请求的能力的侧条的请求。如果接受的话,侧条关闭从两个参与者到其他每一者的音频流,所以他们能进行私人交谈,且同时继续听到所有讨论并继续看到所有参与者且由所有参与者看到。提供了双向发送具有视频和侧条请求的短消息的能力。
不管呼叫是传入呼叫还是传出呼叫,到视频视图的屏幕过渡应当是平滑的。音频可抢先于视频。视频可直到此过渡完成时才被显示。(即,不应在向视频过渡的过程中,不应存在任何跳跃图片、半成形帧等。)向用户显示54视频屏幕的过渡应仅在通话“进行中”之后且不在起始呼叫时开始。来自用户的视频的显示应最大限度地使用分配给用户显示器54的显示器54区域。一个显示54中控件能够将此单通话实例单用户显示54转换为全屏显示54。触摸“全屏”显示54内的任何地方将返回到标准显示54。除了已经提到的通话中控制之外,还应显示用户名称。显示器54和控制面板上的通话实例必须指示呼叫是否为活动的,即通话一般控制是否起作用。当一个通话实例准备好时,通过按压通话实例或主显示54上除通话专用控制区域之外的任何地方来选择活动/不活动。
从一个通话实例(两方呼叫)的过渡应当是平滑的,且应当一旦第二呼叫在“进行中”就被起始。显示54应最大限度地使用分配给用户显示54的显示器54区域。如果必要的话,可在每个边缘处对视频进行裁剪而并非缩放,以适合可用区域。不要求用于两个或两个以上准备好的通话的全屏显示54。除了已经提到的通话控制之外,应针对每一方显示用户名称。必须存在关于双方是单个通话实例的一部分的指示。显示54和控制面板上的通话实例必须指示呼叫是否为活动的。当更多方添加到视频通话中时,可对传入视频进行逐渐裁剪以适合可用显示54区域。
在两个通话实例(两者均为单方呼叫)中,存在向单个用户的两个单独呼叫,所述呼叫两者均被显示。屏幕上显示54和呼叫控制指示清楚地指示这些是两个单独且独立的呼叫,其还指示哪个是活动的(如果有的话)。如果将任一呼叫置于保持状态,那么不再显示那个呼叫,且显示54返回到单通话实例单呼叫显示54。
除显示上文描述的那些之外,用户区域应当还能够显示以下组合中的任一者。
四个通话实例,其每一者均为单方呼叫;
三个通话实例,其中一个呼叫可为两方,且其它呼叫为单方呼叫。
两个通话实例,其中一个通话实例可高达三方或两个通话实例可为两方呼叫。
对“CNN”风格显示54的要求是以上单通话实例单呼叫的那些要求,包括具有全屏显示54的能力。还能够在半个屏幕中显示“CNN”风格呼叫,且将另外半个屏幕用于一个或两个用户显示器区域,后者显示为两个独立通话实例或单个两方通话实例。
提供了为语音和数据流提供各种等级的加密的能力。对诊断、测试、测量和管理工具的访问应使用SMF(简单管理框架),换句话说,将可能以三种方式(经由SNMP、经由网络和经由操作接口(craft interface))来访问所有工具。视频电话15终端必须是可远程管理的,对于每天操作或对于进行错误修复的软件升级来说不需要任何现场IT专门技术。故障诊断也是可远端进行的,且能够确定问题是在单元硬件、单元配置、单元软件、网络40还是网络40服务。管理可采用IP连接性,但必须采用到视频电话15的相对较低带宽连接。
在正常操作下,视频电话15应在加电时执行硬件系统10测试的缩短版本。如果这失败了,那么视频电话15应在主屏幕上显示启动失败消息。可迫使终端进入扩展的硬件诊断模式。这可通过在单元加电时将键盘附接到USP端口或通过按压触摸屏74的右上角来进行。此模式将允许访问底层操作系统10和更强大的诊断功能,以确定是否存在硬件故障。
可包括一系列简单测试,在视频电话15通过启动测试但不为用户提供正确功能性的情况下,用户可运行所述测试。终端提供技术接口,其结合本地键盘(和鼠标)以辅助诊断单元或系统10的问题。这将允许进行对音频和视频等的各种诊断。
能够在远程控制下安全地下载视频电话15终端软件的新版本。“安全地”意味着在所下载版本中发生故障时能够返回到先前版本,而无需本地干涉(即,某人必须安装CD)。能够经由管理接口读取特定视频电话15终端上的软件的软件版本编号以及单元硬件序列号、组件版本号和序列号以及主要子组件的组件版本号。在系统10崩溃的情况下,视频电话15应当存储或已经存储用以辅助诊断所述崩溃原因的信息。一旦视频电话15已重新启动,必须可从远程场所在线检索此信息以供分析。
在受到可分配给此特征的存储空间的限制下,视频电话15从加电开始保持所有动作、事件和状态改变的运行日志。应使得能够存储至少一个月长的活动。此数据可能需要属于许多类别,例如含有用户数据的安全类别(例如所呼叫的号码将仅可由进行呼叫的用户披露)。一般数据,例如呼叫数目、呼叫状态(即,通话实例数目和每个实例的端点)、编码器36和解码器34特征、载体通道错误报告等不是如此敏感的信息。能够记录每次按键以作为帮助诊断系统10级别问题和重建事件链的方式可能是有帮助的。
视频电话15能够以IP级别和SIP级别两者将控制平面级别的交换复制到远程诊断终端(将线路监视器远程连接到视频电话15终端的等效物)。终端管理将监视许多参数,例如网络40质量。必须能够设置阈值且在超出那些阈值时产生警报。ATM接口和以太网接口两者均具有标准测量(例如,类似远程监控),其应可供视频电话15使用。视频电话15应能够将那些警报发送到一个或一个以上网络管理系统。
音频混合器
就音频混合器而言,可产生音频流和视频流且作为具有服务质量能力的ATM网络的一部分的第一节点80希望与第二节点82形成点对点呼叫。第二节点82仅具有音频能力,且为(例如)PSTN电话。第二节点82不是ATM网络的一部分。
第一节点80通过向SIP服务器(其也是ATM网络的一部分)发送信令消息来开始形成到第二节点82的呼叫,所述信息向服务器识别第二节点82是第一节点80正起始的呼叫的目的地。服务器已经具有关于第二节点82的地址信息,将所述地址信息添加到从第一节点80接收到的信令信息,且将信令消息与第二节点82的地址信息传输到音频混合器20,所述音频混合器20也是ATM网络的一部分。
当混合器20接收发源于第一节点80的信令信息时,其根据此信息确定第一节点80希望与第二节点82形成连接。混合器20接着向第二节点82发送邀请,通过所述邀请以某种方式进行通信,例如通过T1线或以太网但并非借助于ATM网络,以在其特征和数据需要以之提供给它的形式(以便它可理解所述数据)方面对其自身进行识别。作为响应,第二节点82向混合器20识别数据必须采用以使得第二节点82能理解所述数据的特定形式,且还向混合器20指示可以向其发送数据,因而可形成连接。
混合器20接着向第一节点80发送信号,指示其已经准备好形成连接。对于第一节点80,混合器20(其为ATM网络的一部分)代表第二节点82,且给予第一节点80这样的印象:第二节点82是ATM网络的一部分且类似于第一节点80。对于第二节点82,混合器20(其也是第二节点82所属的网络或连接性的一部分)代表第一节点80,且给予第二节点82这样的印象:第一节点80是第二节点82所属的相同网络或连接性的一部分,且类似于第二节点82。
第一节点80接着起始数据(包括音频数据)以及单播数据包到混合器20的流动,如此项技术中众所周知。当混合器20接收到所述包时,其缓冲所述包中的数据,如此项技术中众所周知,从而对于以第二节点82为目的地的来自第一节点80的包来说有效地终止连接。早先已通过发送到第二节点82的邀请而被告知数据需要采用以使得第二节点82可理解所述数据的形式的混合器20将所缓冲的数据置于必需的格式中,且接着在恰当的时间限制下,在从混合器20到第一节点80的新的且单独连接中有效地发送经恰当重新格式化的数据。以此方式,形成点对点呼叫,尽管其实际上包含两个不同的连接,且第一节点80和第二节点82都不会意识到利用两个连接来在第一节点80与第二节点82之间创建所需的点对点呼叫。类似地,当数据从第二节点82发送回第一节点80时,重复所述过程(尽管以相反顺序),使得在由混合器20接收到来自第二节点82的数据之后,混合器20将数据重新格式化为第一节点80可理解的形式,且将来自第二节点82的数据(所述数据已在混合器20中缓冲)单播到第一节点80。如果使用IP而并非ATM,那么混合器20将单播IP包发送到第一节点80,如此项技术中众所周知。
现将使用本发明来描述涉及会议的场景(还称为点对多点点对多点连接)。继续上文涉及点对点连接的讨论,第一节点80希望在所述连接中加入作为ATM网络的一部分且具有与第一节点80基本上相同的特征的第三节点84以形成会议。第一节点80向将主持会议的主机节点22发送信令邀请。主机节点22可以是第一节点80或其可以是不同的节点。第一节点80与主机节点22通过服务器进行通信以形成会议,且使第三节点84加入所述会议。出于信令目的,主机节点22邀请且与混合器20形成连接,并导致终止第一节点80与混合器20之间的原始信令连接。响应于来自第一节点80的关于使第三节点84加入连接的请求,主机节点22还邀请并与第三节点84形成连接。在作为ATM网络的一部分的节点将加入到连接中的每种情况下,信令通过服务器且被恰当路由,如此项技术中众所周知。主机节点22充当ATM网络中的会议连接的典型的主机节点。混合器20代表不是ATM网络的一部分但将成为整个会议连接的一部分的任何节点。
就ATM网络上的任何节点来说,混合器20使得作为连接的一部分但不是ATM网络的一部分的任何节点看起来似乎它们与ATM网络上的其它节点一样。通过信令连接,其中所述信令连接形成在主机与混合器20之间及混合器20与第二节点82(由混合器20代表)之间,将来自连接的所有节点的所需信息提供给所述节点中的每一者,以使得它们能够理解所述连接的所有其它节点并与之进行通信。事实上,主机节点22不仅通知所有其它节点关于其它节点的特征的信息,而且向所述节点返回它们最初向主机节点22提供的信息,使得基本上每个节点均取回其自己的信息。一旦分配此信息,便如同任何典型会议情形中通常将出现的那样,执行所述流信息。在ATM网络情形中,第一节点80和第三节点84将使用PMP树来以包形式将信息ATM多播到彼此且ATM多播到混合器20。在IP环境中,第一节点80和第三节点84将把包IP多播到网络中的所有节点(混合器20为用于此目的的节点),且只有作为连接一部分的那些节点将理解并利用作为连接一部分的特定包信息。
混合器20接收来自第一节点80和第三节点84的包,且对它们进行缓冲,如上文所述。根据所属领域的技术人员熟知的标准算法,由混合器20接收到的来自不同节点的包在被接收并混合或相加在一起时被重新格式化。在预定时间,如此项技术中众所周知,由混合器20重新格式化的数据接着被传输到第二节点82。以相同方式,但只是以相反顺序,由混合器20接收到来自第二节点82的数据并进行缓冲。接着,以重新格式化的形式将其多播到第一节点80和第三节点84。
当第四节点(其仅具有音频能力,如同第二节点82且不是ATM网络的一部分)加入到所述会议时,主机节点22与混合器20形成第二信令连接。混合器20又与第四节点形成不同连接,所述连接与混合器20已与第二节点82形成的连接分离。混合器20维持其正支持的会话的列表。在涉及主题会议的会话中,其识别通过混合器20的两个交叉连接。第一交叉连接是通过从主机节点22到第二节点82的信令连接,且第二交叉连接是从主机节点22到第四节点。以此方式,第一和第三节点80、84以及主机节点22相信,存在它们与之进行通信的两个单独节点,其代表第二节点82和第四节点。事实上,混合器20代表第二节点82和第四节点,且分别向第一节点80和第三节点84多播来自第二节点82和第四节点中每一者的数据以维持此错觉以及维持第二节点82和第四节点与第一节点80和第三节点80相像的错觉。
ViPr系统是高度先进的视频会议系统,其提供的“虚拟存在”会议质量远远超过当今市场上任何旧式视频会议系统的能力。所述ViPr系统依赖于点对多点点对多点SVC(PMP-SVC)和IP多播来在会议参与者间建立点对多点点对多点音频/视频媒体流。尽管参与ViPr会议的用户享受到空前的音频和视频质量,但需要使得其它非ViPr用户能够加入ViPr会议。系统10使得单播仅语音电话呼叫(即,PSTN、移动电话和SIP电话)能够添加到多方ViPr会议。
当前ViPr系统通过基于SIP的模拟和数字电话网关来提供对电话系统的支持。此功能性使得ViPr用户能够向电话用户发出点对点呼叫/从电话用户接收点对点呼叫。然而,它们不允许ViPr用户向ViPr会议添加电话呼叫。这是由于电话呼叫的单播本质和电话网关不能将电话流转换为PMP/多播流引起的。ViPr UAM将通过使得ViPr用户能够向ViPr会议添加单播电话呼叫来增强ViPr系统对电话的支持。
为了支持此功能性,ViPr UAM通过以下方式来添加ViPr终端与电话用户(即,PSTN、移动电话和SIP电话)之间的无缝会议功能性:将上游单播电话音频流转换为点对多点点对多点音频流(即,PMP-SVC或IP多播),且将下游PMP/多播ViPr音频流混合/转换为单播电话音频流,以及执行ViPr音频从宽带16位/16KHz PCM编码到G.711或G.722的下游音频代码转换。
由UAM提供的额外功能性是将IP/UDP音频流转换为ATM SVC音频流且反之亦然的中间体网关的功能性。此功能性使得部署在ATM环境下的ViPr系统与以太网网络上的基于SIP的IP语音(VoIP)电话网关之间的互用性成为可能。
UAM允许一个或一个以上ViPr电话与一个或一个以上电话网关一起工作。
UAM将支持以下列配置存在的具有单播音频装置的ViPr电话会议:
Figure A20071010674500561
类型1:支持仅具有一个作为参与者存在的音频单播装置的一个电话会议。
Figure A20071010674500562
类型2:支持多个电话会议。每个电话会议可能具有多个作为参与者存在的音频单播装置。
Figure A20071010674500563
类型3:支持多个电话会议,其中每个电话会议恰好具有一个作为参与者存在的音频单播装置。
优选地,20个参与者(单播装置加上ViPr电话)可由单个单播管理器应用程序服务。
单播装置将用于图1所示的配置中。
如图1所示,达到单播装置和从单播装置到ViPr的所有呼叫总是被发送到UAM。UAM实施B2B SIP UA来将单播装置连接到ViPr。
实例:位于POTS1处的用户A呼叫位于ViPr V1处的用户B。发生以下事件序列:
1.UD1(Mediatrics或任何单播装置)接收来自User_A的连接到User_B的请求。
2.UD1向UAM发送邀请。邀请中的To字段或显示器名称识别所述呼叫是针对User_B的。
3.UAM接收邀请作为传入呼叫C1。
4.UAM从C1上的邀请提取User_B的sip地址,且通过向V1发送邀请来向此用户起始呼叫C2。
5.UAM还将C1交叉连接到C2。
6.V1看到来自UAM的传入邀请,其由SDP识别为ViPr类别装置。因此,V1上的软件知道对等软件能够支持ViPr装置预期具有的所有功能性(包括替换/查阅等)。
7.例如位于V1处的User_B向邀请回复OK。
8.UAM将连接C2标记为准备好的。其接着在C1上发送OK。
此实例中的媒体流
以下列方式中的任一者发送V1与UD1之间的媒体流:
1.将媒体直接从V1发送到UD1。这可通过UAM写入正确SDP来进行。因此,当向V1发送邀请时,其放入UD1的IP地址、端口以用于接收。并且,当向UD1发送OK时,其放入V1的IP地址、端口作为接收地址。
2.媒体由UAM进行转继。在此情况下,UAM将数据从V1转继到UD1,且反之亦然。容易看到,如果UAM和ViPr通信经由ATM云来连接,那么可设定V1与UAM之间的SVC。因此,UAM充当ATM到以太网的网关以用于媒体流量。
进一步扩展实例1,User_A决定将位于V2处的User_B加入到会议中。发生下列事件:
1.UAM与V1之间的Sip连接由具有V1、V2和UAM作为参与者的电话会议C3取代。因此,B2B UA现正将电话会议(C3)与单播呼叫(C1)交叉连接。
2.UAM一直在C3与C4之间转继流量。上文选项11。其混合来自V1和V2的流量,并将其转继到UD1。其还将来自UD1的流量多播到V1和V2。
可将由UAM执行的功能性分成以下部份:
Figure A20071010674500571
SIP B2B UA单元[SBU]。此单元执行实施B2B SIP UA所需的sip信令。
Figure A20071010674500572
媒体交叉连接和混合器[MCMU]。
将通过三个过程来决定UAM功能性:SBU、单播混合器管理器和Sip堆栈,如图2所示。
Sip服务器过程将实施SIP功能性,且将向SBU提供提取的信令API(接口Ia)。接口Ia也保持不改变。
SBU实施呼叫控制和胶合逻辑以用于实施B2B UA。此单元得自呼叫管理器/Vupper编码基数。SBU还负责设定正确混合器流。出于此目的,SBU通过RPC而与UMM过程介接。
UMM实施用于交叉连接媒体流的功能性以及实施音频混合功能性。
SBU实施呼叫控制和胶合逻辑以用于实施B2B UA。SBU还负责设定正确混合器流。出于此目的,SBU通过RPC而与UMM过程介接。
会话
Class MediaSession
{
    int            SelfID    //自身ID
    CVString       GUID        //电话会议ID
    CVList         XIDList; //交叉连接列表
    GUID
}
SIP B2B交叉连接
Class SIPB2BCrossConnect
{
  int              SelfID    //自身ID
  int              SessionID  //作为其中成员的会话的ID
  Int              ViPrLegID //连接到ViPr的SiP呼叫支路
  Int              UDLegID    //连接到单播装置的支路
}
SIP B2B呼叫支路
Class SIPB2BCrossConnect
{
  int              SelfID    //自身ID-由呼叫管理者返回
  int              XID        //拥有此支路的交叉连接的ID
  SipCallLeg       ViPrLeg   //连接到ViPr的支路
  SipCallLeg       UDLeg      //连接到单播装置的支路
}
SBU单元的内部构造为如下:
如可从图3中看到,SBU的设计重新使用并扩展了由呼叫管理者提供的SIP/媒体流接口,以实施用于UAM的信令呼叫控制逻辑。
以下文字展现当用户A向User_B起始呼叫时的控制流程。
下文中,Sip服务器指的是位于UAM处的Sip服务器,SBU指的是位于UAM处的SBU,且UMM指的是位于UAM处的UMM。
为了进一步阐明所述实例,假定以下条件:
-整个网络是以太网网络
-V1的IP地址为172.19.64.101
-V2的IP地址为172.19.64.101
-连接到V1/V2云的UAM的接口的IP地址为172.19.64.51,连接到UD1云的UAM的IP接口为169.144.50.100
-UD1的IP地址为169.144.50.48
-将地址表示为<IP地址,端口>元组
-所述实例中的所有地址和端口是说明性的,不需要将其固定,而是它们由OS分配。
-在以下实例中,SBU(在UAM处)接收的所有SIP事件实际上由Sip服务器接收且接着被传到SBU。然而,出于简洁起见,未展示接收事件并将其传递到SBU的Sip服务器。
用于UD1与V1之间的P2P呼叫的控制流程
以上表格解释了对于通过呼叫会发生的情况。下文是当将此呼叫转换为会议电话时的控制流程。在此情况下,例如User_B将V2处的User_C加入到会议通话中。
进一步假定以下条件:
-V2的IP地址是171.19.64.102
Figure A20071010674500611
Figure A20071010674500621
起始与单播装置上的用户的会议
为了将另一ViPr用户添加到会议,重复步骤12到18。考虑另一单播装置用户(例如,位于POTS2上的User_D)所需的步骤。
假定以下条件:
S位于ViPr V2上的User_C决定将位于POTS2上的User_D加入会议中。
#  位置 动作
19  V2 将位于POTS2处的User_D引导到会议中。
20  H 向UAM发送具有以下信息的邀请:-User_A、User_B和User_C呼叫,连同它们在其上产生媒体流的地址-GUID=900
21  SBU 获得针对传入电话会议(C4)的请求,所述请求具有-GUID=900-目的地址=User_D的地址其接着执行以下任务:-其分配具有ID,XID=2,的SIP交叉连接。-其将C4添加到sip交叉连接XID=2。其还将在C4内的XID成员设置为XID=2。-其搜索所有会话结构以确定是否存在GUD=900的会话。其发现D=100的会话与此电话会议相关联。-其接着将XID=2的SIP交叉连接添加到附接至会话SID=100的交叉连接列表。此时,存在两个SIP交叉连接(XD=1和XID=2),其为SIP会话SID=100的一部分。-其还在sip交叉连接XD=2内存储信息,以指示其与会话=100相关联。-其分配用于从User_D接收流量的地址<169.144.50.51,40011>。-其分配媒体通道CHD=4以用于从User_D<169.144.50.51,40012>接收流量。-其通过向UD1发送邀请而针对User_D起始连接C5。所述邀请含有关于UD1应当在<169.144.50.51,40004>处针对此呼叫发送音频媒体流的信息。-其将C5添加到XID=2的sip交叉连接。因此,XID=2现将CID=4和CD=5连接为背靠背SIP呼叫。-其还将C5的XID成员设置为XID=2。
22  UD1 从UAM接收邀请,且向UAM发送回OK。其在所述OK中指示:其发送用于呼叫C5的数据时所在的地址是<169.144.50.48,50002>。
Figure A20071010674500641
25  SBU 在C3上获得重新邀请,所述重新邀请指示在多播地址<239.192.64.51,40012>上传输的另一用户User_D其接着执行以下任务:-在C3上通过sip服务器向主机发送回OK。-其提取C3是其中成员的sip交叉连接,XID=1。-其从sip交叉连接XID=1中提取会话SID=100-其分配通道CHID=8以从User_D接收音频。-其接着指示UMM接收来自User_D的流量并将其混合到会话SID=100中。如下:-SBU通知UMM:通道=8应当用于向User_D发送数据/从User_D接收数据。因此,通道=8与发送地址和接收地址<239.192.64.51,40012>相关联。-SBU还将通道CHID=8的会话D设置为SID=100。[注意:由于UAMD将IP套接口编程为从不接收在多播地址上传输的包,因而在CHID=8上将接收不到任何流量。这恰好就是所需的。]
26  V1和V2 向由主机发送的重新邀请发送OK。
27  H 从所有参与者接收OK,所述电话会议现具有四个方在通话中。其中两个是单播装置。
用于将第二单播用户添加到会议的控制流程
UMM实施用于交叉连接媒体流的功能性以及实施音频混合功能性。
部署场景1:
参看图4,此场景涵盖两种情况:
多方ViPr音频/视频会议中的ViPr用户将单播仅音频电话用户添加到会议:
在此情况下,多方ViPr会议中的ViPr用户决定将单播电话用户添加到会议。因而,所述参与者中的一者向目的电话号码起始呼叫。ViPr SIP服务器将呼叫重定向到ViPrUAM。ViPr UAM终止ViPr仅音频呼叫,且经由电话网关向目的电话建立背靠背呼叫。
一旦建立了呼叫,ViPr UAM便将从所述电话接收的单播G.711/G.722音频流转换为PMP/多播流,且将其转发到ViPr终端而没有任何代码转换。另一方面,ViPr UAM执行将从各种ViPr终端接收的宽带16位/16KHz PCM ViPr音频流代码转换且混合为一个G.711或G.722单播音频流,并将其转发到电话目的地。
具有电话用户的点对点仅音频会议中的ViPr用户将另一ViPr用户添加到所述会议:
在此情况下,具有电话用户(T)的点对点仅音频呼叫中的ViPr用户(V1)决定将另一ViPr用户(V2)添加到所述会议。因而,ViPr用户V1向目的ViPr用户V2起始音频/视频呼叫。ViPr系统撤销V1与ViPr UAM之间已建立的点对点呼叫,且在V1、V2和ViPr UAM之间重新建立PMP/多播呼叫。
ViPr UAM终止新的ViPr音频/视频呼叫,且将其桥接到已经建立的背靠背电话呼叫。在此整个过程中,电话会议保持为活动的,且切换对于电话用户是透明的。
一旦建立了所述呼叫,ViPr UAM将从电话接收到的单播G.711/G.722音频流转换到PMP/多播流,并将其转发到ViPr终端而没有任何代码转换。另一方面,ViPr UAM执行将从各种ViPr终端接收到的宽带16位/16KHz PCM ViPr音频流代码转换且混合为一个G.711或G.722单播音频流,并将其转发到电话目的地。
ViPr使用会话起始协议(SIP)作为建立、修改和清除多流多媒体会话的手段。UAM将通过以下方式在ViPr终端与电话用户(即,PSTN、移动电话和SIP电话)之间添加会议能力:将上游单播仅语音电话流转换为点对多点流(即,PMP-SVC或IP多播),且将下游ViPr多播/PMP音频流转换为单播电话仅语音流,以及执行ViPr音频的从宽带16位/16KHz PCM编码到G.711或G.722的下游音频代码转换。
部署场景2:
参看图5,此场景涵盖两种情况:
电话用户呼叫ViPr用户:
在此情况下,电话用户向ViPr用户起始呼叫(仅音频)。电话网关将呼叫重定向到ViPr UAM。ViPr UAM终止电话呼叫,且向目的ViPr终端建立背靠背ViPr仅音频呼叫。
一旦建立了所述呼叫,ViPr UAM便将从电话接收到的G.711/G.722音频流转发到ViPr终端而没有任何代码转换。另一方面,ViPr UAM执行将ViPr音频流从宽带16位/16KHzPCM代码转换为G.711或G.722,且将其转发到电话目的地。
ViPr用户呼叫电话用户:
在此情况下,ViPr用户向电话用户起始呼叫。ViPr SIP服务器将呼叫重定向到ViPrUAM。ViPr UAM终止ViPr仅音频呼叫,且经由电话网关向目的电话建立背靠背PSTN呼叫。以与在先前段落中描述的方式相同的方式来进行代码转换。
图6给出UAM的典型使用背景。由UAM提供的特征如下。
特征1
例如,ViPr V1和V2在点对点呼叫中,且它们希望使单播装置UD1加入电话会议。换句话说,希望将在会议中的UD1、V1和V2形成电话会议。例如位于V1处的用户要求位于UD1处的用户加入具有V1和V2作为其他参与者的电话会议。此要求由SIP服务器中的一者转发到UAM。
UAM接着执行以下任务:
-代表UD1加入会议呼叫。将此会议呼叫称为C1。
-还与单播装置形成点对点呼叫。将此会议呼叫称为C2。
-将在C2上接收到的音频数据转继到C1。
-在呼叫C2中接受来自V1和V2参与方的视频数据,混合此数据并将其转发到UD。
特征2
考虑以上图中的vipr网是ATM且UD网是IP网络的情况。同样,假设需要针对音频尽可能地在ATM网络上仅使用SVC而并非LANE/CLIP。这可能是出于安全性考虑或由于性能问题。
在此情况下,如果位于vipr网上的vipr V1希望使单播装置(UD1)加入音频交谈,那么使用UAM来提供用以在ATM网络中使用SVC和在IP网络中使用IP的功能性。
为了进行此,将从V1到UD1的所有呼叫分解成从V1到UAMD和从UAMD到V2的两种呼叫。
可将由UAM支持的特征所需的配置分成以下类别:
-用于ViPr到UD呼叫的配置。
-用于UD到ViPr呼叫的配置。
-普通配置。
普通配置
使得B2BUA SIP UA在任何所需端口(除了5060)上运行。这通过将vipr.ini文件修改为包括以下参数来进行:
SIP_Port=7070[任何有效端口编号]
用于ViPr到UD呼叫的配置
对于典型ViPr电话,当用户拨打“号码”时,其“呼叫请求”被发送到SIP服务器,所述SIP服务器接着将呼叫请求转发到恰当目的地。然而,此情况是不同的。在此情况下,当用户说我希望向单播装置(UD1)讲话时,SIP服务器将所述请求转发到UAM。另外,它还将信息放入请求中,以识别应将此呼叫转发到UD1。因此,SIP服务器经编程以将针对由UAM装置服务的SIP-URI的呼叫路由到恰当UAMD服务器。
还能够规定默认单播装置SIP地址,由UAM接收的所有呼叫被转发到所述SIP地址。此默认地址可通过在vipr.ini文件中添加下列行来指定:
UD_SERVER_ADDRESS=169.144.50.48
X_FORWARD_AVAILABLE=0
应注意到,当从单播装置向ViPr发出呼叫时,必须将所述呼叫传递到UAM。为了进行此,在单播装置处执行恰当配置,对此请参考特定针对单播装置的文献。
用于UD到ViPr呼叫的配置
针对ViPr而在UD处发源的呼叫被路由到UAM。一种用于实现此的方式是通过编程UD来将所有呼叫引导或转接到UAM。同样,在针对UAM的呼叫请求中指定呼叫(例如V1)的最终目的地。通常,此地址将是SIP消息中的To字段。在UD或SIP服务器处执行这些配置。
另外,当UAM接收来自UD的呼叫请求时,其将所述请求转发到网关Marshall服务器以用于对被叫方执行稳健性检查。此网关地址可在vipr.ini文件中指定
GatewayMarshallServer=sip.eng.fore.com:5065
缩写词列表
ATM异步传送模式
ISDN综合业务数据网
IP网际协议
LAN局域网
MC多播(IP)
MCMU媒体交叉连接和混合器
MCU媒体会议单元
PBX专用小交换机(专用电话交换机)
PCM脉冲编码调制
PMP点对多点(ATM)
POTS“老式电话系统”
PRI主要速率接口(ISDN)
PSTN公用交换电话网
SBU SIP背靠背用户代理
SIP会话起始协议
SVC交换型虚拟电路(ATM)
UAM单播音频混合器
ViPrTM虚拟存在系统
WAN广域网
尽管已出于说明目的在前述实施例中详细描述了本发明,但将了解到此类细节仅仅是出于说明目的,且在不偏离本发明精神和范围的情况下所属领域的技术人员可对此作出变化,本发明精神和范围可由所附权利要求书描述。

Claims (22)

1.一种电话会议系统,其包括:
网络;以及
多个节点,其彼此通信以形成在每个节点处的实况场景的会议,每个节点具有带有显示布局的视频显示器,所述节点中的至少一者个别地至少部分控制所述会议中每个节点的所述显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
2.根据权利要求1所述的系统,其中每个节点被迫使以所述特定格式显示视频。
3.根据权利要求2所述的系统,其中每个节点被锁定于所述特定格式。
4.根据权利要求3所述的系统,其中每个节点被迫使在所述显示器上的特定位置处显示来自所述会议的其它节点的特定视频流。
5.根据权利要求4所述的系统,其中每个节点控制在所述屏幕中未由所述节点中的一者控制的任何部分上显示什么。
6.根据权利要求5所述的系统,其中所述节点中的所述一者完全控制每个节点的所述显示布局。
7.一种用于提供电话会议的方法,其包括以下步骤:
利用通过网络彼此通信的多个节点形成在每个节点处的实况场景的会议,每个节点具有带有显示布局的视频显示器;以及
利用所述节点中的至少一者个别地至少部分控制所述会议中每个节点的所述显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
8.一种用于具有其它节点的网络的电话会议节点,其包括:
网络接口,其与所述其它节点通信以形成在每个节点处的实况场景的会议;以及控制器,其个别地至少部分控制所述会议中每个节点的显示布局,所述显示布局具有能够对于每个节点为独特的特定格式。
9.一种用于在至少三个节点之间进行电信会议的方法,其包括以下步骤:
在所述节点之间建立在每个节点处的实况场景的会议;
对所述会议作出改变;以及
仅将所述改变传达到所述节点。
10.根据权利要求9所述的方法,其中所述传达步骤包括以下步骤:仅将所述改变仅传达到受所述改变影响的节点。
11.根据权利要求10所述的方法,其中所述改变步骤包括以下步骤:对所述节点中的一者的状态作出改变。
12.根据权利要求11所述的方法,其中所述改变步骤包括以下步骤:对所述会议的状态作出改变。
13.根据权利要求12所述的方法,其包括以下步骤:将来自所述节点中的一者的定向消息仅发送到少于全部的某些参与方。
14.根据权利要求13所述的方法,其中所述建立步骤包括以下步骤:基于SIPNOTIFY/OK技术来建立所述会议。
15.一种电话会议系统,其包括:
网络;以及
多个节点,其通过所述网络彼此通信以形成在每个节点处的实况场景的会议,当发生改变时,每个节点仅将所述改变传达到其它节点。
16.根据权利要求15所述的系统,其中每个节点仅将所述改变仅传达到受所述改变影响的节点。
17.根据权利要求16所述的系统,其中对所述会议的所述改变包括对所述节点中的一者的状态的改变。
18.根据权利要求17所述的系统,其中对所述会议的所述改变包括对所述会议的状态的改变。
19.根据权利要求18所述的系统,其中所述节点中的一者将定向消息仅发送到少于全部的某些节点。
20.根据权利要求19所述的系统,其中所述多个节点基于SIP NOTIFY/OK技术来建立所述会议。
21.根据权利要求20所述的系统,其中每个节点具有控制器和网络接口,所述网络接口与所述控制器和所述网络通信,所述控制器对其节点作出任何改变,且通过所述网络接口将所述改变通过所述网络发送到所述会议的其它节点。
22.一种用于具有其它节点的网络的电话会议节点,其包括:
网络接口,其与所述其它节点通信以形成在每个节点处的实况场景的实况会议;
以及
控制器,其在发生改变时仅将所述改变传达到所述其它节点。
CN200710106745.6A 2006-06-16 2007-06-15 会议布局控制和控制协议 Active CN101090475B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US81447606P 2006-06-16 2006-06-16
US60/814,476 2006-06-16

Publications (2)

Publication Number Publication Date
CN101090475A true CN101090475A (zh) 2007-12-19
CN101090475B CN101090475B (zh) 2016-02-17

Family

ID=38508691

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200710106745.6A Active CN101090475B (zh) 2006-06-16 2007-06-15 会议布局控制和控制协议

Country Status (5)

Country Link
EP (1) EP1868348B1 (zh)
JP (1) JP5129989B2 (zh)
CN (1) CN101090475B (zh)
CA (1) CA2591862A1 (zh)
RU (1) RU2396730C2 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102007753A (zh) * 2008-02-15 2011-04-06 爱立信股份有限公司 仅使用初始信号消息的电信会话的方法和系统
CN106576153A (zh) * 2014-01-10 2017-04-19 旋转型机器人有限公司 用于在视频会议操作期间控制机器人支架的系统及方法
CN106921843A (zh) * 2017-01-18 2017-07-04 苏州科达科技股份有限公司 数据传输方法及装置
CN107578777A (zh) * 2016-07-05 2018-01-12 阿里巴巴集团控股有限公司 文字信息显示方法、装置及系统、语音识别方法及装置
CN109862305A (zh) * 2019-01-02 2019-06-07 视联动力信息技术股份有限公司 一种视联网开会的方法、装置以及开会时调流的方法
CN110798650A (zh) * 2019-09-24 2020-02-14 福建星网智慧科技股份有限公司 一种基于rtp的多系统媒体流传输控制方法和装置

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE602007001164D1 (de) 2006-06-16 2009-07-09 Ericsson Ab System, Verfahren und Knoten um die Anzahl von Audioströmen in einer Telekonferenz zu begrenzen
JP5450444B2 (ja) * 2007-12-20 2014-03-26 テレフオンアクチーボラゲット エル エム エリクソン(パブル) マルチメディア通話を処理するための方法及び装置
CN101610324A (zh) * 2008-06-18 2009-12-23 深圳华为通信技术有限公司 提示呼叫进展状态的方法、会议控制设备以及会议系统
US8301879B2 (en) * 2009-01-26 2012-10-30 Microsoft Corporation Conversation rights management
CA2850626A1 (en) * 2010-09-15 2012-03-22 Borys Evgenijovych Panchenko Method for automated digital multi-program multi-signal commutation
CN102469295B (zh) * 2010-10-29 2015-03-11 华为终端有限公司 会议控制方法及相关设备和系统
EP2749021B1 (en) 2011-07-29 2020-02-19 Cisco Technology, Inc. Method, computer- readable storage medium, and apparatus for modifying the layout used by a video composing unit to generate a composite video signal
JP2013242357A (ja) 2012-05-18 2013-12-05 Ricoh Co Ltd 情報処理装置、情報処理方法、およびプログラム
JP6146019B2 (ja) 2013-01-25 2017-06-14 日本電気株式会社 通信処理システム、通信処理方法、通信処理装置、通信端末およびそれらの制御方法と制御プログラム
US20220006661A1 (en) * 2014-07-27 2022-01-06 Yogesh Rathod Access and communicate live audio streaming under micro channel or keyword(s)
CN111567037B (zh) 2017-11-10 2022-12-06 惠普发展公司,有限责任合伙企业 会议环境监视
US12009909B2 (en) * 2020-09-19 2024-06-11 Ibiquity Digital Corporation Content linking multicast streaming for broadcast radio
CN116260797A (zh) * 2021-12-09 2023-06-13 北京有竹居网络技术有限公司 一种音视频数据传输的处理方法、装置、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1472962A (zh) * 2002-07-10 2004-02-04 ������������ʽ���� 多参与方视频会议系统、相关方法以及反向信道通信网
CN1561637A (zh) * 2001-10-01 2005-01-05 意大利电信股份公司 用于传输多媒体信息流的系统和方法,例如用于远程教学
CN1679077A (zh) * 2002-08-30 2005-10-05 摩托罗拉公司 具有双向信息传递性能的显示器屏保及其方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1013803A (ja) * 1996-06-18 1998-01-16 Hitachi Ltd 多地点テレビ会議制御装置
US6288739B1 (en) * 1997-09-05 2001-09-11 Intelect Systems Corporation Distributed video communications system
KR100282954B1 (ko) * 1998-12-02 2001-03-02 이계철 단일 스트림 엠펙 동영상과 정지화상의 혼용제어방법
KR100283148B1 (ko) * 1998-12-03 2001-03-02 구자홍 단지점 화상회의 단말기를 통한 다지점 화상회의 시스템
JP2000184346A (ja) * 1998-12-17 2000-06-30 Toshiba Corp 情報端末装置及び情報通信システム並びに表示状態制御方法
JP2000188743A (ja) * 1998-12-21 2000-07-04 Nec Corp 多地点テレビ会議装置における一斉放送方式
JP2001313915A (ja) * 2000-04-28 2001-11-09 Matsushita Electric Ind Co Ltd テレビ会議装置
CN1192619C (zh) * 2002-01-08 2005-03-09 华为技术有限公司 会议电视系统中多画面显示的实现方法
US20040008249A1 (en) 2002-07-10 2004-01-15 Steve Nelson Method and apparatus for controllable conference content via back-channel video interface
RU2240657C1 (ru) * 2003-12-29 2004-11-20 Дмитриев Григорий Гемфриевич Способ и система осуществления видеоконференций
US20050237931A1 (en) 2004-03-19 2005-10-27 Marconi Communications, Inc. Method and apparatus for conferencing with stream selectivity
JP2005333446A (ja) * 2004-05-20 2005-12-02 Nakayo Telecommun Inc 通信会議システム、通信会議方法、および通信端末
US7499075B2 (en) * 2004-09-28 2009-03-03 Seiko Epson Corporation Video conference choreographer

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1561637A (zh) * 2001-10-01 2005-01-05 意大利电信股份公司 用于传输多媒体信息流的系统和方法,例如用于远程教学
CN1472962A (zh) * 2002-07-10 2004-02-04 ������������ʽ���� 多参与方视频会议系统、相关方法以及反向信道通信网
CN1679077A (zh) * 2002-08-30 2005-10-05 摩托罗拉公司 具有双向信息传递性能的显示器屏保及其方法

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102007753A (zh) * 2008-02-15 2011-04-06 爱立信股份有限公司 仅使用初始信号消息的电信会话的方法和系统
CN106576153A (zh) * 2014-01-10 2017-04-19 旋转型机器人有限公司 用于在视频会议操作期间控制机器人支架的系统及方法
CN107578777A (zh) * 2016-07-05 2018-01-12 阿里巴巴集团控股有限公司 文字信息显示方法、装置及系统、语音识别方法及装置
CN106921843A (zh) * 2017-01-18 2017-07-04 苏州科达科技股份有限公司 数据传输方法及装置
CN106921843B (zh) * 2017-01-18 2020-06-26 苏州科达科技股份有限公司 数据传输方法及装置
CN109862305A (zh) * 2019-01-02 2019-06-07 视联动力信息技术股份有限公司 一种视联网开会的方法、装置以及开会时调流的方法
CN110798650A (zh) * 2019-09-24 2020-02-14 福建星网智慧科技股份有限公司 一种基于rtp的多系统媒体流传输控制方法和装置

Also Published As

Publication number Publication date
RU2007122374A (ru) 2008-12-20
EP1868348B1 (en) 2014-01-15
RU2396730C2 (ru) 2010-08-10
EP1868348A2 (en) 2007-12-19
JP2008061220A (ja) 2008-03-13
JP5129989B2 (ja) 2013-01-30
EP1868348A3 (en) 2010-11-03
CA2591862A1 (en) 2007-12-16
CN101090475B (zh) 2016-02-17

Similar Documents

Publication Publication Date Title
CN101090475B (zh) 会议布局控制和控制协议
CN101090328A (zh) 将独立多媒体源关联到会议呼叫中
CN101090329A (zh) 智能音频限制方法、系统和节点
JP4372558B2 (ja) 電気通信システム
US20070291108A1 (en) Conference layout control and control protocol
US20070291667A1 (en) Intelligent audio limit method, system and node
US20070294263A1 (en) Associating independent multimedia sources into a conference call
US20010056466A1 (en) Communication system architecture for voice first collaboration
US20100225736A1 (en) Virtual Distributed Multipoint Control Unit
EP1949682A1 (en) Method for gatekeeper streaming
US8379821B1 (en) Per-conference-leg recording control for multimedia conferencing
CN117135150A (zh) 一种基于音视频融合通讯技术的优化方法及系统
Force Ipvtf
MX2007006914A (es) Metodo, sistema y nodo de limite de audio inteligentes.
MX2007006910A (es) Asociacion de fuentes de multimedia independientes en una llamada de conferencia.
MX2007006912A (es) Control de modelo de conferencia y protocolo de control.

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant