CN103621019A - 多媒体铃声 - Google Patents

Abstract

在本文中所描述的是一种方法和系统（100），用于支持在被适配为通过网络（108）进行通信的两个终端（102、104）之间建立呼叫之前，通过该网络（108）传输实时提前媒体。该系统（100）包括应用服务器（106），被配置为允许在两个终端（102、104）之间的正向和/或反向方向中传输实时提前媒体。

Description

多媒体铃声

技术领域

本发明涉及由电信设备和网络来传输和提供多媒体铃声的领域。

背景技术

当进行电话呼叫并且该呼叫建立在主叫者和被叫者之间时，正向指示，例如铃声被发送给该被叫者，并且反向指示，例如回铃声（ringback tone）被发送给主叫者。对于基本铃声和回铃声，多种改进是可能的，例如一些手机提供如下的选项：选择特定的铃声用于来自保存在手机上的地址本中的一个或多个联系人的呼入呼叫。这些铃声还可以包括视频，例如可视铃声（watchtone），手机拥有者能够创建或者下载可视铃声并且将可视铃声应用于他们地址本中的联系人。

此外，在呼叫建立期间任一方向中所发送的信息能够以许多方式被添加。例如，从被叫者到主叫者，多媒体回铃声能够被用于连同所选择的视频、照片或短语一起，取代通常的铃声来问候主叫者。从主叫者到被叫者，主叫者标识或“主叫者ID”，即该呼叫所源于的电话号码能够被发送。还有可能通过包括视频来补充连同铃声一起被发送的数据，该视频例如由服务提供商所提供的动画、或者被上传至服务提供商的、在呼叫建立期间形成铃声的一部分的预先记录的视频。

国际专利申请WO2011/040673和美国专利公开US2007/0269030均描述了将主叫者标识多媒体内容上传至服务器，并且随后将这个内容传输给被叫者设备。这些系统需要用户在某个较早的时间首先将可视内容上传给服务器，以便使用多媒体铃声或回铃声。备选的铃声或回铃声产品对增强用户体验是合意的。

发明内容

本发明总体上涉及电信网络中终端之间的提前媒体（earlymedia）的通信。包括应用服务器和媒体服务器的计算机系统被描述以促进实时的提前媒体通信。该实时通信可以被提供为除了预先记录的提前媒体的通信之外的选项，例如存储在该电信网络内的媒体。

从一个视角来看，一种用于发起具有实时提前媒体的呼叫的方法包括：从第一终端接收会话建立消息并且将该会话建立消息转发给第二终端。回铃声从第二终端被接收并且被转发给第一终端，并且铃声从第一终端被转发给第二终端。第一终端和/或第二终端指示实时提前媒体将被使用，并且实时提前媒体在第一终端和第二终端之间被传达。

在一些实施例中，该提前媒体与铃声和/或回铃声一起被传输，并且可以是视频数据。该视频数据可以被记录在第一终端或第二终端处，或者由第三方系统来提供。

对该实时提前媒体功能的管理可以包括实施网络策略，以选择性地允许或不允许实时提前媒体。在一些实施例中，转发实时提前媒体包括将该实时提前媒体转码。

还公开了用于实施以上所描述的方法的应用服务器。

从一个视角来看，一种用于支持在被适配为通过网络通信的两个终端之间建立呼叫之前，通过所述网络进行实时提前媒体传输的计算机系统包括应用服务器，该应用服务器被配置为允许实时提前媒体的传输。该应用服务器可以在两个终端之间的任一方向中传输实时提前媒体。

该计算机系统可以包括与应用服务器通信的媒体服务器。该媒体服务器可以接收提前媒体；基于网络策略限制来处理该媒体，并且将经处理的媒体提供给应用服务器，用于传输给两个终端之一或两者。

该计算机系统可以进一步包括与应用服务器通信的数据库，该数据库被适配为接收、存储和/或提供与两个终端相关联的配置信息。该配置信息可以被应用服务器用来管理提前媒体的传输。

