CN105359515A - 视频电话中的视频暂停指示 - Google Patents

Abstract

本发明涉及视频电话，且更确切地说，涉及用于检测视频电话应用程序中的视频暂停的技术。在本发明的一个实例中，用于视频电话的方法包括：在接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置；及基于视频控制包中含有的信息确定所述发送装置已暂停所述视频电话通话的视频部分。

Description

视频电话中的视频暂停指示

相关申请案

本申请案主张2013年7月26日提交的第2477/MUM/2013号印度专利申请案的权益，所述申请案的全部内容以引用的方式并入本文中。

技术领域

本发明涉及视频电话，且更确切地说，涉及用于检测视频电话应用程序中的视频暂停的技术。

背景技术

例如移动电话等的通信装置可包含音频捕获装置，例如，麦克风或语音合成器；用于产生音频包(或帧)的音频编码器；视频捕获装置，例如，相机；及用于产生视频包帧的视频编码器。电话可使用通信协议层，例如，实时传输协议(RTP)、无线电链路协议(RLP)、媒体接入控制(MAC)及物理(PHY)层。在视频电话应用程序中，通信装置可将视频及音频RTP包置于RLP队列中。MAC层模块可从RLP队列的内容中产生MAC层包。MAC层包可转换成PHY层包，以在通信信道上发射到另一通信装置。

发明内容

本发明涉及视频电话，且更确切地说，涉及用于检测视频电话应用程序中的视频暂停的技术。

在本发明的一个实例中，用于视频电话的方法包括：在接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置；及基于视频控制包中含有的信息确定发送装置已暂停视频电话通话的视频部分。

在本发明的另一实例中，配置用于视频电话的设备包括用于在接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置的装置；及用于基于视频控制包中含有的信息确定发送装置已暂停视频电话通话的视频部分的装置。

在本发明的另一实例中，配置用于视频电话的设备包括接收装置，其经配置以在接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置并且基于视频控制包中含有的信息确定发送装置已暂停视频电话通话的视频部分。

在另一实例中，本发明描述一种计算机可读存储媒体，其存储当执行时致使用于视频电话的装置的一或多个处理器执行以下操作的指令：在接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置；及基于视频控制包中含有的信息确定发送装置已暂停视频电话通话的视频部分。

在附图及以下说明中阐述一或多个实施例的细节。

附图说明

图1说明视频及音频编码及解码系统。

图2描绘在通用包交换(PS)网络上的双向VT通话的简化框图。

图3是展示针对在使用呼叫保持显式信令的视频暂停期间通话降级的使用情况的信号流的概念图。

图4是展示针对使用本发明的技术的视频暂停检测的一个使用情况的实例信号流的概念图。

图5是展示针对使用本发明的技术的视频暂停检测的另一使用情况的另一实例信号流的概念图。

图6是展示根据本发明的技术的实例方法的流程图。

具体实施方式

本发明涉及视频电话，且更确切地说，涉及用于检测视频电话应用程序中的视频暂停的技术。用于指示及检测视频电话通话期间的视频暂停的当前技术可导致参与通话的通信装置之间的不明确状态。在一些情况下，在先前已暂停的视频电话通话的视频部分重新启动之后，用于指示视频暂停的当前技术可致使通话中的通信装置中的一者假定单向视频通话(仅从一个装置发送的视频)实际上静止，而另一通信装置可假定双向视频通话(从双方发送的视频)已恢复。本发明的技术涉及避免此不明确状态的用于指示及确定视频暂停的技术。

图1说明可利用本发明的技术的视频编码及解码系统10。系统10包含在发射信道16上将数据发送到解码器系统14的编码器系统12。编码器系统12可处于第一视频通信装置中并且可包含音频源17、视频源18、视频编码器20、音频编码器22、实时传输协议(RTP)/用户数据报协议(UDP)/因特网协议(IP)/点对点协议(PPP)转换模块26、无线电链路协议(RLP)队列28、MAC层模块30及物理(PHY)层模块32。代替图1中展示的元件或除了图1中展示的元件之外，编码器系统12的其它实施例可包含其它元件。编码器系统12的其它实施例可包含比图1中展示的元件少的元件。

解码器系统14可处于另一视频通信装置中并且可包含PHY层模块34、MAC层模块36、RLP队列38、RTP/UDP/IP/PPP转换模块40、视频解码器42、音频解码器44、音频输出单元46及视频输出单元48。代替图1中展示的元件或除了图1中展示的元件之外，解码器系统14的其它实施例可包含其它元件。解码器系统14的其它实施例可包含比图1中展示的元件少的元件。

