CN101321136B - 会话初始协议消息的收发代理方法及相应的处理器 - Google Patents

Abstract

本发明公开了会话初始协议消息的收发代理方法，在会话初始协议消息中扩展设置与代理相关的头域或头域参数，由会话初始协议处理器根据这些扩展的头域或头域参数进行相应处理来实现会话初始协议层代理功能。本发明还提供相应的会话初始协议处理器。本发明由于在会话初始协议层实现代理功能，使得代理机制与业务无关，能够广泛应用于不同的业务中，便于代理功能的复用和统一管理。

Description

会话初始协议消息的收发代理方法及相应的处理器

技术领域

本发明涉及通讯技术领域，具体涉及会话初始协议的消息收发代理方法及相应的处理器。

背景技术

会话初始化协议(SIP：Session Initiation Protocol)是一种应用层控制协议，它可用来创建、修改或终止多媒体会话。SIP网元主要包括用户代理(UA：User Agent)和SIP服务器。

用户代理是发起或者接收呼叫的逻辑实体。用户代理客户端(UAC：UserAgent Client)用于发起请求；用户代理服务端(UAS：User Agent Server)用于接收请求。在一次会话的多个事务中，UAC和UAS的角色是可以互换的。例如在用户A和用户B的呼叫中，用户A向用户B发起呼叫，在呼叫建立的事务中，用户A的UA是UAC，用户B的UA是UAS；呼叫结束时，用户B先挂机，在呼叫释放的事务中，用户B的UA是UAC，用户A的UA是UAS。因此，一般而言UA是UAS和UAC的结合体。UA的实际物理形态包括：支持SIP的移动终端、个人电脑上的软电话终端等。

SIP服务器是为UA转发请求或响应的网络逻辑实体，为所在域内的UA提供用户注册、网络协议(IP：Internet Protocol)地址关联、SIP消息的域内或域外路由等服务。基于功能划分，SIP服务器可包括以下几个独立的逻辑实体：

SIP注册服务器(Registrar)，UA接入网络后需要向注册服务器注册，注册信息可写入定位服务器(Location Server)中；定位服务器提供UA的位置的数据库，不属于SIP网元。在SIP通信中，注册服务器会检索参与方的IP地址和其他相关信息，并将其发送到SIP代理服务器；

SIP代理服务器(Proxy Server)，为UA发送或接收的域内域外请求进行路由，SIP代理服务器通过查询SIP注册服务器获得与UA关联的地址信息；

SIP重定向服务器(Redirect Server)，为SIP代理服务器将SIP消息定向到外部域提供服务；

SIP服务器的不同逻辑实体可以运行于同一硬件设备也可运行于不同的硬件设备上。SIP服务器可视为UAS和UAC的组合体，从UA或网络侧接收消息端为UAS端，向UA或网络侧发送消息端为UAC端。

在采用SIP的业务中存在着各种代理需求，例如，可以允许用户A代理用户B发布呈现信息，即用户A可以发布属于用户B的呈现信息；还可以允许用户A代理用户B发送或接收消息等。为避免上述介绍的代理需求中的“代理”一词，与前述介绍的SIP网元“用户代理”以及SIP服务器的“SIP代理服务器”中的“代理”一词含义混淆，在本文中除前述对SIP网元的介绍部分外，均将用户代理称为用户处理器(仍简记为UA)，并相应的将SIP服务器称为服务处理器。此外，由于用户的操作往往需要UA与服务处理器协同完成，并且基于网络的配置或用户的设置，某些操作既可以在UA上执行，也可以在为UA提供转发服务的服务处理器上执行，因此本文中将用户处理器和服务处理器统称为SIP处理器，简称处理器；例如发送方处理器指发送方UA或为发送方UA提供转发服务的服务处理器。

现有对业务的代理需求的处理一般通过为特定的业务配置代理功能来实现，即，在业务层面上实现代理功能。在对现有技术的研究和实践过程中，发明人发现现有技术存在以下问题：需要对特定业务进行代理逻辑配置以实现该业务的代理功能，如果需要在不同的业务上实现代理功能，则需要分别进行业务逻辑设计，使得业务功能重复，不利于功能复用，也不利于对代理功能进行统一管理。

发明内容

本发明实施例提供能够在协议层实现代理机制的SIP消息的发送代理方法，包括：代理方处理器获取对被代理方的选择信息，所述处理器为用户代理UA或会话初始化协议SIP服务器，或者为UA和SIP服务器；代理方处理器生成原始代发消息；代理方处理器生成认证请求消息，所述认证请求消息的消息体中包括所述原始代发消息或原始代发消息的片段；代理方处理器向被代理方发送所述认证请求消息；代理方处理器接收被代理方处理器根据所述认证请求返回的认证信息；代理方处理器通过将所述认证信息添加到所述原始代发消息的消息体中生成代发消息，所述代发消息中还包括代理属性头域，所述代理属性头域中包括被代理方的信息；代理方处理器将所述代发消息发送给接收方。

以及相应的SIP代发消息的接收方法，包括：接收方处理器获取代发消息，所述代发消息中包括被代理方的认证信息和代理属性头域，所述处理器为用户代理UA或会话初始化协议SIP服务器，或者为UA和SIP服务器；接收方处理器从所述代理属性头域中获取被代理方的信息；接收方处理器根据所述被代理方的信息对所述被代理方的认证信息进行验证，根据验证结果确定是否接受所述代发消息。

本发明实施例并提供与上述方法相应的SIP处理器，所述处理器为用户代理UA或会话初始化协议SIP服务器，或者为UA和SIP服务器。

其一包括：选择获取单元，用于获取对被代理方的选择信息；

认证获取单元，用于向被代理方发送认证请求，并接收被代理方处理器根据所述认证请求返回的认证信息；

所述认证获取单元包括：原始消息单元，用于生成原始代发消息；认证请求单元，用于生成认证请求消息并向被代理方发送所述认证请求消息，所述认证请求消息的消息体中包括所述原始代发消息或原始代发消息的片段；认证接收单元，用于从被代理方返回的对所述认证请求消息的成功响应消息中获取认证信息；

消息生成单元，用于通过将所述认证信息添加到所述原始代发消息的消息体中生成代发消息，所述代发消息中还包括代理属性头域，所述代理属性头域中包括被代理方的信息；

代理发送单元，用于将所述代发消息发送给接收方。

其二包括：代发接收单元，用于获取代发消息，所述代发消息中包括被代理方的认证信息和代理属性头域；

代理分析单元，用于从所述代理属性头域中获取被代理方的信息；

消息处理单元，用于根据所述被代理方的信息对所述代发消息进行处理；

所述消息处理单元包括：代理鉴权单元，用于根据所述被代理方的信息对所述被代理方的认证信息进行验证，根据验证结果确定是否接受所述代发消息。

本发明实施例采用在SIP消息中扩展设置与代理相关的头域或头域参数，由SIP处理器根据这些扩展的头域或头域参数进行相应处理来实现SIP层代理功能的方法。由于在SIP层实现代理功能，使得代理机制与业务无关，能够广泛应用于不同的业务中，便于代理功能的复用和统一管理。

附图说明