从另一个视角来看，一种用于通过网络发起具有实时提前媒体的呼叫的方法包括：第一终端提供会话建立消息，该会话建立消息向网络指示对实时提前媒体的使用；网络将该会话建立消息转发给第二终端；第二终端经由网络将回铃声发送给第一终端；网络从第一终端和/或第二终端接收实时提前媒体被使用的指示；第一终端经由网络将铃声发送给第二终端；第一终端和/或第二终端分别将实时提前媒体连同铃声和/或回铃声一起发送。

根据通过示例的方式而给出的下列描述并且参考附图，本发明进一步的方面和前述段落中所描述的这些方面的进一步的实施例将变得明显。

附图说明

图1示出了根据本发明的一个实施例的多媒体铃声系统的示意性表示。

图2示出了呼叫建立过程中主叫者侧的示意性表示。

图3示出了呼叫建立过程中被叫者侧的示意性表示。

图4示出了已经被建立的呼叫的示意性表示。

图5示出了根据本发明的一个实施例的高层消息流。

图6示出了用于NGN或IMS网络实施的高层消息流。

具体实施方式

本文所描述的多媒体铃声/回铃声系统和方法的实施例，通过使用动态可视主叫线路识别（CLI），提供具有如下能力的被叫者：分别具有主叫方/接收方的预览并且/或者在呼叫建立之前执行其他通信功能。该先于呼叫建立的通信功能在本文中一般被称为“动态多媒体铃声”（DMRT）功能。DMRT功能扩展了针对回铃声和铃声之一或两者的提前媒体支持。

如本文所使用的，术语铃声指代在呼叫建立之前由网络从主叫者转发到被叫者的告警。术语回铃声指代在呼叫建立之前由网络从被叫者转发到主叫者的告警。这些告警形成呼叫建立过程的一部分。当提前媒体被用来补充铃声或者回铃声时，则提前媒体连同铃声告警或回铃声告警一起被发送。

术语“提前媒体”已经被用来指代两个手机（具有或不具有来自网络的协调）在实际通信开始之前相互交换媒体内容的能力。严格地说，“提前媒体”仅增强了信令。尽管会话发起协议（SIP）在本文中被用来描述信令协商能力，以便递送该提前媒体内容，将理解，本文所描述的本发明可以与在呼叫建立之前支持媒体内容的任何适当协议一起被实施。

实时提前媒体指代并非已经预先记录在应用或媒体服务器上的提前媒体。实时提前媒体因此能够指代，例如：

·在会话建立请求被发送给网络或者会话建立请求从网络被接收的时候，被记录或被转发给网络的图像、视频或声音，或者

·在会话建立请求被发送给网络或者会话建立请求从网络被接收的时候，已经被记录在终端或手机上并且然后作为提前媒体被提供给网络的图像、视频或声音。

实时提前媒体直接地从终端被传输，其中该终端能够是发起或接收呼叫的终端。该终端还能够是第三方，诸如由呼叫发起手机或呼叫接收手机所选择的基于位置的服务器，例如与主叫者或被叫者所位于的某个场所相关联的服务器。对于这个布置，或者通过使用DMRT应用中的GPS功能，或者使用如本文其他地方所描述的特殊特征代码，该主叫者/被叫者配置DMRT应用，以使用来源于该第三方的媒体。

1.系统概述

DMRT系统100的一个实施例能够参考图1来理解。DMRT系统100包括手机102和104、服务提供商的DMRT应用服务器106、网络108、服务提供商的媒体服务器112和数据库110。

1.1手机

