2024年6月11日发(作者：)
(19)中华人民共和国国家知识产权局
(12)发明专利说明书
(21)申请号 CN2.8
(22)申请日 2007.10.31
(71)申请人 爱立信电话股份有限公司
地址 瑞典斯德哥尔摩
(72)发明人 C·博伯格 A·林德格伦
(74)专利代理机构 中国专利代理(香港)有限公司
代理人 柯广华
(51)
H04L29/06
权利要求说明书 说明书 幅图
(10)申请公布号 CN 101843071 A
(43)申请公布日 2010.09.22
(54)发明名称
会话发起协议消息有效负荷压缩
(57)摘要
公开一种跨IP多媒体网络在用户终
端(1)和会话发起协议应用服务器(2)之间传
送会话发起协议消息的方法。该方法包括
在发送侧的应用层(4a，5a)内压缩消息有效
负荷并在接收侧的应用层(4b，5b)解压它
们。压缩的消息有效负载经由合适的应用
编程接口(7a)在应用层和会话发起协议用户
代理器(3a)之间传递。
法律状态
法律状态公告日
法律状态信息
法律状态
权 利 要 求 说 明 书
1.一种跨IP多媒体网络在用户终端和会话发起协议应用服务器之间传送会话发起
协议消息的方法，所述方法包括在发送侧的应用层内压缩消息有效负荷并在接收侧
上的应用层解压它们，压缩的消息有效负荷经由合适的应用编程接口在所述应用层
和会话发起协议用户代理器之间传递。
2.如权利要求1所述的方法，所述消息报头被无压缩地发送，使得所述消息能通过
任何中间CSCF和应用服务器来路由。
3.如权利要求1或2所述的方法，消息有效负荷的所述压缩和解压使用gzip来执行。
4.如前面权利要求的任一项所述的方法，并且包括：在从所述用户终端发送到会话
发起协议应用服务器的SIP SUBSCRIBE消息中包括有效负荷压缩将在所述应用服
务器执行的指示，并且随后压缩从所述应用服务器发送到所述用户终端的
SIP NOTIFY消息的有效负荷。
5.如权利要求4所述的方法，并且包括：在所述SUBSCRIBE消息的接受或接受编
码报头字段中包括所述指示。
6.如权利要求5所述的方法，并且包括：经由所述应用编程接口从所述应用层将所
述接受或接受编码报头字段写到所述会话发起协议用户代理器。
7.如权利要求4到6的任一项所述的方法，其中所述SUBSCRIBE和NOTIFY消息
涉及存在服务。
8.如权利要求1到3的任一项所述的方法，并且包括：在从所述用户终端发送到会
话发起协议应用服务器的SIP PUBLISH消息中包括所述消息有效负荷被压缩的指
示。
9.如权利要求8所述的方法，并且包括：在所述PUBLISH消息的“内容-类型”报头
字段中包括所述指示。
10.如权利要求9所述的方法，并且包括：经由所述应用编程接口从所述应用层将
所述内容-类型报头字段写到所述会话发起协议用户代理器。
11.如权利要求8到10的任一项所述的方法，其中所述PUBLISH消息涉及存在服
务。
12.如前面权利要求的任一项所述的方法，其中所述会话发起协议应用服务器是资
源列表服务器。
13.一种配置成在IP多媒体子系统服务网络内操作的用户终端，所述用户终端实现
与会话发起协议用户代理器通信的一个或多个应用层，所述一个或多个应用层经由
应用编程接口与所述会话发起协议通信，所述用户终端进一步配置成在所述一个或
多个应用层压缩和解压外出和进入的SIP消息的有效负荷，并且经由所述应用编程
接口与所述会话发起协议用户代理器交换所压缩的有效负荷。
14.一种配置成在IP多媒体子系统服务网络内操作的会话发起协议应用服务器，所
述应用服务器实现与会话发起协议用户代理器通信的一个或多个应用层，所述一个
或多个应用层经由应用编程接口与所述会话发起协议通信，所述应用服务器进一步
配置成在所述一个或多个应用层压缩和解压外出和进入的SIP消息的有效负荷，并
且经由所述应用编程接口与所述会话发起协议用户代理器交换所压缩的有效负荷。
说 明 书
技术领域
本发明涉及会话发起协议消息的有效负荷的压缩。
背景技术
IP多媒体服务提供相同会话内话音、视频、消息传递、数据等等的动态组合。通
过增加可能组合的媒体和基本应用的数量，将增加提供给最终订户的服务的数量，
并且将丰富人际通信体验。这将导致新一代的个性化、丰富的多媒体通信服务，包
括所谓的“组合IP多媒体”服务。
IP多媒体子系统(IMS)被第三代合作伙伴项目(3GPP)和ETSITISPAN组织定义为在
移动通信网络上提供IP多媒体服务的技术(3GPPTS 22.228，TS 23.228，TS 24.229，
TS 29.228，TS 29.229，TS 29.328和TS 29.329发行版5到7，和TS 24.173发行版
7)。IMS通过标准化IMS服务使能器(Enabler)的使用，提供关键特征来丰富最终订
户人到人的通信体验，标准化IMS服务使能器促进基于IP的网络上新的丰富的人
到人(客户端到客户端)通信服务以及人到内容(客户端到服务器)服务。IMS利用会
话发起协议(SIP)来建立和控制订户终端之间(或订户终端与应用服务器之间)的呼叫
或会话。会话描述协议(SDP)由SIP信令携带，用于描述和协商会话的媒体组件。
虽然SIP是作为订户到订户协议被创建的，但IMS允许运营商和服务提供者控制
订户对服务的访问和相应地对订户计费。
通过示例，图1示意示出在GPRS/PS接入网络的情况下，IMS是如何适应移动网
络架构的(IMS当然能在其他接入网络上操作)。呼叫/会话控制功能(CSCF)在IMS
内作为SIP代理来操作。3GPP架构定义了三种CSCF：代理CSCF(P-CSCF)，它是
用于SIP终端的IMS内的第一联系点；服务CSCF(S-CSCF)，它向订户提供其订阅
的服务；以及询问CSCF(I-CSCF)，它的作用是识别正确的S-CSCF并将经由P-
CSCF从SIP终端收到的请求转发到该S-CSCF。
在IMS服务网络内，提供应用服务器(AS)以用于实现IMS服务功能性。应用服务
器向IMS系统中的最终用户提供服务，它既可以通过SGPP定义的Mr接口作为端
点来连接，也可以通过3GPP定义的ISC接口由S-CSCF来“链入(link in)”。在后一
种情况下，S-CSCF使用初始过滤准则(IFC)来确定在SIP会话建立期间(或者实际为
了相关的任何SIP方法、会话或非会话的目的)，应该“链入”哪些应用服务器。在
IMS注册过程期间，IFC作为订户的订户简档的部分由S-CSCF从HSS接收。
通过AS的使用而促进的示例IMS服务是“存在”的服务。存在服务允许用户向其他
用户散布他们当前的可用性和位置，并且涉及IMS内存在AS的使用。用户使用
SIP PUBLISH方法向存在AS更新他/她的存在状态，存在AS然后向已订阅该用户
的存在的对等用户发出SIP NOTIFY消息。订阅涉及用户发送SIP SUBSCRIBE消
息到存在AS，识别其存在正在被订阅的用户。为了降低IMS网络中流动的存在有
关业务的量，可引入所谓的资源列表服务器(RLS)AS。RLS为指向给定用户的
NOTIFY消息充当“集中器”，缓冲在某一预定义时间期上接收的NOTIFY消息，并
在该时期末尾仅将单个组合的NOTIFY消息发送到订阅的用户。RLS AS还为从用
户接收的SUBSCRIBE消息充当“中间人”。
认识到，NOTIFY消息能非常大，具有超过64K字节的有效负荷。其他的SIP消息
也能同样大。因此，能够压缩消息来降低网络负荷是合乎需要的。而且，消息的压
缩能改善总的等待时间，因为空中接口上(和网络中)发送的大消息可能必须分割成
若干较小的消息。
WO2006/030277描述了用于压缩SIP协议消息的方法和设备，其基于已知为
SIGCOMP(IEEE RFC 3320和3321)的技术。所述方法涉及检查消息类型和内容，
以及有选择地压缩有效负荷和报头的所有或部分，以便在明文中留下必须由中间网
络节点可读的消息组件。
SIGCOMP本身包括静态和动态库，并且在IMS内它是在IMS终端中和P-CSCF中
实现的。静态库包含用于压缩和解压特定消息和消息部分的预定义入口(entry)。这
有两个限制。第一，静态库能包含的压缩/转换信息的量可能由于可用存储器而在
最终用户终端中被限制。第二，将新的压缩实体加入到静态库要求改变客户端和服
务器侧。动态库利用之前的消息来压缩和解压消息。虽然动态库的使用在消息包括
相似数据的情况下将取得好的压缩率，但如果数据从消息到消息改变很多(它将在
多服务环境中是这样)，则压缩率将会低。
不考虑基于SIGCOMP的方法取得的压缩率，SIGCOMP也没有被广泛地部署(并且
静态库将要求正在进行的标准化)，并且因此，将存在一段时间出现大量没有最新
的SIGCOMP支持或者完全没有SIGCOMP支持的终端。如果例如为这种遗留设备
开发IMS存在应用，则关联的SIP消息必须无压缩地传送。这个问题对其他类型
的SIP通知也是适用的，例如，使用XCAP改变事件包来完成的通知。
发明内容
根据本发明的第一方面，提供一种跨IP多媒体网络在用户终端和会话发起协议应
用服务器之间传送会话发起协议消息的方法。该方法包括在发送侧的应用层内压缩
消息有效负荷并且在接收侧上的应用层解压它们，压缩的消息有效负荷经由合适的
应用编程接口在应用层和会话发起协议用户代理器(Agent)之间传递。
通过促进SIP用户代理器以外的有效负荷压缩和解压，本发明的实施例能以没有安
装最新SIP协议的用户终端来实现，例如，不要求SIGCOMP兼容性。
根据本发明的优选实施例，SIP消息报头被无压缩地发送，使得这些消息能通过任
何中间CSCF和应用服务器来路由，而不要求在这些节点解压和再压缩。
利用众所周知和可容易获得的算法来压缩和解压有效负荷是合乎需要的。例如，可
以使用gzip算法(GNU zip的缩写)。
在例如IMS上实现的存在服务的情况下，在从用户终端发送到会话发起协议应用
服务器的SIP SUBSCRIBE消息中包括有效负荷压缩将在应用服务器执行的指示是
优选的。随后从应用服务器发送到用户终端并涉及订户事件的SIP NOTIFY消息的
有效负载被压缩。优选的是，所述指示包括在SUBSCRIBE消息的接受或接受编码
报头字段中。还有更优选的是，该方法包括经由所述应用编程接口将接受或接受编
码报头字段从所述应用层写到会话发起协议用户代理器。在存在服务的情况下，该
方法可包括在从用户终端发送到会话发起协议应用服务器的SIP PUBLISH消息中
包括消息有效负荷被压缩的指示，例如，在内容-类型报头字段中。当然，这些过
程可在不同于存在的IMS服务中采用。
在存在服务情况下，所述会话发起协议应用服务器可以是资源列表服务器。
根据本发明的第二方面，提供一种配置成在IP多媒体子系统服务网络内操作的用
户终端。该用户终端实现与会话发起协议用户代理器通信的一个或多个应用层，所
述一个或多个应用层经由应用编程接口与会话发起协议通信，该用户终端进一步配
置成在所述一个或多个应用层压缩和解压外出和进入的SIP消息的有效负荷，并经
由所述应用编程接口与会话发起协议用户代理器交换压缩的有效负荷。
根据本发明的第三方面，提供一种配置成在IP多媒体子系统服务网络内操作的会
话发起协议应用服务器。该应用服务器实现与会话发起协议用户代理器通信的一个
或多个应用层，所述一个或多个应用层经由应用编程接口与会话发起协议通信，该
应用服务器进一步配置成在所述一个或多个应用层压缩和解压外出和进入的SIP消
息的有效负荷，并经由所述应用编程接口与会话发起协议用户代理器交换压缩的有
效负荷。
附图说明
图1示意示出IP多媒体子系统到3G移动通信系统中的集成；
图2示意示出用于在IMS内实现SIP消息的压缩的功能架构；和
图3是示出用于压缩SIP消息的过程的流程图。
具体实施方式 正如已经讨论过的，在IP多媒体子系统(IMS)内使用的多个不同SIP消息可包括非 常大量的有效负荷数据。这些消息包括例如SIP通知(例如，用于存在、RLS和 XCAP改变)和SIP公布(例如，用于存在)。使用压缩机制来降低消息的大小、特别 是优化空中接口带宽的使用将是有利的。而且，为了允许与不利用SIGCOMP(或 者至少具有最新静态压缩库的SIGCOMP)的遗留终端一起使用压缩，在SIP层之上 的应用层促进压缩是合乎需要的。 这里提议在应用层引入压缩/解压过程，仅用于压缩/解压消息的有效负荷，并且其 利用通常使用的压缩算法，例如“gzip”。gzip基于DEFLATE算法，它是LZ77和 霍夫曼(Huffman)编码的组合。众所周知的zip压缩格式可用作对于gzip的备选。 压缩不对SIP消息报头执行，并且因此，消息通过的任何SIP代理都将不受影响， 因为真正的SIP信息是不压缩的。这在图2中示出，其中用户终端由参考数字1指 示，(存在)AS或RLS由参考数字2指示，相应的SIP UA由3a、3b指示，并且相 应的应用层由4a、4b指示。gzip功能由参考数字5a、5b指示。示例CSCF由参考 数字6指示。 至少在本发明的一些实施例中，压缩/解压过程对SIP用户代理器(在用户终端或者 SIP应用服务器)完全透明。相关应用仅仅经由合适的SIP UA应用编程接口(API)与 SIP UA交换有效负荷数据，并且SIP UA不关心数据是否被压缩(相应的API在图 2中由参考数字7a、7b指示)。这个过程在图3的流程图中示出。然而，在其他实 施例中允许用户终端例如在初始SIP SUBSCRIBE消息中指示它支持SIPNOTIFY 消息中压缩的有效负荷可能是合乎需要的。这能例如通过允许应用将合适的声明写 入到SIP消息报头中来完成。例如，现有“接受”或“接受编码”报头字段能用于此目 的，或者可指定新的SIP报头字段。假设通知方(例如，存在AS)也支持压缩，它 将压缩发送到订户并与订阅的事件相关的所有SIP NOTIFY消息的有效负荷。有效 负荷被压缩的指示可包含在消息报头内，例如，使用PUBLISH和NOTIFY消息的 “内容-类型”报头字段。 压缩可特别在资源列表服务器(RLS)被采用，因为从RLS向用户终端发送的有效负 荷经常包含相同句法(syntax)的大量数据，并且用于其的压缩(例如使用gzip)将是非 常有效率的。 本领域技术人员将认识到，在不脱离本发明范围的前提下，可对上面描述的实施例 进行各种修改。例如，在SIP层内附加地实现SIP消息报头的压缩/解压是可能的。 然而，这能是可选的，取决于在客户端终端(或SIP AS)实现的SIP协议版本，并且 在任何情况下可能是不合乎需要的，因为它可能约束SIP消息无附加处理地通过中 间节点的能力。
发布评论