系统10可经由发射信道16提供例如，用于视频电话(VT)的双向视频及音频发射。反向编码、解码及转换模块可提供于信道16的相对端上。在一些实施例中，编码器系统12及解码器系统14可实施于视频通信装置内，例如，装备用于视频串流、VT或两者的无线移动终端。移动终端可根据例如RTP、UDP、IP或PPP的包交换标准支持VT。

RTP/UDP/IP/PPP转换模块26将合适的RTP/UDP/IP/PPP标头数据添加到从音频编码器22及视频编码器20接收到的音频及视频数据，并且将所述数据置于RLP队列28中。RTP在UDP的顶部上运行，而UDP在IP的顶部上运行且IP在PPP的顶部上运行。MAC层模块30从RLP队列28的内容中产生MACRLP包。PHY层模块32将MACRLP包转换成PHY层包以在信道16上发射。

解码系统14的PHY层模块34及MAC层模块36以反向方式操作。PHY层模块34将从信道16接收到的PHY层包转换成MACRLP包。MAC层模块36将MACRLP包置于RLP队列38中。RTP/UDP/IP/PPP转换模块40从RLP队列38中的数据除去标头信息，并且重新组合视频及音频数据以分别传送到视频解码器42及音频解码器44。

系统10可经设计以支持一或多个无线通信技术，例如，码分多址(CDMA)、频分多址(FDMA)、时分多址(TDMA)，或正交频分复用(OFDM)或另一合适的无线技术。以上无线通信技术可根据各种无线电接入技术中的任一者传送。举例来说，CDMA可根据cdma2000、宽带CDMA(WCDMA)标准、3G、4G、LTE或任何其它基于CDMA的空中接口传送。TDMA可根据全球移动通信系统(GSM)标准传送。通用移动通信系统(UMTS)标准准许GSM或WCDMA操作。对于VT应用程序，系统10可经设计以支持高数据速率(HDR)技术，例如，cdma2000、1xEV-DO、版本0、修订版A或后续EV-DO版本。

视频源18可为视频捕获装置，例如，一或多个摄像机、一或多个视频存档，或摄像机及视频存档的组合。视频编码器20根据例如MPEG-4、H.264/AVC(高级视频译码)，或高效视频译码(HEVC)等的视频压缩方法产生经编码视频数据。还可使用其它视频压缩方法，例如，国际电信联盟(ITU)H.263、VP9、MPEG-2，或其它标准化或专用方法。视频编码器20可提供大体上CODEC相关的视频源速率控制方案。举例来说，视频编码器20可适用于根据HEVC、MPEG4、ITUH.263、ITUH.264或另一标准或技术的视频编码。在一个实例中，视频编码器20可由DSP或嵌入的逻辑核心实施。

音频源17可为例如麦克风或语音合成器装置等的音频捕获装置。音频编码器22可对音频数据进行编码以伴随视频数据。音频数据可根据例如自适应多速率窄带(AMR-NB)或其它技术等的音频压缩方法进行编码。对于VT应用程序，视频将准许一方观看VT会议，并且音频将准许这一方的说话声被听到。

在操作中，RTP/UDP/IP/PPP转换模块26从视频编码器20及音频编码器22获得视频及音频数据包。RTP/UDP/IP/PPP转换模块26将合适的标头信息添加到音频包并且将所得数据插入到RLP队列28内。同样地，RTP/UDP/IP/PPP转换模块26将合适的标头信息添加到视频包并且将所得数据插入到RLP队列28内。MAC层模块30从RLP队列28检索数据并且形成MAC层包。每个MAC层包携载包含于RLP队列28内的RTP/UDP/IP/PPP标头信息及音频或视频包数据。

音频包可独立于视频包插入到RLP队列28中。在一些情况下，从RLP队列28的内容中产生的MAC层包将仅携载标头信息及视频包数据。在其它情况下，MAC层包将仅携载标头信息及音频包数据。

在一些情况下，MAC层包将取决于RLP队列28的内容携载标头信息、音频包数据及视频包数据。MAC层包可根据无线电链路协议(RLP)进行配置并且可称为MACRLP包。PHY层模块32将MACRLP音频-视频包转换成PHY层包以在信道16上发射。

信道16将PHY层包载送到解码器系统14。举例来说，信道16可为有线连接，例如，局域或广域有线网络。或者，如本文所描述，信道16可为无线信道，例如，蜂窝、卫星或光信道。