手机102、104是常规的支持视频的手机，诸如与网络108相关联的移动电话或智能电话。这些手机还能够是计算机或者PDA或者适于通过相关网络进行呼叫的任何终端。将意识到，尽管图1中仅示出了两个手机，现实中可以存在任何数量的关联于网络108、能够支持本文所描述的DMRT功能的手机。如果这些手机中的一个手机不是支持视频的（例如常规电话），则DMRT功能能够被禁用和/或在呼叫建立期间相应地被配置。例如，如果主叫者使用常规电话，它们能够将预先记录的视频（例如，使用因特网）上传给多媒体服务器112，以便在呼叫建立期间与一个或多个能够接收视频和/或多媒体内容的手机一起使用。对于这个场景，提供了单向DMRT功能，取代了当两个手机/所有手机都支持视频时的双向或多向DMRT功能。

在一个实施例中，DMRT功能作为基本电话服务的一部分而被提供。在这个实施例中，DMRT功能是自动可用的，并且能够由任何用户为他们的手机/多个手机启用。

在另一个实施例中，DMRT功能作为用户必须订阅的服务而被提供。在这个订阅模型中，将存在一些使用DMRT的用户以及一些不使用DMRT的用户；因此服务提供商能够将完全的、有限的DMRT功能和/或不将DMRT功能提供给涉及订户和非订户组合的呼叫。

主叫手机（例如，手机102）可以经由固定宽带网络（例如，DSL或电缆）或者无线网络（例如，3G/LTE网络）连接至应用服务器106。支持协议能够是SIP、H.323、或者支持提前媒体的任何其他通信协议。手机102、104上的DMRT应用支持DMRT指示符连同会发建立请求一起的传输，以及提前媒体连同铃声和/或回铃声一起的传输。该应用能够从应用服务器106被下载，或者该应用能够被实施在作为手机硬件的一部分而被提供的嵌入式软件中。

备选地，网络策略能够被实施在应用服务器106中。

在一些实施例中，主叫者手机允许用户在下列铃声选项中的一个选项之间进行选择：

1.没有对铃声增强的简单呼叫。

2.具有当前视图（即作为主叫标识显示媒体的实时视频）的呼叫。

3.具有预先记录内容（即作为主叫线路标识显示媒体的视频或静止图像）的呼叫。

能够通过使用由软件DMRT应用所提供的、终端上的软件菜单，通过配置不必然与DMRT应用直接关联的、电话上的一般设置，通过使用作为如本文其他地方所描述的呼叫前缀的特殊特征码，或者通过其他适当的手段，来完成这个选择。

如果主叫者使用非智能手机，例如ATA（模拟电话适配器），则选择选项1。非智能手机还能够依靠网络来基于特定的订阅而提供另外的服务，例如将预先记录的内容作为CLI显示媒体来传递。

在一个实施例中，SIP和会话描述协议（SDP）被用来管理多媒体通信，并且DMRT应用基于SIP和SDP呼叫建立协议。在这个实施例中，主叫者的手机支持P-Early-Media头部（RFC5009）的使用。该头部包括与提前媒体的使用有关的信息。取代简单地填充该头部中的“supported”字段，该手机添加了方向指示符。这向网络给出了清楚的指示，何种类型的转发提前媒体将会发生。表1中示出了该头部中所使用的方向指示符的示例：

表1

sendrecv	指示提前媒体由该手机发送和接收
		sendonly	指示提前媒体由该手机发送但不由该手机接收
recvonly	指示提前媒体由该手机接收但不由该手机发送

被叫者的手机也能够支持使用P-Early-Media头部作为指示符，并且提供资源分配以便接收提前媒体流。同时，当接收INVITE消息（即当呼叫建立正在被发起时的会话建立消息）时，它使用SIP183会话进度响应。它将通过使用SDP“answer”主体中的“recvonly”属性来指示它仅支持接收媒体流。类似地，通过使用“sendrecv”属性来指示双向的媒体支持。

在一个实施例中，被叫者的手机还根据DMRT提供多媒体回铃声服务，这意味着预先记录的数据或者实时视频连同回铃声一起被传输。对于这个实施例，被叫者的手机需要使用“sendrecv”。否则，“recvonly”是SDP应答中优选的属性。

1.2应用和媒体服务器

