CN1852300A - 一种多媒体消息系统之间进行能力协商的方法 - Google Patents

Abstract

本发明提供了一种多媒体消息系统之间进行能力协商的方法。当两个MMSC之间需要进行互连互通时，发送方MMSC携带自身能力信息向接收方MMSC发送能力协商请求消息；接收方MMSC接收到能力协商请求消息以后，携带其能力信息向发送方MMSC发能力协商响应消息。应用本发明方案可以保证两个MMSC在进行互连互通前自动、准确地知道彼此的支持能力。另外，本发明还实时监控自身支持能力的变化和其它MMSC发送的能力协商请求消息，以便及时更新特性列表，为MMSC采用最合理策略进行互连互通提供保障。

Description

一种多媒体消息系统之间进行能力协商的方法

技术领域

本发明涉及多媒体消息业务(MMS，Multimedia Messaging Service)系统的消息传输处理技术，特别是涉及一种多媒体系统之间进行能力协商方法。

背景技术

多媒体消息业务是为移动运营商提供的一种移动数据增值业务，该业务支持在移动终端用户之间传递含有文本、图像、音频等内容的多媒体消息，也支持移动终端用户与Internet Email用户和MMS业务提供商之间的通信服务。

图1显示了MMS系统的业务环境。MMS系统可以包含许多不同的网络类型，例如2G移动网络、3G移动网络、因特网等，这些不同网络之间的连接基础由因特网协议及其相关的消息协议集提供。MMS系统包括的网元主要有终端侧的MMS用户代理(UA，User Agent)和无线Email客户端(Wired email client)，网络侧的多媒体消息业务环境(MMSE)。MMSE一般包括MMS中继器/服务器(Relay/Server)、MMS用户数据库(User Databases)、信息存储器(MessageStore)以及MMS外部增值应用服务器(VAS，Value Added Service)。其中，MMS中继器/服务器、MMS用户数据库以及信息存储器组成了MMS系统的核心——多媒体业务中心(MMSC，Multimedia Messaging Service Center)。

在运营商开展业务时，经常需要联合多个MMSC向用户提供MMS业务，各个MMSC分别管理各自的用户。图2为多个MMSC互连情况下MMS系统各网元的组网通信示意图，MMS系统各网元之间的接口规范一般按照3GPP和WAP论坛的相关标准为依据。例如：MMSC与用户终端之间通过WAP网关交互，交互协议为MM1协议；MMSC与IP网中的邮件服务器之间采用MM3协议交互，其承载协议为简单邮件传输协议(SMTP，Simple Mail TransferProtocol)；MMSC与业务提供商SP/CP之间采用MM7协议交互，其承载协议一般为超文本传输协议(HTTP，Hypertext Transfer Protocol)；MMSC与MMSC之间则采用MM4协议交互，其承载协议为SMTP协议。在发送多媒体消息的过程中，还需利用对E.164地址进行域名解析的服务器(Enum Server)，该Enum服务器用于向MMSC提供根据接收方用户终端号码进行路由查询的功能，以确认多媒体消息是否需要转发及向哪个MMSC转发。

图3显示了一个MMSC下的用户代理提交一条多媒体消息到另一个MMSC下的用户代理的一般事务处理过程的摘要消息流示意图。图3所示的过程为：发送方用户代理通过提交多媒体请求消息MM1_submit.REQ向发送方MMSC提交一条多媒体信息，并要求接收方MMSC提供递送报告以及阅读报告；发送方MMSC通过MM4接口前转请求消息MM4_forward.REQ把多媒体消息提交给接收方MMSC，多媒体消息包括多媒体信息内容、递送报告请求和阅读报告请求；接收方MMSC通过MM1接口通知请求消息MM1_notification.REQ通知接收方用户代理有多媒体消息到达；接收方MMSC通过MM1接口多媒体接收请求消息MM1_retrieve.REQ向接收方用户代理提交接收到的多媒体消息；接收方用户代理向接收方MMSC发送MM1接口确认请求消息MM1_acknowledgement.REQ；接收方MMSC通过MM4接口递送报告请求消息MM4_delivery_report.REQ向发送方MMSC提交递送报告；发送方MMSC通过MM1接口递送报告请求消息MM1_delivery_report.REQ向发送方用户代理提交递送报告；接收方用户代理通过MM1接口接收方阅读报告请求消息MM1_read_reply_recipient.REQ向接收方MMSC提交阅读报告；接收方MMSC通过MM4接口阅读报告请求消息MM4_read_reply_report.REQ向发送方MMSC提交阅读报告；发送方MMSC通过MM1接口发送方阅读报告请求消息MM1_read_reply_originator.REQ向发送方用户代理提交阅读报告。为了描述更加简洁，这里省略了响应消息的描述。实际上，按照协议规定，MMSC或用户代理可能会向发送请求消息的MMSC或用户发送响应消息。