信道条件可为有线及无线信道的关注点，但对于在无线信道16上执行的移动VT应用程序尤其存在问题，其中信道条件可由于时强时弱或拥塞而受损。举例来说，信道16的特征可在于具有根据信道条件变化的吞吐量的反向链路(RL)。可基于如通过当前无线信道发射速率、无线基站活动及发射功率限制中的一或多者表示的信道条件估计吞吐量。举例来说，可基于当前MAC层数据速率、反向活动位(RAB)及功率放大器(PA)限值确定信道条件。

视频编码器20可相对于目标编码速率保持表示经编码视频的量的虚拟视频缓冲区。目标编码速率可为指定用于在信道16上发射的视频包的最大编码速率。视频编码器20可控制视频从视频源18的实际编码速率。

解码器系统14的PHY层模块34从PHY层包识别MAC层包并且将内容重新组合到MACRLP包中。MAC层模块36随后重新组合MACRLP包的内容以提供视频及音频包以供插入到RLP队列38内。RTP/UDP/IP/PPP模块40移除伴随的标头信息并且将视频包提供到视频解码器42及将音频包提供到音频解码器44。

视频解码器42对视频数据帧进行解码以产生大量视频数据以供驱动显示装置使用。音频解码器44对音频数据进行解码以产生音频信息以例如经由音频扬声器呈现给用户。

视频电话(VT)涉及携载音频及视频数据的包在至少两个装置(例如，系统12及14)之间的实时通信。第一VT装置12包含从例如摄像机或视频存档的视频捕获装置18中获得视频的视频编码器20并且产生视频包。类似地，VT装置12中的音频编码器22从例如麦克风或语音合成器等的音频捕获装置17中获得音频并且产生音频包。将视频包及音频包置于RLP队列28中。MAC层模块30从RLP队列28的内容中产生MAC层包。MAC层包转换成PHY层包，以在通信信道16上发射到第二VT装置14。

在移动VT应用程序中，VT装置(无线终端)经由无线前向链路(FL)(即，“下行链路”)从基站接收PHY层包。VT装置经由无线反向链路(RL)(即，“上行链路”)将PHY层包发射到基站。每个VT装置包含PHY及MAC层以转换接收到的PHY及MAC层包且将包载荷重新组合到音频包及视频包中。VT装置内的视频解码器42对视频数据进行解码，以经由显示装置(视频输出端)48呈现给用户。VT装置内的音频解码器44对音频数据进行解码以经由音频扬声器(音频输出端)46输出。

图2描绘在通用包交换(PS)网络52上的双向VT通话的简化框图。PS网络52可为LTE、HSPA、(e)HRPD、WiFi、卫星、同轴电缆、电力线通信，以及其类似物，或以上各者中的任一者的组合。在装置A的发射侧上，VT通话的音频/视频在麦克风/扬声器56及相机/显示器54处捕获、通过处理单元58预处理(如果可适用)、编码/压缩、RTP/UDP/IP封包化且传递到调制解调器。在装置A的接收侧上，接收到的音频/视频包在发送到麦克风/扬声器56及相机/显示器54之前通过处理单元58解调、解封包化、解抖动、解码、AV同步及后处理(如果可适用)。

同样地，在装置B的发射侧上，VT通话的音频/视频在麦克风/扬声器66及相机/显示器64处捕获、通过处理单元68预处理(如果可适用)、编码/压缩、RTP/UDP/IP封包化且传递到调制解调器。在装置B的接收侧上，接收到的音频/视频包在发送到麦克风/扬声器66及相机/显示器64之前通过处理单元68解调、解封包化、解抖动、解码、AV同步及后处理(如果可适用)。

音频/视频RTCP包也与音频/视频RTP包一起发送，以用于AV同步、媒体性能相关统计、速率调适及其类似者。RTCP包与RTP包相比较少出现。也就是说，RTCP包的控制信息通常每隔500毫秒至每隔2秒发信号通知，而RTP包更经常出现。

在典型的两方视频电话(VT)通话期间，视频可由于用户动作在一或两个方向上暂停一或多次。举例来说，两侧上的用户可将VT应用程序移动到装置后台以简单执行一些其它任务。举例来说，在VT通话当中，用户中的一者可使用手机摄像头来获取图片、快速检查电子邮件或执行另一任务。因此，VT通话的相机资源可释放且在此情况下没有视频发送到对等方。也就是说，当用户将VT应用程序移动到后台时，视频通常不再发送到VT通话中的另一方。因为后台中的VT应用程序的用户可不再参看指示发射了多少视频的预览窗口，所以视频可停止。为了提供增加的私密性且为了避免在不通知的情况下发送视频，VT应用程序将通常停止发送视频RTP包。然而，音频包将继续且VT不终止。视频流停止在一或多个方向上流动而话音对话持续的现象通常被称为视频暂停。