应用服务器106能够是被适配为支持DMRT的、支持语音和数据服务的任何电话服务器。它能够是支持不同代网络技术（例如，阿尔卡特朗讯5420CTS）的聚合电话服务器。应用服务器106管理DMRT应用，并且提供对实时提前媒体的管理和控制。应用服务器106与媒体服务器112对接，媒体服务器112进而提供媒体处理功能。媒体服务器能够是被适配为支持DMRT的任何适当的媒体资源服务器（例如，阿尔卡特朗讯5900MRF）。

当网络从主叫者/被叫者接收了带有指示对DMRT的使用的P-Early-Media头部的会话建立/进度消息时，则DMRT应用服务器106验证主叫者手机102和被叫者手机104两者的DMRT能力和/或订阅。这能够通过在解释从这些手机所接收的呼叫建立消息发送内容时参考数据库110（其包括特征订阅数据库）来完成。如果DMRT（基于手机能力、网络覆盖和/或订阅细节）对于两者的手机是可用的，则在主叫者手机102与被叫者手机104之间启用单向和/或双向多媒体传输（或者如果使用了多个手机，例如在会议呼叫中，则启用多向多媒体传输）。如果DMRT仅对于一个手机可用，服务提供商能够启用单向多媒体传输和/或能够限制或防止任何多媒体传输。

多媒体从主叫者手机102被发送给被叫者手机104，和/或多媒体从被叫者手机104被发送给主叫者手机102。被叫者手机（例如，手机104）经由对实时提前媒体的使用进行管理的应用服务器106接收多媒体铃声。应用服务器106连同媒体服务器112一起操作。当呼叫正被建立时，应用服务器106将来自主叫者INVITE的消息转发给被叫者，被叫者能够使用媒体服务器112地址用于取决于网络策略的连接。提供转发提前媒体指示，以便用于被叫者分配资源来支持提前媒体流。这样的指示连同INVITE消息一起被传递。

当实时提前媒体连同铃声和/或回铃声一起被传输时，该提前媒体可以服从于网络策略。例如，当网络正使用某种服务质量（QoS）控制时，可以对应地指示带宽分配。为了提前媒体遵循网络策略的要求，该提前媒体可能需要处理。这个处理由媒体服务器112来执行。策略要求可能关联于提前媒体内容（例如，仅视频相对视频/音频）、提前媒体长度（例如，一帧视频）、以及提前媒体的预加载。为了实施网络策略所需要的、并且由媒体服务器112所执行的媒体处理，可以包括转码（转码包括数据格式转换，例如为了适应带宽限制）。

为了支持灵活的DMRT方案，应用服务器106支持至少下文（参考使用如上文所描述的订阅模型的实施例）所描述的两个呼叫场景。

i.A方（主叫者）上的DMRT

DMRT功能被配置在手机和数据库110两者中。参考图2，当主叫者200利用指示了DMRT的使用（例如，通过使用P-Early-Media头部）的呼叫建立201来发起呼叫时，DMRT应用服务器106将首先把订阅查询202发送给数据库110。

查询202被用来检查：

1.主叫者被允许使用DMRT，即该用户具有DMRT订阅吗？

2.如果是，被叫者将使用什么类型的内容：实时多媒体或者预先记录的多媒体。预先记录的多媒体将与在呼叫正在进行时用于取回该内容的内容ID相关联。

如果不支持DMRT，则呼叫建立将根据常规的方法继续进行，并且应用服务器106将把所有的DMRT指示从主叫者移除。网络设置可以被配置，由此如果不支持DMRT则在呼叫建立期间默认媒体（例如，图像或声音）被用于显示。

如果支持DMRT，则应用服务器106将进一步检查是否需要媒体转换（例如，将视频/音频转换为仅视频）。任何需要的转换将由媒体服务器112来执行。