图3的消息流不但保证了两个MMSC之间传输具体的多媒体信息，而且通过递送报告和阅读报告使MMSC明确多媒体消息处理的状态和结果，有利于多媒体消息的管理。但是，该消息流模式要求发送方MMSC和接收方MMSC同时支持递送报告和阅读报告，否则无法完成相应的消息请求/响应操作。

目前，MMSC可以有支持消息前转、支持递送报告、支持PDU格式的阅读报告、支持回复计费和支持SMTP长连接等能力，而且随着多媒体消息业务技术的进步，MMSC还可能有其它新的支持能力。但不同的设备厂商在生产MMSC时，并没有一个统一的支持能力标准，所生产的MMSC设备的支持能力可能不同。但是，不管各MMSC的支持能力如何，它们在3GPP和WAP论坛规范下都必须支持MM4_forward.REQ/RES消息，以满足两个MMSC之间最基本的交互。满足MMSC之间交互基本要求的能力称为MMSC的最小功能集，其它的支持能力则为MMSC的扩展功能。

两个MMSC进行交互时，只有知道彼此的支持能力才能够采用最合理的策略发送消息。在不知道彼此能力的情况下，如果一方MMSC发送了对方根本不能识别的消息，将会造成业务流程的混乱；如果一方没有发送对方MMSC可以识别的消息，则不能充分发挥MMSC的能力，造成资源的浪费。

所以，知道彼此的支持能力是两个MMSC进行互连互通的重要前提条件。目前的3GPP和WAP论坛规范并没有提供相应的手段来解决两个MMSC了解彼此支持能力的方法，运营商在实际应用中则采用两种方法：一种是采用最小功能集进行互连互通的方法，另一种是采用手工配置的方法。

图4显示了两个MMSC在不知道彼此支持能力的情况下，采用最小功能集方式进行交互的消息流示意图。这里除了不知道彼此能力之外，其它条件与图3完全一样，图4所示的过程为：发送方用户代理通过MM1_submit.REQ请求消息向发送方MMSC提交一条多媒体信息，并要求接收方提供递送报告和阅读报告；发送方MMSC通过MM4_forward.REQ请求消息把多媒体消息提交给接收方MMSC，多媒体消息包括多媒体信息内容、递送报告请求和阅读报告请求；接收方MMSC通过MM1_notification.REQ请求消息通知接收用户代理有多媒体消息到达；接收方MMSC通过MM1_retrieve.REQ请求消息向接收方用户代理提交该多媒体消息；接收方用户代理向接收方MMSC发送MM1_acknowledgement.REQ请求消息确认多媒体消息的接收；接收方MMSC通过MM4_delivery_report.REQ请求消息向发送方MMSC提交递送报告；发送方MMSC通过MM1_delivery_report.REQ请求消息向发送方用户代理提交递送报告；接收方用户代理通过MM1_read_reply_recipient.REQ请求消息向接收方MMSC提交阅读报告；当接收方MMSC准备向发送方MMSC发阅读报告消息MM4_read_reply_report.REQ请求时，由于接收方MMSC并不知道发送方MMSC是否支持阅读报告，为避免发送对方不能识别的消息，接收方MMSC将采用最小功能集中的MM4_forward.REQ请求消息替代MM4_read_reply_report.REQ请求消息提交阅读报告；由于发送方MMSC接收到的是MM4_forward.REQ请求消息，而不是MM4_read_reply_report.REQ消息，就将接收到的MM4_forward.REQ请求消息作为一条新的多媒体消息进行处理。发送方处理这条新多媒体消息的过程为：发送方MMSC通过MM1_notification.REQ请求消息通知发送用户代理有多媒体消息到达；发送方MMSC通过MM1_retrieve.REQ请求消息向发送方用户代理提交该多媒体消息；发送方用户代理向发送方MMSC发送MM1_acknowledgement.REQ请求消息确认多媒体消息的接收。为了描述更加简洁，这里同样省略了响应消息的描述。显然，采用最小功能集方法的处理过程要复杂得多，而且没有充分地发挥MMSC的支持能力，造成了资源的浪费。

