专利名称：一种传递业务信息的方法及装置的制作方法
技术领域：
本发明涉及无线通信领域，特别是涉及一种传递业务信息的方法及装置。
背景技术：
在通信网中，用户输入信息并发起一个通信请求，请求目的一般为以下三种1、为了和另一用户建立通信联系，则请求目的点为用户输入的请求目的用户标识。
2、为了使用一种业务，则请求目的点为用户输入的业务标识，它表示的是网络提供的业务/服务的标识。
3、为了使用一种业务，同时请求和一个用户建立通信联系或操作用户业务数据等，则请求目的点是输入的业务标识及请求目的用户标识和用户业务数据等业务附属信息。
可见，用户为了使用一种业务通常需要同时提供业务标识和业务附属信息。
SIP协议是一种用于建立、更改和终止多媒体会话或呼叫的应用层控制协议，所述多媒体会话或呼叫包括多媒体会议、远程教学、因特网电话等。用户使用SIP协议发起一个通信请求，请求目的设置在请求消息的请求行(Request-Line)的Request-URI(请求-URI)中。根据SIP标准协议，所述Request-URI可以携带用户标识或业务标识(在使用SIP协议的某些通信网络中，业务标识也被称为PSI)，但Request-URI不支持同时携带业务标识和用户标识。
目前在SIP标准协议中，在一个通信请求消息中同时携带业务标识和用户标识的方法是在Request-URI中携带作为业务附属信息的请求目的用户标识，而业务标识及其它的业务附属信息则通过不同的头域或事件包来指示。由于业务需求是无法事先预测的，如果出现一项新的业务就增加一种新的头域或事件包来指示，这显然不是一个通用的方案。
发明内容
本发明提供一种传递业务信息的方法及装置，用以解决目前没有一种通用的方案可以在SIP消息中同时携带业务标识和业务附属信息的问题。
本发明方法包括下列步骤将业务信息携带于SIP消息的固定信息段中；将所述SIP消息在SIP用户代理之间交互，以实现业务信息的传递。
本发明发起业务请求信息的用户终端装置，包括业务请求信息界面单元，用于向用户提供可输入业务请求信息的操作界面；业务请求信息接收单元，用于接收用户在业务请求信息界面单元提供的操作界面上输入的业务请求信息；业务请求信息发送单元，用于将业务请求信息接收单元接收的业务请求信息构造成SIP消息中的固定信息段，并发送该SIP消息。
本发明有益效果如下本发明不再使用不同的头域或事件包来指示不同的业务，而是将业务信息携带于SIP消息的固定信息段中。即仍可利用Request-URI来携带业务标识和/或请求目的用户标识，其它的业务信息都由逻辑固定信息段(信息输入参数、信息输入头域、信息输入事件包，或者信息输入体)来携带，并由业务控制网元根据业务标识来识别不同的业务。通过本发明的实施，无须在新增业务时相应增加头域或事件包，从而本发明方法可作为兼容所有业务的通用方案，并且符合SIP标准协议。
图1为本发明方法的步流程图；
图2为本发明发起业务请求信息的用户终端装置的结构示意图。
具体实施例方式
为了避免业务种类与头域或事件包相对应，本发明提供了一种通用的传递业务信息的方法，参见图1所示，包括下列主要步骤S1、将业务信息携带于SIP消息的固定信息段中。
S2、将所述SIP消息在用户代理(SIP UA，User Agent)之间交互，以实现业务信息的传递。
S3、根据传递的业务信息为用户提供相关业务。
其中，步骤S1中所述的业务信息包括业务请求信息、业务通知信息和业务协调信息，以下针对业务请求信息在本发明中的实施，以及业务通知信息和业务协调信息在本发明中的实施，分别进行详述。
●针对业务请求信息的详述如下。
业务请求信息包括业务标识和业务附属信息。
本发明将业务标识和业务附属信息携带于SIP消息中的一个或一个以上且为不同业务所共用的固定信息段中，所述固定信息段包括Request-URI信息段和至少一个其它固定位置(逻辑固定信息段)。所述业务标识和业务附属信息的携带，存在三种情况情况一SIP消息中的Request-URI信息段携带所述请求目的用户标识；以及SIP消息中的逻辑固定信息段携带至少一个业务标识。
情况二SIP消息中的Request-URI信息段携带业务标识；以及SIP消息中的逻辑固定信息段携带至少一个业务附属信息。
情况三SIP消息中的Request-URI信息段携带所述请求目的用户标识和业务标识。即所述业务标识作为请求目的用户标识的域名前缀。
上述三种情况中，所述逻辑固定信息段可为SIP消息中的请求行(Request-Line)中的uri-parameters参数、头域(header)、事件包(eventpackage)，或者消息体(message body)。
针对所述uri-parameters参数，可在SIP消息的uri-parameters参数中定义一个信息输入参数，如命名为info-input-param，以携带业务信息。
针对所述头域，可在SIP消息的头域中定义一个信息输入头域，如命名为Info-Input，以携带业务信息。
针对所述事件包，可在SIP消息的事件包中定义一个信息输入事件包，如命名为info-input，以信息输入事件包的参数来携带业务信息。
针对所述消息体，可在SIP消息体中定义一个信息输入媒体类型(mediatype)，格式为MIME媒体类型，如命名为application/info-input，由该信息输入体(body)来携带业务信息。
上述逻辑固定信息段只是逻辑定义，其可以是在SIP协议中定义新扩展的uri-parameters参数、头域、事件包或消息体应用，也可以是SIP协议中已有的uri-parameters参数、头域、事件包或消息体应用的扩展使用；还可进一步区分携带业务标识的逻辑固定信息段和业务附属信息的逻辑固定信息段，如业务标识输入头域和业务附属信息输入头域、业务标识输入事件包和业务附属信息输入事件包、业务标识输入体和业务附属信息输入体等，也可以在逻辑固定信息段内通过不同参数区分携带业务标识和业务附属信息，当然也可以不区分。
对应业务请求信息中的业务标识和业务附属信息的携带方式存在的三种情况，以下通过三个实例具体描述本发明方法。
方法实例一Request-URI携带请求目的用户标识，业务标识携带于逻辑固定信息段中。
在本发明中，业务标识可以是SIP URI格式，如“sipconference-factory@home.net”表示会议业务标识，“sip200@home.net”或“sipprepaid-card@home.net”表示预付费卡号业务标识；还可以是tel URI格式，如“tel200；phone-context＝home.net”表示200卡号业务标识；还可以仅仅是一个域名，省略了用户信息(userinfo)和“@”符，如“sipprepaid-card.com”表示预付费卡号业务标识；还可以是传统的电话号码即业务特征码方式，如“200”表示200卡号业务标识；还可以是描述业务特征/属性的字符串，如“prepaid-card”表示预付费卡号业务标识。
在上述的信息输入参数、或信息输入头域、或信息输入事件包、或信息输入体中，可以只携带一个业务标识，也可以携带一个以上的业务标识，即用户可以按顺序请求多个业务。
下面分别描述几种典型业务的使用1、被叫付费业务用户A发起一个呼叫，要求该呼叫所发生的费用由被叫承担，示例如下INVITE sipmary@home.net；info-input-param＝800 SIP/2.0或者，INVITE sipmary@home.net；info-input-param＝reverse-charging SIP/2.0或者，INVITE sipmary@home.net；info-input-param＝<sipreverse-charging@home.net>SIP/2.0或者，INVITE sipmary@home.net；info-input-param＝<sipreverse-charging.com>SIP/2.0其中，“sipmary@home.net”是SIP URI格式的被叫用户标识，即此次呼叫请求的目的用户标识，“800”或“reverse-charging”或“sipreverse-charging@home.net”或“sipreverse-charging.com”表示被叫付费业务标识的不同格式。网络收到该呼叫，将根据被叫付费业务标识，向计费系统指示此次呼叫费用由被叫用户承担。
通过信息输入头域、或信息输入事件包、或信息输入体携带被叫付费业务标识的示例分别如下INVITE sipmary@home.net SIP/2.0Info-Input800
或者，INVITE sipmary@home.net SIP/2.0Subscriptioninfo-input；service-id＝800或者，INVITE sipmary@home.net SIP/2.0Content-Typeapplication/info-inputservice-id＝800其中，“service-id”是信息输入事件包、或信息输入体中负责传递业务标识的参数，可以看到，示例中信息输入事件包、或信息输入体中通过不同参数区分业务标识和业务附属信息(当然也可以不区分)，而信息输入参数、或信息输入头域中则没有区分业务标识和业务附属信息(当然也可以区分)。
上面采用了“800”的被叫付费业务标识的格式，也可以采用上述的其它格式，示例略。
2、会议业务用户A发起一个呼叫，要求该呼叫加入会议，示例如下INVITE sipmary@home.net；info-input-param＝conference-factory SIP/2.0其中，“sipmary@home.net”是SIP URI格式的被叫用户标识，“conference-factory”标识会议业务，采用其它格式的会议业务标识的示例略。网络收到该呼叫，将根据会议业务标识，申请会议资源，和用户A之间建立会议通道，并将被叫用户也加入该会议，从而使用户A和被叫用户之间建立会议呼叫。
或者，用户A向若干个用户，如用户B、用户C发起呼叫，要求这些用户一起加入会议，示例如下INVITE sipgroup-list1@home.net；info-input-param＝conference-factorySIP/2.0其中，“sipgroup-list1@home.net”是将用户B和用户C作为一个群组/集合的群组标识，它对应的用户B标识和用户C标识可以事先设置在网络中，也可以携带于该呼叫请求消息(SIP INVITE邀请消息)中，如在该消息体中通过XML格式或其它参数格式描述。网络收到该呼叫，将根据会议业务标识，申请会议资源，和用户A之间建立会议通道，并根据上述的群组标识，得到对应的、事先设置在网络中或携带于消息中的用户B标识和用户C标识，再分别将用户B和用户C加入该会议，从而使用户A和用户B、用户C之间建立会议呼叫。
通过信息输入头域、或信息输入事件包、或信息输入体携带会议业务标识的示例如上类似，示例略。
3、用户业务数据操作用户A发起一个呼叫，要求设置遇忙呼叫前转用户业务数据，示例如下INVITE siprose@home.net；info-input-param＝*40*26500000SIP/2.0或用户A也可以通过发起一个订阅请求，来完成遇忙呼叫前转用户业务数据的设置，示例如下SUBSCRIBE siprose@home.net；info-input-param＝*40*26500000 SIP/2.0其中，“siprose@home.net”是用户A自己的用户标识，即此次通信请求的目的用户标识(用户A发起通信请求的目的是操作自己的用户业务数据)；“*40*26500000”则包含了业务标识“*40”、和作为另一种业务附属信息的遇忙呼叫前转目的地址“26500000”，即该示例中没有区分业务标识和业务附属信息，当然也可以区分。
通过信息输入头域、或信息输入事件包、或信息输入体携带会议业务标识的示例如上类似，示例略。
此外本例特殊地方的是，逻辑固定信息段中除了携带业务标识外，还需要携带作为业务附属信息的用户业务数据(遇忙呼叫前转目的地址)，实际上，由于Request-URI携带了作为业务附属信息的请求目的用户标识，显然若某种业务使用中还有其它类型的业务附属信息，则需要通过所述逻辑固定信息段携带，如前述的被叫付费业务，还可以携带一个附属信息，指示此次被叫付费业务的使用是否需要和被叫协商(因为被叫也许不同意该业务的使用)，示例如下INVITE sipmary@home.net SIP/2.0Info-Input800；reverse-charging-consulting＝true其中，“reverse-charging-consulting”表示被叫付费是否要和被叫协商的参数，参数设置为“true”表示需要和被叫协商。
再如，对前述的会议业务，还可以携带其它的附属信息，指示每个加入会议的用户的会议权限(如会议控制权限、能听能说的会议参与者、只能听的会议参与者等)、以及用户的所说语言等，示例如下INVITE sipgroup-list1@home.net SIP/2.0Content-Typeapplication/info-inputservice-id＝conference-factoryuser＝<sipmary@home.net>；rule＝only-listen；language＝englishuser＝<sipalice@home.net>；rule＝listen-speak；language＝french其中，群组标识对应的用户B和用户C的用户标识携带于呼叫请求消息中，分别是“sipmary@home.net”和“sipalice@home.net”，而“rule”表示用户的会议权限，“only-listen”表示只能听，“listen-speak”表示能听能说；而“language”表示用户所说语言，“english”表示英语，“french”表示法语。
方法实例二Request-URI携带业务标识，业务附属信息携带于逻辑固定信息段中。
本例中，由于业务标识由Request-URI携带，因此它只能是URI格式。
类似的，信息输入参数、或信息输入头域、或信息输入事件包、或信息输入体中，可以只携带一个业务附属信息，也可以携带一个以上的业务附属信息。
下面分别描述几种典型业务的使用1、被叫付费业务用户A发起一个呼叫，要求该呼叫所发生的费用由被叫承担，示例如下INVITEsipreverse-charging@home.net；
info-input-param＝<sipmary@home.net>SIP/2.0或者，INVITE sip800@home.net；info-input-param＝<sipmary@home.net>SIP/2.0或者，INVITEtel800；phone-context＝home.net；info-input-param＝<sipmary@home.net>SIP/2.0或者，INVITE sipreverse-charging.com；info-input-param＝<sipmary@home.net>SIP/2.0其中，“sipreverse-charging@home.net”、“sip800@home.net”、“tel800；phone-context＝home.net”、“sipreverse-charging.com”是URI格式的被叫付费业务标识，“sipmary@home.net”是作为业务附属信息的被叫用户标识。
通过信息输入头域、或信息输入事件包、或信息输入体携带作为业务附属信息的被叫用户标识的示例分别如下INVITE sipreverse-charging@home.net SIP/2.0Info-Input<sipmary@home.net>
或者，INVITE sipreverse-charging@home.net SIP/2.0Subscriptioninfo-input；service-param＝<sipmary@home.net>
或者，INVITE sipreverse-charging@home.net SIP/2.0Content-Typeapplication/info-inputservice-param＝<sipmary@home.net>
其中，“service-param”是信息输入事件包、或信息输入体中负责传递业务附属信息的参数，和方法实例一中的示例类似，示例中信息输入事件包、或信息输入体中通过不同参数区分业务标识和业务附属信息(当然也可以不区分)，而信息输入参数、或信息输入头域中则没有区分业务标识和业务附属信息(当然也可以区分)。
上面采用了“sipreverse-charging@home.net”的被叫付费业务标识的格式，也可以采用上述的其它格式，示例略。
而对前述的被叫付费是否要和被叫协商的附属信息，在方法实例二的示例如下INVITE sipreverse-charging@home.net SIP/2.0Info-Input<sipmary@home.net>；reverse-charging-consulting＝true2、会议业务用户A发起一个呼叫，要求该呼叫加入会议，示例如下INVITEsipconference-factory@home.net；info-input-param＝<sipmary@home.net>SIP/2.0其中，“sipconference-factory@home.net”是会议业务标识，一般的，它标识的就是提供处理会议业务控制的会议网元地址，采用其它格式的会议业务标识的示例略，“mary@home.net”是作为业务附属信息的被叫用户标识。
或者，用户A向若干个用户，如用户B、用户C发起呼叫，要求这些用户一起加入会议，示例如下INVITE sipconference-factory@home.net；info-input-param＝<sipgroup-list1@home.net>SIP/2.0或者，INVITE sipconference-factory@home.net；info-input-param＝<sipmary@home.net>，<sipalice@home.net>SIP/2.0其中，信息输入参数可以携带表示用户B和用户C作为一个群组/集合的群组标识“sipgroup-list1@home.net”，也可以携带用户B标识和用户C标识“sipmary@home.net”和“sipalice@home.net”，即可以携带一个以上的业务附属信息。
或者，用户A和用户B已经在通话，用户A请求将该通话加入会议，示例如下
INVITE sipconference-factory@home.ne；info-input-param＝7sdjfkj2356，to-tag＝xyz，from-tag＝pdq SIP/2.0其中，“7sdjfkj2356”、“xyz”和“pdq”一起表示了上述已建立的通话的对话(dialog)标识，该对话标识可以唯一确定一个通话，由于要将指定的通话加入会议，因此必须携带作为业务附属信息的对话标识，而不能携带用户B的用户标识(因为此时用户B可能会建立多个通话)。
通过信息输入头域、或信息输入事件包、或信息输入体携带会议业务标识的示例如上类似，示例略。
而对前述的用户会议权限及用户所说语言的附属信息，采用方法实例二的示例如下INVITE sipconference-factory@home.net SIP/2.0Content-Typeapplication/info-inputuser＝<sipmary@home.net>；rule＝only-listen；language＝englishuser＝<sipalice@home.net>；rule＝listen-speak；language＝french3、用户业务数据操作用户A发起一个呼叫，要求设置遇忙呼叫前转用户业务数据，即遇忙呼叫前转目的地址，示例如下INVITE siptelecommunication-service@home.net；info-input-param＝*40*26500000 SIP/2.0其中，“siptelecommunication-service@home.net”表示电信业务标识，“*40*26500000”是包含遇忙呼叫前转目的地址(26500000)的用户业务数据，这里比较特殊的是，由于Request-URI携带的业务标识(“siptelecommunication-service@home.net”)没有直接出定位出这是对遇忙呼叫前转业务的数据设置，因此信息输入参数中仍需要携带表示遇忙呼叫前转业务属性的信息(“*40”)，即在方法实例二中，逻辑固定信息段也能携带业务标识。
如果Request-URI携带的业务标识可以直接定位出遇忙呼叫前转业务，则信息输入参数可以只携带用户业务数据，示例如下INVITE sipcfb@home.net；info-input-param＝26500000 SIP/2.0或者，INVITE sip*40@home.net；info-input-param＝26500000 SIP/2.0或者，INVITE tel*40；phone-context＝home.net；info-input-param＝26500000 SIP/2.0其中，“sipcfb@home.net”、“sip*40@home.net”、“tel*40；phone-context＝home.net”表示遇忙呼叫前转业务标识。
此外，用户A也可以通过发起一个订阅请求，来完成遇忙呼叫前转用户业务数据的设置，示例如下SUBSCRIBE sipcfb@home.net；info-input-param＝26500000 SIP/2.0通过信息输入头域、或信息输入事件包、或信息输入体携带会议业务标识的示例如上类似，示例略。
4、消息业务用户A发起一个消息业务请求，发送SIP MESSAGE消息，示例如下MESSAGE sipmessage-center@home.net SIP/2.0--boundary1Content-Typeapplication/info-inputuser＝<sipmary@home.net>
--boundary1Content-Typetext/plainHello World！--boundary1其中，“sipmessage-center@home.net”是消息业务标识，一般的，它标识的就是提供处理消息业务控制的消息中心网元地址，该消息被要求发往请求目的用户标识“sipmary@home.net”，消息内容为文本格式的“Hello World！”。
方法实例三Request-URI同时携带请求目的用户标识和业务标识。
现有技术中，当Request-URI携带请求目的用户标识时，其格式一般都具有“域名”信息，如前述示例中的“home.net”就是一个域名，如果在请求目的用户标识的域名前加上一个表示业务标识的前缀，则Request-URI就可以同时携带请求目的用户标识和业务标识，如会议业务，用户A发起一个呼叫，要求该呼叫加入会议，示例如下INVITE sipmary@conference.home.net SIP/2.0其中，“sipmary@conference.home.net”是在请求目的用户标识“sipmary@home.net”中加了作为业务标识的域名前缀“conference”，网络收到该呼叫，将根据会议业务标识“conference”，申请会议资源，并在将请求目的用户加入会议时，删除掉该域名前缀，向请求目的用户发起呼叫INVITE sipmary@home.net SIP/2.0也可以是网络中处理业务触发的网元在根据会议业务标识将该呼叫触发至处理会议业务的网元时，就删除掉该域名前缀，使处理会议业务的网元收到的呼叫如下所示INVITE sipmary@home.net SIP/2.0如果请求目的用户标识是一个群组标识，同样可以加上作为业务标识的域名前缀“sipgroup-list1@conference.home.net”。
在本方法实例中，请求目的用户标识之外的业务附属信息，仍可以通过逻辑固定信息段携带，如方法实例一、方法实例二中的示例所示。
由于所述逻辑固定信息段只是逻辑定义，所以业务附属信息的携带方式不限于上述三个实例中描述的方式，还可包括以下方式。为了简洁仅作概述，具体内容可根据上述三个实例类推得出。
1、逻辑固定信息段不区分不同属性的业务附属信息(请求目的用户标识、用户业务数据、对话标识等)，如前述的service-param参数，此时，可以由网络根据不同的业务标识，以及对业务附属信息的解析，来区分不同属性的业务附属信息。
2、可以按业务附属信息的属性(请求目的用户标识、用户业务数据、对话标识等)来区分携带不同业务附属信息的逻辑固定信息段，如请求目的用户标识输入头域和用户业务数据输入头域、请求目的用户标识输入事件包和用户业务数据输入事件包、请求目的用户标识输入体和用户业务数据输入体等，也可以是在逻辑固定信息段内通过不同参数区分携带请求目的用户标识和用户业务数据等不同属性业务附属信息，甚至还可以进一步区分不同属性的用户业务数据，如用户标识、卡号、密码、权限级别、时间等。
3、可以按业务不同的操作方式来区分携带不同业务附属信息的逻辑固定信息段，如键盘输入信息、菜单输入信息等，键盘输入信息一般是指用户通过按键拨号方式输入的业务请求信息，业务请求信息由用户输入的键盘字符组成，对键盘输入信息来说，业务标识一般是由用户输入的，键盘输入信息相当于1号数字用户信令(Digital Subscriber Signalling No.1)中键盘协议(Keypadprotocol)的键盘设施信息单元(Keypad facility information element)，它允许用户可以通过网络提供的接入码(即业务特征码)来调用(invoke)业务，菜单输入信息一般是指用户通过菜单方式输入的业务请求信息，包括用户选择的菜单项标识，菜单输入信息相当于1号数字用户信令中功能性协议(Functionalprotocol)的设施信息单元(Facility information element)，其中菜单项标识即可以表示业务标识，如“CONF(会议)”，也可以表示业务标识及其操作模式，如“beginCONF(开始会议)”、“endCONF(结束会议)”，在菜单输入信息中，业务标识(还可进一步包括业务的操作模式)一般是由用户根据终端提供的界面显示或功能键来选择的，菜单输入信息中还可以进一步包括用户选择菜单项标识后对应输入的参数值；也可以是在逻辑固定信息段内通过不同参数区分业务不同的操作方式。
4、可以按业务不同的操作目的来区分携带不同业务附属信息的逻辑固定信息段，如业务调用操作、用户业务数据操作等；也可以是在逻辑固定信息段内通过不同参数区分业务不同的操作目的。对业务的调用又可以进一步按不同的操作模式进行区分，如激活、去激活等。
5、可以在逻辑固定信息段内进一步区分不同业务类型的附属信息，即定义不同业务类型的附属信息参数，如实施例中，“reverse-charging-consulting”和“user”、“rights”、“language”就是分属被叫付费业务、会议业务的附属信息。需要说明的是，虽然这里区分了不同的业务，但是在逻辑固定信息段内区分的，没有为不同的业务定义不同的逻辑固定信息段。业务类型可以通过业务标识来表示，也可以通过业务标识和对业务的操作模式(如激活、去激活等)来表示，可以看到这种方式要求逻辑固定信息段内携带业务标识。
这其中，如前所述，由于当前SIP标准中已经通过不同头域、事件包等定义了一些业务及其附属信息，如通过Privacy头域来描述“主叫号码显示限制”业务、通过message-summary事件包来描述“消息等待指示”业务等，从兼容性考虑，本发明定义的信息输入头域、或信息输入事件包、或信息输入体还可以引用这些已有定义，示例如下Info-InputPrivacy＝id。实际上，当前标准中定义的这些业务及其附属信息的使用，一般都是用户采用前述的菜单方式操作输入的，因此，作为较佳实施例，可以在前述的菜单输入信息中引用这些已有定义。
这其中，还有一种比较特殊的区分不同业务的附属信息的方式，当业务附属信息是由网络要求用户输入时，还可以由网络设定表示不同类型的业务附属信息，所设定参数不需要公示(即不是标准定义)，只在当前业务使用中有效，网络向用户发送请求消息，消息中携带此类要求用户输入参数值的参数，除描述参数名称外，还可以定义参数的数据类型，如在用户和网络的通信联系建立成功后，网络向用户发送SIP INFO消息，提示用户输入卡号、密码，示例如下INFO sip[5555::eee:fff:aaa:bbb]8805 SIP/2.0Content-Typeapplication/info-inputrequire-input＝card，type＝xsstring[16]，tag＝abc123require-input＝password，type＝xsstring[6]，tag＝xyz789示例中，“sip[5555::eee:fff:aaa:bbb]8805”是用户的联系地址(因为通信联系已经建立)，“require-input”携带要求用户输入的参数名称及数据类型，示例中分别描述了数据类型是16位字符串的“card”(卡号)、数据类型是6位字符串的“password”(密码)，数据类型采用的是XML Schema规范。也就是说，该请求消息中携带的业务请求信息只描述了名称及数据类型，并没有具体的业务请求信息内容。
用户收到该请求消息，界面上显示要求用户输入的“card”、“password”参数，用户输入参数值后，向网络发送SIP INFO消息，其中携带具体的业务请求信息内容，示例如下INFO sipas.example.com SIP/2.0Content-Typeapplication/info-inputuser-input＝card，value＝1234567890888888，tag＝abc123user-input＝password，value＝123456，tag＝xyz789示例中，“sipas.example.com”是执行该业务的网元域名地址，“user-input”是“require-input”的响应，携带用户输入的参数值。网络可以通过要求用户输入的参数名称来匹配确认输入的参数值是哪个参数的值，如“card”、“password”；还可以通过网络为每个要求用户输入的参数生成的一个对应的tag值来匹配，如卡号参数的tag值“abc123”，密码参数的tag值“xyz789”。
最后，需要说明的是，上述区分业务附属信息的不同方式，可以配合使用，比如可以在表示菜单输入信息的逻辑固定信息段内区分不同业务类型的附属信息，再如可以在逻辑固定信息段内同时携带键盘输入信息的参数和携带不同属性的参数，甚至可以在携带键盘输入信息的参数内再区分不同属性的附属信息。
此外，当逻辑固定信息段携带业务附属信息时，还可以同时携带对该业务附属信息的操作模式，如增加、删除、修改等，通过携带不同的操作模式，可以表示增加或删除用户业务数据、或请求目的用户标识、或对话标识。当逻辑固定信息段携带业务标识时，还可以同时携带对该业务标识的操作模式，表示对业务标识标识的业务进行激活、去激活、验证、挂起(暂停)、恢复等操作，即对业务的调用。操作模式可以通过键盘输入信息、或菜单输入信息携带，也可以缺省不携带，如前述的会议业务，请求目的用户标识或对话标识的操作模式被缺省认为是“加入”会议，再如前述的消息业务，请求目的用户标识的操作模式被缺省认为是“接收”消息，也可以将这类操作模式看成是一种隐式的操作模式被携带。
若所述逻辑固定信息段为信息输入体，则其使用方式如下在上述的实施例中，总是由信息输入参数、或信息输入头域、或信息输入事件包、或信息输入体中的某一种方式来统一携带Request-URI之外的业务请求信息，实际上在信息输入参数、或信息输入头域、或信息输入事件包携带业务标识时(此时Request-URI携带请求目的用户标识)，该业务的其它附属信息的具体内容也可以由信息输入体携带，如前述的被叫付费业务中指示是否和被叫协商的附属信息，示例如下INVITE sipmary@home.net SIP/2.0Info-Input800Content-Typeapplication/info-inputreverse-charging-consulting＝true也就是说，信息输入体作为一种逻辑固定信息段可以单独使用，也可以和其它三种方式(信息输入参数、信息输入头域或信息输入事件包)之一配合使用。更进一步的，其它三种方式之一可以只提供一种业务请求信息传递的指示(没有具体的业务请求信息内容)，即指示当前有某种业务被请求使用，而Request-URI之外的该业务请求信息的具体内容则由信息输入体携带，包括业务标识，比如信息输入事件包和信息输入体的配合使用，示例如下INVITE sipmary@home.net SIP/2.0Subscriptioninfo-inputContent-Typeapplication/info-inputservice-id＝800这里，信息输入事件包只表示业务被请求使用，而被请求业务的具体业务信息内容“800”(业务标识)则由信息输入体携带，当然此时也可以将这个和信息输入体配合使用的事件包命名为“业务请求事件包”，这只是命名的不同，示例略。
此外，信息输入体除了上述示例中的参数描述格式(文本格式)外，还可以采用XML格式来描述不同的业务请求信息元素(element)，如业务标识元素、请求目的用户标识元素等。
下面进一步说明，在本发明中业务请求信息的应用范围本发明方法适用于所有SIP消息，如SIP INVITE邀请消息、SIPSUBSCRIBE订阅消息、SIP NOTIFY通知消息、SIP REFER参考消息、SIP INFO信息消息、SIP MESSAGE即时消息、SIP PUBLISH发布消息、以及各种SIP响应码消息等。
其中，在当前标准SIP协议中，只有SIP SUBSCRIBE、SIPNOTIFY、SIPPUBLISH消息可以携带事件包，其它消息携带事件包是本发明的扩展。
本发明中，使用信息输入事件包和其它三种方式的不同之处在于使用事件包携带业务请求信息、或前述的事件包和信息输入体的配合使用，表示对该业务请求发起了一个订阅请求，发起业务请求的业务请求者和接受并处理业务的业务控制者之间需要创建并维护该事件包对应的订阅实例(subscription)。
此外，上述实施例中，业务标识等是由用户发起通信请求时输入的，实际上，也可能是网络产生的，如网络收到用户发起的通信请求消息，根据用户的业务签约信息，在消息中加上业务签约信息对应的业务标识，如被叫付费业务标识等；或者网络主动发起通信请求消息，在消息中携带业务标识等，本发明同样适用于此种情况。
前面描述了业务请求信息的在SIP协议中的多种携带方式，一般的，作为较佳实施例，可以使用信息输入头域或信息输入体，在其中通过不同的参数区分键盘输入信息和菜单输入信息，键盘输入信息用来携带用户业务数据操作的信息(如前述的“*40*26500000”)、业务调用的信息(如前述的“800”之类的业务特征码)，以信息输入体作为逻辑固定信息段为例Content-Typeapplication/info-input<keypad-input>*40*26500000</keypad-input>
或Content-Typeapplication/info-input<keypad-input>800</keypad-input>
其中，“keypad-input”即表示键盘输入信息参数。
菜单输入信息中又可以分成两类参数一类参数携带不同业务类型信息，如前所述，即可以按业务标识区分业务类型(即前述的菜单项标识表示业务标识)，并以操作模式区分对业务的调用，如Content-Typeapplication/info-input<menu-input>
<service-id>REV_CHARGING</service-id>
<op-mode>active</op-mode>
</menu-input>
其中，“menu-input”即表示菜单输入信息参数，“servie-id”为业务标识参数(即标识不同的业务类型)，“REV_CHARGING”是被叫付费业务的标识，“op-mode”为操作模式参数，“active”(激活)是一种操作模式的取值；或者，也可以按业务标识及其操作模式来区分业务类型(即前述的菜单项标识表示业务标识和业务的操作模式)，如Content-Typeapplication/info-input<menu-input>
<service-op>activeREV_CHARGING</servie-op>
</menu-input>
其中，“service-op”表示业务标识及其操作模式参数，“activeREV_CHARGING”表示对被叫付费业务的操作模式是“激活被叫付费业务”，service-op参数可以看成是上述servie-type和op-mode两个参数的组合。
菜单输入信息中另一类参数携带不同属性的附属信息(如请求目的用户标识、对话标识等)，并以操作模式区分对这些附属信息的操作，如Content-Typeapplication/info-input<menu-input>
<user-identity>28780000</user-identity>
<op-mode>add</op-mode>
</menu-input>
其中，“user-identity”表示请求目的用户标识参数，“add”(增加)是一种操作模式的取值。
可以看到，菜单输入信息中还可以包括不同的业务类型参数(业务标识参数、业务标识及其操作模式参数)、操作模式参数、不同属性的业务附属信息参数(如用户标识参数、对话标识参数等)。
菜单输入信息中的不同参数格式可以预置在用户终端中；也可以由网络侧设备如应用服务器，推送至用户终端，用户操作菜单及输入对应参数值后，通过SIP消息传递，一般的，除了可以采用上述XML描述的信息输入体在SIP消息体中传递外，还可以采用SIP消息携带SOAP(Simple Object AccessProtocol，简单对象访问协议)体、或XCAP(XML Configuration Access Protocol，扩展标记语言配置访问协议)体的方式，SOAP或XCAP是XML的标准化应用，具体介绍可参见相关标准。对于信息输入体采用SOAP或XCAP格式描述，或者定义出一个通用的SOAP或XCAP应用的MIME媒体类型，如“application/xcap+xml”；或者定义出一个指明SOAP或XCAP具体应用场景的MIME媒体类型，如“application/xcap-srvinfo+xml”，表明XCAP在本发明的业务信息应用；或者仍保持前述的信息输入体的MIME媒体类型示例，SOAP或XCAP的应用格式由SIP用户代理对SIP消息体解析时获得。
业务请求信息一般都是由用户终端发起，本发明实施例还提供了一种发起业务请求信息的用户终端装置，参见图2所示，该装置包括依次相连的业务请求信息界面单元、业务请求信息接收单元和业务请求信息发送单元，其中
所述业务请求信息界面单元用于向用户提供可输入业务请求信息的操作界面，该界面由向用户显示信息的显示界面和供用户输入信息的输入界面组成，所述显示界面至少可以是如下三种方式之一预先存储在所述用户终端装置中、网络侧设备推送至所述用户终端装置中、用户预先设置在所述用户终端装置中，其中，用户预先设置在所述用户终端装置中的界面可以由用户通过所述其它两种方式提供的界面操作完成，如用户在所述用户终端装置中预先设置的电话号码簿。
所述业务请求信息接收单元用于接收用户在所述业务请求信息界面单元上输入的业务请求信息，用户输入方式至少可以是如下两种方式之一按键输入信息、选择内置在所述业务请求信息界面单元中的信息输入，后者如用户选择在所述业务请求信息界面单元中显示的电话号码或业务标识等。
所述业务请求信息发送单元用于将所述业务请求信息接收单元接收的业务请求信息构造成SIP消息中的固定信息段，并发送该SIP消息。所述构造方式至少可以是如下三种方式之一将所述业务请求信息接收单元接收的请求目的用户标识构造成Request-URI信息段，将所述业务请求信息接收单元接收的业务标识以及其它可能存在的业务附属信息构造成逻辑固定信息段；将所述业务请求信息接收单元接收的业务标识构造成Request-URI信息段，将所述业务请求信息接收单元接收的业务附属信息构造成逻辑固定信息段；将所述业务请求信息接收单元接收的请求目的用户标识和业务标识构造成Request-URI信息段。所述逻辑固定信息段包括键盘输入信息段和/或菜单输入信息段，可以是uri-parameters参数、或头域、事件包、或者消息体。
●针对业务通知信息和业务协调信息的详述如下。
业务信息除了请求信息外，还可以有通知信息，在业务被请求后，会有相应的业务通知信息向业务请求者通知当前业务的使用情况，此时业务控制者可以通过SIP NOTIFY消息、SIP PUBLISH消息、SIP INFO消息、SIP MESSAGE消息、及各种SIP响应码消息等，携带业务通知信息发送给业务请求者。
一般的，可以直接在该信息输出体中通过文本方式来描述业务当前的使用情况，比如，对前述的会议业务在使用时，如果用户alice退出了会议，作为业务控制者的网元将向业务请求者发送一个业务通知信息，在信息输出体中通过文本“Alice has quitted the conference(Alice已经退出了会议)”来向业务请求者用户A通知这一情况。
业务通知信息的接收者除了业务请求者外，还可以是业务的参与者或关联者，向其通知当前业务的使用情况，如前述的会议业务在使用时，用户alice退出了会议，作为业务控制者的网元除了可以向业务请求者发送一个业务响应信息，还可以向另一个会议参与者mary发送一个业务通知信息。
业务通知信息中的通知内容，一般是由网络生成的，也可以是由用户输入的。
业务通知信息中描述业务当前使用情况的方式，除了上述的文本方式外，还可以是其它媒体类型的通知方式，如语音(信号音或语音通知等)等，如前述的会议业务在使用时，用户alice退出了会议，作为业务控制者的网元除了可以发送一个文本方式的业务通知信息，还可以发送一个携带“Alice退出会议”的语音通知的业务通知信息。
对语音方式的业务通知信息内容来说，可以是一个语音媒体的链接地址，也可以是一个语音类型指示，还可以是一个语音的构成描述(如信号音频率、断续比等)等。
对同一个业务使用情况，业务通知信息可以只携带一种通知方式，也可以携带不同媒体类型的通知方式。一般的，由于用户终端能力的不同，如有的终端不具有文本显示能力，因此同时携带不同媒体类型的通知方式可以更具有通用性。
另外，业务信息除了上述的业务请求信息及业务通知信息外，还可以是业务协调信息，业务协调信息的接收者使用该信息处理所述业务，比如，一次通信可以引发多个不同业务，而这些业务又由网络中不同的业务控制网元处理，且这些业务之间存在兼容性或优先级等冲突时，则需要在这些业务控制网元之间传递不同业务的业务使用情况，以协调这些业务的调用。
业务协调信息和业务通知信息虽然都是传递业务的当前使用情况，但后者表示的仅仅是一种通知信息，比如采用文本方式描述时，业务通知信息的接收者只是显示通知内容，而不去解析其中的具体业务含义；而对前者，由于协调信息要被用来处理业务的调用，业务协调信息的接收者必须能解析信息内容，从中提取出业务的种类和业务当前的使用情况。因此，在业务协调消息中，必须能定义出具体的业务的种类和业务当前状态，比如，可以采用前述的业务标识来表示业务的种类，业务当前状态可以定义为“等待激活”、“已经激活”、“等待撤消”、“临时撤消”、“已经撤消”、“去激活”、“暂停”等若干种，格式为文本方式的字符串。当然，也可以不用具体的业务标识来表示业务的种类，而是将一些具有类似特征的业务中提取出相同的业务特征，将具体的业务分门别类，来表示业务的种类，即业务的种类表示的是一类具有相同业务特征的业务。
如前述的会议业务在使用时，用户John呼叫会议业务请求者用户A，向用户A发送一个SIP INVITE消息，这其中可能会引发某个业务，而该业务和会议业务相互冲突不能被同时调用，因此用户A在收到该SIP INVITE消息后，可以在返回的SIP响应码消息中，携带一个业务协调信息，向该业务的业务控制网元传递会议业务的当前使用情况，协调信息内容包括会议业务标识和“已经激活”的业务当前状态。
类似的，业务协调信息可以适用于前述的所有SIP消息。
在本发明中，可以通过在SIP消息体中定义另一个信息输入媒体类型，由位于SIP消息中固定位置的、为不同业务所共用的该信息输入体来携带业务通知信息和业务协调信息；或者在SIP消息中定义为不同业务所共用的另一个信息输入头域，通过该头域携带业务通知信息和业务协调信息。
上述的该信息输入体和该信息输入头域只是逻辑定义，可以是在SIP协议中定义新扩展消息体应用或头域，也可以是SIP协议中已有的消息体应用或头域的扩展使用，可以由不同的信息输入体或信息输入头域来分别携带业务通知信息和业务协调信息，也可以在同一个信息输入体或信息输入头域中来携带业务通知信息和业务协调信息。
在某些情况下，业务通知信息和业务协调信息在SIP协议中可以是同样的信息段，表明它即可以用作业务通知，也可以用作业务协调，比如如下情况，在SIP分组域和其它协议域如电路域互通时，业务通知信息要在不同的协议间承载，显然，网络需要解析业务通知信息进行处理，将其转换为对端网络协议承载的信息，还要根据对端网络协议承载的信息生成业务通知信息，此时，业务通知信息同时也是业务协调信息，举例来说，一个表示“呼叫转移”的信息段赋值“call transferred”，在SIP分组域内时可以发向用户终端(业务通知信息接收者)进行显示，而在和电路域互通时，互通网元需要解析该信息段赋值，将其转换为综合业务数字网用户部分(Integrated Services Digital Network UserPart)协议所承载的表示“呼叫转移”的信息段赋值，即“call transferred”即是业务通知信息也是业务协调信息，该互通网元即是业务通知信息接收者也是业务协调信息接收者。或者，还有一种情况，用户终端需要根据收到的业务信息在终端界面上显示，同时根据收到的业务信息进行相应的业务处理，此时该业务信息即是业务通知信息也是业务协调信息，举例来说，用户终端在通话中收到一个新的呼入来话，来话消息中携带“呼叫等待”信息段，用户终端解析该信息段，并据此在终端界面上显示“有新呼入来话”，同时据此处理呼叫等待业务的调用。
此外，携带上述业务通知信息和业务协调信息的信息输入体或信息输入头域、和前述携带业务请求信息的信息输入体或信息输入头域也共用一个消息体或头域应用，通过不同参数区分，当然也可以是不同的消息体或头域应用。其中，进一步的，对业务请求信息和业务协调信息来说，都可以携带业务标识参数，而业务的操作模式和业务当前状态具有相似之处，因此还可以在同一个信息输入体或信息输入头域中，采用相同的参数来表示通过菜单输入信息携带的业务请求信息、和业务协调信息，示例如下Content-Typeapplication/info-input<service-info>
<service-id>REV_CHARGING</service-id>
<service-status>require-active</service-status></service-info>
其中，由于要使用相同的参数来表示业务请求信息和业务协调信息，因此不能使用前述的表示菜单输入信息的参数“menu-input”，而改成“service-info”参数，表示和业务类型相关的业务信息，“service-status”是业务当前状态参数，可以同时用来表示对业务的操作模式，“require-active”(请求激活)是一个业务当前状态参数取值，相当于前述的操作模式参数取值“active”，也即表示前述的“等待激活”的业务当前状态，当然，也可以仍分别表示业务的操作模式和业务当前状态。
此外，本发明前面描述了携带业务信息的SIP消息在SIP用户代理之间交互，以实现业务信息的传递，实际上，根据SIP标准，SIP用户代理是SIP实体(entity)的一种，显然按照标准定义，以固定信息段携带业务信息的SIP消息还可以在其它的SIP实体，如在重定向服务器(Redirect Server)、代理服务器(Proxy Server)、注册员(Registrar)之间传递，以及在SIP用户代理和这些SIP实体之间传递。
最后，还需要说明的是，本发明定义的信息输入参数、或信息输入头域、或信息输入事件包、或信息输入体，包括各种业务标识、业务附属信息的名称，以及描述格式，仅仅是作特性示例，如果还有其它的此类定义，尽管名称和格式不同，但只要包含了本发明的SIP协议携带业务信息的特性(业务标识、业务附属信息，以及业务通知信息、业务协调信息使用消息中固定信息段传递)，都将在本发明的要求保护范围之类。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
权利要求
1.一种传递业务信息的方法，其特征在于，包括下列步骤将业务信息携带于SIP消息的固定信息段中；以及将所述SIP消息在SIP用户代理之间交互，以实现业务信息的传递。
2.如权利要求1所述的方法，其特征在于，所述业务信息为业务请求信息、业务通知信息，或者业务协调信息。
3.如权利要求2所述的方法，其特征在于，若所述业务信息为业务请求信息，则业务信息包括业务标识和业务附属信息。
4.如权利要求3所述的方法，其特征在于，所述固定信息段包括SIP消息中的Request-URI信息段和/或逻辑固定信息段。
5.如权利要求4所述的方法，其特征在于，所述业务附属信息包括以下元素中的至少一种请求目的用户标识、用户业务数据和对话标识。
6.如权利要求5所述的方法，其特征在于，SIP消息中的Request-URI信息段携带所述请求目的用户标识；以及SIP消息中的逻辑固定信息段携带至少一个业务标识。
7.如权利要求6所述的方法，其特征在于，所述逻辑固定信息段还携带除请求目的用户标识以外的其它业务附属信息。
8.如权利要求4所述的方法，其特征在于，SIP消息中的Request-URI信息段携带业务标识；以及SIP消息中的逻辑固定信息段携带至少一个业务附属信息。
9.如权利要求8所述的方法，其特征在于，所述逻辑固定信息段还携带除Request-URI信息段携带的业务标识以外的其它业务标识。
10.如权利要求5所述的方法，其特征在于，SIP消息中的Request-URI信息段携带所述请求目的用户标识和业务标识。
11.如权利要求10所述的方法，其特征在于，所述业务标识作为请求目的用户标识的域名前缀。
12.如权利要求10所述的方法，其特征在于，SIP消息中的逻辑固定信息段携带除请求目的用户标识以外的其它业务附属信息。
13.如权利要求4至12任一项所述的方法，其特征在于，所述逻辑固定信息段为以下元素中的至少一种信息输入参数、信息输入头域、信息输入事件包，以及信息输入体。
14.如权利要求13所述的方法，其特征在于，所述信息输入参数位于uri-parameters参数中。
15.如权利要求13所述的方法，其特征在于，所述信息输入体位于SIP消息体中。
16.如权利要求15所述的方法，其特征在于，所述信息输入体以XML或文本格式描述。
17.如权利要求13所述的方法，其特征在于，所述逻辑固定信息段引用SIP标准协议中定义的业务信息段。
18.如权利要求13所述的方法，其特征在于，若Request-URI信息段携带所述请求目的用户标识，则由所述信息输入参数、信息输入头域、或者信息输入事件包携带业务标识，由信息输入体携带除请求目的用户标识以外的其它业务附属信息；或由所述信息输入参数、信息输入头域、或者信息输入事件包携带业务被请求使用的指示，由信息输入体携带除请求目的用户标识以外的其它业务信息。
19.如权利要求13所述的方法，其特征在于，若Request-URI信息段携带业务标识，则由所述信息输入参数、信息输入头域、或者信息输入事件包携带业务被请求使用的指示，由信息输入体携带业务附属信息。
20.如权利要求4至12任一项所述的方法，其特征在于，区分携带业务标识和业务附属信息的逻辑固定信息段。
21.如权利要求4至12任一项所述的方法，其特征在于，区分携带不同类型业务附属信息的逻辑固定信息段。
22.如权利要求21所述的方法，其特征在于，依据以下至少一种方式来区分所述不同类型业务附属信息业务附属信息的属性、业务操作方式，以及业务操作目的。
23.如权利要求4至12任一项所述的方法，其特征在于，在同一个逻辑固定信息段内携带业务标识和/或业务附属信息。
24.如权利要求23所述的方法，其特征在于，通过不同的参数在所述逻辑固定信息段内区分业务标识和业务附属信息。
25.如权利要求23所述的方法，其特征在于，通过不同的参数在所述逻辑固定信息段内区分不同类型的业务附属信息。
26.如权利要求25所述的方法，其特征在于，依据以下至少一种方式来区分所述不同类型业务附属信息业务附属信息的属性、业务操作方式、业务操作目的，以及业务类型。
27.如权利要求26所述的方法，其特征在于，所述逻辑固定信息段内至少包括以下一种参数键盘输入信息参数，以及菜单输入信息参数。
28.如权利要求27所述的方法，其特征在于，所述菜单输入信息参数包括不同的业务类型参数。
29.如权利要求27所述的方法，其特征在于，所述菜单输入信息参数包括不同属性的业务附属信息参数。
30.如权利要求27所述的方法，其特征在于，所述菜单输入信息参数包括操作模式参数。
31.如权利要求4至12任一项所述的方法，其特征在于，所述逻辑固定信息段携带业务附属信息和/或业务标识时，一并携带分别针对该业务附属信息和/或业务标识的操作模式的描述信息。
32.如权利要求1至12任一项所述的方法，其特征在于，所述业务信息涉及的业务包括被叫付费业务应用、会议业务应用、用户业务数据操作，以及消息业务。
33.如权利要求32所述的方法，其特征在于，若业务为被叫付费业务应用，则网络根据被叫付费业务标识，向计费系统指示此次呼叫费用由被叫用户承担。
34.如权利要求32所述的方法，其特征在于，若业务为会议业务应用，则网络根据会议业务标识申请会议资源，并将携带于业务附属信息中的请求目的用户标识加入会议资源。
35.如权利要求2所述的方法，其特征在于，若所述业务信息为业务通知信息或业务协调信息，则所述固定信息段为逻辑固定信息段。
36.如权利要求35所述的方法，其特征在于，所述逻辑固定信息段为以下元素中的至少一种信息输入头域，以及信息输入体。
37.如权利要求36所述的方法，其特征在于，由网络或用户生成描述业务当前使用情况的所述业务通知信息。
38.如权利要求37所述的方法，其特征在于，所述业务通知信息的接收者为业务的请求者、参与者或关联者。
39.如权利要求37所述的方法，其特征在于，所述业务通知信息以至少一种媒体类型描述。
40.如权利要求39所述的方法，其特征在于，所述媒体类型包括文本和语音。
41.如权利要求36所述的方法，其特征在于，若所述业务信息为描述业务当前使用情况的业务协调信息，则业务信息包括业务的种类和业务当前状态。
42.如权利要求41所述的方法，其特征在于，所述业务的种类为业务标识、或表示一类业务。
43.如权利要求41所述的方法，其特征在于，所述业务协调信息在处理业务的业务控制网元之间传递。
44.如权利要求36至43任一项所述的方法，其特征在于，所述业务通知信息、业务协调信息和业务请求信息中的至少两种，通过相同的信息输入头域或信息输入体携带。
45.如权利要求44所述的方法，其特征在于，所述业务协调信息和业务请求信息在信息输入头域或信息输入体中通过相同的参数携带业务标识和业务当前状态。
46.如权利要求36至43任一项所述的方法，其特征在于，所述业务通知信息、业务协调信息和业务请求信息中的至少两种，以不同参数加以区分，并通过相同的信息输入头域或信息输入体携带。
47.如权利要求36至43任一项所述的方法，其特征在于，所述业务通知信息、业务协调信息和业务请求信息中的至少两种，通过不同的信息输入头域或信息输入体携带。
48.如权利要求1所述的方法，其特征在于，所述SIP消息可以在SIP用户代理之外的SIP实体之间交互、或在所述SIP实体和SIP用户代理之间交互。
49.如权利要求3所述的方法，其特征在于，处理所述业务的业务控制网元向用户要求输入所述业务附属信息时，设定所述业务附属信息。
50.一种发起业务请求信息的用户终端装置，其特征在于，包括业务请求信息界面单元，用于向用户提供可输入业务请求信息的操作界面；业务请求信息接收单元，用于接收用户在业务请求信息界面单元提供的操作界面上输入的业务请求信息；业务请求信息发送单元，用于将业务请求信息接收单元接收的业务请求信息构造成SIP消息中的固定信息段，并发送该SIP消息。
全文摘要
本发明公开了一种传递业务信息的方法及装置，用以解决目前没有一种通用的方案可以在SIP消息中同时携带业务标识和业务附属信息的问题。包括下列步骤将业务信息携带于SIP消息的固定信息段中；将所述SIP消息在SIP用户代理之间交互，以实现业务信息的传递。通过本发明的实施，无须在新增业务时相应增加头域或事件包，从而本发明方法可作为兼容所有业务的通用方案，并且符合SIP标准协议。本发明用户终端装置包括业务请求信息界面单元、业务请求信息接收单元和业务请求信息发送单元。
文档编号H04Q7/22GK101079810SQ20071008741
公开日2007年11月28日 申请日期2007年3月16日 优先权日2006年5月10日
发明者施有铸 申请人:华为技术有限公司