CN101395883A

CN101395883A - 通过用于改善现有呼叫线路标识服务的基于ims的plmn传递预定制名片多媒体内容的方法和结构

Info

Publication number: CN101395883A
Application number: CN200780004735.XA
Authority: CN
Inventors: G·德詹; A·米利塔鲁; A·伯纳迪
Original assignee: Siemens SpA
Current assignee: Nokia Communications Italian Co; Nokia Communications Ltd; HMD Global Oy
Priority date: 2006-02-10
Filing date: 2007-02-05
Publication date: 2009-03-25
Anticipated expiration: 2027-02-05
Also published as: EP2022231A2; EG25320A; MX2008010216A; US20090264112A1; CN101395883B; EP1819125A1; WO2007090587A2; WO2007090587A3; US8140060B2

Abstract

在为了传送基于IP的多媒体服务到终端用户而连接到IMS平台的蜂窝电话网络内，执行改善的呼叫线路标识(CLI)服务。新结构基于被连接到IMS和核心网络的分组交换(PS)域的多媒体CLI专用服务器(MM－CLI)。MM－CLI包括：控制服务器、媒体存储器、和web接口。控制服务器用于处理包括称为MESSAGE的SIP元素的SIP信令流，MESSAGE在它的主体中携带所谓的名片的多媒体内容或HTTP地址链接以检索所述的多媒体内容的部件。媒体存储器根据各自用户的简档，存储名片的所述的多媒体内容和/或所述的HTTP地址链接。web接口允许终端用户通过有地址的HTTP链接下载名片的多媒体部件。手机包括客户机应用，用于监视主叫者的线路状态并且在呼叫步骤的正好开始瞬间传送SIP MESSAGE。客户机进一步监视被叫者的线路状态和到来的SIP栈，用于同步CLI信息以及获得或检索名片的多媒体内容。用户电话内部的显示器呈现和播放名片(图2)。

Description

通过用于改善现有呼叫线路标识服务的基于IMS的PLMN传递预定制名片多媒体内容的方法和结构

技术领域

本发明涉及例如UMTS和GSM-GPRS的2.5代以上的PLMN中追加业务的领域，并且更精确地涉及一种通过用于改善现有呼叫线路标识服务的基于IMS的PLMN传递预定制名片多媒体内容的方法和结构。下文中，术语“名片”(business card)还包括“访问卡”或任意等同的表达。在说明书的最后给出有益的缩写词和文献的参考。

背景技术

现今，为了有利于享受由通过IP的传统电信协议提供的许多吸引人的东西以及同时经历其呼叫可能经过的不同类型网络上的“无缝”通信的无线客户，IP和PLMN网络间的大型集成在进行中。这促进了通信场景和诸如语音呼叫期间实时多媒体流交换的服务组合的大量多样化。IP-PLMN集成的核心是称为IMS的3GPP平台，IMS已经适当地被引入来为运营商、服务提供者、及客户提供计划要提供IP的那种服务能力。IMS平台的主要焦点是为用户/客户机提供加入多媒体会话的能力，在多媒体会话中他们被允许发送和接收语音及数据通信，甚至在漫游时。为了建立会话和在移动网络上提供的服务，IMS将采用新兴的IP version 6(IPV6)和SIP协议。SIP是用于建立、修改和结束与两个或更多个参与者之间的会话的应用层控制(信令)协议。这些会话包括因特网多媒体会议、因特网电话会议、呈现服务和多媒体分布等。通过代理和重定向请求到用户的当前位置，SIP支持用户移动性。对于更多细节参见最后的[RFC3261]。为了同一目的，[TS_22.228]确定来自用户观点的必要请求。可以在[TS_23.002]中发现IMS子系统的参考结构。可以在[TS_23.228]中发现有关实体的更详尽说明。

SIP是基于类似HTTP的请求/响应事务模型；每一SIP事务由在服务器上请求特殊方法或功能的请求和至少一个响应构成。标题是传送关于消息的信息的SIP消息的一部分，它被结构化作标题字段序列。标题字段被命名为提供关于消息的附加信息的属性。诸如媒体类型、编解码或采样率的会话细节没有采用SIP来描述。而是SIP消息的主体包括编码为某种其它协议格式的会话说明。一个这种格式是会话描述协议(SDP)[RFC2327]。与由电子邮件消息携带的文件附件或在HTTP消息中携带的网页相似的方式，SDP主体由SIP消息携带：对于HTTP参考[RFC2616]。命名为“MESSAGE”的SIP请求消息由规范[RFC3428]引入，以在请求主体中携带建立特定服务所需要的信息。MESSAGE是由每一SIP平台和SIP应用环境支持的非常灵活的SIP请求消息。实际上，它是可以在会话内或会话外使用的通用的异步SIP消息。还可能根据服务请求来限定它的结构。SIP MESSAGE请求的标题字段“主题”提供摘要或指示SIP MESSAGE消息的属性，无需解析会话描述就可以允许呼叫过滤。

在追加服务的范围内，[TS_24.081]文件是相关的现有技术，它针对下述条目指定了在无线接口上采用的程序：线路标识追加服务的普通操作、注册、擦除、激活、停用、调用和询问。特别相关的是假设呼叫线路身份(CLI)为条目1(CLIP)和2(CLIR)。CLI由呼叫方BCD号码以及可选地呼叫方子地址和/或没有CLI的原因构成。呼叫方BCD号码信息元素的目的是标识呼叫源；它是类型4信息元素。在网络到移动站方向中，它有3个八比特组(octet)的最小长度和14个八比特组的最大长度。此信息元素在移动站到网络方向不被使用。呼叫方子地址是类型4信息元素，具有2个八比特组的最小长度和23个八比特组的最大长度，它的目的是确定与呼叫源相关的子地址(IMEI)。当呼叫线路标识限制可应用时，源网络为目的网络提供带有可能的附加地址信息的呼叫方ISDN号码不允许呈现给被呼叫方的通知。