图1是本发明方法实施例一SIP消息的发送代理方法流程示意图；

图2是本发明方法实施例二SIP消息的发送代理方法流程示意图；

图3是本发明方法实施例三SIP代发消息的接收方法流程示意图；

图4是本发明方法实施例四SIP消息的发送代理方法流程示意图；

图5是本发明方法实施例五SIP代发消息的接收方法流程示意图；

图6是本发明方法实施例六SIP消息的接收代理方法流程示意图；

图7是本发明装置实施例一SIP处理器逻辑结构示意图；

图8是本发明装置实施例二SIP处理器逻辑结构示意图；

图9是本发明装置实施例三SIP处理器逻辑结构示意图；

图10是本发明装置实施例四SIP处理器逻辑结构示意图；

图11是本发明装置实施例五SIP处理器逻辑结构示意图；

图12是本发明装置实施例六SIP处理器逻辑结构示意图；

图13是本发明装置实施例七SIP处理器逻辑结构示意图；

图14是本发明方法实施例二和三应用于INVITE方法的消息流程图；

图15是本发明方法实施例二和三应用于MESSAGE方法的消息流程图；

图16是本发明方法实施例四和五应用于INVITE方法的消息流程图。

具体实施方式

本发明实施例提供了SIP消息的收发代理方法，在SIP消息中扩展设置与代理相关的头域或头域参数，由SIP处理器根据这些扩展的头域或头域参数进行相应处理来实现SIP层代理功能。本发明实施例还提供对通过SIP消息的发送代理方法发送的代发消息的接收方法，以及与上述各种方法相应的SIP处理器。以下分别进行详细说明。

方法实施例一、一种SIP消息的发送代理方法，流程如图1所示，包括：

A1、代理方处理器获取对被代理方的选择信息。

代理方处理器可根据代理方用户输入的信息，例如代理方用户在用户界面上填写的被代理方标识等，获取对被代理方的选择；或者也可按照代理方用户预置的规则选择被代理方。

A2、代理方处理器生成代发消息，所述代发消息中包括代理属性头域，所述代理属性头域中包括被代理方的信息。

本文中将通过发送代理机制发送的消息称为代发消息。在本实施例中，代发消息与代理方作为普通用户时发送的一般SIP消息类似，主要区别在于需要指示该消息是代理另一方发送的，因此需要在普通SIP消息的基础上添加一个代理属性头域(以下称为Delegator头域)，可以在该头域中放置被代理方的信息，例如被代理方的SIP地址(SIP URI或SIPS URI，URI：Uniform ResourceIdentifier)。Delegator头域的一个示例如下：

Delegator：Bexample.com

其中“Bexample.com”为被代理方用户“B”的SIP URI。

进一步的，为了能够向消息接收方传达代发消息进行代理发送的原因，还可以在生成代发消息时，在代发消息中再添加原因属性头域(以下称为Delegation-Reason头域)，在该头域中说明代理的原因。Delegation-Reason头域的一个示例如下：

Delegation-Reason：on vacation

其中“on vacation”为代理原因。

此外，为确保消息接收方能够正确识别和处理代发消息中与代理相关的信息，例如Delegator头域、Delegation-Reason头域，可在代发消息的要求属性头域(以下称为Require头域)中设置代理标签(以下用delegation来表示代理标签)。Require头域是现有SIP消息中可包括的一种属性头域，Require头域中包括的标签用于通知接收方应该用什么样的SIP扩展来处理本消息，本实施例扩展了Require头域的标签内容，以delegation标签指示处理本消息的网元需要支持代理机制。本实施例中Require头域的一个示例如下：

Require：delegation

当然，在实际消息中Require头域还可进一步包括其他标签内容。

另外，与上述Require头域的设置相似，还可以在代发消息的支持属性头域(以下称为Support头域)中设置delegation标签，用于向接收方指明代理方支持代理机制。Support头域也是现有SIP消息中可包括的一种属性头域，本实施例中Support头域的一个示例如下：

Support：delegation

同样，在实际消息中Support头域也可进一步包括其他标签内容，指明代理方支持的其他扩展。

A3、代理方处理器将所述代发消息发送给接收方。

本实施例中代理方直接将代发消息发送给接收方。

本实施例中的代理方处理器可以是代理方用户处理器也可以是代理方服务处理器，还可以由两者共同充当，例如可由代理方用户处理器生成普通SIP消息，由代理方服务处理器提供代理服务，即在普通SIP消息中添加与代理相关的头域以及参数生成最终的代发消息并发送。

本实施例在SIP层实现代理发送功能，使得代理发送机制与业务无关，能够广泛应用于不同的业务中，便于代理发送功能的复用和统一管理。

方法实施例二、一种SIP消息的发送代理方法，本实施例与方法实施例一相比，区别在于增加了被代理方对代理方的代理发送行为的鉴权认证过程。本实施例方法流程如图2所示，包括：

B1、代理方处理器获取对被代理方的选择信息。

本步骤可参考方法实施例一中的步骤A1。

B2、代理方处理器向被代理方发送认证请求。

认证请求可以通过特定的消息或消息内容来表示，本实施例中将代理方发送的用于进行认证请求的消息称为认证请求消息。为便于被代理方对代理方的代理发送行为进行鉴权认证，可以在认证请求消息中携带与代发消息相关的信息，具体可采用如下方式：

①代理方处理器生成原始代发消息。所谓原始代发消息指已经包括了代发消息的基本内容，但还不具有认证信息的消息。

②代理方处理器生成认证请求消息，所述认证请求消息的消息体中包括所述原始代发消息或原始代发消息的片段。

可以将整个原始代发消息都放入认证请求消息中，使被代理方获知其全部内容；也可只放入原始代发消息的片段，例如原始代发消息中一些主要的参数和头域，可以包括原始代发消息的方法名(Method)、携带代理方标识的来自属性头域(以下称为From头域)、携带接收方标识的目标属性头域(以下称为To头域)等。

此外，与方法实施例一中类似，为确保接收认证请求消息的被代理方，能够正确处理这个为代发消息进行认证请求的认证请求消息，即支持本实施例代理鉴权机制，可在认证请求消息的Require头域中设置delegation标签。

③代理方处理器向被代理方发送所述认证请求消息。

B3、被代理方处理器根据所述认证请求返回认证信息。

被代理方接收到认证请求消息后，若认证请求消息的Require头域中设置有delegation标签，被代理方处理器可先根据delegation标签的要求确定自身支持代理机制，然后对代理方的认证请求进行处理。具体可包括：

①被代理方处理器获取所述认证请求消息中包括的原始代发消息或原始代发消息的片段，根据自身的代理策略生成认证信息，认证信息具体可以是对原始代发消息中的某些头域或请求的签名。

进一步的，被代理方在签名时可以指定许可的有效期，有效期可以是一次有效，也可以是在一段时间内有效。如果是一次有效，则代理方每次代理被代理方发送代发消息都需要向被代理方请求认证。如果是在一段时间内有效，则在有效时间内，若代理方再次代理被代理方发送代发消息，可直接使用已获得的认证信息，不需要再次请求。