如果实时内容与铃声一起被发送，则该内容直接从主叫者200流式传输，或者根据来自应用服务器106跨越网络108的协调被媒体服务器112转换。媒体服务器112被用来实施用于在媒体类型、媒体长度等方面转换针对媒体内容的任何相关网络策略。当实施了网络策略时，来自订阅查询202的结果、检查结果204，从DMRT服务器106被推送给媒体服务器112，以在呼叫建立之前准备潜在的到来媒体。这可以包括如上文所描述的转码。

如果预先记录的多媒体内容被用于DMRT，则媒体服务器112被插入媒体路径中，从而使用系统默认内容或预定义的内容。在这种情况中，来自订阅查询202的结果、检查结果204，从DMRT服务器106被推送给媒体服务器112，以在呼叫建立之前准备潜在的到来媒体。

DMRT应用服务器106支持终端用户经由web接口（如在3GPP标准中所定义的Ut接口）上传他们优选的多媒体内容，用于实时视频流式传输，或者当在进行呼叫之前预先记录的视频数据正被保存至媒体服务器112时。

ii.B方（被叫者）上的DMRT

参考图3，在从被叫者300接收SIP183响应之后，应用服务器106将会把订阅查询302发送给数据库110，以确认被叫者300是否具有DMRT订阅。用于被叫者的查询302与如上文所描述的用于主叫者的查询202相同，并且在适当的地方包括回铃声内容ID。

如果该系统正在进行媒体转换，或者系统默认内容或预先记录的媒体内容被使用，则建立与媒体服务器112的媒体服务器连接304，其后完成与被叫者300的呼叫建立306，由此主叫者200所提供的媒体内容被传递给被叫者300。

参考图4，当DMRT服务对于主叫者200或被叫者300是活动的，则与媒体服务器112的媒体路径将被建立在中间，以在正向方向402上提供多媒体铃声，或者在反向方向404上提供多媒体回铃声。用于铃声和回铃声两者的多媒体，能够经由使用如3GPP Ut接口406的标准接口的应用服务器106，被上传至媒体服务器112。

1.3网络

网络108在例如信令和路由方面是常规的，除了网络108在用于手机102、104之间的呼叫建立的路径中包括应用服务器106。例如，网络108能够是支持3G、GSM、VoIP和/或VoLTE的NGN/IMS网络。

在NGN/IMS网络中所实施的DMRT解决方案可以构建在已有的多媒体回铃声服务上，并且SIP然后将被用于控制通过IP的多媒体通信会话。在一些实施例中，当支持DMRT的SIP客户端发起视频呼叫时，主叫者能够选择使用由摄像头所采集的当前视图或者存储在网络中已有的视频剪辑，来发送给被叫者。已有的视频剪辑能够由该用户预先记录并且被上传至服务提供商的多媒体服务器112，诸如动画之类的视频剪辑可以由该用户购买并且被上传至多媒体服务器112，和/或能够使用已经在服务器112上的视频剪辑，例如由服务提供商所提供的视频剪辑。

对于本文所描述的DMRT解决方案，假设是：尽管DMRT在手机102、104处或在应用服务器106或媒体服务器112处的网络中提供将被过滤或改变的音频内容，但是终端用户被允许使用具有视频和音频内容两者的提前媒体。例如，作为增值服务，当将实时多媒体铃声传递给被叫者时，服务提供商可以将音频流从实时多媒体铃声移除。

除了实时视频、预先记录的视频和动画，多媒体还能够是一个或多个现场采集的静止图像、延时的静止图像和/或音频。多媒体以标准数据文件的格式（例如，用于视频的AVI或者用于图像的JPEG）被传输。多媒体还可以以其他格式被传输，例如与DMRT相关联的正当多媒体数据。

经由DMRT应用服务器106上的Ut web接口406，用户具有选择来购买现成的多媒体剪辑和/或将他们自己的内容上传至媒体服务器112上。当终端用户选择使用预先记录的内容作为铃声时，该内容可以经由Ut接口或者作为提前媒体的一部分而被传递。当实时视频与铃声/回铃声一起使用时，内容管理不可用，但是媒体服务器112仍然执行媒体处理功能，诸如：