概述技术问题

呼叫线路身份(CLI)是实际执行来使终端用户能够查看谁正在呼叫他的移动设备的服务，是多数的移动(以及固定的)用户认为理所当然的特性。现有CLI实际是很差类型的服务，可能获得的所有信息仅仅由限制到仅有下行链接的少量字节携带。这与IMS平台提供的服务的巨大机会和用户的期待成了尖锐的对照。

发明内容

考虑到描述的技术的状况，本发明的目的是提供强化的CLI追加服务。发明概要和优点

通过提供如权利要求1中公开的用于执行呼叫线路标识服务的方法，发明获得所述的目的。另外的有利特性在从属方法权利要求中描述。

本发明的方法包括步骤：

a)在呼叫建立的正好开始的瞬间，由主叫者给IMS的CLI专用应用发送已知为MESSAGE的SIP请求，该请求在主体中包括主叫者和被叫者的SIP URI；

b)由所述的CLI专用应用，在所述的SIP MESSAGE主体中包括匹配两个SIPURI的预定制个人卡的多媒体内容，该个人卡在下面被称为名片，或一些用于检索之前存储的多媒体内容部件的地址链接；

c)CLI专用应用传送所述的SIP MESSAGE到被叫者；

d)在被叫者的电话上接收所述的SIP MESSAGE，以及从SIP MESSAGE主体直接获得所述的多媒体内容，或为了呈现和播放名片采用所述的地址链接来检索所述的部件。

本发明进一步的目标是根据相关权利要求使所述的方法实施的CLI专用网络结构。

根据本发明，多媒体CLI应用强化了“呼叫线路标识”概念，使用户在音频呼叫建立期间能够发送自己的预定制名片给其它IMS(IP多媒体子系统)用户。

通过将诸如图片、文本信息、声音文件及小视频剪辑的多媒体内容与电话呼叫建立关联，此服务实现了标准CLI服务。因此用户在电话呼叫的响铃时间期间享受多媒体体验。此外，用户然后可以浏览安装在电话中的多媒体工具夹应用中他们的联系人的全部名片文件夹。

对于UMTS和EDGE/DTM网络，多媒体CLI服务是基于IMS的服务。

使终端用户能够查看谁正在呼叫他的移动设备的呼叫线路身份(CLI)服务，是多数的移动(以及固定的)用户认为理所当然的特性。通过使用户能够创建多种个人化的“名片”，IMS加强了此非常基本(但非常需要)的服务，当用户被呼叫时，名片将被显示在其它用户的移动设备上。这些名片包括大批包括图片、文本、音乐、语音、链接和/或动画的可定制部件。

另外，用户可以创建多种不同的名片，然后定义过滤标准来确定哪一个应该被显示。过滤标准(定义用户的简档)包括呼叫/被呼叫方白名单以及由用户允许的媒体部件名单。

多媒体CLI服务的目标客户是业务用户和大量市场用户。这将吸引业务用户，因为它是附加的市场工具并且通过虚拟名片(被存储在被呼叫方的电话上)的使用允许业务用户增强自己的联网文件夹。诸如十多岁的大量市场用户将欣赏服务的个人化属性，给他们更多的机会来表达自己的个性。

考虑收入策略，多媒体CLI应用潜在地能够是免费服务(来增加客户忠诚并且减少变动)或者跟随净费用定价模型。可选地，基于购买预定制名片或增加允许的名片数目的需要，可以创建业务模型。IMS提供基本的架构来使得包含关键服务过滤和触发能力(确定哪个呼叫名片应当被显示)以及会话建立能力的多媒体CLI服务。

该应用将对已经配置IMS平台的操作者要求最小的CAPEXA，其中多媒体CLI应用(运行在具有SIP能力的应用服务器上)以及必要的客户机SW插入(可在客户机上下载)作为配置业务所需要的唯一增加投资。

订购MM-CLI服务的用户创建一套带有他们个人细节、联系人地址、图片、可选的还带有音频文件或视频的名片。

用户将名片关联到他们个人的联系人(伙伴、伙伴名单、群)。

用户在他们的简档设置中指定他们不想接收的媒体内容(例如，没有音频文件)。

当用户打电话给另一个用户时，当电话响铃的时候由主叫者(或缺省的一个)选择的名片在被叫者电话中作前景显示。

被叫方可以保存名片并且一旦呼叫结束就再一次显示该名片。

被叫方可以返回它自己的名片给呼叫者。

根据本发明的适合网络电话(voice over IP)会议，PoC等的一个可选实施方式，用于控制MM-CLI服务的消息可以替换地包含在SIP INVITE的主体中。

附图说明

被考虑为新的本发明的的特性随着附加权利要求中特性来提出。参考下面结合完全非限制说明目的给出的附图实施方式的详细说明，发明和它的优点将被理解，并且其中：

—图1显示了根据本发明为了执行单一服务域中的多媒体呼叫线路标识(MM-CLI)服务的基于UMTS/GSM-GPRS服务器的场景；

—图2显示图1场景的非常概括的网络结构；

—图3概括图1用于激活域(enabled domains)间互联MM-CLI服务的场景；

—图4概括图1用于从激活的到未激活的服务域互联MM-CLI服务的场景；