采用人工配置方法是说在由人工干预MMSC的操作过程，强制MMSC发送消息，以充分发挥其能力，但这种方法需要人工参与，效率低，容易出错，导致业务流程混乱。

由此可见，现有技术还不能在不同的MMSC之间自动地进行能力协商，达到明确彼此支持能力的目的，因此，也不能使MMSC按照合理的策略进行互连互通。

发明内容

有鉴于此，本发明的主要目的在于提供一种多媒体消息系统之间进行能力协商的方法，使MMSC之间能自动进行能力协商，明确彼此的支持能力，从而可以采用合理的策略进行互连互通。

为了达到上述目的，本发明方法步骤为：

a、发送方多媒体业务中心MMSC向接收方MMSC发送携带有自身支持能力信息的能力协商请求消息；

b、接收方MMSC收到能力协商请求后，将自身的支持能力信息携带于能力协商响应消息中发送给所述发送方MMSC。

进一步，该方法包括：发送方MMSC从发出能力协商响应消息起的预设时间内，判断是否有接收方MMSC发送的能力协商响应消息，如果没有，则进行异常操作处理，结束能力协商过程；否则，不作处理。

为了与其它MMSC进行能力协商，该方法包括：发送方MMSC判断是否还要向第三方MMSC发送能力协商请求消息，如果是，则将第三方MMSC作为接收方MMSC，返回步骤a；否则，不作处理。

进一步，该方法包括：接收方MMSC记录所收到的能力协商请求中携带的发送方MMSC的支持能力信息；

步骤b之后进一步包括：发送方MMSC记录所收到的能力协商响应中携带的接收方MMSC的支持能力信息。

为了及时更新MMSC自身的能力信息，该方法包括：每个MMSC实时监控自身的支持能力是否有变化，如果有，则更新自身记录的支持能力信息。

为了及时更新其它MMSC的能力信息，该方法包括：发送方MMSC和/或接收方MMSC实时监控是否收到第三方MMSC发来的能力协商请求消息，如果收到，则记录能力协商请求消息中携带的支持能力信息，并向第三方MMSC发送携带自身支持能力信息的能力协商响应消息；否则，不作处理。

为了更好地记录MMSC的能力信息，该方法为每个MMSC设置用于记录支持能力信息的特性列表，则所述记录为：MMSC将收到的支持能力信息记录在自身的特性列表中；所述更新为：MMSC更新自身特性列表中记录的支持能力信息。

综上所述，本发明提出的一种多媒体消息系统之间进行能力协商的方法具有以下优点：

本发明中，每个MMSC可以通过能力协商请求/响应消息的交互，将自身支持的能力信息通知其它MMSC，并获取其它MMSC支持的能力信息，如此，使MMSC能够快速、准确地获得与之交互的其它MMSC的支持能力信息，为MMSC采用合理的策略提供可靠的保障。另外，本发明中的每个MMSC还对其自身的支持能力变化和接收到的能力协商请求消息进行实时监控，使每个MMSC中的特性列表可以得到及时更新。

附图说明

图1是典型的多媒体消息系统体系结构图；

图2是多个MMSC互连情况下MMS系统各网元的组网通信示意图；

图3是现有技术中典型的两个MMSC交互的摘要消息流示意图；

图4是现有技术中典型的两个MMSC采用最小功能集方式交互的摘要消息流示意图；

图5是应用本发明方案的MMSC之间进行能力协商的流程图；

图6是应用本发明方案的两个MMSC的典型摘要消息流示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步地详细描述。

本发明的基本思想是：在两个MMSC之间增加一对能力协商请求/响应消息，使MMSC之间能通过能力协商过程获取对方的支持能力信息。具体方法是：发送方MMSC向接收方MMSC发送携带自身支持能力信息的能力协商请求消息；接收方MMSC在收到发送方MMSC的能力协商请求消息后，将自身的支持能力信息携带于能力协商响应消息中发送给发送方MMSC。

此外，发送方MMSC对自身支持能力是否变化以及是否有第三方MMSC向自身发送能力协商请求消息进行实时监控，以便及时更新支持能力信息记录，该记录形式可以由用户根据需要任意设定，在本发明实施例中采用一种特性列表的形式来实现。本发明方案所描述的发送方MMSC、接收方MMSC和第三方MMSC只是一个相对的概念，第三方MMSC是指除发送方MMSC和接收方MMSC以外的任意一个MMSC，可以是发送方MMSC已知的MMSC，也可以是发送方MMSC不知道的或新加入网络的MMSC。在实际应用中，一个MMSC既可以是发送方MMSC，也可以是接收方MMSC或第三方MMSC，所以，本发明的方案对每个MMSC都是适用的。