②被代理方处理器生成所述认证请求消息的成功响应消息，所述成功响应消息的消息体中包括所述认证信息。基于SIP中通常的请求/响应机制，本实施例中采用认证请求消息的成功响应消息来携带认证信息。对于认证请求消息，被代理方处理器也可能返回其他响应信息，例如若被代理方处理器不支持代理机制或鉴权未通过，则可能返回错误或失败响应消息，说明鉴权认证不成功。

③被代理方处理器向代理方发送所述携带认证信息的成功响应消息。

B4、代理方处理器接收所述认证信息。

代理方处理器可以从接收到的对认证请求消息的成功响应消息中，获取该成功响应消息所携带的认证信息。

B5、代理方处理器生成携带认证信息的代发消息。

基于步骤B2中提供的具体认证请求方式，代理方处理器可通过将获得的认证信息添加到原始代发消息的消息体中，生成代发消息。

当然，与方法实施例一中类似，代发消息中还设置包括被代理方的信息的Delegator头域。并且进一步的，还可包括Delegation-Reason头域、携带delegation标签的Require头域和Support头域等，可参考方法实施例一中的步骤A2。

B6、代理方处理器将所述代发消息发送给接收方。

本实施例中代理方直接将代发消息发送给接收方。

本实施例中执行认证请求的代理方处理器可以是代理方用户处理器也可以是代理方服务处理器。执行鉴权认证的被代理方处理器可以是被代理方用户处理器也可以是被代理方服务处理器。

本实施例在方法实施例一基础上增加了对代理方代理发送行为的鉴权过程，提高了代理发送机制的安全性。需要说明的是，代发消息中的认证信息是可选的，如果包含，则表明被代理方允许代理方发送此代发消息；如果不包含，接收方可能接收也可能拒绝这个代发消息，取决于接收方的策略。被代理方可以使用各种适合的签名机制对代理消息进行认证，本实施例对此不作限定。

方法实施例三、一种SIP代发消息的接收方法，流程如图3所示，包括：

C1、接收方处理器获取代发消息，所述代发消息中包括Delegator头域。

接收方收到的代发消息与代理方直接发送的一般SIP消息类似，只是在代发消息中以Delegator头域指示了这个消息是代理另一方发送的，并且可能还包括与代理相关的其他信息，例如Delegation-Reason头域，以及认证信息等。

C2、接收方处理器从Delegator头域中获取被代理方的信息。

接收方接收到代发消息后，若代发消息的Require头域中设置有delegation标签，接收方处理器可先根据delegation标签的要求确定自身支持代理机制，再进行进一步的操作。对Require头域进行检查的时机，以及对检查结果的处理，可参照现有SIP规范中提供的方式，例如若接收方发现不支持Require头域中的某些标签所指示的扩展，可以产生错误响应，通知对方哪些标签是自己所不支持的。

C3、接收方处理器根据所述被代理方的信息对所述代发消息进行处理。

接收方处理器对代发消息的处理可根据该消息对应的方法类型来执行。例如对于呼叫请求(INVITE)方法的消息可以将被代理方的信息，例如被代理方显示名，显示在接收方的用户界面上，按照接收方用户的选择执行相应操作。

特别地，为提高安全性，接收方处理器可以在对代发消息进行其他处理之前，先根据被代理方的信息对代发消息进行鉴权处理，本实施例中提供如下三种鉴权方式：

方式一、接收方处理器具有由被代理方配置的许可信息。

这种情况下，鉴权处理的步骤为：接收方处理器根据从Delegator头域中获取的被代理方的信息以及预置的许可信息对代发消息进行鉴权，根据鉴权结果确定是否接受所述代发消息。例如，如果接受则可按照消息类型继续进行处理，如果不接受则可返回拒绝或错误消息。

方式二、代发消息中包括被代理方的认证信息。

例如接收方收到的是按照方法实施例二方法发送的代发消息。这种情况下，鉴权处理的步骤为：接收方处理器根据从Delegator头域中获取的被代理方的信息对代发消息中携带的被代理方的认证信息进行验证，根据验证结果确定是否接受所述代发消息。

方式三、接收方处理器没有预置的许可信息，代发消息中也没有认证信息。

这种情况下，接收方处理器可以联系被代理方，询问被代理方是否允许代理方发送上述代理消息。具体步骤可包括：

①接收方处理器向被代理方发送鉴权请求消息，所述鉴权请求消息中包括代理方标识和/或所述代发消息，或者包括代理方标识和/或所述代发消息的片段。

②被代理方处理器根据所述鉴权请求消息返回鉴权应答消息，所述鉴权应答消息中包含鉴权结果信息。

③接收方处理器根据所述鉴权结果信息确定是否接受所述代发消息。

C4、此外，无论是否对代发消息进行鉴权处理，接收方处理器在收到代发消息，从Delegator头域中获取被代理方的信息后，都可以向被代理方发送通知消息，所述通知消息中包括所述代发消息的信息。这样，被代理方即可获知代理方的代理发送行为以及相关内容，有利于信息安全。

本实施例中的接收方处理器可以是接收方用户处理器也可以是接收方服务处理器，还可以由两者共同充当，例如可由接收方服务处理器执行代发消息的鉴权处理，鉴权通过后再将代发消息转发给接收方用户处理器进行进一步处理。接收方的服务处理器是否进行鉴权操作，可以由接收方用户在服务处理器上设置的配置信息来确定。

本实施例可对采用方法实施例一或二发送的代发消息进行接收处理。

方法实施例四、一种SIP消息的发送代理方法，本实施例与方法实施例一和二相比，主要区别在于采用间接发送的方式进行发送代理，即代理方首先将代发消息发送给被代理方，由被代理方处理后再转发给接收方。本实施例方法流程如图4所示，包括：

D1、代理方处理器获取对被代理方的选择信息。

本步骤可参考方法实施例一中的步骤A1。

D2、代理方处理器生成代发消息，所述代发消息中包括接收方标识和携带delegation标签的Require头域。

基于现有SIP消息格式，该接收方标识可设置于代发消息的To头域中。

D3、代理方处理器将所述代发消息发送给被代理方。

D4、被代理方处理器收到代发消息后，根据代发消息的Require头域中的delegation标签，确定自身支持代理机制，即能够正确识别和处理代发消息。

D5、被代理方处理器对代发消息进行鉴权，根据鉴权结果确定允许对所述代发消息进行处理。

本步骤为可选步骤，目的在于通过鉴权确定代理者的操作权限。

D6、被代理方处理器对所述代发消息进行处理。

处理过程可按照被代理方处理器上与发送代理相关的设置进行，具体设置内容可以由被代理方用户配置。一些可选的处理过程示例如下：

处理一、将代发消息的请求资源标识(Request-URI)修改为代发消息所携带的接收方标识。Request-URI用于对消息的路由，被代理方处理器收到的代发消息的Request-URI一般为被代理方的SIP地址，因此需要在转发前修改为接收方标识。

处理二、删除代发消息的Require头域中的delegation标签。这表示被代理方不要求接收方支持代理机制。此时若代发消息中不包含其他与代理机制相关的信息，则接收方接收到的代发消息可视为一个普通SIP消息；并且接收方可能无法分辨这个消息是由代理方直接发送的，还是由代理方首先发送给被代理方然后再由被代理方转发的。

