驻留在设备上的媒体文件的制作方法
【专利摘要】一种设备配置用于在IP网络上进行通信。该设备包括：用户接口；用于访问存储在存储器(该存储器在该设备中或者与该设备相关联)中的信息媒体文件的存储器接口；以及媒体文件流式传输器。该设备配置用于：在呼叫建立期间、在呼叫进行期间或者在呼叫结束时，从IP网络接收指令，该指令标识媒体文件中的一个或更多个。该设备配置用于经由存储器接口从存储器访问所标识的媒体文件，并且对所标识的媒体文件进行流式传输以经由用户接口传达媒体文件中的信息。
【专利说明】驻留在设备上的媒体文件
【技术领域】
[0001]本发明涉及在基于互联网协议(IP)的多媒体通信中的驻留在设备上的媒体文件，具体地涉及在播放公告中使用驻留在设备上的媒体文件。
【背景技术】
[0002]基于IP的通信使得能够在IP网络上进行多媒体通信(例如语音、视频等)。例如，IP多媒体子系统(MS)是由第三代合作伙伴计划(3GPP)定义用以提供(移动)通信网上的IP多媒体服务的技术。以下关于图1描述IMS，图1示意性地示意了在通用分组无线业务(GPRS)接入网的情况下MS如何融入移动网络架构。
[0003]当需要向主叫方或者被叫方播放诸如公告之类的信息媒体(例如，语音/音频或视频)时，尤其是当一方或者两方均连接到访问IP网络而不是归属IP网络(例如位于外国)时，出现问题。在这种情况下，通常将媒体从存储媒体的订户的归属网络中的服务器或者其他实体路由到被服务的订户(主叫方或被叫方)的终端。这可以涉及在大距离上路由媒体。以下针对LTE语音(VoLTE)通信的情况描述该问题的具体示例，但是所描述的问题和解决方案不限于这种通信。
[0004]3GPP还开发了系统架构演进(SAE)作为演进的核心网架构，以及长期演进(LTE)无线移动通信标准作为演进的移动无线接入网。SAE架构是整个基于IP的，控制面和用户面分离。SAE架构的主要组件是增强型的分组核心(EPC)。EPC作为GPRS网络的等价物。LTE标准仅支持分组交换(PS)，然而在许多传统网络中语音(以及其他媒体)呼叫是电路交换的(CS)。LTE的采用意味着:运营商需要重新设计其语音呼叫网络，并且优选的方式是使用基于頂S的VoLTE (LTE语音)。
[0005]通常在IP网络中，具体地在VoLTE情况中，做出了巨大的努力来优化个人到个人的通信的媒体流(用户面)。具体地，当从在一个国家中漫游的主叫方向另一个国家中的被叫方建立语音或视频呼叫时，将用户面(以及控制面)直接从主叫方当前驻留的国家传送到目的地国家，其中被叫方是订户。用户面和控制面横贯MS互连网络(IPX)。
[0006]当需要向主叫方或者被叫方播放公告(或者其他媒体)时，通常将媒体从归属IMS网络中的媒体资源功能(MRF)路由到被服务的订户(主叫方或者被叫方)的终端。在本讨论的上下文中，MRF包括媒体资源功能控制器(MRFC)和媒体资源功能处理器(MRFP) 二者。MRF可以采用若干方式进行部署，例如:
[0007]I)部署在地理上分布的MRF-例如，一个MS运营商可以在每一个区域(例如，欧洲、北美、亚洲等)中部署一个MRF-由此限制被服务的订户与MRF之间的平均距离。
[0008]2)部署共享的MRF-例如，一个頂运营商可以允许其他运营商在其MRF中存储媒体文件，并且其它頂S运营商于是可以将它们所服务的订户连接到共享的MRF。
[0009]第一种方法的一个缺点是:MS运营商不得不在管理和维持遍布全球的可能大量MRF上投资。此外，即使减小被服务的用户与MRF之间的平均距离，作为结果的有效距离可能仍然太大以致于不能证明向漫游用户播放公告是合适的。此外，“本地MRF”的可用性可以根据被服务的订户当前正在漫游的国家而不同。结果，控制通信会话的多媒体电话(MMTel)服务逻辑不得不根据订户当前正在驻留的国家来适配其逻辑处理。
[0010]第二种方法的缺点是:需要在各个MS运营商之间达成管理协议。同样，共享的MRF媒体文件的可用性可以因国家而不同。这使得MMTel服务逻辑必须针对每一个国家适配其逻辑处理。此外，订户的服务将针对每一个国家而不同。
【发明内容】
[0011]本发明的目的是消除以上缺点中的至少一些，并提供一种用于通信的改进设备、一种在设备处提供公告作为IP网络上的呼叫的一部分的方法、以及一种改进的多媒体电话MMTel应用服务器。尽管上述问题涉及长期演进语音(VoLTE)的呼叫的情况，然而所描述的机制可用于互联网协议IP网络上的任意MMTel呼叫，包括机器对机器(M2M)数据呼叫、VoLTE、LTE视频以及其他形式的接入(例如以太网)上的MMTel。应注意，进行呼叫的IP网络的订户可以是“游牧的”，即，连接到国外的IP接入网。
[0012]根据第一方案，一种设备配置用于在IP网络上进行通信。该设备包括:用户接口 ；用于访问存储在存储器(该存储器在该设备中的，或者与该设备相关联)中的信息媒体文件的存储器接口 ；以及媒体文件流式传输器。该设备被配置用于:在呼叫建立期间、在呼叫进行期间或者在呼叫结束时，从IP网络接收指令，该指令标识媒体文件中的一个或更多个。该设备配置用于经由存储器接口从存储器访问所标识的媒体文件，并且对所标识的媒体文件进行流式传输以经由用户接口传达媒体文件中的信息。
[0013]该设备还可以配置用于:向IP网络通知存储在存储器中的信息媒体文件。
[0014]根据第二方案，一种在设备处提供公告作为IP网络上的呼叫的一部分的方法包括:给该设备提供对一个或更多个信息媒体文件的访问。在呼叫建立期间、在呼叫进行期间或者在呼叫结束时，从IP网络向该设备发送指令，该指令标识信息媒体文件中的至少一个。在用户终端上对至少一个所标识的信息媒体文件进行流式传输，以经由用户接口向该设备的用户传达媒体文件中的信息。
[0015]根据第三方案，多媒体电话MMTel应用服务器配置用于从参与到IP网络上的通信会话中或者处于该会话的建立期间的设备接收对该设备能够访问的一个或更多个信息媒体文件的指示。该MMTel应用服务器配置用于向该设备提供用于对一个或更多个信息媒体文件进行流式传输的指令，以便在用户接口上播放其中的信息，该指令标识要播放的信息媒体文件。
[0016]优点在于:这里描述的实施例提供一种被服务的订户(例如，VoLTE订户)可以接收针对呼叫的媒体(例如，语音或视频)公告的机制，而不管他/她驻留的或者当前位于的(如果漫游)国家。该方法不依赖于所访问的IP网络中的特定功能。此外，所提出的方法减轻了在被服务的订户处于遥远的(国外的)国家中时对于公告的长距离媒体传送的需要。
【专利附图】
【附图说明】
[0017]图1是示意性示意与GRPS接入网的移动网络架构相关联的MS网络的网络图。
[0018]图2是示意性示意简化的通用IP通信网架构的框图。
[0019]图3是示意性示意针对VoLTE的情况的提供(provis1n)驻留在终端上的媒体的简化的网络架构的框图。
[0020]图4是示意播放呼叫前的公告的流程的信令图。
[0021]图5是示意播放呼叫结束的公告的流程的信令图。
[0022]图6是示意在呼叫建立失败时播放公告的流程的信令图。
[0023]图7是示意播放呼叫中公告的流程的信令图。
[0024]图8是包括三个音脉冲的序列的预付费警告音的图形说明。
[0025]图9是由音参数定义的警告音的示例的图形说明。
[0026]图10是示意在呼叫前的公告中使用本地公告的语音XML的示例的信令图。
[0027]图11是示意播放公告的过程的总结的框图。
[0028]图12是描述针对也采用增值服务VAS的实施例的图11的架构的扩展的框图。
[0029]图13是描述实施例中所涉及的原理方法步骤的流程图。
[0030]图14是示意配置用于在IP网络上进行通信的设备的实施例的原理功能组件的框图。
[0031]图15是示意多媒体电话(MMTel)服务器的原理功能组件的框图。
【具体实施方式】
[0032]下面将首先关于通用的网络架构、然后关于长期演进语音(VoLTE)会话以及IP多媒体子系统(IMS)的网络架构来描述实施例。实施例描述在呼叫进行期间播放公告的具体情况，但是所描述的原理不限于播放语音(即音频)公告，而是可以应用于任意媒体数据(例如包括视频)的流式传输。
[0033]图2示意性地示出了简化的通用通信网架构，包括多媒体通信设备20、IP接入网22、IP通信网24以及电话应用服务器26的形式的设备。电话应用服务器26具有或者至少能够访问永久存储公告媒体文件的存储器A。
[0034]多媒体通信设备20被配置用于进行基于IP的通信，例如语音通信或者视频通信。设备20可以是移动的，例如移动终端、或者固定设备或终端。示例包括:基于桌上型的有线VOIP电话、基于PC的软件电话以及移动(手持)IP通信终端。装置20在功能上连接到IP接入网22。设备与接入网之间的连接特性取决于设备的类型。例如，移动电话通过无线电信令连接到接入网22。
[0035]IP接入网22用于提供设备20与IP通信网24之间的功能连接。IP通信网24允许设备20建立与在功能上连接到IP通信网24的其他用户设备或者在功能上连接到其它通信网的用户设备的通信会话。
[0036]电话应用服务器26在功能上连接到IP通信网24，并且用于建立媒体(例如语音或视频)通信会话。语音会话和视频会话是可以在IP通信网24内执行的服务。语音会话或者视频会话的执行要求在设备20与电话应用服务器26之间建立电话服务关系。语音会话或视频会话的执行还通过在设备20和电话应用服务器26 二者中的服务逻辑处理来完成。
[0037]IP通信网24通常包含部署在一个或更多个节点中的多个功能组件(参见，例如图1中示意性描述的MS网络)。IP通信网24在逻辑上划分为归属IP通信网和访问IP通信网。通常，每个IP通信网无论是归属网络还是访问网络，都是为特定地理区域提供服务。设备20与归属IP通信网的订户相关联(例如属于)。电话应用服务器26驻留在归属IP通信网中。IP接入网22连接到访问IP通信网。当订户位于他的/她的通信区域中时，访问IP通信网将与归属IP通信网相同。然而，通常，访问IP通信网和归属IP通信网可以是不同的网络，并且因此存在有利于两个网络之间的通信的IP基础设施。
[0038]通常，在设备和IP通信网之间使用两类通信协议:
[0039]I)呼叫控制信令:该协议包括用于建立通信会话(以及其他)的信令消息；以及
[0040]2)媒体传送:该协议包括用于传送媒体(例如数字化的语音、视频等)的消息。
[0041]这些信号/消息在图2中示出的实体之间传递，用实线连接线28表示。
[0042]电话应用服务器26可以访问存储在存储器A中的公告文件集合，这些公告文件可以在声音或视频通信会话建立期间或者完成后使用。存储该公告文件集合的存储器A可以在电话应用服务器内26内部，或者可以被包含在外部数据存储器中。在后一种情况下，该公告文件集合可以是可访问的并且可以由多个电话应用服务器使用。
[0043]用于播放公告的机制的原理如下。设备20包含MMTel通信会话所需的媒体文件集合。该媒体文件集合通常包括“订户繁忙”、“订户不可达”、“网络拥塞”、“正在转移呼叫”、“呼叫禁止”、“低信用警告”等的标准的公告。设备20可以在会话建立的开始时向电话应用服务器26报告设备20的公告能力以及设备20已经在其本地存储器中存储的公告媒体文件。备选地，如下面进一步解释的，作为会话建立流程的一部分，可以向设备20提供公告媒体文件。当MMTel服务逻辑想播放公告时，MMTel服务逻辑指示设备20播放所要求的公告。被服务的订户现在已经收到公告而无需长距离的媒体传送。该机制可以应用在呼叫建立期间、在进行呼叫期间或者在呼叫结束时。如果在进行呼叫期间播放公告，则当公告播放完成时，MMTel服务逻辑指示设备20重新建立用户面以继续与远程方的会话。
[0044]除了别的以外，设备20与电话应用服务器26之间的上述电话服务关系可以用于将公告文件的指定子集传送到设备20。公告文件的传送可以通过呼叫控制信令协议或者通过其他通信或数据传送方式来完成。这通过图2中的箭头线29示意。
[0045]设备20包括:包括用于接收并存储公告文件的处理器P在内的功能组件。处理器P可以从电话应用服务器26接收公告文件，并且将这些公告文件存储在存储器M中。存储器M可以是终端20内部的硬连接的存储设备，例如随机存取存储器(RAM)、外部可编程只读存储器(EPROM)或者硬盘。备选地，存储器M可以被包含在诸如标识模块(例如通用集成电路卡UICC)之类的可移除设备中。提供用户接口 Π用于向用户播放公告。用户接口 UI可以集成到终端20 (例如，内置扬声器)，或者可以在终端20的外部，例如通过有线连接的或者无线连接的(例如，通过蓝牙?)的外部扬声器。呼叫处理功能C控制语音和多媒体呼口q。呼叫处理功能C负责处理通信会话。呼叫处理功能C可以访问存储器M，以检索公告并在用户接口 UI上播放这些公告。公告的检索和播放可以在由电话应用服务器26指示时发生。
[0046]以下描述的实施例涉及经由MS网络的VoLTE呼叫。
[0047]图1是示例性示意在通用分组无线电服务(GPRS)接入网的情况下IMS如何融入移动网络架构的网络图。向EPC/LTE接入应用相同原理。对通信的控制发生在三个层(或者面)。最低层是连接层1，也称为承载面，并且通过连接层I将信号指引至/自正在接入网络的用户设备(UE)。中间层是控制层4，并且顶部是应用层6。
[0048]MS3包括核心网3a和服务网络3b，核心网3a在中间的控制层4以及连接层I上操作。MS核心网3a包括:在连接层I处经由GGSN2将信号发送/接收至/自GPRS网络的节点；以及包括呼叫/会话控制功能(CSCF) 5在内的网络节点，CSCF5在中间的控制层4中操作为頂S内的SIP代理。归属订户服务器(HSS)8存储订户信息的细节。图1中还示出了多媒体资源功能实体2 (参照以上的MRFC和MRFP)。图1中未示出的其他IMS实体可以包括接入会话边界网关(A-SBG)、互连边界控制功能(IBCF)、转换网关(TrGW)等。顶部的应用层6包括MS服务网络3b。提供应用服务器(AS) 7用于实现MS服务功能。
[0049]如图1所示，用户设备(UE)可以通过附着到接入网然后通过连接层I来接入MS。例如，UE可以经由增强型分组核心网(EPC)/LTE接入来进行附着。
[0050]图3针对VoLTE的情况在概念上并且用基本的形式示出驻留在终端上的媒体(例如公告)的提供(provis1n)的架构。假定被通知的读者熟知VoLTE架构，尽管应注意以下几点。MS用户所操作的采取VoLTE设备30形式的设备经由IP接入网32连接到访问IMS网络34，IP接入网32可以包括合称为增强型分组系统(EPS)的LTE和EPC。访问MS网络34在功能上连接到订户的归属MS网络36。访问MS网络34和归属MS网络36包括上述图1中的功能实体。
[0051]用户面和控制面信令二者直接从设备30通过接入网32传递到访问网络34，并且从访问网络34沿着实线38传递到目的地MS网络。访问MS网络34与订户的归属MS网络36之间的控制面信令(如线37所示)横贯MS互连网络(IPX-未示出)。用户面信令直接通过访问MS网络34传递到目的地MS网络。从访问MS网络34路由到目的地MS网络的MS路由要求在访问MS网络34和归属MS网络36 二者中的特定的支持。由驻留在归属MS网络36中的MMTel应用服务器提供MS上的呼叫服务。
[0052]根据当前描述的实施例，VoLTE设备30访问包含媒体文件集合的本地存储器39，以进行常规VoLTE呼叫处理。这些媒体文件包括:通常在呼叫建立期间使用的公告；可以在呼叫进行期间使用的公告；以及可以在呼叫结束时使用的公告。应注意，根据现有技术的流程，MMTel应用服务器可以在归属MS网络中的媒体资源功能处理器(MRFP)中存储该公告集合。然而，根据目前提出的方法，本地存储器39包含该公告集合的副本。
[0053]本地存储器39可以是VoLTE设备30中的存储器，或者是可插入到设备中的WCC中的存储器。在VoLTE设备30准备好被用于建立多媒体(例如语音和视频)呼叫之前，需要对VoLTE设备30进行个性化。这涉及用个人信息(例如:一个或多个MS公共用户标识(MPU)、IMS私人用户标识(MPI)、归属IMS网络域名等)、以及用指定的配置文件和存在于nCC上的IP多媒体服务标识模块(ISM)应用中的指定文件对VoLTE设备30进行编程。编程可以用空中下载(OTA)方法来实现，在OTA方法中，頂S运营商通过移动无线电接入网远程地对设备和ISM应用进行编程。OTA是公知的技术并且对于编程VoLTE设备是可接受的方法。
[0054]在本实施例中，对VoLTE设备30进行编程以准备用于正常的操作还包括下载包括公告在内的媒体文件集合。通常，包括约25个公告的公告集合可以用于常规的电话。于是，将公告存储在VoLTE设备30的本地存储器39中。公告可以存储在设备30中，存储在nCC上的SM应用中的合适的数据文件中-例如，通用(U) SM或者IS頂应用-或者存储在与设备相关联(包含在设备中)的另一数据存储卡上。例如，公告可以以原生的8000Hz的8比特的脉冲编码调制(PCM)形式来传送并存储。PCM的I秒消耗数据存储器的8千字节，因此每平均5秒的25公告将共计约IM字节的数据，这恰好在当前移动设备的数据存储器限制之内。
[0055]将媒体文件从MS归属网络36传送到VoLTE设备30可以使用文件传送协议(FTP)。VoLTE设备30配备有终端配置程序，并且为了下载媒体文件，向设备30发送FTP地址(ftp://)。因此，设备30可以使用FTP检索文件(的副本)。
[0056]当VoLTE设备30建立多媒体电话会话，或者作为始发终端或者作为端接终端，VoLTE设备30向MMTel应用服务器报告其进行本地公告流式传输的能力以及VoLTE设备30所具有的在本地存储器中可用的公告。该报告可以如在以下示例中这样完成:
[0057]始发语音/视频呼叫
[0058]INVITE sip: john.smithimy-company.com SIP/2.0
[0059]…
[0060]Supported: 10rel,
[0061]media_streaming ! ims.vodafone.uk/media_files/mmtel/mmtel-files-vO
[0062]3.07.12
[0063]端梓语咅/视频呼叫
[0064]SIP/2.0 2000k
[0065]…
[0066]Supported: 10rel,
[0067]me d i a_s t r e am i n g ! ims.vodafone.uk/media_files/mmtel/mmtel-files-v03.07.12
[0068]字符 串 “media_streaming ! ims.vodafone.uk/media_files/mmtel/mmtel-files-V03.07.12”针对所支持的头部形成选项标签。互联网工程任务组(IETF)RFC3261，第8.1.1.9和第20.37节包括对所支持的头部的描述。在本示例中，选项标签的含义如下:
[0069]media_streaming该令牌标识终端提供本地公告的能力；
[0070]!该字符作为分隔符；
[0071]ims.vodafone.uk这是订户的归属MS网络。该MS网络拥有并分发媒体文件集合；
[0072]/media_files/mmtel/这构成了公告文件的目录结构；
[0073]mmtel-files-v03.07.12这是包含公告的文件的名称，包括版本号。
[0074]当建立会话时，MMTel应用服务器于是可以确定哪些公告媒体文件可用。如果终端不报告其公告能力，或者如果要求的媒体文件(例如，要求v03.07.10或者之后版本)在终端中不可用，则MMTel应用服务器可以恢复到现有技术的方法，例如不播放公告或者建立向归属MS网络中的MRF的(国际的)用户面连接。
[0075]当网络运营商具有可用的新公告时，OTA预配置(provis1ning)系统可以用于向被服务的VoLTE终端发送OTA通知，以更新其存储的公告文件。该运营商的VoLTE终端于是使得所请求的公告文件可用。
[0076]以下示例描述在VoLTE呼叫进行期间播放(流式传输)公告。
[0077]图4是示意播放呼叫前的公告(即，在呼叫建立流程完成之前向主叫方A方40做出的公告)的信令图。所示出的信令一直到由MMTel AS42将会话发起协议(SIP)邀请请求转发到目的地一方。A方40正在使用包括SIP用户代理(UA)的设备(例如以上根据图3描述的VoLTE设备30)。该图是一种简化，没有示出A方40与MMTel AS42之间的功能实体，并且没有示出SIPlOO尝试信令。
[0078]在信号401处，A方40发送用于建立语音呼叫的邀请请求。邀请请求401包含会话描述协议(SDP)要约(offer)，指示针对该媒体会话所提供的媒体流的特性。邀请请求401还包括此前描述的所支持的头部。MMTel服务确定应当向A方40做出呼叫前的公告，并且因此在信号402中，MMTel AS42向A方40发送183会话进行(progress)响应。183会话进行信号402包含对可靠的临时响应的请求以及，还包括针对A方UA的对指定公告进行播放(流式传输)的指令。例如，信号402可以包括SIP指令:
[0079]SIP/2.0 183Sess1n progress
[0080]…
[0081]Media:mmtel-files-v03.07.12\25
[0082]SIP头部Media:构成从媒体文件mmtel-files-v03.07.12播放公告25的指令。在183会话进行信号402中不必包括SDP应答。公告媒体文件被本地包含在VoLTE设备中。设备可以通过将PCM从所标识的媒体文件直接流式传输到终端中的媒体播放器，来在内部将公告流式传输到用户。
[0083]当已经播放公告时，A方40的设备中的UA发送确认响应-PRACK403，作为183会话进行信号402所要求的可靠的临时响应。PRACK403向MMTel AS42指示公告的播放已经完成并且服务逻辑可以继续其处理。应注意，在PRACK403返回之前183会话进行信号402可以被重复若干次，这是因为对于可靠的临时响应的请求的发送方期待立即的响应。在信号404中，MMTel AS42用SIP2000K来对A方40进行应答。然后，在信号405中，MMTel AS42向目的地一方转发邀请，以便呼叫建立可以继续。
[0084]图5是示意用于播放呼叫结束的公告的流程的信令图。实体包括:参与到呼叫中的VoLTE订户50的SIP UAjVoLTE订户50在这种情况下可以是主叫方(A方)或者被叫方(B方)；以及如上图4中的所述的MMTel AS42。信令交换501和502表示正在进行并且将要结束的呼叫。
[0085]在信号503中，MMTel AS42向VoLTE订户发送SIP再见(Bye)请求，VoLTE订户在这种情况下可以是主要方(A方)或者被叫方(B方)。再见请求503包含播放本地公告的指令，例如:
[0086]Bye sip:245.33.87.34:5056SIP/2.0
[0087]…
[0088]Media:mmtel-files-v03.07.12\20
[0089]在信号504中，订户的SIP UA50像通常一样以2000K响应。在步骤505，UA50然后开始对所请求的呼叫结束公告(来自媒体文件mmtel-files-V03.07.12的公告20)的媒体文件进行流式传输。对于本地公告的播放不需要SDP协商。再见请求503暗示所建立的用户面将被终结。
[0090]图6是示意用于在呼叫建立失败时播放公告的过程的信令图。主叫A方40和MMTel AS42与上面图4中描述的相同。信号601和602是从主叫的A方向被叫方(未示出)发送的SIP邀请。信号603是由被叫方返回的SIP “486此时繁忙”消息，并且该信号由MMTel AS62在信号604中转发到A方40。“486此时繁忙”604还包含采取以下形式的公告指令:
[0091]SIP/2.0486Busy here
[0092]…
[0093]Media:mmtel-files_v03.07.12\15
[0094]在信号605中，A方的终端设备40中的SIP UA响应于“486此时繁忙” 604发送SIP “Ack”，SIP “Ack”由MMTel AS42在信号606转发到被叫方。在步骤607处，A方设备40中的SIP UA播放所标识的公告媒体文件(mmtel-files-v03.07.12\15)。应注意，是否已经提供了临时的SDP回答或者SDP协商不重要，这是因为对于呼叫失败公告不需要SDP。终端可以将所存储的公告的媒体(例如，PCM采样)直接流式传输至终端中的播放器。
[0095]呼叫结束的公告通常可以是重复的公告。例如，可以重复地播放公告，直至用户“挂断”(即，释放连接)。这可以利用像“重复”的媒体播放参数来完成，例如:
[0096]SIP/2.0 486Busy here
[0097]…
[0098]Media:mmtel-files_v03.07.12\15 ；repeat = 5
[0099]参数repeat = 5指示应当重复公告最多5次。
[0100]图7是示意用于播放呼叫中间(mid-call)的公告的信令图。实体包括:参与呼叫的VoLTE订户70的设备中的SIP UA,向VoLTE订户70播放呼叫中间的公告，并且VoLTE订户70在这种情况下可以是主叫方(A方)或者被叫方(B方)；以及MMTel AS42，如上面图4中所示。信令交换701和702表示正在进行的呼叫。在信号703-705中，根据现有方法，MMTel AS42使用SIP邀请事务(transact1n)(重新邀请)来针对远程方的媒体连接更新用户面(特别是SDP)。此外，在信号706-708中，MMTel AS42使用类似的重新邀请事务来针对订户70的媒体连接更新用户面。在本实施例中，向被服务的订户70发送的邀请请求706包含应用本地公告播放的指令。例如:
[0101]INVITE sip:245.33.87.34:5056SIP/2.0
[0102]…
[0103]Media:mmtel-files-v03.07.12\10
[0104]在本示例中，请求设备从其已经访问的媒体文件集合mmtel-files_v03.07.12中播放媒体文件。在步骤709，订户70的设备播放所标识的公告媒体文件。在信号710中，订户70的SIP UA向MMTel AS42发送更新信号，以指示公告播放的完成。当MMTel AS42接收到更新信号710时，其用SIP2000K消息711进行响应，并且于是可以应用所要求的SIP信令712、713来重连各方，以继续呼叫。
[0105]图8是包括由200ms间隔分离的三个200ms持续时间的音脉冲的序列在内的预付费警告音的图形说明。预付费警告音的概念已经在GSM/3G网络中建立。作为一个示例，服务控制点(SCP)可以与移动交换中心(MSC)具有“移动网络增强型逻辑的订制应用”(CAMEL)关系，以用于应用针对呼叫的在线充值。SCP在呼叫进行期间的某一时刻可以指示MSC将警告音注入到语音路径。与SCP具有CAMEL关系的MSC与媒体网关(MGW)具有控制关系。呼叫的用户面横贯MGW。这促进MSC在SCP的指令下指示MGW在呼叫中应用警
AK Vr.1=I 曰。
[0106]然而，对于MS/MMTel网络，因为在MS网络中媒体路径(用户面)没有利用与用户面在GSM/3G网络中的MGW中锚定相同的方式在MGW或者MRF中锚定而产生问题。MMTel-AS向MMTel呼叫的媒体路径注入警告音的唯一可能是:其临时地修改呼叫的用户面并在被服务的订户(SIP终端)与MRF之间建立用户面连接。于是MMTel-AS必须指示MRF播放警告音。随后，MMTel-AS不得不在每个端点之间重新建立用户面。这种播放总持续时间为Is的警告音的方法很麻烦，需要大量的信令开销。此外，用户面的双重建立可能导致语音或者其他媒体的中断。
[0107]上述呼叫公告的相同原理可以用于提供对于该插入警告音的问题的解决方案。通过包括预付费警告音作为本地存储的、并且MMTel用户设备(UE)设备已经访问的媒体文件集合中的一个媒体文件，MMTel AS可以指示UE播放特定的本地存储的包括(标准化的)警告音的媒体文件。包括如由UE在呼叫建立时或者之前向MMTel-AS所报告的公告的媒体文件集合包括预付费警告音媒体文件。这种解决方法的优点是:不需要(双重)SDP更新，不需要MRF来连接到语音路径，并且不需要在MMTel-AS与MRF之间建立控制关系。
[0108]例如，MMTel-AS可以指示MMTel UE播放警告音的一种方式是如在IETF RFC6086中定义的那样通过发送SIP “Info”请求。根据定义的语法和语义，可以在Info请求的主体部分中包含用于播放警告音的指令。
[0109]警告音的特性(音调、频率、音量)可以用与GSM/3G中标准化相同的方式在MMTel公告集合的上下文中进行标准化。备选地，或者此外，可以提供灵活的警告音，其中MMTel-AS在SIP Info消息中包括音描述符集合作为定义警告音的参数。从3GPP TS23.078再现的图9示意了由这种参数定义的警告音的示例，包括:警告周期(整个持续时间)、包括多个突发以及突发之间的间隔在内的突发列表、以及构成每个突发的音持续时间和音之间的音间隔。因此，需要将灵活的警告音的参数标准化为MMTel公告集合的一部分。
[0110]在上述流程之后，MMTel UE向MMTel-AS报告其支持的预付费警告音。例如，支持SIP的头部可以包括:
[0111]Supported: 10rel，
[0112]media_streaming ! ims.vodafone.uk/media_files/mmtel/mmtel-files-v03.07.12
[0113]选项标签
[0114]media_streaming ! ims.vodafone.uk/media_files/mmtel/mmtel-files-v03.07.12涉及包括预付费警告音的本地存储的公告媒体文件。备选地，专用选项标签可用于该目的:例如:
[0115]Supported: 10rel，
[0116]media_streaming ! ims.vodafone.uk/ media_f i I es/ mmtel/mmtel-files-v03.07.12，mmtel-warning-tones
[0117]选项标签“mmtel-warning-tones”指示UE支持警告音的生成。
[0118]上述实施例包括MMTel AS既向VoLTE订户提供应用本地媒体的指令，又提供对要被流式传输的实际媒体文件的指示。提供对要被流式传输的实际媒体文件的指示足以播放单个完整的公告。然而，也可以用类似的方法(例如在收集用户输入(例如，数字)中或者在播放级联的公告中涉及用户交互)来处理更复杂的情况，但是可能要求额外的SIP信令逻辑。定义对复杂公告的播放(并且当需要时，收集用户输入)的一种备选方法是使用根据预定的协议(例如，语音XML(可扩展标记语言))进行编程的媒体文件。
[0119]图10是示意将语音XML用于本地公告以及呼叫前的公告中的用户交互的示例的信令图。主叫A方40和MMTel AS42与上面图4中描述的相同。信号1001是来自主叫A方40的VoLTE设备的经由MMTel AS42路由的SIP邀请。A方40的VoLTE设备包括具有嵌入式语音XML执行引擎的手机应用。信号1002是从MMTel AS42向A方40发送的SIP183会话进行消息，并且包含用于建立语音XML信令关系的地址和相关标识符。所支持的头部包括:
[0120]SIP/2.0 183Sess1n progress
[0121]...
[0122]Media:voicexml = http://mmtel-asLims.0perator.se/voice-xml-scripts/voice-xml-script_10.vxml〈sess1n_id>
[0123]A方40的VoLTE设备使用mmtel -asI.ims.0perator, se作为建立语音XML关系的地址。A方40的VoLTE设备向该地址发送HTTP Get (获得)命令1003，该地址将通过域名系统(DNS)配置，分解为服务该订户的MMTel AS42的IP地址。后缀〈sess1n-1d>标识HTTP获得请求被耦合到的MMTel会话。MMTel AS42返回2000K信号1004，并且之后交换语音XML相关的信令，A方40的设备通过该交换获得并执行所要求的XML文件。
[0124]作为流程的一部分，可以提示A方40输入信息(例如，采取在键区上输入数字的形式)。当已经获得要求的XML文件时，A方40的设备执行要求的XML文件来播放公告(步骤1005)。在完全语音XML执行之后，A方40的设备与MMTel AS82交换另一 HTTP获得事务1006、1007。那时，MMTel服务逻辑可以继续呼叫建立，如由MMTel AS42向目的地方转发的邀请1008所示。A方40的设备准备接收对初始邀请请求1001的SIP响应。
[0125]将根据预定协议(例如语音XML)编程的可执行的媒体文件用于公告播放和用户交互提供了在设备中执行(复杂的)脚本的灵活性。尽管图10示意了呼叫前的公告/交互，语音XML可以用于呼叫前、呼叫中间以及呼叫结束时的公告/用户交互。当将语音XML应用于呼叫结束时的公告时，则MMTel服务逻辑不得不保持活动直至公告完成，因为语音XML关系在公告完成时(即，公告已经被整个播放)终止。最后的HTTP获得事务1006、1007在公告完成之后发生。因此，为了播放单个的呼叫结束时的公告(包括成功建立的呼叫和不成功的呼叫建立二者)，优选地在最后的请求或向A方40的设备发送的响应中包括公告指令。然后，MMTel服务逻辑可以终止，并且A方40的设备可以播放本地公告，而无需与MMTel服务逻辑进一步交互。
[0126]图11总结与图3的简化的网络架构相关的上述流程，并且对于相同的实体使用相同的附图标记。此外，图11示出了连接到归属頂S网络36内的MMTel AS42，如上面图4中所述。如通过单箭头虚线1101表示的，VoLTE设备30向MMTel AS42报告其本地公告能力以及本地存储的公告媒体文件。用MMTel AS35与VoLTE设备30之间的双箭头虚线1102表示使用驻留在终端上的媒体文件在设备30处播放本地公告。
[0127]图12描述了也采用来自增值应用服务器(VAS) 33的增值服务的实施例的图11的架构的扩展。相同的附图标记被用于与图11中相同的实体。VAS33使用(变量)Parlay-X与MMTel AS42进行通信。当VoLTE设备30建立呼叫(例如，语音和/或视频)时，照常存在与MMTel AS的SIP信令。如上述对于图11，线1101表示正在向MMTel AS42报告的终端的本地公告能力，使得MMTel AS42能够将该终端的本地公告能力用于使得终端30使用MMTel逻辑扩展来播放指定的公告媒体文件。VAS33包括可以由MMTel AS42针对多媒体通信会话所调用的服务逻辑。当VAS33已经通过与MMTel AS42的Parlay-X协议获得了对呼叫的控制时，VAS33可以向MMTel AS42提供关于如何进一步处理多媒体会话的指令。Parlay-X路径用虚线箭头1201表示。
[0128]VAS逻辑调用1201包括关于终端的逻辑公告能力的信息。VAS33此时还可以使用该能力。具体地，当VAS33需要向被服务的订户播放公告时，VAS33首先从所报告的设备能力确定所要求的公告在设备中是本地可用的。VAS逻辑现在可以通过Parlay-X上的信令，指示设备30播放特定的本地公告。这由VAS33与VoLTE终端30之间的双箭头虚线1202表示。在该实施例中，VoLTE预配置(provis1ning)系统应当保证向VoLTE设备30提供VAS33可能想要在设备30处播放的媒体文件。例如，在上述示例中的文件集合mmtel-files-v03.07.12可以包括常规MMTel业务所需要的媒体文件以及由VAS33提供的特殊增值业务的媒体文件。
[0129]图13是示描述包括在上述实施例中的原理方法步骤的流程图。在步骤1301，将公告媒体文件下载到订户的用户终端设备(例如VoLTE终端)，以存储在设备可访问的存储器中。这可以在设备发起呼叫之前发生。在步骤1302，设备发起多媒体呼叫并向MMTel AS报告其公告能力以及可用媒体文件的列表。在步骤1303，MMTel AS确定是否也存在可以应用于呼叫的增值业务。如果存在，则在步骤1304，MMTel AS向相关联的VAS提供可用媒体文件的列表。在步骤1305，MMTel AS确定要作出的公告，并指示设备播放所列出的媒体文件中的特定的一个。在步骤1306，设备通过流式传输特定的媒体文件来播放公告，以便在与设备相关联的用户接口(例如扬声器、显示屏等)上播放公告。
[0130]图14是示意了配置用于在IP网络上进行通信的设备1400的实施例的原理功能组件的框图。设备1400包括IP接口 1401，通过IP接口 1401在设备1400与IP网络之间发送并接收控制面和用户面信号。设备还包括处理能力1402，处理能力1402包括用于流式传输媒体文件的媒体流式传输器1403。可选地,处理器1402还可以包括电话应用，具有嵌入式XML执行引擎1404或者用于执行根据预定协议编程的媒体文件的类似能力。设备1400还包括公告媒体文件146存储在其上的存储器1405。如上述讨论的，存储器1405可以是内置于设备1400中的存储器，或者设备1400可以包括用于访问存储在存储器设备中的数据的存储器接口，存储器设备可插入到设备(以及可从设备移除)，例如nCC。设备1400还包括用户接口，用户接口在所描述的实施例中包括扬声器1407和显示器1408，在扬声器1407和显示器1408上可以向用户播放包含在媒体文件1406中的媒体。再次，如上所述，用户接口可以形成设备1400的一部分(如图所示)，或者可以是与设备具有有线的或者无线的连接的接口。
[0131]图15是示意多媒体电话MMTel应用服务器1500的原理功能组件的框图。服务器1500包括输入/输出1501，通过输入/输出1501发送和接收去至/自其他网络实体的信令/消息。存储器1502存储数据和编码指令。处理器1503执行配置服务器1500的编程指令。在处理器1503内有流式传输指令单元1504和信令关系信息单元1505。MMTel服务器1500经由输入/输出1501从参与到在IP网络上的通信会话中的设备或者在该会话的建立期间接收对该设备能够访问一个或更多个信息媒体文件的指示。信令关系信息单元1505根据从网络接收到的信号确定何时应当在设备处对包含在信息媒体文件的一个中的公告(或者其他信息)进行流式传输。程序指令将流式传输指令单元1504配置为:经由输入/输出1501向设备提供用于对信息媒体文件中的一个或更多个进行流式传输的指令，以在用户接口上播放其中的信息。对设备的指令标识要播放的信息媒体文件。
[0132]上述实施例促进播放例如公告的媒体文件，并且应用用户交互，本地地从连接到IP网络的设备(例如VoLTE终端)。在呼叫建立时，向MMTel服务逻辑报告可以在终端中自动提供(auto-provis1ned)的公告的标准化组。MMTel服务逻辑于是可以指示终端播放任意公告，作为其服务逻辑执行的一部分。方法可以是扩展的，以使增值业务(VAS)可以使用这些本地公告。实施例主要针对听得见的公告进行描述的，但是可等同地适用于例如视频公告的其他媒体，其中视频文件(例如*.mpg)可以以与音频文件相同的方式提供(provis1n)给设备。尽管实施例描述VoLTE终端的使用，方法大体上可应用于MMTel设备，例如(游牧的)以太网/有线、WLAN、电缆等。
[0133]上述实施例促进向MMTel订户播放驻留在终端上的媒体以及与MMTel订户的用户交互，而无需在订户的终端与MRF(例如，在归属MS网络中)之间建立媒体连接。结果，可以实现媒体传输开销中的显著节约，特别地对于VoLTE呼叫。此外，由于对于用户交互(公告播放)将存在更少的延迟，因此对来自终端本地的媒体的流式传输(与来自(远程位置的)MRF相反)可以改善用户体验。这减轻了在针对漫游的VoLTE订户播放公告中的显著问题。
【权利要求】
1.一种设备(30 ;1400)，配置用于在IP网络上进行通信，并且包括:用户接口(1407，1408);用于访问存储在所述设备中的存储器(1405)或者与所述设备相关联的存储器(1405)中的信息媒体文件(1406)的存储器接口 ；以及媒体文件流式传输器(1403)， 其中所述设备配置用于:在呼叫建立期间、在呼叫进行期间或者在呼叫结束时，从IP网络接收指令，所述指令标识所述媒体文件(1406)中的一个或更多个；经由存储器接口从存储器(1405)访问所标识的媒体文件；以及对所标识的媒体文件进行流式传输以经由用户接口传达媒体文件中的信息。
2.根据权利要求1所述的设备，还配置用于:向IP网络通知存储在存储器(1405)中的信息媒体文件(1406)。
3.根据权利要求1或2所述的设备，其中所述媒体文件流式传输器(1403)是用于播放媒体文件的驻留在设备上的媒体流式传输器，其中响应于所述指令，所述设备在驻留在设备上的媒体流式传输器与用户接口(1407,1408)之间建立媒体连接，以播放所标识的信息媒体文件。
4.根据前述任一项权利要求所述的设备，还配置用于:下载信息媒体文件(1406)以便存储在存储器(1405)中。
5.根据权利要求4所述的设备，所述设备具有相关联的通用集成电路卡UICC，所述ncc包括IP多媒体服务标识模块IS頂应用，所述设备配置用于:作为ISM应用的远程空中下载OTA编程的一部分,下载信息媒体文件(1406)。
6.根据前述任一项权利要求所述的设备，还包括处理器(1402)，用于对根据指定的媒体编码协议存储的媒体文件进行流式传输。
7.根据前述任一项权利要求所述的设备，其中所述设备配置用于访问的IP网络是IP多媒体子系统頂S网络(34、36)。
8.根据权利要求7所述的设备，被配置为长期演进语音VoLTE设备。
9.一种在设备处提供公告作为IP网络上的呼叫的一部分的方法，所述方法包括: 给所述设备提供(1301)对一个或更多个信息媒体文件的访问； 在呼叫建立期间、在呼叫进行期间或者在呼叫结束时，从IP网络向所述设备发送指令(1305)，所述指令标识所述信息媒体文件中的至少一个；以及 在所述设备上对所标识的所述至少一个信息媒体文件进行流式传输(1306)，以经由用户接口向所述设备的用户传送媒体文件中的信息。
10.根据权利要求9所述的方法，还包括:向IP网络通知(1302)存储在存储器中的所述设备能够访问的信息媒体文件。
11.根据权利要求10所述的方法，其中通过提供标识存储在存储器中的信息媒体文件的“支持SIP的头部”的选项标签来通知IP网络。
12.根据权利要求9至11中任一项所述的方法，其中播放所标识的信息媒体文件包括在驻留在设备上的媒体流式传输器与用户接口之间建立媒体连接。
13.根据权利要求9至12中任一项所述的方法，还包括:从所述设备的用户的归属MS网络下载(1301)信息媒体文件，以存储在存储器中。
14.根据权利要求9至13中任一项所述的方法，其中所述指令由MMTel应用服务器发送。
15.根据权利要求9至14中任一项所述的方法，还包括:向增值业务VAS通知(1304)所述设备可用的所述一个或更多个信息媒体文件，所述VAS向用户终端发起所述指令。
16.一种多媒体电话MMTel应用服务器(1500)，配置用于:从参与到IP网络上的通信会话中的设备或者在所述会话的建立期间接收对所述设备能够访问的一个或更多个信息媒体文件的指示，并向所述设备提供用于对所述信息媒体文件中的一个或更多个进行流式传输的指令，以便在用户接口上播放所述信息媒体文件中的一个或更多个中的信息，所述指令标识要播放的信息媒体文件。
17.根据权利要求16所述的MMTel应用服务器(1500)，还配置用于:向所述设备提供用于建立信令关系的信息，以使所述设备能够使用所述信令关系来检索根据指定的媒体编码协议进行编码的媒体文件，以用于在所述设备处进行流式传输。
【文档编号】H04L29/06GK104272696SQ201280072713
【公开日】2015年1月7日 申请日期:2012年4月27日 优先权日:2012年4月27日
【发明者】罗希尔·诺尔德斯 申请人:瑞典爱立信有限公司