以MMSC1、MMSC2和MMSC3三个MMSC进行交互为例，每个MMSC所在的MMS系统如图1所示，包含2G移动网络、3G移动网络、因特网，各种网络之间的连接基础由因特网协议及其相关的消息协议集提供。MMS系统包括的网元有终端侧的MMS用户代理和无线Email客户端，网络侧的多媒体消息业务环境(MMSE)，MMSE则包括MMS中继器/服务器、MMS用户数据库、信息存储器以及MMS外部增值应用服务器。三个MMSC互连时的组网情况如图2所示。MMSC与用户终端之间通过MM1协议交互；MMSC与IP网中的邮件服务器之间采用MM3协议交互；MMSC与业务提供商SP/CP之间采用MM7协议交互；MMSC与MMSC之间则采用MM4协议交互。

本实施例中，可以在每个MMSC中设置了一个特性列表，用来记录该MMSC自身以及与之交互的MMSC的支持能力信息，该特性列表及各单元初始值如表一所示：

MMSC标识	是否支持递送报告	是否支持回复计费	是否支持PDU格式的阅读报告	是否支持SMTP长连接
					MMSC1	否	否	否	否
MMSC2	否	否	否	否

MMSC3

否

否

否

否

表一

其中，列表单元初始值均为“否”，当明确某MMSC有某一支持能力后，将对应的列表单元的值更新为“是”。

本发明设计的能力协商请求/响应消息采用的格式符合MM4接口消息格式要求，其摘要消息如表二所示：

摘要消息	类型	方向
			MM4_capability_negotiation.REQ	请求	发起方MMSC→接收方MMSC
MM4_capability_negotiation.RES	响应	接收方MMSC→发送方MMSC

表二

本发明设计的能力协商请求消息MM4_capability_negotiation.REQ字段描述如表三所示：

信息单元	字段名	存在情况	说明
				3GPP MMS Version	X-Mms-3GPP-MMS-Version	必备	表明本MMSC所支持的3GPP MMSVersion版本号
Message Type	X-Mms-Message-Type	必备	表示本消息的名称：MM4_capability_negotiation.REQ
				Transaction ID	X-Mms-Transaction-ID	必备	用于唯一标识一对MM4_capability_negotiation.REQ/RES的ID
Delivery reportsupporting	X-Mms-Delivery-Report-Support	可选	用于标识发送方MMSC是否支持递送报告消息
				Reply chargingsupporting	X-Mms-Reply-Charging-Support	可选	用于标识发送方MMSC是否支持回复计费
read report in PDUformat supporting	X-Mms-PDU-Read-Report-Support	可选	用于标识发送方MMSC是否支持PDU格式阅读报告
				SMTP longconnectionsupporting	X-Mms-SMTP-Long-Connection-Support	可选	用于标识发送方MMSC是否支持SMTP长连接

表三

本发明设计的能力协商响应消息MM4_capability_negotiation.RES字段描述如表四所示：

信息单元	字段名	存在情况	说明
				3GPP MMS Version	X-Mms-3GPP-MMS-Version	必备	表明本MMSC所支持的3GPPMMS Version版本号
Message Type	X-Mms-Message-Type	必备	表示本消息的名称：MM4_capability_negotiation.RES
				Transaction ID	X-Mms-Transaction-ID	必备	用于唯一标识一对MM4_capability_negotiation.REQ/RES的ID
Delivery reportsupporting	X-Mms-Delivery-Report-Support	可选	用于标识接收方MMSC是否支持递送报告消息
				Reply chargingsupporting	X-Mms-Reply-Charging-Support	可选	用于标识接收方MMSC是否支持回复计费
read report in PDUformat supporting	X-Mms-PDU-Read-Report-Support	可选	用于标识接收方MMSC是否支持PDU格式阅读报告
				SMTP longconnection supporting	X-Mms-SMTP-Long-Connection-Support	可选	用于标识接收方MMSC是否支持SMTP长连接

表四