处理三、若被代理方处理器对代发消息进行了鉴权，还可以在代发消息中增加被代理方处理器的认证信息。这种情况下需要保留Require头域中的delegation标签。此外，若执行鉴权的是被代理方用户处理器，此处理通常可省略。

处理四、在代发消息中增加Delegator头域，Delegator头域中包括被代理方的信息。这表示被代理方希望接收方获知代发消息的被代理方。这种情况下需要保留Require头域中的delegation标签。

上述各种处理在彼此不冲突的前提下可同时被选择。

D7、被代理方处理器将处理后的代发消息发送给所述接收方标识指示的接收方。

本实施例中的代理方处理器可以是代理方用户处理器也可以是代理方服务处理器。本实施例中的被代理方处理器可以是被代理方用户处理器也可以是被代理方服务处理器，被代理方处理器对代发消息可进行鉴权也可不进行鉴权，鉴权结果可添加也可不添加进代发消息。

本实施例在SIP层实现间接代理发送功能，由于代发消息需要经过被代理方的转发，安全性更好，并且便于被代理方对代发消息进行鉴权。此外，通过间接代理发送的代发消息可无需要求接收方支持代理机制，兼容性好。

方法实施例五、一种SIP代发消息的接收方法，本实施例提供对采用间接代理发送方式发送的代发消息的接收方法，流程如图5所示，包括：

E1、接收方处理器获取代发消息，所述代发消息中包括携带有delegation标签的Require头域。

E2、接收方处理器根据Require头域中的delegation标签，确定自身支持代理机制，即能够正确识别和处理代发消息。

E3、接收方处理器对所述代发消息进行处理。

处理过程可按照接收方处理器上与代发消息相关的设置进行，具体设置内容可以由接收方用户配置。一些可选的处理过程示例如下：

处理一、若代发消息中包括Delegator头域，接收方处理器可从Delegator头域中获取被代理方的信息。

处理二、进一步的，接收方处理器可根据被代理方的信息对代发消息进行鉴权，根据鉴权结果确定是否接受该代发消息。由于在间接代理发送方式中，代发消息要经过被代理方，并且被代理方可能已经对消息进行鉴权，因此接收方可省略鉴权步骤，当然也可不省略。

此外，在进行鉴权时，若代发消息中还包括被代理方的认证信息，则鉴权过程可以是根据被代理方的信息对被代理方的认证信息进行验证的过程。

接收方在验证出认证信息是被代理方用户的(说明代发消息的鉴权由被代理方用户处理器执行)，或者确认认证信息是被代理方服务处理器的(说明代发消息的鉴权由被代理方服务处理器执行)以后，可以根据接收方的本地策略接受或拒绝这个消息。

本实施例中的接收方处理器可以是接收方用户处理器也可以是接收方服务处理器，还可以由两者共同充当，例如可由接收方服务处理器执行代发消息的鉴权处理，鉴权通过后再将代发消息转发给接收方用户处理器进行进一步处理。接收方的服务处理器是否进行鉴权操作，可以由接收方用户在服务处理器上设置的配置信息来确定。

本实施例可对采用方法实施例四发送的代发消息进行接收处理。

方法实施例六、一种SIP消息的接收代理方法，流程如图6所示，包括：

F1、被代理方处理器获取接收方代理规则配置信息。

接收方代理规则配置信息确定当收到SIP消息时，由谁来进行代理接收。通常该规则由被代理方用户进行配置，被代理方用户可以采用SIP的方法，例如发送特定的SIP消息进行配置；也可以采用非SIP的方法，例如直接进行参数设置的方式进行配置。本实施例中给出两种配置方式的示例：

方式一、直接配置。

用户可以在自己的SIP处理器中直接设置接收方代理规则，所称SIP处理器包括用户处理器和服务处理器。接收方代理规则可以采用XML格式的文档表示。例如，可将接收方代理规则文档的根元素命名为<delegation-rules>，<delegation-rules>元素由若干<rule>元素组成；每个<rule>元素包含<condition>和<action>两个子元素，<condition>子元素指明规则适用的条件，<action>子元素指明条件满足时的代理方。

方式二、发送SIP消息配置

此方式下，接收方代理规则配置信息配置在用户的服务处理器上，即由被代理方服务处理器执行接收代理操作。用户可以使用注册(REGISTER)消息设置由谁来代理接收SIP消息，具体设置过程可包括：

①被代理方用户处理器向被代理方服务处理器发送REGISTER消息，该REGISTER消息中包括联系属性头域(以下称为Contact头域)，Contact头域中包括用delegation标签标记的代理方标识，例如代理方的地址。REGISTER消息是现有SIP规范中的消息，可通过扩展其Contact头域的参数，以delegation标签指示相应条目的地址为代理方地址。

②被代理方服务处理器根据收到的REGISTER消息，记录其中用delegation标签标记的代理方标识作为用户的接收方代理规则配置信息。

F2、被代理方处理器获取代收消息。

本文中将通过接收代理机制转发的消息称为代收消息。

F3、被代理方处理器按照所述接收方代理规则配置信息将所述代收消息转发给代理方。例如，在由被代理方服务处理器执行接收代理操作时，当SIP消息到达被代理方服务处理器，该服务处理器即获取记录的相应用户的代理方地址，然后将消息转发给代理方。

为避免代收消息发生循环转发，即代理方将收到的代收消息又转发给自己的代理，被代理方处理器可在转发代发消息前执行防止循环的转发策略。当然，被代理方处理器也可按照从接收方代理规则中获取的代理方信息直接转发代发消息。本实施例中提供如下三种防止循环的转发策略：

策略一、仅代理转发一次。步骤包括：

Fa1、判断代收消息中是否包括转发属性头域(以下称为Delegation头域)，若是，则执行步骤Fa2；若否，则执行步骤Fa3。

Fa2、确定Delegation头域的值为否(no)，说明所述代收消息不再接受代理转发操作，不再进行代理转发操作，可返回一个错误消息。

Fa3、在代收消息中增加Delegation头域，并设置Delegation头域的值为no。这样代理方处理器若同样设置了接收代理，也不会再转发该代发消息了。

策略二、代理转发有限次。步骤包括：

Fb1、判断代收消息中是否包括Delegation头域，若是，则执行步骤Fb2；若否，则执行步骤Fb5。

Fb2、判断Delegation头域的值是否为no，若是，则执行步骤Fb3；若否，则执行步骤Fb4。

Fb3、不再进行代理转发操作，可返回一个错误消息。

Fb4、将Delegation头域的值减一，若原Delegation头域的值为一则将Delegation头域的值设置为no，说明所述代收消息已达到最大代理转发次数，不再接受代理转发操作。

Fb5、在代收消息中增加Delegation头域，并设置Delegation头域的值，假设为N，说明该代收消息最多可代理转发N+1次。

策略三、记录并判断代理转发地址。步骤包括：

Fc1、判断代收消息是否包括转发地址头域(以下称为Delegatee头域)，若是，则执行步骤Fc2；若否，则执行步骤Fc5。