返回参考图2，VT系统得益于允许装置A(或装置B)向装置B(或装置A)指示其已暂停视频的技术。VT系统还得益于允许装置在传入视频中断时区分中断的视频是否归因于视频发射的故意停止(例如，视频暂停)，或中断的视频是否是发射路径的严重退化的结果的技术。此类技术可适用于单向视频(或视频共享(VS))通话以及多方VT/VS通话。

一个现有的解决方案是指示视频暂停被称为呼叫保持过程。也就是说，当装置A暂停视频时，其使用显式信令使装置B视频流暂停，且反之亦然。此方法可变得复杂和/或不明确，尤其当与用户起始的通话降级(例如，用户将VT通话从双向视频通话改变成单向视频通话)和/或用户起始的通话升级(例如，用户将VT通话从单向视频通话改变成双向视频通话)混合时。

图3是展示针对在使用呼叫保持显式信令的视频暂停期间通话降级的使用情况的信号流的概念图。通话作为VT通话开始。在时间100处，装置A及装置B处于VT通话中并且正发送音频及视频RTP包两者以及音频及视频RTCP包。在事件1处，装置A用户的用户将VT应用程序移动到后台。事件1导致视频暂停。在常规解决方案中，视频暂停触发显式信令使装置B视频暂停。图3中展示的信号传递被称为会话起始协议(SIP)。在时间102处，装置A将re-INVITE(视频：仅发送、音频：发送接收)SIP消息发送到装置B。re-INVITE消息指示装置A将针对视频包操作为“仅发送”。也就是说，装置A指令装置B停止将视频包发送到装置A。在时间104处，装置B对SIP消息200OK(视频：仅发送、音频：发送接收)作出响应，从而指示装置B已接受请求且将处于“仅发送”模式(即，装置B将仅接收视频包且不发送视频包)。因此，在时间106处，不存在除了来自任一装置的RTCP之外的视频业务。

在图3的实例中，在事件2处，装置B的用户起始降级以将双向视频通话改变成单向视频(事件2)。然而，由于装置B已接受将处于“仅接收”模式的请求，因此装置B无法发送SIP消息(视频：仅接收、音频：发送接收)以指示所述降级，因为其已由于事件1处于此状态中。接下来，在事件3中，装置A的用户将VT应用程序移动到前台。在时间108处，此事件触发装置A将SIP消息re-INVITE(视频：发送接收、音频：发送接收)发送到装置B，以从装置A的视角恢复双向视频。然而，由于其呈现为对装置B的‘升级’(从单向视频到双向视频)，因此装置B促使用户接受所述升级。然而，在时间110处，归因于事件2，装置B的用户将有可能通过发送SIP消息603(拒绝)来拒绝‘升级’。在这种情况下，装置A将假定VT通话是双向视频通话，而装置B将假定VT通话是单向视频通话。此实例表明用于指示视频暂停的通过使用显式SIP信令引起的信令及用户期望，具体而言用于呼叫保持过程的信令的混淆/不明确性。

鉴于这些缺点，本发明提出一种用于指示及确定视频暂停的替代方法。本发明的方法不采用任何显式信令消息(例如，SIP消息)。替代地，本发明提出使用传入媒体本身携载的已获得信息。举例来说，本发明提出使用RTP及/或RTCP包(例如，视频RTP不活动/活动、RTCP包类型及/或视频RTCP包中携载的统计数据)中含有的信息作为视频暂停的指示。此方法提供用于确定视频暂停的实时、简单、清晰且有效的机构，而不会引起信令及用户体验/期望的混淆。

同样，假定来自图2的装置A及装置B处于活动的VT通话中并且装置A暂停视频(例如，由于将VT应用程序移动到后台)。在这种情况下，装置A停止将视频RTP包发送到装置B。然而，装置A继续发布视频RTCP包。根据规定RTP及RTCP信令协议的因特网工程任务小组(IETF)文件RFC3550，当视频暂停时，仍在暂停之后发信号通知包含发送器报告(SR)(即，“净荷类型”＝200)的初始两个RTCP包。SR包含关于发送器信息部分中的“发送器的包数量”及“发送器的八位字节数量”的信息。“发送器的包数量”是所发送的RTP包的数目，而“发送器的八位字节数量”是RTP包中发送的总数据量。来自http://www.ietf.org/rfc/rfc3550.txt的IETFRFC3550从2013年7月25日起可用，其全部内容以引用的方式并入本文中。

