专利名称：一种在sip协议中请求业务修改的方法、网络系统及装置的制作方法
技术领域：
本发明涉及SIP领域，特别是涉及一种在SIP协议中请求业务修改的方法、
网络系统及装置。
背景技术：
会话初始协议(Session Initiation Protocol, SIP )是一个应用层的控制协议， 可以用来建立、修改和终止多i某体会话(或会议)，例如实现Internet电话。 SIP协议也支持邀请参与者参加已经存在的会话，比如在多方会议中的应用。
在SIP协议中使用Dialog ID (对话标识)来标识用于一个Dialog (对话) 内消息的路由。Dialog ID包含进行通信的两个UA (用户代理)的target (目的 信息)、Route Set (路由集)及Call ID (呼叫标识)等。其中，对于每个UA 而言自己发布的目标信息称为Local Target (本端目标)，对端发布的目标信 息称为remote target (远端目标)；Route Set用于指一个对话内的请求需要由 哪些状态代理服务器(Statefiil Proxy)等中间实体进行转发；UAC (用户代理 客户端)在生成一个对话内的请求消息时，需要将Remote Target作为请求消 息的RequestURI (请求统一资源标识，RURI)，将Route Set填写到请求消息 的Route头域，并且根据协议规定填写其他头域(如CallID、 CSeq等)以及根 据应用填写其他消息头域以及消息体(Body)等部分信息。如果下一跳支持 松散路由，那么直接将生成的请求消息发送到下一跳；如果下一跳不支持松 散路由，那么UAC需要将RURI移到Route头域末尾作为最后一条URI，并且将 第一个RouteURI移到RURI,然后将消息发送出去。当请求消息最终到达UAS (用户代理服务端)时，RURI应该是UAS发布的Local Target (对于UAC来讲 则是Remote Target)。从这个处理过程可以看出UAC在发送一个对话内的请
求时无法修改Remote Target。同时目前还没有能够实现通过对话内的请求消 息来请求新的业务的协议相关技术。
网络电视(IP Television, IPTV)是一种利用宽带有线电视网，集互联网 多媒体、通讯等多种技术于一体，向家庭用户提供包括数字电视在内的多种 交互式业务的技术。
目前，许多标准组织在研究IPTV。如图l所示，是现有的标准组织ETSI TISPAN所定义的IMS based IPTV (基于IP多媒体子系统的IPTV )的业务功能 架构。
其中，业务控制功能(IPTV Service Control Function, SCF)为用户业务 的访问进行控制，媒体功能(IPTV Media Functions, MF )负责为用户终端(UE ) 提供媒体流的控制与交付(Delivery)。可分为媒体控制功能(IPTV Media Control Functions, MCF)和々某体交付功能(IPTV Media Delivery Functions, MDF)。媒体交付功能通常是一些媒体服务器，在媒体控制功能的控制下向 用户终端传送用户需要的媒体流。媒体控制功能还能接收和处理用户的播放 控制操作，例如媒体的快进、后退、暂停、定位等操作，这种操作通常使用 实时流协议(Real Time Streaming Protocol, RTSP)来实现。
在用户访问BC业务过程中如果用户请求新的BC业务(即BC业务切换， 如LTV业务中用户请求进行频道切换)或者BC业务包(即BC业务的集合)； 但是，根据现有的SIP协议，被请求对象的信息需要在请求消息的RURI中携带， 而根据对话内请求消息的生成方法，RURI必须是对话建立时或者修改过程中 远端UA发布的远端目标正在进行的LTV会话进行修改。因此采用现有的SIP 协议不能在访问BC业务过程中请求新的业务。
故，在一些特定的业务应用(如IPTV)中需要SIP协议能够请求新的业务 以便对业务过程进行控制，实现特定的业务功能。但是现有目前SIP协议无法 提供请求新的业务的能力。
发明内容
有鉴于此，本发明实施例所要解决的技术问题在于，提供一种在SIP协议
中请求业务修改的方法、网络系统及装置。
为解决上述4支术问题，本发明实施例的一种在SIP协议中请求业务修改 的方法，包括如下步骤
第一用户代理与第二用户代理建立对话并进行业务传输；
第一用户代理请求业务修改，将携带有所请求的新业务的目标业务标识 的请求消息路由至第二用户代理；
第 一用户代理收到来自第二用户代理的确定响应后，与第二用户代理之 间进行新业务的传输。
相应的，本发明实施例的一种在SIP协议中请求业务修改的网络系统， 至少包括第一用户代理及第二用户代理，其中，
所述第一用户代理，用于在需要请求业务修改时，将携带有所请求的新 业务的目标业务标识的请求消息路由至第二用户代理；
所述第二用户代理，用于根据所述目标业务标识，为所述第一用户代理 提供所述新业务，或使用第一用户代理所提供的所述新业务。
一种用户代理，用于在SIP协议中请求业务修改，包括
业务修改请求单元，将携带有所请求的新业务的目标业务标识的请求消 息路由至所述对端用户代理；
业务修改处理单元，用于在收到来自所述对端用户代理的确定响应后， 与对端用户代理之间进行新业务的传输。
综上，根据本发明实施例的方法、网络系统及用户代理，可以通过扩展 或复用SIP协议的请求消息(如INVITE消息)，在其中携带所请求的新业务 的目标业务标识，并路由至对端用户代理，来请求业务修改，对端用户代理 根据所接收到请求消息中的目标业务标识，与发送请求的用户代理进行该新 业务的传输；可以应用在一些特定的场合，诸如进行电视频道切换、实现媒 体资源控制等。
图l是现有的 一种基于IMS的IPTV的业务功能架构示意图2是本发明在SIP协议中请求业务修改的方法第 一 实施例的流程示意
图3是本发明实施例在IPTV BC业务中的应用的流程示意图； 图4是本发明实施例在士某体资源访问中的应用的流程示意图； 图5是本发明在SIP协议中请求业务修改的网络系统的 一个实施例的结构 示意图。
具体实施例方式
下面结合附图以优选实施例对本发明进行详细说明。
本发明的实施例是通过对SIP协议进行扩展，使在对话中，通过SIP的协 议消息(如INVITE消息)来携带一个目标业务标识(即修改后的业务标识信 息)，来请求业务修改。
如图2所示，是本发明在SIP协议中请求业务修改的方法第一实施例的流 程示意在本实施例中，第 一用户代理(UA1)请求访问由第二用户代理(UA2) 所提供的第一业务(如sip:servicel@example.com):
步骤S201: UA1向代理服务器(Proxy)请求访问第一业务(如， sip:servicel@example.com),例如可以通过INVITE消息携带该请求；
步骤S202:代理服务器(Proxy)将该请求消息路由至UA2;
步骤S203: UA2接受业务请求，并返回对请求的成功响应消息(如200OK 消息)；
步骤S204: Proxy将该响应消息路由至UAl; 步骤S205: UA1返回对响应消息的确认消息(ACK); 步骤S206: Proxy将确认消息(ACK)路由至UA2;
UA2开始为UA1提供第一业务，UA1使用UA2所提供的第一业务。
在某些情况下，UA1需要请求对业务进行修改或者请求新的业务(即目 标业务，如sip:service2⑥example.com),例如，在IPTVBC业务中由于用户请 求访问新的BC业务而导致需要进行业务切换的情形，此时
步骤S207: UA1请求对业务进行修改或者请求新的业务(目标业务，如 为第二业务)，例如在INVITE消息携带sip:service2⑥example.com,其中， sip:service2⑥example.com即为目标业务(第二业务)标识；
步骤S208: Proxy将新的请求消息(INVITE)路由至UA2;
步骤S209: UA2确认可以为UA1提供目标业务，并返回对该请求的成功 响应消息(200OK);
S210: Proxy将成功响应消息(200OK);洛由至UA1。
S211: UA1返回对响应消息的确认消息(ACK);
S212: Proxy将确认消息(ACK)路由至UA2;
UA2开始为UA1提供该第二业务，UA1使用UA2所提供的第二业务。
UA2在会话(Dialog)建立过程中发布的Local Target (即对端实体的 Remote Target) URI的Hostport (主机及端口 )必须能够定位到一个唯一的SIP 实体UA2，因此UAl对远端目标URI的userpart (用户部分)的修改，或者对 URI非传输参数的修改，或者增加新的参数不会导致Dialog内的请求消息被路 由到其他实体或者消息路由失败。因此UA1在步骤S207中发送请求消息时需 要保持RURI的hostport部分与Remote Target的hostport部分4呆持一致(如下面 的各RURI中均为"ua2.example.com")，同时通过use卬art部分增加目标业务 参数new-target、或者将userpart修改为目标业务、或者增加RURI扩展参数 new-target来携带目标业务标识。如以下示例中的任意一种
sip :service 1 ;new-target=sip0/o3 Aservice2Yo40. example .com@ua2 .example .co
m
sip:service 1 ;new-target=service2@ua2.example.com sip:servicel@ua2.example.com;new-target="sip:service2@example.com" sip:service2@ua2.example.com sip:service20/o40example.com@ua2.example.com
因为代理服务器(Proxy)等SIP实体根据UA1的请求消息(如INVITE ) 的RURI的主机及端口hostport部分(如"ua2.example.com")将该请求消息最 终路由到UA2 ，因此上述几种携带方式均没有涉及对RURI的主机及端口 hostport部分的修改，故都不会影响代理服务器(Proxy)等中间网络实体对请 求消息的路由，能保证消息可以被正确路由到UA2，并由UA2提供目标业务。
上述说明了UA1通过对远端目标URI的userpart进行修改、对URI非传输相 关参数的修改，或者增加新的参数来携带目标业务标识，在本发明的其他的 实施方式中，UA1也可以通过扩展SIP头域、复用已有的SIP头域或者通过消息 体来携带该新的业务标识(即目标业务标识)。如以下示例中的任意一种
通过扩展SIP头域携带，例如可以扩展一个P-New-Target来携带该标识，
如
P画New-Target: sip:service2@example.com;
通过复用P-Called-Party-ID头域或其他已有SIP头域携带该标识，如 P-Called-Party-ID: sip:service2@example.com; 通过SIP消息体携带该标识，如 Content-Type: Application/New-Target New-Target=sip: service2@example .com
在上述示例中，在步骤201至步骤206中，UA1可以与UA2进行支持请求业 务修改的能力协商和确定，例如，可以通过Supported (或Require)进行扩展 能力协商；或者通过Contact头域URI的扩展参数携带UAl以及UA2的支持请求 业务修改的能力信息；或者在请求或者响应消息中携带扩展头域或者扩展消 息体的类型传递或者协商UA 1以及UA2的支持请求业务修改的能力信息。在 UA1、 UA2确定双方都支持该扩展时，使用前面描述的各种方式来请求业务修 改，以保证请求业务修改能够能够被正确理解和执行。在具体的实施方式中， 可以
通过Supporte樣明消息的发送者支持请求业务修改，如 Supported: new-target
通过Require表明消息的发送者支持并且要求对端实体支持请求业务修 改，如
Require: new-target
通过Contact头域URI表明消息的发送者支持并且要求对端实体支持请求 业务修改，如
Contact: sip:servicel @ua2.example.com;new-target
通过携带P-New-Target头域表明消息的发送者支持通过该头域请求业务 》务改，如
P-New-Target:
通过Acc印t头域中包含请求业务修改的消息体类型表明消息的发送者支 持通过该种类型的消息体方式请求业务修改，如 Accept: Application/New-Target
进一步通过Proxy-Require进行扩展能力协商，以确保代理服务器(Proxy) 能够正确将请求业务修改的请求消息路由到UA1或者UA2;或者通过 Record-Route头域或Route头域URI的扩展参数表明该URI所代表的代理服务 器(Proxy)是否支持对请求业务修改的请求消息的路由，以确保请求业务修 改的请求消息能够被正确的路由到对端UA。在UA1、 UA2在确定代理服务器 (Proxy)支持对请求业务修改的请求消息的路由时，使用前述描述的各种方 式来请求业务修改，以保证所述请求消息能够被正确的路由到对端UA。如
通过Proxy-Require表明要求代理服务器(Proxy)支持对请求业务修改的 请求消息的路由，如果Proxy不支持则必须拒绝请求消息，如 Proxy-Require: new-target
通过Route头域URI表明该URI所代表的代理服务器(Proxy)支持对请求 业务修改的请求消息的路由，如
Route: sip:proxy 1 .example.com;new-target
通过Record-Route头域URI表明该URI所代表的代理服务器(Proxy)支持 对请求业务修改的请求消息的路由，如
Record-Route: sip:proxy 1 .example.com;new曙target
根据以上支持请求业务修改的能力协商和传递的方法，以扩展Contact和 Route头域URI参数为例进行详细说明，本领域的技术人员不难根据上文描述 推导出其他能力协商和传递的实施方法。
步骤S201中，UAl通过Contact头域URI参数表明是否支持请求业务修改， 其中，参数"new-target"表明UAl支持请求业务修改
INVITE sip:servicel@example.com SIP/2.0
Contact: sip:usera@ual .example.com;new-target
上述方法同样适用于UA2请求业务修改，如在IPTV UE访问BC业务期间 业务控制功能SCF根据用户登记的定时LTV节目观看功能请求IPTV UE进行 BC业务切换(如LTV频道切换)，甚至不同类型业务之间的切换；再如在由 SCF根据用户登记的定时LTV节目观看功能主动请求IPTV UE进行BC业务访 问(此时SCF作为初始业务发起者UA1， IPTV UE作为初始业务请求接受者 UA2),在业务访问过程中用户请求BC业务切换等。
本领域技术人员根据上述方法不难推导出UA2请求业务修改的具体实现 过程。
步骤S202中，代理服务器(Proxy)通过Record-Route表明是否支持请求 业务修改的请求消息的路由，其中，参数"new-target"表明代理服务器(Proxy) 支持对请求业务修改的请求消息的路由
INVITE sip:servicel@example.com SIP/2.0
Contact: sip:usera@ual ,example.com;new國target
Record"Route: sip:proxy 1 .example.com;new國target
步骤S203中，UA2将响应消息(200 OK)路由至代理服务器(Proxy)， 将接收到的请求消息中的Record-Route通过Route返回给UA1，同时通过 Contact头域URI参数表明是否支持请求业务修改，其中，Contact中的参数 "new-target"表明UA2支持请求业务修改
SIP/2.0 200 OK
Contact: sip:service 1 @ua2.example.com;new-target Route: sip:proxy 1 .example.com;new-target
步骤S204中，代理服务器(Proxy)将响应消息(200OK)路由至UAl: SIP/2.0 200 OK
Contact: sip:servicel @ua2.example.com;new-target Route: sip:proxy 1 .example.com;new-target
UA1 、UA2可以根据消息中获取到的对端目标以及Record-Route或者Route 头域中携带的实体的能力信息，确定是否有必要的SIP实体不支持请求业务修 改或者支持对请求业务修改请求消息的路由。在确定所有必要的实体都支持 请求业务修改或者支持对请求业务修改请求消息的路由后，UA1或者UA2就可
以向根据业务需要请求业务修改。
图3是本发明在IPTVBC业务中的应用的流程示意图；其中，同一业务功 能控制实体(SCF)可以为用户提供用户可以访问的多个或者所有BC业务或 者BC业务包的业务提供和控制的功能。初始时IPTV UE与SCF之间建立了业 务会话后用于用户访问第一个BC业务或者业务包。由于用户操作触发BC业务 切换或者BC业务包切换(如LTV频道切换)，IPTVUE (用户终端)请求新 的BC业务或BC业务包。
步骤S301: IPTV UE向中间网络(如在IMS based IPTV中为IMS网络)请 求i方问某个BC业务包，如sip:bc-pkgl@example.com;
步骤S302:中间网络将该请求消息路由至SCF，在此实施例中，所述中间 网络可以为IMS网络，如为IMS网络则包括P-CSCF、 S-CSCF等实体；
步骤S303: SCF接受业务请求，如果所请求的BC业务包属于IPTV UE所 代表的用户可以访问的BC业务包，则返回对该请求的成功响应消息(如200 OK消息)。其中响应消息中Contact头域URI可以诸如为 sip:bc-pkgl @scfl .example.com;
步骤S304:中间网络将该响应消息路由至IPTVUE，并且如果中间网络需 要对用户接入网络访问BC业务媒体数据进行控制，则记录用户可以访问的BC 业务包或者可以访问的媒体授权信息；
步骤S305: IPTVUE返回对响应消息的确认消息(ACK);
步骤S306:中间网络将确认消息(ACK)路由至SCF;
SCF开始为IPTV UE提供BC业务包中所包含的BC业务的访问和控制。 IPTV UE获得SCF所提供的业务并通过多播方式接收媒体流来实现多播业务 媒体数据的接收。如果中间网络需要对用户接入网络访问BC业务媒体数据进 行控制，在IPTV UE请求通过多播方式访问BC业务媒体数据时，中间网络根 据记录的用户可以访问的BC业务包或者可以访问的媒体授权信息允许或者拒 绝用户的多播士某体数据访问。
当用户需要访问新的BC业务包(如需要访问新的BC业务包内的BC业务 或LTV频道节目)时需要进行业务切换
步骤S307: IPTV UE通过re-INVITE请求访问新的BC业务包，其中 re-INVITE请求中携带新的业务的标识(即目标业务标识，如BC业务包标识)， 如为sip:bc-pkg2@example.com; 正如前面所描述的，在本发明实施例中， 可以采用诸如通过在RURI的userpart部分增加目标业务参ft、或者将userpart 修改为目标业务等其他的方式来携带该目标业务标识；例如，该RURI为以下 示例中的任意一种
sip:bc-pkgl ;new-target=bc-pkg20/840example.com@scfl .example.com
sip:bc-pkgl ;new-target=bc-pkg2@scfl .example.com
sip:bc-pkg2%40example.com@scfl.example.com
sip:bc-pkg2@scfl .example.com
sip:bc-pkgl@scfl .example.com;new-target=，，sip:bc-pkg2@example.com，，
sip:service2@ua2.example.com;new-target=sip:bc-pkg2
或者，通过扩展SIP头域P-New-Target携带目标业务标识，如
P-New-Target: sip:bc-pkg2@example.com;
或者，通过复用P-Called-Party-ID等已有SIP头域携带目标业务标识，如 P-Called-Party-ID: sip:bc-pkg2@example.com; 或者，通过SIP消息体携带目标业务标识，如 Content-Type: Application/New-Target New-Target=sip:bc-pkg2@example.com
步骤S308:中间网络将新的请求消息(INVITE)路由至SCF;
步骤S309: SCF确认可以为IPTV UE所代表的用户提供目标业务标识所标 识的BC业务或者BC业务包，则SCF接收业务修改请求并返回对该请求的成功 响应消息(200OK); S310:中间网络将响应消息(200 OK)路由至IPTV UE,并且如果中间 网络需要对用户接入网络访问BC业务媒体数据进行控制，则记录用户可以访 问的BC业务包或者可以访问的士某体授权信息。
S311: IPTVUE返回对响应消息的确认消息(ACK);
S312:中间网络将确认消息(ACK)路由至SCF;
SCF开始为IPTV UE提供新的BC业务包中所包含的BC业务的访问和控 制。IPTV UE获得SCF所提供的业务并通过多播方式接收媒体流来实现多播业 务媒体数据的接收。如果中间网络需要对用户接入网络访问BC业务々某体数据 进行控制，在IPTV UE请求通过多播方式访问BC业务媒体数据时，中间网络 根据记录的用户可以访问的BC业务包或者可以访问的媒体授权信息允许或者 拒绝用户的多播媒体数据访问。
同理，进一步的，IPTVUE和SCF可以进行支持请求新业务的能力协商， 具体步骤可以参见对图2的说明，在此不进行详述。
如果初始时IPTV UE请求访问某一BC业务，之后由于用户操作需要访问 新的BC业务。以上方法同样可以应用于BC业务的切换。
在IPTV UE访问BC业务、单播LTV (即通过单播媒体传送方式提供LTV 业务)、内容点播(Content On Demand, CoD)或^L频点播(Video On Demand, VoD)、时移电视(Time Shift TV)或TsTV (用户可以访问过去某个时间已 经播放完成的LTV电视节目内容)等IPTV业务时，SCF也可以根据需要同样 釆用上述方法请求业务修改，如主动请求终端进行业务切换或者频道切换。
上述方法同样适用于基于IMS的IPTV系统或者网络以及基于非IMS的 IPTV系统或者网络。当应用于基于IMS的IPTV系统或者网络时中间网络为 IMS网络，包括P-CSCF、 S-CSCF以及用户接入控制等；当应用于基于非IMS 的IPTV系统或者网络时，中间网络为相应的业务路由子网络。
本发明实施所揭示的方法除了应用于IPTV系统或者网络外，还可以应用 于其他业务。如基于SIP的媒体资源访问。
如图4所示，是本发明在媒体资源访问中的应用的流程示意其中，步骤S40至步骤S42为业务建立过程，在该建立过程中，媒体资源 客户端(Media Resource Client, MRC)初始请求媒体资源服务器(media resource server, MRS)播放anouncementl,随着业务的进行，在步骤S44至步 骤S46中，MRC向MRS请求新的媒体资源，即请求播放anouncement2。
根据现有基于SIP协议的媒体资源访问技术，通过SIP请求可以携带 VoiceXML脚本连接、媒体播放、媒体录制、DTMF检测、语音合成、语音识 别、文本语音转换、建立会议以及会议控制等，因此在INVITE消息中可以携 带以上信息向MRS请求媒体资源业务，在业务进行过程中可以通过Remote Target来指定下一步的媒体资源业务。因此在图4中，具体的，RURI或者 P-New-Target可以为
播放媒体
P-New-Target: sip:annc@ms2.example.net;
play=file:〃fileserver，example.net//geminii/yourHoroscope.wav P-New國Target: sip:annc@ms2.example.net;
play=http:〃audio.example.net/allcircuitsbusy .g711 P-New誦Target: sip:annc@ms.example.net; play=file:〃fs.example.net//clips/my-intro.dvi; \
content-type=video/mpeg0/o3bencode%d3314M-25/625-50
携带VoiceXML脚本连接
P-New-Target: sip:dialog@mediaserver.example.net; \
voicexml=http:〃vxmlserver.example.net/cgi-bin/script.vxml
如图5所示，是本发明在SIP协议中请求业务修改的网络系统的结构示 意图。在本发明实施例提供的网络系统中，至少包括第一用户代理(UA1 ) 及第二用户代理(UA2)及中间实体(如Proxy)等，其中
第一用户代理，用于在需要进行业务修改或切换时，在SIP协议的INVITE 消息中携带所请求的目标业务标识，并路由至第二用户代理；
所述第二用户代理，用于根据所述目标业务标识，为所述第一用户代理 提供相应业务，或使用第一用户代理所提供的相应业务。
在具体实现时，所述第一用户代理包括
能力协商单元，用于在和第二用户代理建立对话时，进行支持请求业务 修改的能力的协商；
业务修改请求单元，用于通过扩展SIP消息，将携带有所请求的目标业 务标识的INVITE消息路由至第二用户代理，在本发明的一些实施例中，其是 通过扩展或复用SIP消息的头域、扩展SIP消息的消息体、扩展SIP消息的 RURI参数中任一方式来携带该目标业务标识；
业务修改处理单元，用于在收到来自第二用户代理的确定响应后，为第 二用户代理提供与该目标业务标识对应的业务，或接收来自该第二用户代理 的与该目标业务标识对应的业务。
同样，第二用户代理包括能力协商单元、业务修改响应单元及业务修 改处理单元。
其中，业务修改响应单元，用于在接收到第一用户代理的带有请求的目 标业务标识的INVITE消息时，向第一用户代理发送响应消息(如确定响应消 息，或拒绝响应消息)；
业务修改处理单元，用于为第一用户代理提供与目标业务标识对应的业 务，或接收来自第一用户代理的与目标业务标识对应的业务。
在本发明的其他一些实施例中，第一用户代理也可以包括业务修改响应 单元，第二用户代理也可以包括业务修改请求单元。
第一用户代理和第二用户代理的能力协商单元是通过在INVITE消息的 Supported头域或R叫uire头域中携带一个能力标签("new-target")、在INVITE 消息的Contact头域中扩展URI的参数、在INVITE消息中携带一个扩展头域 (P-New-Target )、或在INVITE消息的Accept头域携带请求业务修改的消息 体类型中任意一种来实现所述协商和确定。
在本发明实施例的一个具体应用中，该目标业务标识信息为目标多播业 务标识或目标多播业务包标识(如电视频道标识)；该第一用户代理为IPTV 终端(如UE或STB等)，该第二用户代理为IPTV业务控制功能(SCF )实 体，同理，在其他的实施例中，该第一用户代理也可以为SCF实体，该第二 用户代理为IPTV终端。
在本发明实施例的另 一个具体应用中，该目标业务标识为目标媒体资源 标识；该第一用户代理为媒体资源客户端；该第二用户代理为媒体资源服务 器。
该第一用户代理及第二用户代理的更多细节可以在对图2中的描述获得。 综上，本发明实施例所提出的方法、网络系统及用户代理，通过在扩展 或复用SIP协议消息的头域、消息体或RURI的参数，携带目标业务标识，使能 够请求新的业务；从而在诸如IMS basedIPTV中进行电视频道的业务切换，以 及实现快速媒体资源控制等。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本
发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在 本发明的保护范围之内。
权利要求
1.一种在SIP协议中请求业务修改的方法，其特征在于，包括如下步骤:第一用户代理与第二用户代理建立对话并进行业务传输；第一用户代理请求业务修改，将携带有所请求的新业务的目标业务标识的请求消息路由至第二用户代理；第一用户代理收到来自第二用户代理的确定响应后，与第二用户代理之间进行新业务的传输。
2、 如权利要求l所述的方法，其特征在于，所述第一用户代理将携带有 所请求的新业务的目标业务标识的请求消息路由至第二用户代理的步骤进一 步包括所述第一用户代理通过扩展或复用SIP消息的头域、扩展SIP消息的消息 体或扩展SIP消息的RURI参数任一方式来携带所述目标业务标识。
3、 如权利要求l所述的方法，其特征在于，该第一用户代理请求更新业 务的步骤进一步包括第一用户代理与第二代理进行支持请求业务修改的能力的协商和确定。
4、 如权利要求3所述的方法，其特征在于，所述进行支持请求业务修改 的能力的协商的步骤为第一用户代理与第二用户代理通过SIP消息的Supported头域或Require 头域进行所述能力的协商和确定；或第一用户代理与第二用户代理通过SIP消息的Contact头域URI的扩展参 数携带支持业务修改的能力信息进行所述能力的协商和确定；或第一用户代理与第二用户代理通过在SIP消息中携带扩展头域或扩展消 息体的类型来进行所述能力的协商和确定。
5、 如权利要求l所述的方法，其特征在于，所述第一用户代理与第二用 户代理之间进行新业务的传输的步骤为 所述第 一用户代理为所述第二用户代理提供与所述目标业务标识对应的业务；或者所述第 一用户代理接收来自第二用户代理的与所述目标业务标识对应的 业务。
6、 如权利要求1至5任一项所述的方法，其特征在于，所述将携带有所 请求的新业务的目标业务标识的请求消息路由至第二用户代理的步骤包括第 一用户代理将新业务的请求消息发送至中间网络实体，由中间网络实 体将该请求消息路由至第二用户代理。
7、 如权利要求6所述的方法，其特征在于，所述方法进一步包括第一 用户代理与所述中间网络实体通过Proxy-Require进行扩展能力协商，以确保 所述中间网络实体能够将所述请求消息路由至第二用户代理；或者与第一用户代理连接的所述中间网络实体通过SIP消息的Record-Route 头域或者Route头域URI的扩展参数携带支持业务修改的能力信息进行所述 能力的协商。
8、 如权利要求1至5任一项所述的方法，其特征在于，所述目标业务标 识为目标多播业务标识或目标多播业务包标识。
9、 如权利要求1至5任一项所述的方法，其特征在于，所述第一用户代 理为IPTV终端；所述第二用户代理为IPTV业务控制功能实体；或所述第 一用户代理为IPTV业务控制功能实体；所述第二用户代理为IPTV 终端。
10、 如权利要求1至5任一项所述的方法，其特征在于，所述目标业务 标识为目标媒体资源标识；所述第一用户代理为媒体资源客户端；所述第二 用户代理为媒体资源服务器。
11、 一种在SIP协议中请求业务修改的网络系统，至少包括第一用户代 理及第二用户代理，其特征在于， 所述第一用户代理，用于在需要请求业务修改时，将携带有所请求的新业务的目标业务标识的请求消息路由至第二用户代理；所述第二用户代理，用于根据所述目标业务标识，为所述第一用户^C理 提供所述新业务，或使用第一用户代理所提供的所述新业务。
12、 如权利要求11所述的网络系统，其特征在于，所述第一用户代理是 通过扩展或复用SIP消息的头域、扩展SIP消息的消息体、扩展SIP消息的 RURI参数中任一方式来携带所述目标业务标识。
13、 如权利要求12所述的网络系统，其特征在于，所述第一用户代理与 所述第二用户代理均进一步包括能力协商单元，用于协商和确定支持请求业务修改的能力。
14、 如权利要求11到13任一项所述的网络系统，其特征在于，所述目 标业务标识为目标多播业务标识或目标多播业务包标识；所述第一用户代理 为IPTV终端；所述第二用户代理为IPTV业务控制功能实体。
15、 如权利要求11到13任一项所述的网络系统，其特征在于，所述目 标业务标识为目标媒体资源标识；所述第一用户代理为媒体资源客户端；所 述第二用户代理为士某体资源服务器。
16、 一种用户代理，用于在SIP协议中请求业务修改，其特征在于，包括业务修改请求单元，将携带有所请求的新业务的目标业务标识的请求消 息路由至所述对端用户代理；业务修改处理单元，用于在收到来自所述对端用户代理的确定响应后， 与对端用户代理之间进行新业务的传输。
17、 如权利要求16所述的用户代理，其特征在于，所述目标业务标识携 带在扩展或复用的SIP消息的头域、扩展的SIP消息的消息体或扩展的SIP 消息的RURI参数中。
18、 如权利要求17所述的用户代理，其特征在于，进一步包括能力协商单元，用于和对端用户代理进行支持请求业务修改的能力的协商。
19、 如权利要求16到18任一项所述的用户代理，其特征在于，所述目 标业务标识为目标多4番业务标识或目标多播业务包标识。
20、 如权利要求16到18任一项所述的用户代理，其特征在于，所述第 一用户代理为IPTV终端；所述对端用户代理为IPTV业务控制功能实体；或所述用户代理为IPTV业务控制功能实体；所述对端用户代理为IPTV终端。
21、 如权利要求16到18任一项所述的用户代理，其特征在于，所述目 标业务标识为目标J 某体资源标识；所述用户代理为媒体资源客户端；所述对 端用户代理为媒体资源服务器。
全文摘要
本发明公开了一种在SIP协议中请求业务修改的方法，包括如下步骤第一用户代理与第二用户代理建立对话并进行业务传输；第一用户代理请求更新业务，将携带有所请求的新业务的目标业务标识的请求消息路由至第二用户代理；第一用户代理收到来自第二用户代理的确定响应后，与第二用户代理之间进行新业务的传输。本发明还公开了相应的网络系统及用户代理。实施本发明的实施例，可以实现可以通过对SIP消息进行扩展，来携带目标业务标识，可以请求业务修改，从而可以应用在一些诸如进行电视频道切换、实现媒体资源控制的特定的场合。
文档编号H04L12/56GK101374138SQ20071002981
公开日2009年2月25日 申请日期2007年8月21日 优先权日2007年8月21日
发明者漆宝剑, 鹏 王, 雷晓松 申请人:华为技术有限公司