Fc2、检查Delegatee头域中是否包括被代理方(即当前接收方)的标识，若是，说明转发循环，执行步骤Fc3；若否，则执行步骤Fc4。

Fc3、不再进行代理转发操作，可返回一个错误消息。

Fc4、将被代理方标识添加于Delegatee头域中。

Fc5、在代收消息中增加Delegatee头域，并将被代理方标识设置于Delegatee头域中。

本实施例中的被代理方处理器可以是被代理方用户处理器也可以是被代理方服务处理器。

本实施例在SIP层实现代理接收功能，使得代理接收机制与业务无关，能够广泛应用于不同的业务中，便于代理接收功能的复用和统一管理。

应当理解，实现本发明SIP消息的代理发送和代理接收方法的软件可以存储于计算机可读介质中。实现发送代理的一种软件在代理方处理器执行时，包括如下步骤：获取对被代理方的选择信息；生成代发消息，所述代发消息中包括代理属性头域，所述代理属性头域中包括被代理方的信息；将所述代发消息发送给接收方。相应的接收软件在接收方处理器执行时，包括如下步骤：获取代发消息，所述代发消息中包括代理属性头域；从所述代理属性头域中获取被代理方的信息；根据所述被代理方的信息对所述代发消息进行处理。

实现发送代理的另一种软件在代理方处理器执行时，包括如下步骤：获取对被代理方的选择信息；生成代发消息，所述代发消息中包括接收方标识和要求属性头域，所述要求属性头域中包括代理标签；将所述代发消息发送给被代理方。该软件在被代理方处理器执行时，包括如下步骤：根据所述要求属性头域中的代理标签，确定自身支持代理机制后，对所述代发消息进行处理；将处理后的代发消息发送给所述接收方标识指示的接收方。相应的接收软件在接收方处理器执行时，包括如下步骤：获取代发消息，所述代发消息中包括要求属性头域，所述要求属性头域中包括代理标签；根据所述要求属性头域中的代理标签，确定自身支持代理机制后，对所述代发消息进行处理。

实现接收代理的软件在被代理方处理器执行时，包括如下步骤：获取接收方代理规则配置信息；获取代收消息；按照所述接收方代理规则配置信息将所述代收消息转发给代理方。

所述的可读介质，如：ROM/RAM、磁碟、光盘等。

下面对本发明实施例的SIP处理器进行详细说明。

装置实施例一、一种SIP处理器10，如图7所示，包括：

选择获取单元11，用于获取对被代理方的选择信息。

消息生成单元12，用于生成代发消息，所述代发消息中包括代理属性头域，所述代理属性头域中包括选择获取单元11获取的被代理方的信息。根据实际要求，消息生成单元12还可在代发消息中放置原因属性头域和要求属性头域等。

代理发送单元13，用于将消息生成单元12生成的代发消息发送给接收方。

本实施例SIP处理器可作为代理方处理器执行方法实施例一。

装置实施例二、一种SIP处理器20，与装置实施例一的主要区别在于增加了与鉴权认证相关的逻辑结构，如图8所示，包括：

选择获取单元21，用于获取对被代理方的选择信息。

认证获取单元24，用于向被代理方发送认证请求，并接收所述被代理方处理器根据所述认证请求返回的认证信息。认证获取单元24的具体逻辑结构可包括：

原始消息单元241，用于生成原始代发消息；

认证请求单元242，用于生成认证请求消息，所述认证请求消息的消息体中包括原始消息单元241生成的原始代发消息或原始代发消息的片段；并向被代理方发送所述认证请求消息；

认证接收单元243，用于从被代理方返回的，对认证请求单元242发送的认证请求消息的成功响应消息中，获取认证信息。

消息生成单元22，用于生成代发消息，所述代发消息中包括认证获取单元24获取的认证信息和代理属性头域，所述代理属性头域中包括选择获取单元21获取的被代理方的信息。根据实际要求，消息生成单元22还可在代发消息中放置原因属性头域、要求属性头域等。消息生成单元22可以通过将认证接收单元243获取的认证信息添加到原始消息单元241生成的原始代发消息的消息体中，生成所述代发消息。

代理发送单元23，用于将消息生成单元22生成的代发消息发送给接收方。

上述选择获取单元21、消息生成单元22、代理发送单元23和认证获取单元24属于本实施例SIP处理器的UAC部分。本实施例SIP处理器还可包括与代理发送的鉴权认证相关的UAS部分，包括：

代理认证单元25，用于根据代理方发送的认证请求返回认证信息。代理认证单元25的具体逻辑结构可包括：

认证处理单元251，用于获取代理方发送的认证请求消息中包括的原始代发消息或原始代发消息的片段，根据自身的代理策略生成认证信息；

认证响应单元252，用于生成所述认证请求消息的成功响应消息，所述成功响应消息的消息体中包括认证处理单元251生成的认证信息；并向代理方发送所述成功响应消息。

为保证所获取的认证请求消息中包括设置有代理标签的要求属性头域时，代理认证单元25能正确识别和处理，本实施例SIP处理器的UAS部分还可包括：

支持判断单元26，用于在代理认证单元25对所述认证请求消息进行处理前，根据所述要求属性头域中的代理标签，确定本处理器支持代理机制。

需要说明的是，由于SIP消息中的要求属性头域属于现有规范，因此本实施例支持判断单元可以与现有SIP处理器中对要求属性头域进行支持判断的单元合并设置，即可通过扩展现有支持判断单元的功能来实现。

基于本实施例SIP处理器UAC部分的逻辑结构，其可作为代理方处理器执行方法实施例二；基于本实施例SIP处理器UAS部分的逻辑结构，其可作为被代理方处理器执行方法实施例二。

装置实施例三、一种SIP处理器30，如图9所示，包括：

代发接收单元31，用于获取代发消息，所述代发消息中包括代理属性头域。

代理分析单元32，用于从代发接收单元31收到的代发消息的代理属性头域中获取被代理方的信息。

消息处理单元33，用于根据代理分析单元32获取的被代理方的信息对所述代发消息进行处理。根据处理内容的具体设置，消息处理单元33可具有相应的具体逻辑结构，例如，可包括对代发消息进行鉴权的代理鉴权单元331。当然，消息处理单元还可包括对SIP消息执行通常处理流程的逻辑结构。

基于不同的条件，代理鉴权单元331可采用不同的鉴权方式，提供不同的功能：

其一、当预置有由被代理方配置的许可信息时，代理鉴权单元用于根据代理分析单元32获取的被代理方的信息以及预置的许可信息对所述代发消息进行鉴权，根据鉴权结果确定是否接受所述代发消息；

其二、当代发接收单元31获取的代发消息中包括被代理方的认证信息时，代理鉴权单元用于根据代理分析单元32获取的被代理方的信息对所述被代理方的认证信息进行验证，根据验证结果确定是否接受所述代发消息；

其三、当既没有预置的许可信息，代发消息中也不包括被代理方的认证信息时，代理鉴权单元331可采用如下逻辑结构(由于该结构为可选项之一，因此在图9中以虚线表示)：