如果装置A已暂停视频且停止发送RTP包，那么两个连续RTCP包的第二RTCP包应具有与两个连续RTCP包的第一RTCP包中含有的“发送器的包数量”及“发送器的八位字节数量”相同的“发送器的包数量”及“发送器的八位字节数量”。也就是说，如果两个连续RTCP包具有指示已不发送数据(即，发送器的包数量及/或发送器的八位字节数量相同)的SR信息，那么接收装置(例如，装置B)可经配置以确定视频RTP包的停止是归因于视频暂停而不是通信信道的降级。然而，如果在已停止接收RTP包之后，两个连续RTCP包中的SR指示继续发送RTP包(例如，发送器的包数量及/或发送器的八位字节数量不相同)，那么接收装置可继续配置为用于VT通话的信道已降级并且在一些实例中，VT通话应被终止。而且，如果视频暂停足够长，那么在通过装置A发布的SRRTCP包之后的后续RTCP包应为接收器报告(RR)(即，“净荷类型”＝201)RTCP包。

因此，当视频RTP包的接收被中断而视频RTCP包保持到达时，装置B可确定装置A暂停视频(而不是确定从装置A到装置B的发射路径降级并且在此情况下视频RTP及RTCP两者应被丢失)。如果接收到的RTCP包是SR，那么装置B可通过检验“净荷类型”信息(SR对RR)及/或“发送器的包数量”及“发送器的八位字节数量”字段来进一步确认此结论。在装置B已确认装置A已归因于视频暂停而停止发送视频RTP包后，装置B可继续将视频发送到装置A(在这种情况下，装置A可仅终止视频RTP包或重新组合及解码每一帧，但不呈现其)、将其自身侧VT应用程序置于后台(即，视频暂停)以实行一些其它任务，或甚至将VT通话降级到单向视频等，同时仍保持与装置A的音频连接。如果装置B将其自身侧VT应用程序移动到后台或将VT通话降级到单向视频，那么装置B将停止发送视频RTP包，同时继续将视频RTCP包发送到装置A。来自装置B的RTCP包可由装置A以相同方式用于测定通过装置B的视频暂停。当两端停止将视频RTP包发送到彼此时，从每一侧发送的RTCP包最终将是空的RR。

在本发明的另一实例中，结合RTCP包的持续接收，RTP包的存在或缺乏可用于确定VT通话中的装置已起始视频通话。举例来说，在其中VT通话使用RTCP包之间的长时延(例如，2秒或大于2秒)的一些情况下，等待两个连续的RTCP包来确定视频是否已暂停可为不合需要的。因此，本发明进一步提出使用RTP包的持续非接收作为额外触发来确定已发生视频暂停。

作为一个实例，装置B停止从装置A接收视频RTP包并且随后接收一个RTCP包。在已接收RTCP包之后，装置B可启动计时器。如果在计时器达到某个预定阈值之前未接收到RTP包，那么装置B可主动地确定装置A已暂停视频。所述阈值可设定成小于RTCP包之间的间隔的任何值。在接收到第二连续RTCP包时，装置B随后可确认视频暂停的确定。以此方式，在其中存在RTCP包之间的长时延的情况下可更快速地对视频暂停作出确定。

总而言之，使用本发明的技术，当一个装置在VT通话中暂停视频时，对等方可通过检查传入视频RTP不活动、RTCP包类型及/或视频RTCP包中携载的统计数据可靠地且实时地检测此事件。当视频RTP包恢复时，对等方可确定视频暂停被终止。在一些实例中，装置可基于以上检测向用户呈现视频暂停启动及视频暂停终止指示。

在使用本发明的技术时，特定通话/媒体流中的一些可取决于装置B(即，尚未暂停的装置)的动作及/或在装置A暂停视频之后事件的顺序而改变。图4是展示针对使用本发明的技术的视频暂停检测的一个使用情况的实例信号流的概念图。在时间200处，装置A及装置B处于双向VT通话中，其中发送音频及视频RTP包两者，以及音频及视频RTCP包。在事件1处，装置A将VT应用程序置于后台，由此暂停视频且停止视频RTP包的发射。因此，在时间202处，视频RTP包未发送到装置B。视频RTCP包被继续发送到装置B。基于上文描述的本发明的技术，装置B基于视频RTCP包中的信息(例如，SR)确定已发生视频暂停。在图4的实例中，在时间204处，在装置B已通过装置A检测到视频暂停时，装置B决定继续发送视频RTP包。