·在网络中将实时多媒体的音频分量滤除；

·控制媒体内容的长度；和/或

·将媒体转码以遵守带宽限制。

1.4数据库

数据库110被用来管理DMRT订阅信息以及多媒体内容两者。该数据库包括订户的记录和相关联的多媒体。这些记录使得网络能够供应多媒体数据文件的传输，并且包括诸如多媒体内容类型、播放时间、文件名称和大小等的信息。该数据库是链接多媒体数据库，该链接多媒体数据库存储了链接至媒体服务器上资源的元数据。该数据库能够构建在任何商业可用的产品上，例如Oracle或微软SQL服务器。

对于点对点的实施方式（下文所描述的），对数据库的使用是可选的。

2.使用DMRT的呼叫建立

参考图5，示出了高层消息流图500，其指示了DMRT如何在客户端与网络之间工作。

1.当支持DMRT的客户端A502发送会话建立消息504（用于聊天、呼叫等）时，消息504在信令部分包括DMRT指示符508，以指示客户端对DMRT的支持。

2.当网络506从客户端A502接收会话发起请求504时，网络506将关于下列各项来评价它的策略：

a.客户端A允许DMRT吗？

b.被允许通过至另一端的DMRT媒体是多长（例如5秒）？

c.允许DMRT携带视频以及音频吗？

在一个实施例中，DMRT在手机102、104处或在应用服务器106

或媒体服务器112处的网络中提供将被过滤或改变的音频内容。

将意识到，取决于相关的协议和/或网络针对DMRT应用所提供

的支持，网络可以实施附加的或者备选的策略特征（相比上面的

a.-c.）。

3.如果网络506完成DMRT策略检查509并且允许使用DMRT，则网络506将把请求510连同DMRT指示符512一起传递给客户端B514。

4.当同样支持DMRT特征的客户端B514接收请求510、512时，它将返回“响铃”消息516。同时，它将准备客户端B上的媒体资源（即套接字分配），以便接受以到来的IP分组为形式的到来DMRT媒体。

5.“响铃”消息518被转发给客户端A502，客户端A502然后以多媒体铃声520的形式向网络发起动态媒体传输，多媒体铃声520包括连同实时媒体或预先记录的媒体（例如，视频）的铃声，并且DMRT520被转发给客户端B514。取决于网络设置，客户端A502还能够从网络506接收媒体流，例如多媒体回铃声522，多媒体回铃声522包括连同来自客户端B514的实时媒体或预先记录的媒体（例如，视频）一起的回铃声。提前媒体在事件523处被建立。

6.为了前进至实际的呼叫建立，客户端B接受该会话并且返回OK消息524。

7.网络506将OK消息传递给客户端A502。双向实时通信528在这个点开始。

图6示出了用于在NGN/IMS网络的情况中使用DMRT的呼叫建立的信令。主叫方602发送SIP INVITE604以发起呼叫建立，SIPINVITE604包括指示对DMRT的使用的P-Early-Media头部。当被转发的SIP INVITE610由被叫方614接收时，被叫方的SIP客户端建立视频显示作为提前媒体协商的一部分。被叫方614然后将183会话进度消息616发送给NGN/IMS核心网络606，NGN/IMS核心网络606进而将183会话进度消息618转发给主叫方602。对于将被可靠传输的183响应，主叫方602返回进度确认消息PRACK630，进度确认消息PRACK630在632中被转发给被叫方。用于PRACK的OK响应然后从被叫方614被传递给网络（634）并且稍后（636）被传递给主叫方。

提前媒体流623然后在两方之间被建立。DMRT铃声620将从主叫方602到被叫方614而被建立。多媒体回铃声622在网络的协调下也可能从被叫方到主叫方。

当被叫方614接通该呼叫，200OK响应624被返回给网络，并且随后OK响应626被发送给主叫方。主叫方602将把确认ACK640返回给网络，并且随后ACK642被发送给被叫方。此处双向实时通信644开始。