正常操作情况下，发送方MMSC携带自身支持能力向接收方发送能力协商请求消息MM4_capability_negotiation.REQ；收到能力协商请求消息以后，接收方MMSC会向发送方MMSC发送MM4_capability_negotiation.RES响应消息，以确认成功接收MM4_capability_negotiation.REQ消息。

异常操作情况下，接收方MMSC将不返回MM4_capability_negotiation.RES响应消息。发送方MMSC在预设的时间里如果没有收到MM4_capability_negotiation.RES响应消息时，则退出能力协商过程。

本实施例中，MMSC1、MMSC2和MMSC3不知道彼此的支持能力，假定MMSC1支持递送报告和PDU格式的阅读报告；MMSC2支持递送报告和PDU格式的阅读报告；MMSC3支持递送报告、回复计费、PUD格式的阅读报告和SMTP长连接。本实施例假定MMSC1先与MMSC2进行能力协商，此后，MMSC1接收到MMSC3的能力协商请求消息。

参照图5，本实施例中MMSC1为了达到分别与MMSC2和MMSC3进行能力协商的目的，MMSC1执行的步骤包括：

步骤501：MMSC1设置自身的特性列表，并把自身的支持能力信息记录在特性列表中。

本实施例中，MMSC1自身特性列表的初始化状态如表五所示：

MMSC标识	是否支持递送报告	是否支持回复计费	是否支持PDU格式的阅读报告	是否支持SMTP长连接
					MMSC1	是	否	是	否
MMSC2	否	否	否	否
					MMSC3	否	否	否	否

表五

步骤502：MMSC1携带自身能力信息向MMSC2发能力协商请求消息MM4_capability_negotiation.REQ。

本实施例中，MMSC1携带的自身能力信息包括支持递送报告、支持PDU格式的阅读报告。

步骤503：MMSC1在预设的时间内判断是否接收到能力协商响应信息，如果接收到响应消息，则继续下一步；否则，进入异常操作处理。

本实施例中，假定MMSC1正常接收到MMSC2的能力协商响应信息，则继续执行下一步。

步骤504：MMSC1接收到MMSC2的能力协商响应消息MM4_capability_negotiation.RES后，取出消息中的MMSC2支持能力信息，并将MMSC2的支持能力信息记录在MMSC1的特性列表中。

本实施例中，执行步骤504之后，MMSC1的特性列表如表六所示；

MMSC标识	是否支持递送报告	是否支持回复计费	是否支持PDU格式的阅读报告	是否支持SMTP长连接
					MMSC1	是	否	是	否
MMSC2	是	否	是	否
					MMSC3	否	否	否	否

表六

步骤505：MMSC1判断是否还需要给第三方MMSC发送能力协商请求消息，如果需要，则返回步骤502；否则，执行下一步。

本实施例中，假定MMSC1只向MMSC2发送能力协商请求消息，因此继续执行下一步。

步骤506：MMSC1实时监控有无第三方MMSC发送来的能力协商请求，如果有，则执行步骤507；否则，执行步骤508。

本实施例中，假定MMSC1检查到有MMSC3发送的能力协商请求消息，则继续执行步骤507。

步骤507：MMSC1取出消息中的第三方MMSC支持能力信息，并记录在特性列表中，再向第三方MMSC发送能力协商响应消息。

本实施例中，MMSC1记录下MMSC3的能力信息，MMSC3的支持能力包括递送报告、回复计费、阅读报告和SMTP长连接，MMSC1记录结果如表七所示：

MMSC标识	是否支持递送报告	是否支持回复计费	是否支持PDU格式的阅读报告	是否支持SMTP长连接
					MMSC1	是	否	是	否
MMSC2	是	否	是	否
					MMSC3	是	是	是	是

表七

步骤508：MMSC1实时监控自身的支持能力是否有变化，如果有，则执行步骤509，更新特性列表，将MMSC1自身的支持能力信息记录在MMSC1的特性列表中；否则，返回步骤506。

本实施例中，假定MMSC1没有能力变化，则返回步骤506，继续实时监控是否接收到能力协商请求消息以及自身支持能力是否有变化，直到结束能力协商过程。

如表七所示，本实施例的执行结果可以使MMSC1从自身的特性列表中知道MMSC2和MMSC3的支持能力。同理，MMSC2和MMSC3也可以通过执行步骤501～509的过程，从各自的特性列表中知道MMSC1的支持能力，从而可以采取合理的策略实现MMSC之间的互连互通。