在事件2处，装置B的用户执行降级操作以将VT通话置于单向模式中。响应于降级操作，re-INVITE及200OKSIP消息在时间206及208处互换以将VT通话置于单向模式中。因此，在时间210处，未从任一装置发送视频RTP消息。音频RTP/RTCP消息及视频RTCP消息被继续发送。

在事件3处，装置A的用户将VT应用程序返回到前台。因此，在时间212处，视频RTP包再次被发射到装置B。在时间214处，归因于在事件2处的用户降级，装置B继续仅发射音频RTP包。然而，由于通过RTCP包而不是显式SIP信令检测到视频暂停，因此两个装置正确地确定单向视频通话仍有效。

图5是展示针对使用本发明的技术的视频暂停检测的另一使用情况的另一实例信号流的概念图。在时间302处，装置A及装置B处于双向VT通话中，其中发送音频及视频RTP包两者，以及音频及视频RTCP包。在事件1处，装置A将VT应用程序置于后台，由此暂停视频且停止视频RTP包的发射。因此，在时间304处，视频RTP包未发送到装置B。视频RTCP包被继续发送到装置B。基于上文描述的本发明的技术，装置B基于视频RTCP包中的信息(例如，SR)确定已发生视频暂停。在图5的实例中，在时间306处，在装置B已通过装置A检测到视频暂停时，装置B决定停止将视频RTP包发送到装置A。

在事件2处，装置B的用户执行降级操作以将VT通话置于单向模式中。响应于降级操作，re-INVITE及200OKSIP消息在时间308及310处互换以将VT通话置于单向模式中。因此，在时间312处，未从任一装置发送视频RTP消息。音频RTP/RTCP消息及视频RTCP消息被继续发送。

在事件3处，例如，响应于用户输入，装置A将VT应用程序返回到前台。因此，在时间314处，视频RTP包再次被发射到装置B。在时间316处，归因于在事件2处的用户降级，装置B继续仅发射音频RTP包。然而，由于通过RTCP包而不是显式SIP信令检测到视频暂停，因此两个装置正确地确定单向视频通话仍有效。与图3中的通话/媒体流相比，图4及图5中的每个装置的状态在每一步骤是确定性的，并且从用户期望视角不存在混淆。

图6是展示根据本发明的技术的实例方法的流程图。图6的技术可通过图2.1的装置A或装置B的一或多个结构单元或处理器执行。

根据图6的实例，视频电话通话中的接收装置(例如，装置B)可经配置以在接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置(600)。接收装置可进一步经配置以基于视频控制包中含有的信息确定发送装置已暂停视频电话通话的视频部分(602)。

在本发明的一个实例中，在视频数据包已停止到达之后，在接收装置处继续接收到视频控制包。在一些实例中，视频数据包是实时传输协议(RTP)包，并且视频控制包是RTP控制协议(RTCP)包。在一些实例中，RTCP包中的用于确定发送装置是否已暂停视频电话通话的视频部分的信息是包数量及总数据量中的一或多者。在与RTCP一致的一些实例中，包数量是RTCP包的发送器报告(SR)中的发送器的包数量，并且其中总数据量是RTCP包的SR中的发送器的八位字节数量。

在本发明的另一实例中，确定发送装置已暂停视频电话通话的视频部分包括：比较两个连续RTCP包中的包数量及总数据量中的一或多者以确定视频是否已暂停，其中如果包数量及总数据量中的一或多者对于两个连续RTCP包相同，那么确定视频已暂停。

在本发明的另一实例中，确定发送装置已暂停视频电话通话的视频部分包括在已接收到视频控制包之后启动计时器，并且如果在从计时器的启动开始的阈值时间内未接收到视频数据包，那么确定发送装置已暂停视频电话通话的视频部分。在一些实例中，阈值时间小于两个连续视频控制包之间的时间。

在一或多个实例中，所描述的功能可用硬件、软件、固件或其任何组合来实施。如果以软件实施，则所述功能可作为一或多个指令或代码在计算机可读媒体上存储或发射，并且由基于硬件的处理单元执行。计算机可读媒体可包含计算机可读存储媒体，其对应于有形媒体，例如数据存储媒体，或包含促进将计算机程序从一处传送到另一处的任何媒体(例如，根据通信协议)的通信媒体。以此方式，计算机可读媒体大体上可对应于(1)非暂时性的有形计算机可读存储媒体或(2)通信媒体，例如，信号或载波。数据存储媒体可为可由一或多个计算机或一或多个处理器存取以检索用于实施本发明中所描述的技术的指令、代码及/或数据结构的任何可用的媒体。计算机程序产品可包含计算机可读媒体。