鉴权请求单元3311，用于向被代理方发送鉴权请求消息，所述鉴权请求消息中包括代理方标识和/或所述代发消息，或者包括代理方标识和/或所述代发消息的片段；

鉴权处理单元3312，用于从被代理方返回的对鉴权请求单元3311发送的鉴权请求消息的应答消息中获取鉴权结果信息，根据所述鉴权结果信息确定是否接受所述代发消息。

为保证所获取的代发消息中包括设置有代理标签的要求属性头域时，代理分析单元32能正确识别和处理，本实施例SIP处理器还可包括：

支持判断单元34，用于在代理分析单元32对所述代发消息进行处理前，根据所述要求属性头域中的代理标签，确定本处理器支持代理机制。

此外，本实施例SIP处理器还可包括：

通知单元35，用于在代理分析单元32获取被代理方的信息之后，向被代理方发送通知消息，所述通知消息中包括所述代发消息的信息。

本实施例SIP处理器可作为接收方处理器执行方法实施例三。

需要说明的是，本实施例中描述的是SIP处理器作为消息接收方时的逻辑结构，本实施例SIP处理器可与装置实施例一和二中作为消息发送方的SIP处理器设置于同一设备中。当本实施例SIP处理器与装置实施例二中的SIP处理器设置于同一用户处理器或服务处理器时，支持判断单元34和支持判断单元26可合用，即本发明装置实施例中的支持判断单元可提供对收到的所有SIP消息中要求属性头域的代理标签的支持判断，而不区分消息类别。

装置实施例四、一种SIP处理器40，如图10所示，包括：

选择获取单元41，用于获取对被代理方的选择信息。

间接消息生成单元42，用于生成代发消息，所述代发消息中包括接收方标识和要求属性头域，所述要求属性头域中包括代理标签。

间接代理发送单元43，用于将间接消息生成单元42生成的代发消息发送给选择获取单元41确定的被代理方。

本实施例SIP处理器可作为代理方处理器执行方法实施例四。

装置实施例五、一种SIP处理器50，如图11所示，包括：

代理接收单元51，用于接收代理方发送的代发消息，所述代发消息中包括接收方标识和要求属性头域，所述要求属性头域中包括代理标签。

支持判断单元52，用于根据代理接收单元51收到的代发消息的要求属性头域中的代理标签，确定本处理器支持代理机制。

代发处理单元53，用于在支持判断单元52确定本处理器支持代理机制后，对所述代发消息进行处理。

代发发送单元54，用于将代发处理单元53处理后的代发消息发送给所述接收方标识指示的接收方。

为支持对代发消息的鉴权操作，本实施例SIP处理器还可包括：

代发鉴权单元55，用于在支持判断单元52确定本处理器支持代理机制后，在代发处理单元53对代发消息进行处理前，对所述代发消息进行鉴权，根据鉴权结果确定允许代发处理单元53对所述代发消息进行处理。

根据处理内容，代发处理单元53可选择包括如下逻辑结构：

标识修改单元531，用于将所述代发消息的请求资源标识修改为所述接收方标识；

标签删除单元532，用于删除所述代发消息的要求属性头域中的代理标签；

属性增加单元533，用于在所述代发消息中增加代理属性头域，所述代理属性头域中包括被代理方的信息；

认证增加单元534，用于在代发鉴权单元55对代发消息鉴权通过后，在所述代发消息中增加被代理方处理器的认证信息；

在代发处理单元53可选的上述四种逻辑结构中，若选择了属性增加单元533或认证增加单元534，则不同时选择标签删除单元532，因此在图11中标签删除单元532以虚线表示。

本实施例SIP处理器可作为被代理方处理器执行方法实施例四。本实施例SIP处理器可与装置实施例四中作为代理方的SIP处理器设置于同一设备中，分别支持该设备作为代理方或被代理方时的操作。

装置实施例六、一种SIP处理器60，如图12所示，包括：

代发接收单元61，用于获取代发消息，所述代发消息中包括要求属性头域，所述要求属性头域中包括代理标签。

支持判断单元62，用于根据代发接收单元61获取的代发消息的要求属性头域中的代理标签，确定本处理器支持代理机制。

消息处理单元63，用于在支持判断单元62确定本处理器支持代理机制后，对所述代发消息进行处理。

根据处理内容，消息处理单元63可选择包括如下逻辑结构：

属性获取单元631，用于当代发接收单元61获取的代发消息中包括代理属性头域时，从所述代理属性头域中获取被代理方的信息。

代理鉴权单元632，用于根据属性获取单元631获取的被代理方的信息对所述代发消息进行鉴权，根据鉴权结果确定是否接受所述代发消息。

本实施例SIP处理器可作为接收方处理器执行方法实施例五。

需要说明的是，本实施例中描述的是SIP处理器作为消息接收方时的逻辑结构，本实施例SIP处理器可与装置实施例四和五中的SIP处理器设置于同一设备中。当本实施例SIP处理器与装置实施例五中的SIP处理器设置于同一用户处理器或服务处理器时，支持判断单元62和支持判断单元52可合用。

装置实施例七、一种SIP处理器70，如图13所示，包括：

规则配置单元71，用于获取接收方代理规则配置信息。具体逻辑结构可包括：

注册消息单元711，用于获取注册消息，所述注册消息中包括联系属性头域，所述联系属性头域中包括用代理标签标记的代理方标识；

规则记录单元712，用于根据注册消息单元711获取的注册消息，记录所述用代理标签标记的代理方标识作为所述接收方代理规则配置信息。

代收接收单元72，用于获取代收消息。

代收转发单元73，用于按照所述接收方代理规则配置信息将代收接收单元72获取的代收消息转发给代理方。

为避免接收代理操作的循环转发，本实施例SIP处理器还可包括执行防止循环的转发策略的代收处理单元74，根据不同的转发策略，代收处理单元74可提供不同的功能：

其一、用于在代收转发单元73转发代收接收单元72获取的代收消息之前，确定所述代收消息中不包括转发属性头域，并在所述代收消息中增加转发属性头域，并设置所述转发属性头域的值为否，标识所述代收消息不再接受代理转发操作。

其二、用于在代收转发单元73转发代收接收单元72获取的代收消息之前，判断所述代收消息是否包括转发属性头域，

若是则确定所述转发属性头域的值不为否；将所述转发属性头域的值减一，若原转发属性头域的值为一则将所述转发属性头域的值设置为否，标识所述代收消息不再接受代理转发操作，

若否则在所述代收消息中增加转发属性头域，并设置所述转发属性头域的值。

其三、用于在代收转发单元73转发代收接收单元72获取的代收消息之前，判断所述代收消息是否包括转发地址头域，

若是则确定所述转发地址头域中不包括所述被代理方的标识，并将被代理方标识添加于所述转发地址头域中，

若否则在所述代收消息中增加转发地址头域，并将被代理方标识设置于所述转发地址头域中。

本实施例SIP处理器可作为被代理方处理器执行方法实施例六。

为更好的理解本发明实施例，下面以实际的应用场景为例，说明方法实施例二和三，以及方法实施例四和五，在具体SIP消息收发过程中的应用。

示例一、INVITE方法的消息的直接发送代理和接收(对应方法实施例二和三)。