—图5显示用户终端的MM-CLI的功能结构；

—图6显示图5的用户终端内MM-CLI呼叫客户机模块的流程图；

—图7显示图5的用户终端内MM-CLI被呼叫客户机模块的流程图；

—图8到11显示对于同一服务域内提供的MM-CLI服务的相同数目的使用情形的不同消息序列图表；

—图12和13分别显示用于根据图3和图4的结构互联MM-CLI服务的两个消息序列图表；

—图14显示可由网站入口检索的一些样本页MM-CLI。

具体实施方式

图1显示包括具有两个移动终端MT A和MT B的移动无线系统(UMTS或GSM-GPRS)的简化通信场景，两个移动终端MT A和MT B(multiRAB或DTM都可以)通过核心网络(core network)以及MT A和MT B属于的共用IMS域彼此连接。非限制的，除了称为MM-CLI的块外，图1中描述的结构大部分可以从3GPP技术规范(TS)中获得，还考虑整理过的IETF RFC。移动无线系统在连接到无线接入网络(RAN)—UTRAN或GERAN的核心网络(CN)中被细分。核心网络包括CS域、基于GPRS的PS域、以及连接到PS域的IMS。无线接入网络包括多个服务小区，每个服务小区对应于由各自基站(BS)产生的覆盖区域。RAN的全部BS被连接到能够并行处理CS呼叫和分组数据传输的共用控制器RNC/BSC。在核心网络内，CS域包括MSC和网关元素GMSC；MSC被连接到控制器和GMSC。PS域包括SGSN节点和网关GGSN节点；SGSN节点被连接到控制器和GGSN节点。IMS域包括下列元素：CSCF、HSS、和MM-CLI服务器。CSCF块被连接到IMS内的HSS和MM-CLI，并且被连接到GGSN外部节点。

根据附图的印象，存在四条曲线。实线与语音呼叫的CS路径相关，它离开移动终端MT B并且通过CS域到达MT A。点划线与两个终端MT A和MT B间的SIP信令路径相关，它穿过PS域和IMS内部的MM-CLI服务器。第一虚线与名片的管理消息相关，它离开MT B并且通过PS和IMS域到达MM-CLI服务器。第二虚线与名片的管理消息相关，它离开MM-CLI服务器并且通过IMS和PS域到达MTA终端。在下文中，缩写MT，UE，MS被认为意思相同。

IMS涉及采用由PS域提供的业务来提供多媒体服务的一套CN实体。CSCF元素能够按照下列三种方式动作：呈现-CSCF(P-CSCF)，询问-CSCF(I-CSCF)，服务-CSCF(S-CSCF)。当IMS被从与IMS相同的管理区域内部联系时，P-CSCF是终端用户设备联系的第一点。P-CSCF：传送SIP消息；转换ID而非SIPURI为SIP URI；维持它自身与每一UE间的安全连接。当IMS被另一个管理域的IMS联系时，I-CSCF是第一联系点。I-CSCF：传送SIP消息；从HSS获取S-CSCF的地址；隐蔽内部网络配置、容量和拓扑。服务S-CSCF执行会话控制和服务触发。S-CSCF：担任注册员(接收注册请求的服务器)；传送SIP消息；与诸如MM-CLI的应用服务器(AS)交互；根据HSS/UMTS数据验证。HSS是包含IMS与订户相关信息的数据库。此数据库包括关于：标识；授权的服务；订购的服务的数据。图1的IMS平台提供下列能力：

—接入控制：IMS必须能够在任意时刻验证用户是否被允许使用IMS的资源。

—能力协商：IP多媒体应用必须具有识别并且选择可用媒体部件和会话的QoS的可能性。IM子系统必须允许这样的协商从任意一方(用户、运营商、或代表他们的应用自身)并且在任意时刻(在会话请求时、接受期间或会话期间)开始。

—多媒体会话的重定向：IM子系统必须可以识别针对IP多媒体会话或单个会话的单个媒体的替换目的。与能力协商相似，IM子系统必须允许这样的重定向从任意一方(接收方、发送方或代表它们的网络实体)，在任意时刻(会话建立之前、初始请求期间、建立期间或正在进行的会话期间)开始。

—请求IP多媒体会话：用户必须能够请求一个或多个IP多媒体会话并且激活每一多媒体会话内的并发应用。为此目的，依靠主叫方能力，通过电话和因特网拨号的使用可以识别实体。

—处理到来的会话：终端实体必须能够识别会话的源，以协商与用户简档交互的能力并且来决定是接收或拒绝该会话。特别地，它必须能够仅仅接受所提供的媒体的子集。

—正在进行的会话的处理：如前所述，用户在会话期间必须能够决定IP多媒体应用的媒体部件的增加或删除。而且，用户必须能够在稍后的时间延缓和重新开始一个多媒体会话。

—结束会话：用户必须能够在任意时刻结束正在进行的会话。

—本地服务：当漫游到归属环境外时，用户必须能够访问被访问网络提供的本地属性的服务。

参考图2，我们看到MM-CLI服务器1中下列三个彼此互联的功能块：MM-CLI控制服务器2、MM-CLI媒体存储器3和MM-CLI web接口4。MM-CLI控制服务器2通过ISC接口被连接到S-CSCF。MM-CLI web接口4通过HTTP链接被连接到PS域。MM-CLI服务器1通过SQL链接被进一步地连接到CSDM块并且通过Ro接口被进一步地连接到OCF块。在操作中：