借助于实例而非限制，此类计算机可读存储媒体可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储装置、磁盘存储装置或其它磁性存储装置、快闪存储器或可用于存储呈指令或数据结构的形式的所要程序代码且可由计算机存取的任何其它媒体。并且，任何连接被恰当地称为计算机可读媒体。举例来说，如果使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)或例如红外线、无线电及微波等无线技术从网站、服务器或其它远程源发射指令，那么同轴电缆、光纤电缆、双绞线、DSL或例如红外线、无线电及微波等无线技术包含在媒体的定义中。然而，应理解，计算机可读存储媒体及数据存储媒体并不包含连接、载波、信号或其它暂时性媒体，而是实际上针对于非暂时性有形存储媒体。如本文所使用，磁盘及光盘包含压缩光盘(CD)、激光光盘、光学光盘、数字多功能光盘(DVD)、软性磁盘及蓝光光盘，其中磁盘通常以磁性方式再现数据，而光盘用激光以光学方式再现数据。上述各者的组合也应包含在计算机可读媒体的范围内。

指令可由一或多个处理器执行，所述一或多个处理器例如，一或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)、或其它等效的集成或离散逻辑电路。因此，如本文中所使用的术语“处理器”可指前述结构或适合于实施本文中所描述的技术的任何其它结构中的任一者。另外，在一些方面，本文所述的功能性可在配置用于编码及解码的专用硬件及/或软件模块内提供，或者并入在组合式编解码器中。而且，可将所述技术完全实施于一或多个电路或逻辑元件中。

本发明的技术可在各种装置或设备中实施，包含无线手持机、集成电路(IC)或一组IC(例如，芯片组)。本发明中描述各种组件、模块或单元来强调经配置以执行所公开的技术的装置的功能性方面，但未必需要通过不同硬件单元实现。相反地，如上文所描述，各种单元可结合合适的软件及/或固件组合在编解码器硬件单元中，或者通过互操作硬件单元的集合来提供，所述硬件单元包含如上文所描述的一或多个处理器。

描述了各种实例。这些及其它实例在权利要求书的范围内。

Claims (30)

1.一种用于视频电话的方法，所述方法包括：

在接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置；及

基于视频控制包中含有的信息在所述接收装置处确定所述发送装置已暂停所述视频电话通话的视频部分。

2.根据权利要求1所述的方法，其中在所述视频数据包已停止到达之后，在所述接收装置处继续接收到所述视频控制包。

3.根据权利要求1所述的方法，其中所述视频数据包是实时传输协议RTP包，并且其中所述视频控制包是RTP控制协议RTCP包。

4.根据权利要求3所述的方法，其中所述RTCP包中的用于确定所述发送装置是否已暂停所述视频电话通话的视频部分的所述信息是包数量及总数据量中的一或多者。

5.根据权利要求4所述的方法，其中所述包数量是所述RTCP包的发送器报告SR中的发送器的包数量，并且其中所述总数据量是所述RTCP包的所述SR中的发送器的八位字节数量。

6.根据权利要求4所述的方法，其中在所述接收装置处确定所述发送装置已暂停所述视频电话通话的所述视频部分包括：

比较两个连续RTCP包中的所述包数量及所述总数据量中的一或多者以确定所述视频是否已暂停，其中如果所述包数量及所述总数据量中的一或多者对于所述两个连续RTCP包相同，那么确定所述视频已暂停。

7.根据权利要求1所述的方法，其中在所述接收装置处确定所述发送装置已暂停所述视频电话通话的所述视频部分包括：

在已接收到视频控制包之后启动计时器；及

如果在从所述计时器的所述启动开始的阈值时间内未接收到视频数据包，那么确定所述发送装置已暂停所述视频电话通话的所述视频部分。

8.根据权利要求7所述的方法，其中所述阈值时间小于两个连续视频控制包之间的时间。

9.一种配置用于视频电话的设备，所述设备包括：

用于在接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置的装置；及

用于基于视频控制包中含有的信息在所述接收装置处确定所述发送装置已暂停所述视频电话通话的视频部分的装置。

10.根据权利要求9所述的设备，其中在所述视频数据包已停止到达之后，在所述接收装置处继续接收到所述视频控制包。