场景假设：Alice要代理Bob与David通话。即代理方为Alice，被代理方为Bob，接收方为David。Bob所在域的服务处理器提供代理服务功能，设置了允许Alice代理自己与David通话的权限。Alice与David通话前设置了此次通话是代理Bob的。

本示例的消息流程如图14所示，包括：

1、Alice选择被代理者Bob，向Bob发送认证请求。本示例中以MESSAGE消息实现认证请求消息。构造认证请求消息的过程如下：

①构造原始代发消息，内容如下：

上述原始代发消息中除Delegator头域外，其他部分采用普通INVITE消息的结构。其中第一行包括三部分，“INVITE”为消息的方法名，“sip:davidbiloxi.com”为Request-URI，“SIP/2.0”为协议版本号。第一行后面为多个头域：

Via头域记录本消息的发送路径，消息每经过一跳，就添加一个Via头域来指示经过的地址，branch参数为当前事务的标识符；

Max-Forwards头域限制消息传送的跳数，它包含一个整数，在每一跳这个整数都会被减少；

To头域指示消息发送的目标，包含一个显示名“Bob”和一个地址；

From头域指示消息的发起人，也包含一个显示名“Alice”和一个地址，这个头域还包含了一个用于鉴别的tag参数；

Call-ID头域包含一个全局唯一标识符来标识这次呼叫；

Cseq头域包含一个整数和一个方法名，当前会话中每一个新的请求都会增加这个整数的值，保证这个数值是有序的；

Contact头域指示对方将来请求的发送地址；

Content-Type头域描述消息体的类型，在这个例子里消息体采用了会话描述协议(SDP：Session Description Protocol)描述，但是消息体内容没有给出(Alice′s SDP not shown)；

Content-Length头域指出了消息体的字节数。

以下示例中给出的消息内容可参照上述说明，不再赘述。

在原始代发消息中Request-URI为最终消息接收方David的SIP地址。To头域的值为最终消息接收方David的SIP地址。From头域的值为代理方Alice的SIP地址。Delegator头域的值为被代理者Bob的SIP地址，这个值是由Alice在发起呼叫前设置的。

②构造认证请求消息，内容如下：

上述认证请求消息的方法名为“MESSAGE”。Require头域的值设置为：delegation，表示需要被代理方支持代理机制。Content-Type头域设置为：application/sipfrag，将前述构造的原始代发消息的片段，包括第一行和与鉴权相关的头域放在MESSAGE消息体中，本例选择From头域，和To头域。

③Alice的用户处理器向Bob发送上述MESSAGE消息。

2、Bob的服务处理器支持代理机制，根据Bob所设置的规则，同意Alice的请求，将认证信息放在对上述MESSAGE消息的成功响应消息(200OK)中返回给Alice。Bob返回的成功响应消息内容如下：

上述成功响应消息的Content-Type头域的值为multipart/signed类型，消息体中包含对原始代发消息片断的认证信息，认证信息包括从“Content-Type”头域行到最后一行“boundary42”的部分。

3、Alice的用户处理器从上述成功响应消息中提取认证信息部分，构造代发消息，内容如下：

在构造上述代发消息时，Alice的用户处理器将之前构造的原始代发消息的Content-Type值设置为MIME类型：multipart/mixed。消息体中包含两种MIME类型：第一种是原始代发消息中的Content-Type类型，其内容为原始代发消息的消息体；第二种是multipart/signed类型，其内容是步骤2中成功响应消息的消息体，即认证信息部分。

4、Alice的用户处理器将最终生成的INVITE请求发送给David。

5、David的用户处理器接收INVITE请求，根据包含的被代理者的标识及其认证信息进行鉴权，验证认证信息有效。

6、David的用户处理器开始振铃，同时返回一个临时响应消息(未在图14中画出)。并且David的用户处理器的用户界面上除了显示主叫方Alice外，还显示被代理方Bob。David认识Bob，看到Alice是代理Bob发起呼叫的，因此接起电话，David的用户处理器返回最终的成功响应消息(200OK)。

7、Alice的用户处理器发送ACK方法的消息，开始通话。

示例二、MESSAGE方法的消息的直接发送代理和接收(对应方法实施例二和三)。

场景假设：Alice要代理Bob发送消息给David。即代理方为Alice，被代理方为Bob，接收方为David。Bob所在域的服务处理器提供代理服务功能，设置了允许Alice代理自己发送消息给David的权限。

本示例的消息流程如图15所示，包括：

1、Alice选择被代理者Bob，向Bob发送认证请求。本示例中以MESSAGE消息实现认证请求消息。构造认证请求消息的过程如下：

①构造原始代发消息，内容如下：

上述原始代发消息中Request-URI为最终消息接收方David的SIP地址。To头域的值为最终消息接收方David的SIP地址。From头域的值为代理方Alice的SIP地址。Delegator头域的值为被代理者Bob的SIP地址。

②构造认证请求消息，内容如下：

上述认证请求消息的Content-Type头域设置为：message/sip，将前述构造的原始代发消息放在MESSAGE消息体中。

③Alice的用户处理器向Bob发送上述MESSAGE消息。

2、Bob的服务处理器将认证信息放在对上述MESSAGE消息的成功响应消息(200OK)中返回给Alice。Bob返回的成功响应消息内容如下：

上述成功响应消息的Content-Type头域的值为multipart/signed类型，消息体中包含对原始代发消息片断的认证信息，认证信息包括从“Content-Type”头域行到最后一行“boundary42”的部分。

3、Alice的用户处理器从上述成功响应消息中提取认证信息部分，构造代发消息，内容如下：

在构造上述代发消息时，Alice的用户处理器将之前构造的原始代发消息的Content-Type值设置为MIME类型：multipart/mixed。消息体中包含两种MIME类型：第一种是原始代发消息中的Content-Type类型，其内容为原始代发消息的消息体；第二种是multipart/signed类型，其内容是步骤2中成功响应消息的消息体，即认证信息部分。

4、Alice的用户处理器将最终生成的MESSAGE消息发送给David。

5、David的用户处理器接收MESSAGE消息，根据包含的被代理者的标识及其认证信息进行鉴权，验证认证信息有效。

6、David的用户处理器返回成功响应消息(200OK)。

示例三、INVITE方法的消息的间接发送代理和接收(对应方法实施例四和五)。

场景假设：Alice要代理Bob与David通话。即代理方为Alice，被代理方为Bob，接收方为David。Bob所在域的服务处理器提供代理服务功能，设置了允许Alice代理自己与David通话的权限。Alice与David通话前设置了此次通话是代理Bob的。

本示例的消息流程如图16所示，包括：

1、Alice选择被代理者Bob，向Bob发送代发消息，内容如下：

上述代发消息中Request-URI为被代理方Bob的SIP地址。To头域的值为最终消息接收方David的SIP地址。From头域的值为代理方Alice的SIP地址。Require头域包含delegation标签。

2、Bob的服务处理器收到INVITE请求，查看Require头域包含delegation标签，表示需要代理机制，于是根据Bob的设置对Alice发来的请求进行鉴权，鉴权通过后，Bob的服务处理器将自己的签名信息添加到上述消息中。并修改Request-URI值为David的SIP地址。处理后的INVITE请求内容如下：