·MM-CLI控制服务器2处理SIP信令流。它还关心策略规则(客户简档)，消息过滤和内容插入将由此实例提供。执行将采用普遍存在的SIP应用服务器作为底层的服务。由于在此服务中没有执行面向会话的媒体数据交换，SIP会话的使用被避免。相反，SIP元素“MESSAGE”被采用来传送MM-CLI控制消息和MM-CLI多媒体内容。因此，消息模式可以被描述作基于“页模式”。稍后将给出MM-CLI SIP MESSAGE的语义和语法。

·MM-CLI媒体存储器3服务器存储名片的所有多媒体内容，例如，图片、视频或音频文件。

·MM-CLI web接口4有两个主要目的：a)允许终端用户控制存储的名片并且执行策略控制；b)名片的多媒体部件的下载。免费的Apache服务器可以被用作主网站入口。

·网站入口服务器(未示出)驻留用于接入服务功能(名片创建/删除/修改，名片分配、用户简档管理等)的网页，以及由用户为创建他们自己的名片(甚至http链接)上传的内容。网站入口从具有选项菜单的特定项目的客户应用来接入。在用户已经一次插入他的证书，采用cookie机制授权他对入口进行后来的访问。如果名片被允许包括大量视频内容，Web服务器将驻留该内容并且经由特定文件夹的NFS安装使他们对于流平台可用。如图14所示，一些样品页可由网站入口检索到。

图1的场景和图2的等同结构中BC服务的传送将参考图8到11连续引入的相关消息序列图表来详述。

图3和4是当用户属于不同IMS域(并且也属于不同网络)时图1的一般化。域互相作用是MM-CLI服务的重要点。对于域互相作用，可以显示两个不同的场景：

1.域A和B是启动了MM-CLI服务的(此选项被优选)。

2.域A是启动了MM-CLI服务的，而域B不是(或反之)。

第一互相作用场景在图3中可见，其中整个网络包括作为域A和域B示出的两个互联的网络，由MT A接入的第一个和由MT B接入的第二个。每一域包括图1中指定的全部元素。两个手机MT A和MT B可以通过两个CS核在语音路径上执行语音呼叫，以及在两个MM-CLI服务器间的相关信令链路上交换SIP消息。当域都具有MM-CLI能力时，互相作用通过IMS互相作用概念被很好的定义。来自域A中MTA的每一SIP消息将通过若干代理被路由到域B中的UE。在具有两个MM-CLI服务器的这样的场景中需要特定策略控制。UE A是域A中的BC的源，UE B是域B中BC的源。当UE A发送BC时，依靠域A中MM-CLI服务器中的策略，BC将被发送到域B中的MM-CLI。域B中的MM-CLI服务器也将正在采用策略控制并且能够拒绝该BC。对于此类型的互相作用信令流在图12中示出。

图4的第二互相作用场景不同于图3的场景的地方仅仅在于域B内缺少MM-CLI服务器。在这种情况下，域A内的MM-CLI服务器直接与域B的IMS核交换SIP消息。对于此类型互相作用的信令流在图13中示出。很清楚，由于缺少MM-CLI应用服务器，域B中的接收MT B不能应用策略规则。对于这种情况，域A中的MM-CLI服务器将发送缺省的名片。

MM-CLI终端MT A和MT B的结构在图5中示出。该结构由多个部件组成，该多个部件由LEGENDA中包括的多种类型的线来表示。OS部件提供诸如IP栈，TCP/IP栈，多媒体构架或链接管理器的服务。

MM-CLI服务器逻辑的操作对于呼叫客户机模块在图6中呈现，对于被呼叫者在图7中呈现。如图6中所示，呼叫客户机负责监视线路状态：当用户呼叫号码时，它创建MM-CLI MESSAGE并且将它发送给服务器。在另一方面，如果有到来的呼叫，被呼叫客户机匹配到来的CLI和从服务器到达的可能(eventual)MM-CLI MESSAGE。在匹配时，采用MM-CLI SIP MESSAGE中包含的信息，从缓存检索(如果之前存储在手机上)或从入口下载名片。MM-CLISIP MESSAGE主体包含下列参数：

服务器(所有者)：驻留MM-CLI内容的服务器的域名/IP地址。

邀请者：呼叫者的SIP/电话URI。此参数由被呼叫客户机使用来匹配从CS核接收的CLI信息。

端口：TCP端口号码，在此服务器监听到来的HTTP请求。

SkinID：当名片被创建时由服务器产生的唯一标识符。它由客户机用于识别缓存的名片并且来确定名片内容是否必须被升级。

协议：缺省值为HTTP。此参数指示客户机必须采用来提取名片内容的协议。

图像：相对路径，在此路径下，附属到名片的JPEG图像可能被在服务器中发现。

文本：相对路径，在此路径下，附属到名片的TXT文件可能被在服务器中发现。

ftext：名片创建期间由入口中的用户直接编辑的字符串。它在名片中显示。

视频：具有相对路径的字符串(语法路径SP说明)，在此路径下附属到名片的3gp视频剪辑可以在流服务器(由rlink标识)和文件的说明中发现。