在一个实施例中，CLI作为所接收的视频流的子标题而被显示。当被叫方614接通电话时，普通视频呼叫将开始。

3.附加特征

DMRT解决方案能够以点对点模式或基于网络的模式来完成。这些模式除了如上文所描述的基本DMRT功能，还支持多个附加的特征。

3.1点对点模式

对于点对点模式，该解决方案将依赖对手机的增强。同时，它服从于网络带宽和媒体流策略检查，媒体流策略检查控制订户对提前媒体和媒体内容（音频对比视频）的使用。当不存在对使用提前媒体的策略限制时，该客户端将提供本地媒体转换，例如仅在发送给被叫方之前记录视频内容。该客户端将通过某些指示在该呼叫建立消息中仍然指示对DMRT的使用。该呼叫流程类似于图5中所示出的呼叫流程，但是不存在网络元件。

在点对点模式中，附加特征包括主叫者选择使用保存在主叫者的手机上的预先记录的视频或图像，作为取代实时视频而被用作提前媒体的多媒体内容。另一个附加特征是上传与不同分类相关联的内容。可能的分类能够是，例如，联系人组或内容类型、依赖位置的内容、依赖于呼叫所进行的一天中的时间的内容、依赖于另一个时间变量，诸如一周、一月中的一天，或者日历或一年中的一天。

3.2基于网络的模式

对于基于网络的解决方案，DMRT在相同的策略控制下运行，但是为服务提供商和终端用户两者提供更大的灵活性。上文关于点对点解决方案所描述的附加特征能够在基于网络的解决方案中进行扩展。例如，取决于被叫者的标识或被叫者的位置，与多媒体内容相关联的分类能够进一步包括铃声/回铃声分类。当呈现服务由网络运营商提供时，这样的多媒体内容能够与呈现信息（例如，头像（avatar）图标、在线状态等）链接。

当主叫者进行呼叫时，网络能够自动地获得主叫者或被叫者的位置（用SIP P-Access-Network-Info头部或呈现更新）或他们的模式，他们的模式与呈现服务相关联（例如，如GSMA RCS中所定义的hyper-available），以决定如果内容已经根据位置被分类则哪个内容将传递。例如，当主叫者在位置A（例如，街道）时，可以传递实时视频内容，而当主叫者在位置B（例如，医院）时，可以传递预先记录的音频内容。

进一步地，特殊特征代码也能够被配置用于终端用户，来用作主叫前缀，以开启或关闭对不同分类的使用，或者指示哪个多媒体内容将使用。如果默认设置是允许DMRT用于所有的呼叫，则例如#33能够被定义为禁用DMRT，并且#34被定义为使用预先记录的多媒体铃声。用户能够拨#33<…>来呼叫网络以禁用该多媒体铃声，或者拨#34<…>来使用预先记录的内容，其中<…>指代与配置选项相关联的代码。

还提供了一种用于控制显示以及重写（override）多媒体CLI显示的网络机制。例如，网络能够限制提前视觉内容传递时间。由于提前媒体内容消耗网络带宽，服务运营商将通常实施策略，诸如被允许播放的媒体的长度。为了实施这样的限制，媒体服务器112被用来提供媒体转换。例如，当正向提前媒体从主叫方被连接至媒体服务器时，它将采集第一帧并且将其转换为将被发送给被叫方的静态图像。

本文所描述的多媒体铃声/回铃声系统和方法，通过使用动态可视主叫线路识别，提供了具备在呼叫建立之前具有主叫方的预览能力的被叫方。从被叫者的视角，能够实时地观看主叫者，取代对于呼入呼叫简单地被提示有姓名文本、图像或一段音乐，提供了另一个级别的用户体验。实时视觉识别也可以被用于附加的鉴别目的，例如被叫者可以被提供有关于呼入呼叫是否应当被立即处理的附加信息。这对于紧急呼叫或者甚至欺骗预防能够是有用的。