11.根据权利要求9所述的设备，其中所述视频数据包是实时传输协议RTP包，并且其中所述视频控制包是RTP控制协议RTCP包。

12.根据权利要求11所述的设备，其中所述RTCP包中的用于确定所述发送装置是否已暂停所述视频电话通话的视频部分的所述信息是包数量及总数据量中的一或多者。

13.根据权利要求12所述的设备，其中所述包数量是所述RTCP包的发送器报告SR中的发送器的包数量，并且其中所述总数据量是所述RTCP包的所述SR中的发送器的八位字节数量。

14.根据权利要求12所述的设备，其中所述用于在所述接收装置处确定所述发送装置已暂停所述视频电话通话的所述视频部分的装置包括：

用于比较两个连续RTCP包中的所述包数量及所述总数据量中的一或多者以确定所述视频是否已暂停的装置，其中如果所述包数量及所述总数据量中的一或多者对于所述两个连续RTCP包相同，那么确定所述视频已暂停。

15.根据权利要求9所述的设备，其中所述用于在所述接收装置处确定所述发送装置已暂停所述视频电话通话的所述视频部分的装置包括：

用于在已接收到视频控制包之后启动计时器的装置；及

用于在从所述计时器的所述启动开始的阈值时间内未接收到视频数据包的情况下确定所述发送装置已暂停所述视频电话通话的所述视频部分的装置。

16.根据权利要求15所述的设备，其中所述阈值时间小于两个连续视频控制包之间的时间。

17.一种配置用于视频电话的设备，所述设备包括：

接收装置，其经配置以：

在所述接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置；及

基于视频控制包中含有的信息确定所述发送装置已暂停所述视频电话通话的视频部分。

18.根据权利要求17所述的设备，其中在所述视频数据包已停止到达之后，在所述接收装置处继续接收到所述视频控制包。

19.根据权利要求17所述的设备，其中所述视频数据包是实时传输协议RTP包，并且其中所述视频控制包是RTP控制协议RTCP包。

20.根据权利要求19所述的设备，其中所述RTCP包中的用于确定所述发送装置是否已暂停所述视频电话通话的视频部分的所述信息是包数量及总数据量中的一或多者。

21.根据权利要求20所述的设备，其中所述包数量是所述RTCP包的发送器报告SR中的发送器的包数量，并且其中所述总数据量是所述RTCP包的所述SR中的发送器的八位字节数量。

22.根据权利要求20所述的设备，其中所述接收装置进一步经配置以：

比较两个连续RTCP包中的所述包数量及所述总数据量中的一或多者以确定所述视频是否已暂停，其中如果所述包数量及所述总数据量中的一或多者对于所述两个连续RTCP包相同，那么确定所述视频已暂停。

23.根据权利要求17所述的设备，其中所述接收装置进一步经配置以：

在已接收到视频控制包之后启动计时器；及

如果在从所述计时器的所述启动开始的阈值时间内未接收到视频数据包，那么确定所述发送装置已暂停所述视频电话通话的所述视频部分。

24.根据权利要求23所述的设备，其中所述阈值时间小于两个连续视频控制包之间的时间。

25.一种计算机可读存储媒体，其存储当执行时致使用于视频电话的装置的一或多个处理器执行以下操作的指令：

在接收装置处检测到与视频电话通话相关联的视频数据包已停止来自发送装置；及

基于视频控制包中含有的信息在所述接收装置处确定所述发送装置已暂停所述视频电话通话的视频部分。

26.根据权利要求25所述的计算机可读存储媒体，其中在所述视频数据包已停止到达之后，在所述接收装置处继续接收到所述视频控制包。

27.根据权利要求25所述的计算机可读存储媒体，其中所述视频数据包是实时传输协议RTP包，并且其中所述视频控制包是RTP控制协议RTCP包。

28.根据权利要求27所述的计算机可读存储媒体，其中所述RTCP包中的用于确定所述发送装置是否已暂停所述视频电话通话的视频部分的所述信息是包数量及总数据量中的一或多者。

29.根据权利要求28所述的计算机可读存储媒体，其中所述包数量是所述RTCP包的发送器报告SR中的发送器的包数量，并且其中所述总数据量是所述RTCP包的所述SR中的发送器的八位字节数量。

30.根据权利要求28所述的计算机可读存储媒体，其中所述指令进一步致使所述一或多个处理器：

比较两个连续RTCP包中的所述包数量及所述总数据量中的一或多者以确定所述视频是否已暂停，其中如果所述包数量及所述总数据量中的一或多者对于所述两个连续RTCP包相同，那么确定所述视频已暂停。