3、Bob的服务处理器将修改后的INVITE请求转发给David。

4、David的用户处理器接收INVITE请求，对Bob的服务处理器的签名信息进行验证，验证签名有效，处理请求，按照INVITE请求中Via头域的指示返回成功响应消息(200OK)，内容如下：

5、Bob的服务处理器将David的成功响应消息转发给Alice。

通过上述实施例可以看出，本发明实施例采用在SIP消息中扩展设置与代理相关的头域或头域参数，由SIP处理器根据这些扩展的头域或头域参数进行相应处理来实现SIP层代理功能的方法。由于在SIP层实现代理功能，使得代理机制与业务无关，能够广泛应用于不同的业务中，便于代理功能的复用和统一管理。

以上对本发明实施例所提供的SIP消息的收发代理方法、对通过SIP消息的发送代理方法发送的代发消息的接收方法、相应的各种SIP处理器进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (15)

1.一种会话初始协议消息的发送代理方法，其特征在于，包括：

代理方处理器获取对被代理方的选择信息，所述处理器为用户代理UA或会话初始化协议SIP服务器，或者为UA和SIP服务器；

代理方处理器生成原始代发消息；

代理方处理器生成认证请求消息，所述认证请求消息的消息体中包括所述原始代发消息或原始代发消息的片段；

代理方处理器向被代理方发送所述认证请求消息；

代理方处理器接收被代理方处理器根据所述认证请求返回的认证信息；

代理方处理器通过将所述认证信息添加到所述原始代发消息的消息体中生成代发消息，所述代发消息中还包括代理属性头域，所述代理属性头域中包括被代理方的信息；

代理方处理器将所述代发消息发送给接收方。

2.根据权利要求1所述的发送代理方法，其特征在于，所述被代理方处理器根据认证请求返回认证信息包括：

被代理方处理器获取所述认证请求消息中包括的原始代发消息或原始代发消息的片段，根据自身的代理策略生成认证信息；

被代理方处理器生成所述认证请求消息的成功响应消息，所述成功响应消息的消息体中包括所述认证信息；

被代理方处理器向代理方发送所述成功响应消息。

3.根据权利要求2所述的发送代理方法，其特征在于，所述代理方处理器在生成认证请求消息时，还在所述认证请求消息的要求属性头域中设置代理标签；

所述被代理方处理器在获取认证请求消息中包括的原始代发消息或原始代发消息的片段之前，先根据所述要求属性头域中的代理标签，确定自身支持代理机制。

4.根据权利要求1～3任意一项所述的发送代理方法，其特征在于，所述代理方处理器生成代发消息时，还在所述代发消息中设置原因属性头域，所述原因属性头域中包括代理的原因。

5.根据权利要求1～3任意一项所述的发送代理方法，其特征在于，所述代理方处理器生成代发消息时，还在所述代发消息的要求属性头域中设置代理标签，所述要求属性头域中的代理标签指示处理本消息的网元需要支持代理机制。

6.一种会话初始协议代发消息的接收方法，其特征在于，包括：

接收方处理器获取代发消息，所述代发消息中包括被代理方的认证信息和代理属性头域，所述处理器为用户代理UA或会话初始化协议SIP服务器，或者为UA和SIP服务器；

接收方处理器从所述代理属性头域中获取被代理方的信息；

接收方处理器根据所述被代理方的信息对所述被代理方的认证信息进行验证，根据验证结果确定是否接受所述代发消息。

7.根据权利要求6所述的接收方法，其特征在于，所述接收方处理器从代理属性头域中获取被代理方的信息的步骤之后还包括：

接收方处理器向被代理方发送通知消息，所述通知消息中包括所述代发消息的信息。

8.根据权利要求6或7所述的接收方法，其特征在于，所述代发消息中包括要求属性头域，所述要求属性头域中包括代理标签；

所述接收方处理器在从代理属性头域中获取被代理方的信息之前，先根据所述要求属性头域中的代理标签，确定自身支持代理机制。

9.一种会话初始协议处理器，所述处理器为用户代理UA或会话初始化协议SIP服务器，或者为UA和SIP服务器，其特征在于，包括：

选择获取单元，用于获取对被代理方的选择信息；

认证获取单元，用于向被代理方发送认证请求，并接收被代理方处理器根据所述认证请求返回的认证信息；

所述认证获取单元包括：原始消息单元，用于生成原始代发消息；认证请求单元，用于生成认证请求消息并向被代理方发送所述认证请求消息，所述认证请求消息的消息体中包括所述原始代发消息或原始代发消息的片段；认证接收单元，用于从被代理方返回的对所述认证请求消息的成功响应消息中获取认证信息；

消息生成单元，用于通过将所述认证信息添加到所述原始代发消息的消息体中生成代发消息，所述代发消息中还包括代理属性头域，所述代理属性头域中包括被代理方的信息；

代理发送单元，用于将所述代发消息发送给接收方。

10.根据权利要求9所述的会话初始协议处理器，其特征在于，进一步包括：

代理认证单元，用于根据代理方发送的认证请求返回认证信息。

11.根据权利要求10所述的会话初始协议处理器，其特征在于，所述代理认证单元进一步包括：

认证处理单元，用于获取代理方发送的认证请求消息中包括的原始代发消息或原始代发消息的片段，根据自身的代理策略生成认证信息；

认证响应单元，用于生成所述认证请求消息的成功响应消息，所述成功响应消息的消息体中包括所述认证信息；并向代理方发送所述成功响应消息。

12.根据权利要求11所述的会话初始协议处理器，其特征在于，所述代理认证单元获取的认证请求消息中包括要求属性头域，所述要求属性头域中设置有代理标签，

所述处理器进一步包括：支持判断单元，用于在所述代理认证单元对所述认证请求消息进行处理前，根据所述要求属性头域中的代理标签，确定本处理器支持代理机制。

13.一种会话初始协议处理器，所述处理器为用户代理UA或会话初始化协议SIP服务器，或者为UA和SIP服务器，其特征在于，包括：

代发接收单元，用于获取代发消息，所述代发消息中包括被代理方的认证信息和代理属性头域；

代理分析单元，用于从所述代理属性头域中获取被代理方的信息；

消息处理单元，用于根据所述被代理方的信息对所述代发消息进行处理；

所述消息处理单元包括：

代理鉴权单元，用于根据所述被代理方的信息对所述被代理方的认证信息进行验证，根据验证结果确定是否接受所述代发消息。

14.根据权利要求13所述的会话初始协议处理器，其特征在于，进一步包括：

通知单元，用于在所述代理分析单元获取被代理方的信息之后，向被代理方发送通知消息，所述通知消息中包括所述代发消息的信息。

15.根据权利要求13或14所述的会话初始协议处理器，其特征在于，所述代发接收单元获取的代发消息中包括要求属性头域，所述要求属性头域中包括代理标签，

所述处理器进一步包括：支持判断单元，用于在所述代理分析单元对所述代发消息进行处理前，根据所述要求属性头域中的代理标签，确定本处理器支持代理机制。

Images