将理解，如本文所描述的使用SIP来支持DMRT应用的NGN/IMS网络实施方式，是本发明的实施方式的一个示例。只要能够供应视频数据，具有任何类型架构和协议的任何通信网络将是合适的。例如，如本文所描述的DMRT系统和方法也能够使用H.323或基于http的协议来实施。

将理解，在本说明书中公开并且定义的本发明延伸至所提到的或者根据文本或附图是明显的两个或更多个别特征的所有备选组合。所有这些不同的组合构成本发明各种备选的方面。

Claims (18)

1.一种用于发起具有实时提前媒体的呼叫的方法，所述方法包括：

从第一终端接收会话建立消息并且将所述会话建立消息转发给第二终端；

从所述第二终端接收回铃声并且将所述回铃声转发给所述第一终端；

从所述第一终端和/或所述第二终端接收实时提前媒体被使用的指示；

从所述第一终端接收铃声并且将所述铃声转发给所述第二终端；

从所述第一终端和所述第二终端中的至少一个接收实时提前媒体；以及

将所接收的实时提前媒体分别转发给所述第二终端和/或所述第一终端。

2.根据权利要求1所述的方法，其中所述提前媒体与所述铃声和/或所述回铃声一起被传输。

3.根据权利要求1或权利要求2所述的方法，其中所述实时提前媒体是视频数据。

4.根据权利要求3所述的方法，其中所述视频数据被记录在发送所述会话建立消息的所述第一终端处。

5.根据权利要求3所述的方法，其中所述视频数据被记录在发送所述回铃声的所述第二终端处。

6.根据权利要求1至3中任一项所述的方法，其中所述实时提前媒体由第三方提供。

7.根据前述权利要求中的任一项所述的方法，进一步包括网络策略实施，以选择性地允许或不允许实时提前媒体。

8.根据前述权利要求中的任一项所述的方法，其中转发实时提前媒体包括将所述提前媒体转码。

9.根据前述权利要求中的任一项所述的方法，进一步包括检查订阅数据。

10.一种应用服务器，被配置为执行根据权利要求1至9中任一项所述的方法。

11.一种计算机系统，所述计算机系统用于支持在被适配于通过网络进行通信的两个终端之间建立呼叫之前，通过所述网络进行实时提前媒体传输，所述计算机系统包括：

应用服务器，被配置为允许在所述两个终端之间在正向方向上和/或在反向方向上传输实时提前媒体。

12.根据权利要求11所述的系统，其中所述实时提前媒体源自所述终端之一或两者。

13.根据权利要求12所述的系统，其中所述实时提前媒体是由所述终端中的相应一个或两者记录的视频。

14.根据权利要求11所述的系统，其中所述实时提前媒体由第三方提供。

15.根据权利要求11至14中任一项所述的系统，进一步包括与所述应用服务器通信的媒体服务器，所述媒体服务器被适配为：

接收所述提前媒体；

基于网络策略限制来处理所述媒体；以及

将经处理的媒体提供给所述应用服务器，用于向所述两个终端之一或两者传输。

16.根据权利要求11至15中任一项所述的系统，进一步包括：

与所述应用服务器通信的数据库，所述数据库被适配为接收、存储和/或提供与所述两个终端相关联的配置信息；

其中所述配置信息被所述应用服务器用来管理所述提前媒体的所述传输。

17.根据权利要求16所述的系统，其中所述配置信息包括订阅数据。

18.一种用于通过网络发起具有实时提前媒体的呼叫的方法，所述方法包括：

第一终端提供会话建立消息，所述会话建立消息向所述网络指示对实时提前媒体的使用；

所述网络将所述会话建立消息转发给第二终端；

所述第二终端经由所述网络将回铃声发送给所述第一终端；

所述网络从所述第一终端和/或所述第二终端接收实时提前媒体被使用的指示；

所述第一终端经由所述网络将铃声发送给所述第二终端；

所述第一终端和/或第二终端分别将实时提前媒体连同所述铃声和/或回铃声一起发送。

Images