专利名称：背靠背用户代理及其传输信息的方法
技术领域：
本发明涉及通信领域，特别是IP多媒体子系统(IMS, IP Multimedia Subsystem )。
背景技术：
在IMS网络中，许多SIP消息是由用户代理(UA， User Agent)传递的。 由于用户代理的能力(capability)和特征(characteristics)参差不齐，当在 一些对话建立和业务开展过程中，中间网元和/或对端用户代理，了解其他 用户代理的能力信息是至关重要的。RFC 3840定义了一种在SIP消息的 Contact头域的参数中携带用户代理的能力和特征信息的方法，这样用户发起 注册或对话时就可以在Contact头域中将自己的能力和特征信息通知给中间 网元和/或对端用户代理，作为中间网元和对端用户代理处理该对话的 一个 重要参考。如，在会议建立过程中，当会议中心邀请用户加入会议时，可以通过 Contact头域中的isfocus参数让终端感知到当前对话的对端是会议中心，从而 可以指导用户针对会议进行相关操作，如订阅会议状态。RFC 3840所定义的 通过Contact来携带终端的能力和特征信息的方法，在信令路径中都是Proxy 的情况下可以操作的很好；但是，如果信令路径中存在背靠背用户代理 (B2BUA， Back to Back User Agent)的话，由于背靠背用户代理在转发Invite 消息的同时会修改消息的Contact头域，因此发起端UA的能力和特征信息将 在B2BUA处被修改，而无法传递到后续的网元和/或接收对话的UA。请参阅图l,为现有技术中的会议申请流程示意图。步骤S1:用户发出INVITE请求，其中携带有sip: Conf-Factory，表示 申请会议。
步骤S2:用户代理1接到该INVITE请求将其转发。步骤S3:背靠背用户代理接到该INVITE请求将其转发。步骤S4:用户代理2接到该INVITE请求将其转发至会议中心。步骤S5:会议中心接到该INVITE请求后，返回200 OK响应，并在Contact头域中携带Conf-ID及isfocus参数。步骤S6:用户代理2接到该200 OK响应后，将其转发给背靠背用户代理。步骤S7:背靠背用户代理接到该200OK响应后，将Contact头域修改 为背靠背用户代理的地址(Contact: B2BUA),然后转发给用户代理l。 步骤S8:用户代理l接到该200OK响应后，将其转发给用户。 由于背靠背用户代理将Contact头域修改为背靠背用户代理的地址，导 致Contact头域中原来携带Conf-ID及isfocus参数丟失，使得用户无法依据 携带Conf-ID及isfocus参数获知会议中心的地址，进而无法进行会议相关 的操作，从而影响会议业务的提供。发明内容为解决现有技术中，背靠背用户代理影响会议业务的问题，本发明提供 一种传输用户代理的信息的方法。本发明还提供一种背靠背用户代理。一种背靠背用户代理传输信息的方法，其包括如下步骤收到对话建立 请求消息或对话建立响应消息的时，保留消息中原有的Contact头域，在转发 消息中添加Record-Route头域，携带背靠背用户代理自身地址。一种背靠背用户代理，其包括接收单元、Record-Route处理单元及发送 单元，该接收单元用于接收对话建立请求消息或对话建立响应消息；该 Record-Route处理单元用于在所述消息中添加Record-Route头域，内容为该
背靠背用户代理的地址；该发送单元用于发送该Record-Route处理单元处理 过的消息。上述背靠背用户代理的通过Record-Route头域携带路由地址，而不是修 改Contact头域，使得会议中心在Contact头域中携带的Conf-ID及isfocus 参数传输到用户，用户就可以根据Conf-ID及isfocus参数进行电话会议的 其他相关操作了，从而保证了会议业务的正常开展。
图1为现有技术中的会议申请流程示意图。 图2为本发明第一实施方式会i义申请流程的示意图。 图3为本发明第一实施方式背靠背用户代理的示意图。 图4为本发明第二实施方式对话流程的示意图。
具体实施方式
请参阅图2，为本发明第一实施方式会议申请流程的示意图。由于背靠 背用户代理在一次对话过程中关联了两个对话，需要对这两个对话分别维护 一个路由集，且这两个路由集是相互独立，因此背靠背用户代理在收到对话 建立请求消息时，取出对话建立请求消息中的所有的Record-Route保存，作 为对话建立请求方的路由集。背靠背用户代理在转发该请求消息时，先去掉 收到的请求中所有的Record-Route,同时为了不修改原请求消息中Contact头 域又要保证UAS后续的请求能够正确的路由到自己，背靠背用户代理在转发 的请求消息时添加Record-Route头域，携带该背靠背用户代理的地址。背靠背用户代理在收到对话建立请求的响应消息时，取出该响应消息中的所有的Record-Route并去掉最后一个Record-Route，然后保存，作为到对 话建立响应方的路由集。在转发对话建立请求的响应消息时，为了不修改原响应消息中Contact 头域又要保证UAC后续的请求能够正确的路由到自己，背靠背用户代理在响
应消息中添加Record-Route头域，内容为自己的地址。步骤l:用户A发出INVITE请求，其中携带有sip: Conf-Factory，表示申请会议。步骤2:用户代理1接到该INVITE请求后，在该INVITE请求中添加 Record-Route头域，内容为用户代理l的地址，然后将其转发。步骤3:背靠背用户代理接到该INVITE请求后，为了后续请求消息能 够路由至用户A,背靠背用户代理通过获取请求消息中的Record-Route列表 并保存，作为到用户A的路由集，还需去掉收到的请求中所有的 Record-Route ，然后在该INVITE请求中添加Record-Route头域，内容为背 靠背用户代理的地址，然后将其转发。步骤4:用户代理2接到该INVITE请求后，在该INVITE请求中添加 Record-Route头域，内容为用户代理2的地址(Record-Route: Proxy2 )，然 后将其转发给会议中心。步骤5:会议中心接到该INVITE请求后，在Contact头域中携带Conf-ID 及isfocus参数，然后携带Record-Route返回200 OK响应。步骤6:用户代理2接到该200OK响应后，将其转发给背靠背用户代理。步骤7:背靠背用户代理接到该200OK响应后，背靠背用户代理可通 过获取200 OK响应消息中的Record-Route列表，并去掉Record-Route列表 中最后一个URI (因为最后一个URI是背靠背用户代理自己的地址，无需保 存)，然后保存修改后Record-Route列表，作为到会议中心路由集；还需去 掉收到的响应消息中所有的Record-Route ,然后在响应消息中添加 Record-Route头域，内容为自己的地址；另外，在步骤3中，背靠背用户代 理已获得到用户A的路由集，此时背靠背用户代理去掉收到的响应消息中 所有的Record-Route后，在响应消息中添加步骤3保存的用户A的 Record-Route列表，然后在Record-Route列表顶部添加 一条Record-Route ，
内容为背靠背用户代理(B2BUA)的地址，然后将其转发给用户代理1。步骤8:用户代理l接到该200 OK响应后，将其转发给用户A，使得 用户A可以获得会议中心在Contact头域中携带的Conf-ID及isfocus参数， 并进行会议的后续操作。由于背靠背用户代理的路由地址皆保存在Record-Route头域，而不是修 改Contact头域，既保证后续请求的正确路由，又保障Contact头域中信息的 端到端传输，使得会议中心在Contact头域中携带的Conf-ID及isfocus参数 传输到用户A，用户A就可以根据Conf-ID及isfocus参数进行电话会议的 其他相关操作了，从而保证了会议业务的正常开展。上述实施方式不局限于电话会议的对话，还可用于其他形式的对话，如 用户之间的对话或用户代理之间的对话等。请参阅图3，为本发明第一实施方式背靠背用户代理的示意图。该背靠背 用户代理单元10包括接收单元2、 Record-Route处理单元5、存储单元8 及发送单元9，该接收单元2用于接收消息；该Record-Route处理单元5用 于去掉收到的消息中所有的Record-Route,然后在收到的消息中添加 Record-Route头域，内容为背靠背用户代理单元自己的地址。该Record-Route 处理单元5还用于获取请求消息的Record-Route列表作为该请求消息的请求 方的路由集；及获取响应消息的Record-Route列表，并去掉列表中的最后一 个URI(因为最后一个URI是背靠背用户代理自己的地址，无需保存)，作为 该响应消息发送方的路由集；该存储单元8用于保存该Record-Route处理单 元5获取或处理的Record-Route列表；该发送单元9用于将Record-Route 处理单元处理过的消息发送出去。请参阅图4，为本发明第二实施方式对话流程的示意图。该对话流程为 两个用户之间的对话流程。步骤01:用户A发出INVITE请求，并通过contact头域携带用户A的 能力信息(contact: A)。
步骤02:用户代理1接到该INVITE请求后，在该INVITE请求中添加 Record-Route头域，内容为用户代理1 ( proxyl )的地址，然后将其转发。步骤03:背靠背用户代理接到该INVITE请求后，为了后续请求消息能 够路由至用户A，背靠背用户代理通过获取请求消息中的Record-Route列表 并保存，作为到用户A的路由集；还需去掉收到的请求中所有的 Record-Route,然后在该INVITE请求中添加Record-Route头域，内容为背 靠背用户代理(B2BUA)的地址，然后将其转发。步骤04:用户代理2接到该INVITE请求后，在该INVITE请求中添加 Record-Route头域，内容为用户代理2 ( Proxy2 )的地址，然后将其转发给 用户B。步骤05:用户B接到该INVITE请求后，通过Contact头域中携带用户 A的能力信息获知用户A的能力，然后返回200 OK响应，并通过Contact 头域中携带用户B的能力信息(contact: B),并携带请求消息中 Record-Route 。步骤06:用户代理2接到该200 OK响应后，根据其中的Record-Route 将其转发给背靠背用户代理。步骤07:背靠背用户代理接到该200 OK响应后，背靠背用户代理可 通过获取200 OK响应消息中的Record-Route列表，并去掉Record-Route列 表中最后一个URI (因为最后一个URI是背靠背用户代理自己的地址，无需 保存)，然后保存修改后Record-Route列表，作为到用户B的路由集；还需 去掉收到的响应消息中所有的Record-Route,然后在响应消息中添加 Record-Route头域，内容为自己的地址；另外，在步骤03中，背靠背用户 代理已荻得到用户A的路由集，此时背靠背用户代理去掉收到的响应消息 中所有的Record-Route后，在响应消息中添加步骤03保存的用户A的 Record-Route列表，然后在Record-Route列表顶部添力口一条Record-Route， 内容为背靠背用户代理(B2BUA)的地址，然后将其转发给用户代理1。
步骤08:用户代理1接到该200 OK响应后，将其转发给用户A，使 得用户A可以获得用户B的能力信息，并进行后续操作。步骤09:用户A发送ACK消息，其中Requst-URI为用户B的地址， Route为Proxy 1和B2BUA。步骤010:用户代理1收到ACK消息后，将其转发至B2BUA，其中 Requst-URI为用户B的地址，Route为B2BUA。步骤Oil: B2BUA收到ACK消息后，ACK消息中的Route为背靠背 用户代理的地址，删除Route; ACK消息的Request-URI为用户B的地址； B2BUA需要在转发的ACK消息中添加到用户B的路由集，然后转发至用 户B， Route为Proxy2。步骤012:用户代理2收到ACK消息后，将其转发至用户B，其中 Requst-URI为用户B的地址。步骤013:用户B发送Bye消息，其中Requst-URI为用户A的地址， Route为Proxy2和B2BUA。步骤014:用户代理2收到Bye消息后，将其转发至B2BUA，其中 Requst-URI为用户A的地址，Route为B2BUA。步骤015: B2BUA收到Bye消息后，由于Bye消息中的Route为背靠 背用户代理的地址，则删除Route，由于Bye消息的Request-URI为用户A 的地址；B2BUA需要在转发的Bye消息中添加到用户A的路由集，然后转 发至用户A， Route为Proxyl。步骤016:用户代理1收到Bye消息后，将其转发至用户A,其中 Requst-URI为用户A的地址。步骤017-020:用户A经由用户代理1、 B2BUA及用户代理2向用户B 返回2000K响应消 息。B2BUA在对话建立后，还可以向对话的两端发送对话内的请求消息， 如relnvite、 Bye等，在构造请求消息的Contact头域时，可以填B2BUA自
己的地址，也可以填写接收方的对端的Contact地址，如给用户B发relnvite 或Bye时，Contact中填用户A的地址，但由于relnvite消息会刷新远端目 标地址(remote target URI),因此建议发送relnvite时填写接收方对端的 Contact信息。由于背靠背用户代理的路由地址皆保存在Record-Route头域，而不是修 改Contact头域，既保证后续请求的正确路由，又保障Contact头域中信息的端 到端传输，使得两个用户在对话的过程中可以通过Contact头域携带的能力 信息，用户获知对端能力信息带来方便。上述方法或装置不限于传输能力信息，还可以传输通过通过Contact头域携带的其他信息。以上所述，仅为本发明较佳的具体实施方式
，但本发明的保护范围并不局 限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易 想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护 范围应该以权利要求的保护范围为准。
权利要求
1. 一种背靠背用户代理传输信息的方法，其包括如下步骤收到对话建立请求消息或对话建立响应消息的时，保留消息中原有的Contact头域，在转发消息中添加Record-Route头域，携带背靠背用户代理自身地址。
2. 如权利要求1所述的方法，其特征在于进一步包括，当收到对话 建立请求消息时，保存对话建立请求消息的Record-Route列表，作为到对话 建立请求方的路由集。
3. 如权利要求1所述的方法，其特征在于进一步包括，当收到对话 建立响应消息时，获取对话建立响应消息中的Record-Route列表，去掉其中 的最后 一个Record-Route后保存，作为到对话建立响应方的路由集。
4. 如权利要求1所述的方法，其特征在于进一步包括，收到对话中 请求消息时，当对话中请求消息的Route为背靠背用户代理的地址时，则删 除Route,在消息中添加到对话中请求消息的Requst-URI中地址的路由集并 转发。
5. 如权利要求1至4任意一项所述的方法，其特征在于进一步包括， 如果转发消息中有Record-Route,则去掉转发消息中的Record-Route。
6. —种背靠背用户代理，其特征在于，包括接收单元、Record-Route 处理单元及发送单元，该接收单元用于接收对话建立请求消息或对话建立响 应消息；该Record-Route处理单元用于在所述消息中添加Record-Route头 域，内容为该背靠背用户代理的地址；该发送单元用于发送该Record-Route 处理单元处理过的消息。
7. 如;K利要求6所述的背靠背用户代理，其特征在于该Record-Route 处理单元用于获取收到的消息中的Record-Route,当收到的消息为对话建立 请求消息时，获取该对话建立请求消息的Record-Route列表作为到对话建立 请求方的路由集；当收到的消息为对话建立请求的响应消息时，去掉该响应消息的Record-Route列表中的最后一个Record-Route,作为到该对话建立响 应方的^各由集。
8. 如权利要求7所述的背靠背用户代理，其特征在于其进一步包括 一存储单元，用于保存该Record-Route处理单元获取的Record-Route列表。
9. 如权利要求6至8任意一项所述的背靠背用户代理，其特征在于 该Record-Route处理单元还用于去掉所述消息中的Record-Route。
全文摘要
本发明提供一种背靠背用户代理传输信息的方法，其包括如下步骤收到消息时，保留消息中原有的Contact头域，在转发消息中通过添加Record-Route头域，内容为背靠背用户代理自身地址，以保证后续请求的正确路由，同时保障Contact头域中信息的端到端传输。本发明还提供一种背靠背用户代理。该方法通过Record-Route来保证后续请求能够正确路由到B2BUA，而不是修改Contact头域，使得能力信息可以通过Contact头域携带，从而保证了会议业务的正常开展。
文档编号H04L12/58GK101212418SQ20061006376
公开日2008年7月2日 申请日期2006年12月31日 优先权日2006年12月31日
发明者楷 文, 杨开封, 蒋群兵, 超 陈 申请人:华为技术有限公司