其中，步骤506和步骤508是实时的，没有严格的顺序要求，所以，步骤506和步骤508可在步骤501以后的任意时刻执行，本实施例只列举了其中一种顺序进行描述，而把步骤506和步骤508设置在步骤501以后的其它流程也可以有效地完成本发明方案。

另外，如果步骤506中的第三方MMSC是一个新加入网络的MMSC，则MMSC1可以在发现自身特性列表中不存在该新MMSC的信息后，先将该新MMSC的标识添加在自身特性列表中，再在特性列表中记录该新MMSC的支持能力信息，然后向该新MMSC发送携带自身支持能力的能力协商响应消息。

本实施例中所描述的能力协商请求/响应过程在实际应用中可以由MMSC在任意时刻发起，比如：在某个MMSC需要获知其它MMSC的支持能力信息时，发起两个MMSC间的能力协商过程；再比如：当一个新MMSC加入网络时，发起两个MMSC间的能力协商过程，所述能力协商过程可以由该新MMSC主动发起，也可以由网络中已存在的MMSC在检测到网络中有新MMSC加入时发起。

图6显示了本实施例中MMSC1、MMSC2和MMSC3进行能力协商的消息流示意图，图6所示过程为：MMSC1通过MM4_capability_negotiation.REQ向MMSC2发能力协商请求消息；MMSC2通过MM4_capability_negotiation.RES向MMSC1发能力协商响应消息；MMSC3通过MM4_capability_negotiation.REQ向MMSC1发能力协商请求消息；MMSC1通过MM4_capability_negotiation.RES向MMSC2发能力协商响应消息。能力协商以后，MMSC1、MMSC2和MMSC3可以采用合理的策略进行互连互通，从而充分发挥MMSC的支持能力。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1、一种多媒体消息系统之间进行能力协商的方法，其特征在于，该方法包括以下步骤：

a、发送方多媒体业务中心MMSC向接收方MMSC发送携带有自身支持能力信息的能力协商请求消息；

b、接收方MMSC收到能力协商请求后，将自身的支持能力信息携带于能力协商响应消息中发送给所述发送方MMSC。

2、根据权利要求1所述的方法，其特征在于，该方法进一步包括：发送方MMSC判断从发出能力协商响应消息起的预设时间内，是否收到接收方MMSC发送的能力协商响应消息，如果没有，则结束能力协商过程；否则，不作处理。

3、根据权利要求1所述的方法，其特征在于，步骤b之后，该方法进一步包括：发送方MMSC判断是否还要向第三方MMSC发送能力协商请求消息，如果是，则将第三方MMSC作为接收方MMSC，返回步骤a；否则，不作处理。

4、根据权利要求1或3所述的方法，其特征在于，步骤b进一步包括：接收方MMSC记录所收到的能力协商请求中携带的发送方MMSC的支持能力信息；

步骤b之后进一步包括：发送方MMSC记录所收到的能力协商响应中携带的接收方MMSC的支持能力信息。

5、根据权利要求4所述的方法，其特征在于，该方法进一步包括：为每个MMSC设置用于记录支持能力信息的特性列表；

则所述记录为：MMSC将收到的支持能力信息记录在自身的特性列表中。

6、根据权利要求1或3所述的方法，其特征在于，该方法进一步包括：每个MMSC实时监控自身的支持能力是否有变化，如果有，则更新自身记录的支持能力信息，再返回步骤a；否则，不作处理。

7、根据权利要求6所述的方法，其特征在于，该方法进一步包括：为每个MMSC设置用于记录支持能力信息的特性列表；

则所述记录为：MMSC将收到的支持能力信息记录在自身的特性列表中；

所述更新为：MMSC更新自身特性列表中记录的支持能力信息。

8、根据权利要求1或3所述的方法，其特征在于，发送方MMSC和/或接收方MMSC实时监控是否收到第三方MMSC发来的能力协商请求消息，如果收到，则记录能力协商请求消息中携带的支持能力信息，并向第三方MMSC发送携带自身支持能力信息的能力协商响应消息；否则，不作处理。

9、根据权利要求8所述的方法，其特征在于，该方法进一步包括：每个MMSC实时监控自身的支持能力是否有变化，如果有，则更新自身记录的支持能力信息。

10、根据权利要求9所述的方法，其特征在于，该方法进一步包括：为每个MMSC设置用于记录支持能力信息的特性列表；

则所述记录为：MMSC将收到的支持能力信息记录在自身的特性列表中；

所述更新为：MMSC更新自身特性列表中记录的支持能力信息。

Images