rlink：指示驻留视频中指定内容的流服务器的RTSP URL(rtsp://server.domain/path)。rlink/path(路径)是可由手机直接运行的RTSP URL。

音频：具有相对路径的字符串(语法路径SP说明)，在此路径下附属到名片的音频文件可以在服务器和文件的说明中发现。

flink：具有网站(个人主页，喜欢的书签，博客)的HTTP URL和它的说明的字符串(语法URL SP说明)。

模板：指定预配置名片模板的标识符。样本模板是“图片在右上角，文本在左中”以及“图片作为背景和文本在中央”。

颜色：颜色标签由六个十六进制值构成(000000＝黑，FF0000＝红，FFFFFF＝白)。

定义描述MM-CLI名片部件的XML主体格式被认为是强制的。

指定的结构为用户终端提供下列能力：多任务；在呼叫中，应用切换；为名片提供引擎；MM-CLI扩展地址薄；存储能力；文件系统；IMS会话管理器(在具有IMS会话管理器的设备中SIP栈和高级的API应当是可用的)；同时的CS/PS转换(DTM)，(根据3GPP TS 43.055，终端应当为级别A或应当支持DTM)。

传送的MM-CLI名片不得不被显示。需要的说明通常被命名为“情景说明”。许多格式是可以想到的。作为非常基本的格式，基于MIME类型的格式可能被采用。对于基本的MM-CLI目的，带有文本消息和图片以及铃音的多方消息将被提出。图片也可以被链接到MM-CLI媒体存储服务器。图4左上角的MT A显示对于这样一个方法的实例设计。带有预定义最大长度的文本将总是显示为带有预定义的字体，并且图像将被按比例显示以适合显示器尺寸。下面具有文本和图片的多方消息的实例被给出：

Content-Type:multipart/mixed；

boundary＝＂------------020605080305050205010003＂

This is a multi-part message in MIME format.

--------------020605080305050205010003

Content-Type:text/plain；charset＝ISO-8859-1；format＝flowed

Content-Transfer-Encoding:7bit

This is a test！

--------------020605080305050205010003

Content-Type:image/jpeg；

name＝＂Example＂

Content-Transfer-Encoding:base64

Content-Disposition；inline；

filename＝＂image.jpg＂

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDEkSEw

HUHRof

BttyGXSkJHMEtVTzVPEfqtvb3cIt/wDbnngvxW3ufcRhB1.7ddVaNI5emzf8AaOHKqT

rcmIPb

y/O6xmziPLKiakVSzzUpHCDyBYML+7G8+XM8CzULVBHEQIUWmhAQAkJtcnvOJLSHil

SIxVVQ

rkcUryiNEF978PD3crduFfVOSlecSHDltI1MCatpXeNbAJwkLewF29rs7ueCPR/oGP

Ia2OoH

HJKTdSWFvIDsGLaxmOEtJDMbugJ78Ba/TENQxeMAE4Dy6brISDFLKvCbjhY7HESTJc

wYvXOz

F7cZ2QeK3K/fbGOeQV8iLGOjiMHiCjYA3vew8d8EabSbMwaYknvY4PUuSU1OgUre2C

KRpGLI

oA8MbYzGYzGHljg/PG8fLHTGYzGY/9k＝

--------------020605080305050205010003-

目标服务在为MM-CLI名片的外观(颜色、字体、模板、图像的位置等)提供个人化特征方面应当尽可能的灵活。为了这种特定的目的，我们将定义基于XML的说明来增加多部件/混合的主体。内容-类型应当为应用/mmcli+xml。提出的文件类型定义(DTD)为：

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

<!ELEMENT BC(owner，components，template)>

<!ELEMENT owner{#PCDATA}>

<!ELEMENT components(media＊)>

<!ELEMENT media{#PCDATA}>

<!ATTLIST media type(image|text|sound|video|web)＂text＂>

<!ELEMENT template(bg，fg，font)>

<!ATTLIST template template-id CDATA#REQUI RED>

<!ELEMENT bg(#PCDATA)>

<!ELEMENT tg(#PCDATA)>

<!ELEMENT font(#PCDATA)>

这里接着是一个包含名片的XML说明的多部件/混合主体的实例：

Contenc-Type:multipart/mixed；

boundary＝＂------------020605080305050205010003＂

This is a multi-part message in MIME format

--------------020605080305050205010003

Content-Type:application/mmcli+xml；charset＝UTF-8

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

<！DOCTYPE BC SYSTEM＂bc.dtd＂>

<BC>

<owner>sip:user@mydomain.com</owner>

<media type＝＂image＂>myself.jpg</media>

<media

type＝＂sound＂>http://web.mydomain.com/mypath/myringtone.mid</media>

<media

type＝＂video＂>rtep://vs.mydomain.com/mypath/myvideo.3gp</media>

</components>

<font>arial</font>

</template>

</BC>

--------------020605080305050205010003

Content-Type:text/plain；charset＝ISO-8859-1；format＝flowed

Content-Transfer-Encoding:7bit

Hi this is me！

--------------020605080305050205010003

Content-Type:image/jpeg；

name＝＂Example＂

Content-Transfer-Encoding:base64

Content-Disposition:inline；

filename＝＂myself.jpg＂

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcG8QgHBwcJCQgKDBQNDAsLDBkSEw

8UHRof

8ttyGXSkJHMEtVTzVPEfqtvb3cIt/wDbnngvxW3ufcRhB17ddVaNISemzf8AaOHKgT

rcmIPb

y/O6xmziPLKiakVSzzUpHCDyBYML+7GS+XM8CzUlVBHEQIUWmhAQAkJtcnvOJlSHil

SIxVVQ

rkcUryiNEF978FD3crduFfVOSlecSHDltI1MCatpXeNbAJwkLewF29ra7ueCPR/oGP

Ia2OoH

HJKTdSWFvIDsGLaxmOEtJDMbugJ78Ba/TENQxeMAE4Dy6brISDFLKvCbjhY7HESTJc

wYvxOz

F7cZZQeK3K/fbG0eQV8iLG0jiMHiCjYA3vew8d8EabSbMwaYknvY4PUuSUlOgUre2C

KRpGLI

oA8MbYzGYzGHljg/PG8fLHTGYzGY/9k＝

--------------020605080305050205010003-

其它可用的协议：

众所周知的HTML或WAP格式被用于显示静态内容，通常是格式化的文本和图像的混合。MM-CLI消息可以采用这种格式来显示名片。如果全部内容被包括到MM-CLI消息中，则多部件MIME类型消息必须被使用。它还可以包括至MM-CLI媒体存储服务器的链接。

SMIL格式被MMS使用并且将由大范围的终端支持。SMIL支持诸如格式化文本、图像(Gif和Jpeg)或3GPP视频(H.263、MPEG4)的许多媒体类型。在SMIL中还定义了定时模型(timing model)。

BIFS由ISO/IEC和MPEG-4系统组的一部分来定义。它允许带有多媒体内容和附加2D和3D对象说明的场景说明。还有定时模型被定义。BIFS由DMB广播系统来使用并且将被具有DMB能力的手机支持。DMB是一种即将到来的标准并且在韩国可用，并且从2006年起在欧洲能够可用。

系统说明现在通过示出针对一套用于MM-CLI服务的重要使用情况的相关流程图和包含呼叫流程的技术实现来完善。MM-CLI客户机经由GGSN连接到PS网络。信令路径由IMS(CSCF)控制。MM-CLI应用服务器包括MM-CLI服务逻辑和网站入口。为了联系人名单和群管理或策略目的，服务器的服务逻辑部分被连接到CSDM。网站入口被用于管理来自UE或因特网的MM-CLI名片。它还允许经由来自UE的专门链接下载多媒体内容。在多数情况下，主叫UEA仅发送存储在MM-CLI应用服务器上的优选的名片的参考。这通过在SIPMESSAGE中定义下面的内容来完成：

空白主体：将使用对UE B依靠策略控制的缺省MM-CLI名片。

参考：UE A发送至存储的名片的参考。

内容：UE A发送带有被包含的所有多媒体内容的名片消息。在那种情况下，可能在MM-CLI应用服务器上存储名片。它还是在不具有MM-CLI能力的域中的方式。

IMS CSCF将来自UE A的消息中继到MM-CLI应用服务器。服务器将发送根据策略的名片到UE B。多媒体内容将被包含在SIP消息中。参考图8的信令流程，名片被独立于早先同一名片的接收地发送给UE。

对于图9中只发送至多媒体内容的参考到UE B，有很多原因。在这种情况下，仅仅至MM-CLI应用服务器上存储的多媒体内容的链接经由SIP MEAAGE被发送到UE B。一些原因如下：

·缓存：一次接收的BC能够被避免多次传送。这也将加速在UE B的终端上显示BC。

·消息将是短的。具有包含的所有内容的大消息必须经过许多代理(例如，S-CSCF，P-CSCF，...)。这将延迟该服务。

参考图9的信号流：

1.通过拨号码或从被呼叫号码的联系薄/记录中检索该号码，用户UE A开始呼叫。1’.CS核立即发送CLI信息到被叫方(在蜂窝网络中此服务缺省)。

2.应用创建包含数据特定信息的SIP MESSAGE并且将它发送给MM-CLI服务器。

3.CSCF路由该消息到专用的应用服务器。

4.MM-CLI服务器匹配主叫方和被叫用户的SIP URI，并且找到适合的名片(特定的名片或缺省的名片)。然后被叫用户的简档被与名片的部件相匹配来移除不需要的媒体。

5.如果主叫方还没有被列入黑名单，则服务器为被叫方创建包含所有信息的消息，以从服务器自己或从缓存中检索名片部件。

6.CSCF路由MESSAGE到被叫方。

7.SIP栈采用SIP 200 OK确认该服务器。

8.CSCF路由该200到AS(它担当B2BUA的角色)。

9.AS为主叫用户返回200。

10.CSCF在上行方向路由它。

11.客户机应用匹配主叫号码(CLI)和MESSAGE中包含的数据。

12.如果名片之前被下载的话，则检查缓存以最终检索该名片。

13.如果名片近期已经被改变或从缓存移除，则客户机在HTTP链接上从MM-CLI服务器下载名片的部件并且呈现它们。

14.MM-CLI服务器采用HTTP 200 OK确认MM-CLI服务器。

15.手机正在响铃并且名片被显示到UE B不应答。

当采用到MM-CLI应用服务器的链接以获取多媒体内容时，安全概念必须被建立。为此，当带有图9选项的域互相作用被请求时，应当特别的小心。

参考图10的信令流程，考虑拒绝名片机会。如果UE B已经将UE A列入黑名单，则来自UE A的名片将被重定向，而不通知UE A或UE B。

参考图11的信令流程，考虑了返回名片给主叫者的机会。还可能主叫方接收他自己的BC或来自UE B的BC。图中描述的信令流程提供了用于返回名片给主叫者的最简单的解决方案。在对UE-A发送的第一SIP MESSAGE的响应SIP 200 OK中返回名片的可能性也在估计中。

图12的信令流与图3的两个具有MM-CLI能力的域A和B间的互相作用相关；而图13的信令流涉及图4的激活的域A和未激活的域B间的互相作用。

随着MM-CLI服务传递，错误是可能的，例如：

·B方没有IMS账户，并且因此未注册(→404未发现)。

·B方有IMS账户，但未在IMS注册(→404未发现)。

·B方在IMS注册，但没有运行的MM-CLI客户机(→超时)。

·B方在IMS注册并且没有运行的MM-CLI客户机，但是缺省的客户机SIP应用正在运行并且正在应答消息(→取决于缺省的运行客户机)。

收费

为了收费，不同的模型可以应用，每一模型引起对结构的不同技术需求：

1.承载(Bearer)收费：通过PS域交换的数据量被测量并且用作收费基础。没有特别的服务收费。这种类型的收费由PS-基础结构完成。

2.基于会话的收费：IMS会话的持续时间被测量并且用作收费基础。这种类型的收费可以由IMS核来完成。

3.基于数量和内容的收费：经由特定IMS会话发送的数据的数量被测量并且可能数据的类型/质量也被测量。这允许非常不同的收费模型。这些测量仅由数据流经过的服务器来执行。在此描述的结构是聚焦在此收费方法上。

MM-CLI服务中的收费应当由MM-CLI服务器提供。对此有很多原因：

·当采用收费模型1时，被叫者不得不为每一接收的MM-CLI名片付费。他不得不为将从MM-CLI应用服务器传递的多媒体内容付费。如果MM-CLI名片被存储在MM-CLI应用服务器上，则主叫者仅仅需要为主叫者和MM-CLI应用服务器间少量的信令数据付费。仅在MM-CLI卡被存储在UE上的情况下，主叫者也不得不为多媒体内容付费。

·收费模型2也不能被采用，因为将没有UE A和UE B间的会话。仅仅SIP“MESSAGE”将被交换。

·对于MM-CLI服务的收费模型应当与SS7SMS服务相似，仅仅MM-CLI卡的主叫者应当支付。MM-CLI应用服务器可以为这样一种方法提供收费模型。

如果两个UE处于不同的域并且在两个域都提供MM-CLI服务，则“主叫方支付”收费模型可以被实现。在仅有一个域提供MM-CLI服务的情况下，可以产生两个差别：

·主叫者处于MM-CLI服务的域而被叫者未处于：被叫者不得不为他接收的多媒体数据量付费。根据主叫者域中的收费模型，主叫者也不得不为该服务付费。

·主叫者未处于MM-CLI服务的域而被叫者处于：在这种情况下，MM-CLI卡被存储在主叫者UE上。根据被叫者的收费模型，仅仅主叫者需要为MM-CLI服务付费。

基于上面的描述，本领域技术人员不脱离本发明的范围可以在补充实施方式中引入一些改变。因此预期本发明包含后面权利要求覆盖的任意和全部这种实施方式。

有用的缩写词

3GPP-第三代合作伙伴项目

AMR-自适应多速率

API-应用程序接口

AS-应用服务器

BC-名片

CDR-费用数据记录

CLI-呼叫线路标识

CLIP-CLI呈现

CLIR-CLI限制

CNAME-规范终端标识SDES项

CR-呼叫识别器

CS-电路交换

CSI-(CS和IMS联合服务)

CSCF-呼叫状态控制功能

CSDM-共用服务数据管理器

DNS-域名服务器

DTM-双传输模式

EDGE-GSM演进的增强型数据速率

EGPRS-增强型GPRS

GERAN-GSM/EDGE无线接入网

GGSN-网关GPRS支持节点

GMSC-网关MSC

GLMS-群组名单管理服务

GPRS-通用分组无线服务

HSS-归属用户服务

HTTP-超文本传输协议

IEC-国际电工委员会

ISO-标准组织

IETF-因特网工程任务组

IM-IP多媒体

IMEI-国际移动设备标识

IM-MGW-IP多媒体媒体网关功能

IMS-IP多媒体核心网子系统

ISDN-综合业务数字网

JPPEG-联合图形专家组

MCDF-媒体控制和复制功能

MGCF-媒体网关控制功能

MGW-媒体网关功能

MIME-多用途互联网邮件扩展

MMS-多媒体消息收发服务

MNO-移动网络运营商

MPEG-移动图像专家组

MPM-移动状态管理器

MRF-多媒体资源功能

MS-移动台

MSISDN-移动用户ISDN号码

MT-移动终端

NFS-网络文件系统

PCF-策略控制功能

PLMN-公共陆地移动网

PS-分组交换

QoS-服务质量

RAB-无线接入承载

RFC-请求评议

RNC-无线网络控制器

RTCP-实时传输控制协议

RTP-实时传输协议

SDP-会话描述协议

SGSN-服务GPRS支持节点

SIP-会话初始协议

SMIL-同步多媒体集成语言

SSRC-同步源

TCP-传输控制协议

TS-技术规范

UDP-用户数据报协议

UE-用户设备

UMTS-通用移动通信系统

URI-通用资源标识符

URL-通用资源定位符

UTRAN-UMTS地面无线接入网

XML-可扩展标记语言

WAP-无线应用协议

参考文献

[TS_22.101] 3GPP TS 22.101 V 6.7.0，″Service Principles″，Release 6.

(March 2004).

[TS_23.002] 3GPP TS 23.002 V 6.1.0，″Network Architecture″，Release 5，

(June 2003).

[TS_22.228] 3GPP TS 22.228 V 6.5.0，″Service requirements for the

Internet Protocol(IP)multimedia corenetwork subsystem″；

Stage 1，Release 6，(January 2004).

[TS_24.081] 3GPP TS 24.081 V 6.0.0-″Line Identification Supplementary

Services″-Stage 3，(2004-12).

[TS_23.228] 3GPP TS 23.228 V 6.5.0，″IP Multimedia Subsystem(IMS)″，

Release 6，(March 2004).

[RFC3261] IETF RFC 3261″Sip Initiator Protocol″，June 2002

[RFC3428] IETF RFC 3428″Session Initiation Protocol(SIP)Extension

for Inslant Messaging″，H.Schuizrinne，et al.，December 2002

[RFC2327] IETF RFC 2327″SDP：Session Description Protocol″，April

1998

[RFC2616] IETF RFC 2616″HTTP/1.1：Hypertext Transfer Protocol″，

June 1999.

[RFC2617] IETF RFC 2617，″HTTP Authentication：Basic and Digest

Access Authentication″.J.Franks，P.Hallam-Baker，J.

Hostetler，S.Lawrence，P.Leach，A.Luotonen，L.Stewart.

June 1999.(Status：DRAFT STANDARD).

[RFC3275] IETF RFC 3275″(Extensible Markup Language)XML-

Signature Syntax and Processing″，J.Reagle et al.，March

2002.

[RFC2046] IETF RFC 2046″Multipurpose Internet Mail Extensions

(MIME)Part Two：Media Types″，N.Freed et al.，November

1996.

[RFC2387] IETF RFC 2387″The MIME Multipart/Related Content-type″，

E，Levinson.August 1998.

[RFC2070] IETF RFC 2070″Intern″ationalization of the Hypertext Markup

Language(HTML)″，F.Yergeau et al.，January 1997、

[RFC0793] IETF RFC 0793 or STD 0007，″Transmission Control Protocol＂，J.

Postel，Sept，01 1981.

[RFC0768] IETF RFC 0768 or STD 0006，″User Datagram Protocol″，J.Postel，

Aug.28 1980

Claims

1、一种用于在下面被称为IMS的蜂窝电话网络内部执行下面被称为CLI的呼叫线路标识服务的方法，该蜂窝电话网络包括基于SIP的基础结构，并与核心网络集成来经由IP为用户提供多媒体服务，其中在电话呼叫的响铃期间，该网络向被叫者至少发送主叫者的线路身份，以在接通中继状态之前显示在电话的屏幕上，特征在于包括步骤：

b)由所述的CLI专用应用在所述的SIP MESSAGE主体中包括匹配两个SIP URI的预定制个人卡的多媒体内容，该个人卡在下面被称为名片，或一些用于检索以前存储的多媒体内容部件的地址链接；

c)CLI专用应用传送所述的SIP MESSAGE到被叫者；

2、权利要求1的方法，特征在于所述的SIP MESSAGE内容还包括名片的标识符。

3、权利要求1或2的方法，特征在于所述的多媒体内容包括文本信息、和/或图片、和/或声音文件、和/或小的视频剪辑。

3、权利要求1或2的方法，特征在于被叫者将获得的名片和相应的标识符一起存储在内部缓存中。

4、权利要求3的方法，特征在于，当到来的名片标识符匹配存储的名片标识符时，被叫者从缓存中检索出所述的名片。

5、权利要求1至4中任何一个的方法，特征在于，被叫者向所述的CLI专用应用发送主叫者的黑名单，这些主叫者的名片不能传送。

6、权利要求1至5中任何一个的方法，特征在于，所述的CLI专用应用向主叫者返回被叫者的名片。

7、权利要求1至6中任何一个的方法，特征在于，订购CLI服务的用户：

-创建多种名片，以将这些名片按照以下方式与这些用户的联系人关联：个人地址、伙伴名单、群、和各自的多媒体内容；

-依靠包括主叫/被叫方、白/黑名单、和这些用户不想接收的媒体内容的过滤标准，定义与所述的名片关联的不同用户的简档；

-向被叫者传送与该被叫者的用户简档匹配的名片。

8、权利要求1至7中任何一个的方法，特征在于，所述的CLI专用应用包括到驻留由用户上载的多媒体内容和http链接以创建他们自己的名片的网站入口的接口。

9、权利要求8的方法，特征在于，从带有选项菜单的特定项目的客户应用访问所述的网站入口服务器。

10、权利要求8或9的方法，特征在于，用户一旦插入他的证书后，采用cookie机制授权他对所述的网站入口进行任何后来的访问。

11、权利要求1至10中任何一个的方法，特征在于，所述的网站入口服务器设置流平台的特定网络文件系统文件夹，该流平台用于使大的视频内容对名片可用。

12、权利要求1至11中任何一个的方法，特征在于，多媒体内容的所述部件采用XML主体格式描述。

13、权利要求1至12中任何一个的方法，特征在于，被叫者在具有所述CLI专用应用的HTTP链接上获取所述的多媒体内容或检索相关的部件。

14、一种用于在下面被称为IMS的蜂窝电话网络内部执行下面被称为CLI的呼叫线路标识服务的网络体系，该蜂窝电话网络包括基于SIP的基础结构，并与核心网络集成来经由IP为用户提供多媒体服务，特征在于包括：

-多媒体CLI专用服务器(1)，下面称为MM-CLI，被连接到IMS和核心网络的分组交换域(PS)；

-MM-CLI(1)的控制装置(2)，用于处理包括称为MESSAGE的SIP元素的SIP信令流，该MESSAGE在它的主体中携带所谓的名片的多媒体内容或HTTP地址链接以检索所述的多媒体内容的部件；

-MM-CLI(1)的存储装置(3)，用于存储名片的所述的多媒体内容和/或所述的HTTP地址链接；

-MM-CLI(1)的web接口装置(4)，用于允许终端用户通过有地址的HTTP链接下载名片的多媒体部件；

-用户电话内部的第一客户机应用，用于监视主叫者的线路状态并且在呼叫步骤的正好开始瞬间传送所述的SIPMESSAGE；

-用户电话内部的第二客户机应用，用于监视被叫者的线路状态和到来的SIP栈，以同步CLI信息以及获得或检索名片的多媒体内容；

-用户电话内部的显示器，用于呈现和播放名片。