WO2007128198A1

WO2007128198A1 - A method and device for transferring service information

Info

Publication number: WO2007128198A1
Application number: PCT/CN2007/001206
Authority: WO
Inventors: Youzhu Shi
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-05-10
Filing date: 2007-04-13
Publication date: 2007-11-15

Abstract

A method and device for transferring service information, solves the problem that the service identification and the service append information are carried in the SIP information, simultaneously. The method includes the following steps: the service information is carried in the fixed information segment of the SIP information; the SIP information is interacted between the SIP user agents, so as to implement the service information transmission. By the application of the present invention, when the new service is increased without increases the header or event package, therefore the method can be compatible with the all of service as a common scheme and comply with the SIP standard protocol. The user terminal device includes: service request information interface unit, service request information receiving unit and service request information transmitting unit.

Description

Method and device for transmitting business information

The present invention relates to the field of wireless communications, and in particular, to a method and apparatus for transmitting service information. Background technique

In the communication network, the user inputs information and initiates a communication request, and the request destination one is the following three types:

1. In order to establish a communication connection with another user, the request destination point is a request destination user identifier input by the user.

2. In order to use a service, the request destination is the service identifier input by the user, which indicates the identity of the service/service provided by the network.

3. In order to use a service and request to establish a communication connection with a user or operate user service data, etc., the request destination is service identification information such as the input service identifier and the request destination user identifier and user service data.

It can be seen that in order to use a service, a user usually needs to provide both service identification and service attachment information.

The SIP protocol is an application layer control protocol for establishing, changing, and terminating multimedia sessions or calls, including: multimedia conferencing, distance learning, Internet telephony, and the like. The user initiates a communication request using the SIP protocol, and the request destination is set in the Request-URI (Request -U I ) of the request-line of the request message. According to the SIP standard protocol, the Request-URI may carry a user identifier or a service identifier (in some communication networks using the SIP protocol, the service identifier is also called PSI), but the Request-URI does not support carrying the service identifier and the user at the same time. Logo.

Currently, in the SIP standard protocol, a method for carrying a service identifier and a user identifier in a communication request message is: carrying a request destination user identifier as a service attachment information in a Request-URI, and the service identifier and other service attachment information are Indicated by a different header field or event package. Since business requirements cannot be predicted in advance, adding a new header field or event package to indicate a new service is obviously not a general solution. Summary of the invention

The embodiment of the invention provides a method and a device for transmitting service information, so that the service identifier and the service accessory information can be carried in the SIP message at the same time.

The method of the embodiment of the invention comprises the following steps:

The service information is carried in the fixed information segment of the SIP message; the SIP message is exchanged between the SIP user agents to implement the delivery of the service information.

A user terminal device for initiating service request information according to an embodiment of the present invention includes: a service request information interface unit, configured to provide an operation interface for inputting service request information to the user; and a service request information receiving unit, configured to receive the user in the service The service request information input on the operation interface provided by the information interface unit is configured to: the service request information sending unit is configured to construct the service request information received by the service request information receiving unit into a fixed information segment in the SIP message, and send the SIP message.

The embodiment of the present invention no longer uses different header fields or event packets to indicate different services, but carries the service information in the fixed information segment of the SIP message. That is, the Reques t-URI can still be used to carry the service identifier and/or the request destination user identifier, and other service information is composed of logical fixed information segments (information input parameters, information input header fields, information input event packets, or information input bodies). To carry, and the service control network element identifies different services according to the service identifier. The embodiment of the present invention does not need to increase the header field or the event packet correspondingly when the service is newly added, so that the method of the embodiment of the present invention can be used as a universal solution compatible with all services, and conforms to the SIP standard protocol. DRAWINGS

1 is a flow chart of steps of a method according to an embodiment of the present invention;

FIG. 2 is a schematic structural diagram of a user terminal apparatus for initiating service request information according to an embodiment of the present invention. detailed description In order to prevent the service category from corresponding to the header field or the event package, the embodiment of the present invention provides a general method for transmitting service information. Referring to FIG. 1, the following main steps are included:

51. Carry the service information in a fixed information segment of the SIP message.

52. The SIP message is exchanged between user agents (SIP UA, User Agent) to implement delivery of service information.

53. Provide related services to users according to the delivered service information.

The service information described in step S1 includes: service request information, service notification information, and service coordination information, and the following is implemented in the present invention for service request information, and implementation of service notification information and service coordination information in the present invention. , detailed separately.

* The details of the service request information are as follows.

The service request information includes a service identifier and a service subsidiary information.

In the embodiment of the present invention, the service identifier and the service accessory information are carried in one or more fixed information segments shared by different services in the SIP message, where the fixed information segment includes: a Request-URI information segment and at least one other Fixed position (logical fixed information segment). There are three cases in which the service identifier and the service subsidiary information are carried:

The case--: the Request-URI information segment in the SIP message carries the request destination user identifier; and the logical fixed information segment in the SIP message carries at least one service identifier.

Case 2: The Request-URI information segment in the SIP message carries the service identifier; and the logical fixed information segment in the SIP message carries at least one service attachment information.

Case 3: The Request-URI information segment in the SIP message carries the request destination user identifier and service identifier. That is, the service identifier is used as the domain name prefix of the request destination user identifier. In this case, the logical fixed information segment can be considered to be in the Request-URI information field.

In the above three cases, the logical fixed information segment may be a fixed information segment, an eader, an event package, or a message body in a request line (Request-Line) in a SIP message. The fixed information segment in the request line may be a uri-pammeters parameter or a domain name prefix.

For the uri-parameters parameter, it can be defined in the uri-parameters parameter of the SIP message. An information input parameter, such as: named info-input-param, to carry business information. For the header field, an information input header field may be defined in the header field of the SIP message, such as: named Info-Input, to carry the service information.

For the event package, an information input event package may be defined in the event package of the SIP message, for example: Named as info-input, the service information is carried by the parameter of the information input event package.

For the message body, an information input media type (media type) may be defined in the SIP message body, and the format is a MIME media type, such as: named application/info-input, and the information input body (body) carries the service. information.

The above logical fixed information segment is only a logical definition, which may be a new extended uri-parameters parameter, a header field, an event packet or a message body application in the SIP protocol, or a uri-parameters parameter existing in the SIP protocol, and a header. The extended use of the domain, the event package, or the message body application; the logical fixed information segment carrying the service identifier and the logical fixed information segment of the service attached information, such as: the service identifier input header field and the service subsidiary information input header field, the service The identification input event package and the service auxiliary information input event package, the service identification input body, and the service auxiliary information input body may also carry the service identification and the service auxiliary information through different parameters in the logical fixed information segment, and may or may not be distinguished.

There are three cases in which the service identifier and the service attachment information are carried in the corresponding service request information. The following three examples are specifically described.

Method Example 1: The Request-URI carries the request destination user identifier, and the service identifier is carried in the logical fixed information segment.

In the embodiment of the present invention, the service identifier may be in a SIP URI format, such as "sip: conference-factory @home .net" indicating the conference service label "only, "sip:200@home.net" or "sip:prepaid- Card@home.net,, indicates the prepaid card number service identifier; it can also be in tel URI format, such as "tel:200;phone-context=home.net" means 200 card number service identifier; it can also be just a domain name, omitted User information ( userinfo ) and " @ " characters, such as "sip:prepaid-card.com" means the prepaid card number service identifier; also can be the traditional phone number, that is, the service feature code mode, such as "200" means the 200 card number service identifier Can also describe the business A character/attribute string, such as "prepaid-card", indicates the prepaid card number service identifier.

In the above information input parameter, or the information input header field, or the information input event package, or the information input body, only one service identifier may be carried, or more than one service identifier may be carried, that is, the user may request multiple services in sequence. .

The following describes the use of several typical services:

1. Called payment service

User A initiates a call and asks for the cost of the call to be borne by the called party. The example is as follows: INVITE sip:mary@home.net; info-input-param=800 SIP/2.0

Or ,

INVITE sip:mary@home.net; info-input-param=reverse-charging SIP/2.0 or,

INVITE sip: mary@home.net; info-input-param=<sip:reverse-charging@home.net> SIP/2.0

Or ,

INVITE si :mary @home.net; info-input-param=<sip:reverse-charging.com> SIP/2.0

Where "sip:mary@home.net" is the called user ID in the SIP URI format, ie the destination user ID of the call request, "800,, or "reverse-charging" or "sip:reverse-charging@home" .net" or "si: reverse-charging.com" indicates the different format of the called payment service identifier. When the network receives the call, it will indicate to the charging system that the call charge is from the called user according to the called payment service identifier. Bear.

Examples of carrying the called pay service identifier through the information input header field, or the information input event package, or the information input body are as follows:

INVITE sip:mary@home.net SIP/2.0

Info-Input: 800

Or,

INVITE sip:mary@home.net SIP/2.0

Subscription: info-input; service-id=800 or,

INVITE sip:mary@home.net SIP/2.0

Content-Type: application/info-input

Service-id=800

The service-id is the parameter of the information input event package or the information input body responsible for transmitting the service identifier. It can be seen that the information input event package or the information input body in the example distinguishes the service identifier and the service association by different parameters. The information (of course, it is also possible to distinguish), and the information input parameter, or the information input header field, does not distinguish between the service identifier and the service attachment information (of course, it can also be distinguished).

The above format of the called "800" service payment service identifier is also adopted, and other formats as described above may also be used.

2. Conference business

User A initiates a call and asks the call to join the conference. The example is as follows:

INVITE sip:mary@home.net; info-input-param=conference-factor SIP/2.0 where "sip:mary@home.net" is the called user ID in SIP URI format, and "conference-factory" identifies the conference service. An example of using a conference service identifier in other formats is omitted. Upon receiving the call, the network will establish a conference channel with the user A according to the conference service identifier, and establish a conference channel with the user A, so that the conference call is established between the user A and the called user.

Alternatively, User A initiates a call to several users, such as User B and User C, and asks these users to join the conference together. Examples are as follows:

INVITE sip:group-listl @home.net; info-input-param=conference-factory SIP/2.0

The sip:group-listl@home.net is a group ID that uses the user B and the user C as a group/collection. The user B identifier and the user C identifier can be set in the network in advance. It is carried in the call request message (SIP INVITE invite message), as described in the message body by XML format or other parameter format. After receiving the call, the network will apply for conference resources according to the conference service identifier, establish a conference channel with user A, and obtain the conference identifier according to the above group identifier. The corresponding set in advance in the network carried in the message or a user B and a user identification identifier C, respectively and then user B and user C to join the conference, so that the users A and B, to establish a conference call between the user C ₀

An example of carrying a conference service identifier through an information input header field, or an information input event package, or an information input body is similar to the above, and the example is omitted.

3, user business data operations

User A initiates a call and requests to set up the call forwarding user service data. The example is as follows: INVITE sip:rose@home.net; info-input-param=*40*26500000 SIP/2.0 or user A can also initiate a Subscribe to the request to complete the setting of the service data of the busy call forwarding user. The example is as follows:

SUBSCRIBE sip:rose@home.net; info-input-param=*40*26500000 SIP/2.0 where "sip:rose@home.net," is User A's own user ID, which is the destination user of this communication request. Identification (user A initiates a communication request for the purpose of operating his own user service data); "*40*26500000" contains the service identifier "*40", and the busy call forwarding destination address as another service accessory information "26500000", that is, the service identification and service attachment information are not distinguished in this example, and can of course be distinguished.

In addition, in the special case of this example, in addition to carrying the service identifier, the logical fixed information segment needs to carry the user service data (the destination address of the busy call forwarding) as the service affiliate information. In fact, since the Request-U I carries As the request destination user identifier of the service affiliate information, it is obvious that if there is another type of service attachment information in a certain service, it needs to be carried by the logical fixed information segment, such as the aforementioned called payment service, and may also carry an accessory. The information indicates whether the use of the called payment service needs to be negotiated with the called party (because the called party may not agree with the use of the service), as follows:

INVITE sip:mary@home.net SIP/2.0

Info-Input: 800; reverse-charging-consulting=true Among them, "reverse-charging-consulting" indicates whether the called party should negotiate with the called party. The parameter is set to "true" to indicate that it needs to negotiate with the called party.

For example, for the foregoing conference service, other accessory information may also be carried, indicating the conference authority of each user joining the conference (such as conference control authority, conference participants who can listen, conference participants who can only listen, etc.) ), as well as the language spoken by the user, etc., examples are as follows:

INVITE sip :group-list l@home.net SIP/2.0

Content-Type: application/info-input

Service-id= conference-factory

User=<sip: mary@home.net>; mle=only-listen; language=english

User=<sip:alice@home.net>; rule=listen-speak; language=french

The user IDs of the user B and the user C corresponding to the group identifier are carried in the call request message, and the other words are "si:mary @home.net" and "sip:alice@home.net", and "rule" " indicates the user's meeting permissions, "only-listen" means listening only, "listen-speak" means listening, and "language" means the user's language, "english" means English, and "french" means French.

Method Example 2: The Request-URI carries the service identifier, and the service accessory information is carried in the fixed information segment.

In this example, since the service ID is carried by the Request-URI, it can only be in the URI format. Similarly, the information input parameter, or the information input header field, or the information input event package, or the information input body may carry only one service attachment information, or may carry more than one service attachment information.

The following describes the use of several typical services:

1. Called payment service

User A initiates a call and asks for the cost of the call to be borne by the called party. The example is as follows: INVITE sip:reverse-charging@ ome.net; info-input-param=<sip:mary@home.net> SIP/2.0

Or,

INVITE sip:800@home.net; info-input-param=<sip:mary@home.net> SIP/2.0 or,

INVITE tel:800;phone-context=home.net; info-input-param=<sip: mary@home .net> SIP/2.0

Or,

INVITE sip:reverse-charging.com; info-input-param=<sip: mary @home .net>

SIP/2.0

Where " sip:reverse-charging@home.net " , " sip: 800@home.net , , , "tel:800;phone-context=home.net'\ "sip:reverse-charging.com" is a URI The format of the called paying service identifier, "sip:mary@home.net," is the called subscriber identity as the service affiliate information.

Examples of the called user identity that is carried as service attached information through the information input header field, or the information input event package, or the information input body are as follows:

INVITE sip:reverse-charging@home.net SIP/2.0

Info-Input: <si : mary @home.net>

Or,

INVITE sip: reverse-charging@home.net SIP/2.0

Subscription: info-input; service-param=<sip:mary@home.net>

Or; > '

INVITE sip: reverse-charging@home.net SIP/2.0

Content-Type: application/info-input

Service-param=<sip :mary @home .net>

Wherein, "service-param" is a parameter of the information input event package or the information input body responsible for transmitting the service subsidiary information, and is similar to the example in the method instance 1. In the example, the information input event package, or the information input body passes different parameters. The service identifier and the service affiliate information are distinguished (of course, it is also possible to distinguish), and the information input parameter or the information input header field does not distinguish between the service identifier and the service attachment information (of course, it can also be distinguished).

The format of the called payment service identifier of "sip: reverse-charging@home.net" is used above, and other formats as described above may also be used. And for the aforementioned affiliate information to be negotiated with the called party, in the example of method example two: ^:

INVITE sip:reverse-charging@home.net SIP/2.0

Info-Input: <sip:mary@home.net>; reverse-charging-consulting=true

2. Conference business

INVITE sip :conference-factory@home.net; info-input-param=<sip: mary@home.net> SIP/2.0

The sip:conference-factor @home.net is the conference service identifier. Generally, it identifies the conference network element address that handles the conference service control. The example of the conference service identifier in other formats is slightly, "mary@ Home.net" is the called user ID as the business affiliate information.

INVITE sip:conference-factory@home.net; info-input-param=<sip:group-listl@home.net> SIP/2.0

Or,

INVITE sip :conference-factory@home.net; info-input-param=<sip:mary@home.net>, <sip:alice@home.net> SIP/2.0 where the information input parameters can be carried to represent user B and User C as a group/collection group identifier "sip:group-listl@home.nef ' may also carry user B identifier and user C identifier: "sip :mary @home.net" and "sip:alice@ Home.net", that is, you can carry more than one auxiliary information.

Or, user A and user B are already in a call, and user A requests to join the call to the conference, as shown below:

INVITE sip: conference-factory @home .ne; info-input-param=

7sdj fkj2356 ₅ to-tag=xyz,from-tag=pdq SIP/2.0

Among them, "7sdjfkj2356,,""xyz" and "pdq" together represent the dialog of the above established call, which can uniquely identify a call, because the specified pass The voice joins the conference, so it must carry the conversation identifier as the service attachment information, and cannot carry the user ID of the user B (because user B may establish multiple calls at this time).

For the aforementioned user conference rights and the auxiliary information of the language spoken by the user, an example of the method example 2 is as follows:

INVITE sip:conference-factory@home.net SIP/2.0

Content-Type: application/info-input

User=<sip:mary@home.net>; rule^only-listen; language=english

User=<sip:alice@home.net>; rule=listen-speak; language=french

3, user business data operations

The user Α initiates a call to set the forwarded call forwarding user service data, that is, the busy call forward destination address, as follows:

INVITE sip: telecommunication-service@home.net; info-input-param=*40*26500000 SIP/2.0

Where " sip: telecommunication-service@home.net," indicates the telecommunication service identity, "*40*26500000" is the user service data containing the destination address of the busy call forwarding (26500000), which is more special because of Request - The service identifier carried by the URI ("sip:telecommunication-service@home.net") is not directly located. This is the data setting for the busy call forwarding service. Therefore, the information input parameter still needs to be carried before the busy call. The information of the service attribute ("*40"), that is, in the method instance 2, the logical fixed information segment can also carry the service identifier.

If the service identifier carried in the Request-URI can directly locate the busy call forwarding service, the information input parameter can only carry the user service data. For example, the following is as follows:

INVITE sip:cfb@home.net; info-input-param=26500000 SIP/2.0

Or,

INVITE sip:*40@home.net; info-input-param=26500000 SIP/2.0 or,

INVITE tel:*40;phone-context=home.net; info-input-param=26500000 SIP/2.0

Among them, "sip:cfb@home.net", "sip:*40@home.net" "tel: * 40;phone-context=home.net" means busy call forwarding service identification.

In addition, User A can also complete the setting of the service data of the busy call forwarding user by initiating a subscription request, as follows:

SUBSCRIBE sipxfb@home.net; info-input-param=26500000 SIP/2.0 An example of carrying a conference service identifier through a letterhead input header field, or an information input event packet, or an information input body is similar to the above example.

4, messaging business

User A initiates a message service request and sends a SIP MESSAGE message. The example is as follows: MESSAGE sip:message-center@home.net SIP/2.0

—boundary 1

Content-Type: application/info-input

User=<sip: mary@home.net>

—boundary 1

Content-Type: text/plain

Hello World!

—boundary 1

The sip:message-center@home.net is a message service identifier. Generally, it identifies the message center network element address that provides control of the message service. The message is sent to the request destination user identifier "sip: Mary@home.net" , the message content is "Hello World!" in text format.

Method Example 3: The Request-URI carries both the request destination user ID and the service identifier.

In the prior art, when the Request-URI carries the request destination user identifier, its format generally has "domain name" information. For example, "home.net" in the foregoing example is a domain name, if the domain name of the destination user identifier is requested. The previous prefix indicating the service identifier, the Request-URI can carry both the request destination user ID and the service identifier, such as the conference service, and user A initiates a call. To request the call to join the conference, the example is as follows:

INVITE si : mary@conference.home.net SIP/2.0

Where "sip:mary@conference.home.net" is added to the domain name prefix "conference" as the service identifier in the request destination user identifier "sip:mary@home.net", the network receives the call and will be based on the conference. The service identifier "conference" applies for the conference resource, and when the request destination user joins the conference, the domain name prefix is deleted, and the call is initiated to the request destination user:

INVITE sip:mary@home.net SIP/2.0

The network element that is triggered by the processing service in the network may delete the domain name prefix when the call is triggered to the network element that processes the conference service according to the conference service identifier, so that the call received by the network element processing the conference service is as follows: :

INVITE sip:mary@home.net SIP/2.0

If the request destination user ID is a group ID, the domain name prefix "sip:group-listl @conference.home.net" can also be added as the service identifier.

In the example of the method, the service auxiliary information other than the destination user identifier can still be carried by the logical fixed information segment, as shown in the example in the method instance 1 and the method instance 2.

Since the logical fixed information segment is only logically defined, the manner in which the service attached information is carried is not limited to the manner described in the above three examples, and may also include the following manner. For the sake of brevity, only the overview, the specific content can be derived from the above three examples.

1. The logical fixed information segment does not distinguish the service affiliate information of different attributes (requesting destination user identifier, user service data, dialog identifier, etc.), such as the aforementioned service-param parameter. At this time, the network can be based on different service identifiers. And the analysis of the business affiliate information to distinguish the business subsidiary information of different attributes.

2. The logical fixed information segment carrying the different service affiliate information may be distinguished according to the attributes of the service affiliate information (requesting destination user identifier, user service data, dialog identifier, etc.), such as the request destination user identifier input header field and the user service data input header. The domain, the request destination user identifier input event packet, the user service data input event packet, the request destination user identifier input body, and the user service data input body, etc., or may be different in the logical fixed information segment to distinguish the user name of the request request by different parameters. Different service attribute information, such as user service data, can even further distinguish user service data of different attributes, such as user ID, card number, password, privilege level, time, and so on.

3. The logical fixed information segments carrying different service affiliate information, such as keyboard input information and menu input information, can be distinguished according to different operation modes of the service. The keyboard input information generally refers to the service request information input by the user through the key dialing manner, and the service The request information is composed of keyboard characters input by the user. For keyboard input information, the service identifier is generally input by the user, and the keyboard input information is equivalent to the keyboard protocol of Digital Subscriber Signalling No.1.

(Keypad protocol) Keypad facility information element, which allows the user to invoke the service through the access code (ie, service signature) provided by the network. The menu input information generally refers to the user through the menu mode. The input service request information, including the menu item identifier selected by the user, and the menu input information is equivalent to the functional protocol in the digital user signaling No. 1.

(Function protocol element), where the menu item identifier can represent a service identifier, such as "CON (conference)", and can also represent a service identifier and its operation mode, such as "beginCOMF (starting conference), , "endCO F (end meeting),,, in the single input information, the service identifier (which may further include the operation mode of the service) is generally selected by the user according to the interface display or function key provided by the terminal, menu input The information may further include a parameter value corresponding to the input after the user selects the menu item identifier; or may be a different operation mode for distinguishing the service by different parameters in the logical fixed information segment.

4. The logical fixed information segments carrying different service affiliate information, such as service invocation operations and user service data operations, may be distinguished according to different operational purposes of the service; or different operations may be differentiated by different parameters in the logical fixed information segment. purpose. The call to the service can be further differentiated according to different modes of operation, such as activation, deactivation, and the like.

5. The auxiliary information of different service types can be further distinguished in the logical fixed information segment, that is, the auxiliary information parameters of different service types are defined, as in the embodiment, "reverse-charging-consulting" and "user,,, "rights", "language" is the affiliate information of the called paying service and the conference service. It should be noted that although different services are distinguished here, different logical fixed information is defined for different services. Information segment. Business type can pass The service identifier indicates that it can also be represented by the service identifier and the operation mode of the service (such as activation, deactivation, etc.). It can be seen that the method requires the service identifier to be carried in the logical fixed information segment.

Among them, as mentioned above, since the current SIP standard has defined some services and their affiliate information through different header fields, event packets, etc., such as the "calling number display restriction" service through the Privacy header field, through message- The summary event package describes "message waiting indication, service, etc., from the compatibility considerations, the information input header field defined by the embodiment of the present invention, or the information input event package, or the information input body may also refer to these existing definitions, examples are as follows : Info-Input: Privacy=id. In fact, the use of these services and their associated information defined in the current standard is generally input by the user using the aforementioned menu mode. Therefore, as a preferred embodiment, These existing definitions are referenced in the menu input information.

Among them, there is a special way of distinguishing the affiliate information of different services. When the service affiliate information is input by the network, the network setting may also indicate different types of service affiliate information. The set parameters are not required. The publicity (that is, not the standard definition) is valid only in the current service usage. The network sends a request message to the user. The message carries such a parameter that requires the user to input the parameter value. In addition to describing the parameter name, the data type of the parameter may also be defined. For example, after the communication connection between the user and the network is successfully established, the network sends a SIP INFO message to the user, prompting the user to input the card number and password, as follows:

IKFO sip:[5555::eee:ff :aaa:bbb]:8805 SIP/2.0

Content-Type: application/info-input

Require-input^card, t pe=xs: string [16], tag=abcl23

In the example, "sip:[5555::eee:fff:aaa:bbb]:8805" is the user's contact address (because the communication link has been established), "require-input" carries the parameter name and data type that the user is required to enter. The example describes the "card" (card number) whose data type is a 16-bit string, the "password" (password) whose data type is a 6-bit string, and the XML Schema specification for the data type. That is to say, the service request information carried in the request message only describes the name and the data type, and there is no specific service request information content. The request message can also be other types of messages, such as HTTP. Messages, etc.

The user receives the request message, and the interface displays the "card" and "password" parameters that the user is required to input. After the user inputs the parameter value, the user sends a SIP INFO message to the network, which carries the specific service request information content, as follows:

INFO sip:as.example.com SIP/2.0

Content-Type: application/info-input

User-input=card, value=1234567890888888, tag=abcl23

User-input=password, value=123456, tag=xyz789

In the example, " sip:as.example.com, is the domain name of the network element that performs the service, and "user-input" is the response of "require-input", which carries the parameter value entered by the user. The network can request input by the user. The parameter name matches the value of the parameter that confirms the input parameter value, such as "card", "password"; it can also be matched by the network for a corresponding tag value generated by each parameter input by the user, such as the card number parameter. The tag value is "abcl23" and the tag value of the password parameter is "xyz789".

Finally, it should be noted that different ways of distinguishing the service affiliate information may be used together, for example, the subsidiary information of different service types may be distinguished in the logical fixed information segment indicating the menu input information, and may be in the logical fixed information segment. At the same time, the parameters of the keyboard input information and the parameters carrying different attributes can be used to distinguish the auxiliary information of different attributes in the parameters carrying the keyboard input information.

In addition, when the logical fixed information segment carries the service auxiliary information, the operation mode of the service auxiliary information, such as adding, deleting, modifying, etc., may be carried, and the user service data may be added or deleted by carrying different operation modes. Or request the destination user ID, or the conversation ID. When the logical fixed information segment carries the service identifier, the operation mode of the service identifier may be carried at the same time, indicating that the service identified by the service identifier is activated, deactivated, verified, suspended (suspended), restored, etc. Call. The operation mode can be carried by the keyboard input information, or the menu input information, or can be carried by default. For example, the foregoing conference service, the operation mode of requesting the destination user identifier or the dialog identifier is considered as "joining" by default, and then Message service, request purpose The mode of operation of the user identity is considered to be a "receive" message by default, and such mode of operation can also be considered as an implicit mode of operation being carried.

If the logical fixed information segment is an information input body, the usage is as follows:

In the foregoing embodiment, the service request information other than the Request-U I is always carried by the information input parameter, or the information input header field, or the information input event package, or the information input body. In fact, when the information input parameter, or the information input header field, or the information input event package carries the service identifier (the Request-URI carries the request destination user identifier), the specific content of other auxiliary information of the service may also be input by the information input body. Carrying, as mentioned in the aforementioned called payment service, ancillary information indicating whether to negotiate with the called party, examples are as follows:

INVITE sip:mar @home.net SIP/2.0

Info-Input: 800

Content-Type: application/info-input

Reverse-charging-consulting=tme

That is to say, the information input body can be used alone as one kind of logical fixed information segment, or can be used in combination with one of the other three methods (information input parameter, information input header field or information input event package). Further, one of the other three methods may only provide an indication of service request information transmission (no specific service request information content), that is, indicating that some service is currently requested to be used, and the Request-URI is The specific content of the service request information is carried by the information input body, including the service identifier, such as the use of the information input event package and the information input body. Examples are as follows:

INVITE sip:mary@home.net SIP/2.0

Subscription: info-input

Content-Type: application/info-input

Service-id=800

Here, the information input event package only indicates that the service is requested to be used, and the specific service information content "800" (service identification) of the requested service is carried by the information input body. Of course, this information can also be used together with the information input body. The event package is named "Business Request Event Package", which is just a different name, the example is omitted. In addition, the information input body may use an XML format to describe different service request information elements, such as a service identification element, a request destination user identification element, etc., in addition to the parameter description format (text format) in the above example.

The following applies to the application scope of the service request information in the embodiment of the present invention: The method in the embodiment of the present invention is applicable to all SIP messages, such as: SIP INVITE invite message, SIP SUBSCRIBE subscription message, SIP NOTIFY notification message, SIP REFER reference message. , SIP INFO information message, SIP MESSAGE instant message, SIP PUBLISH release message, and various SIP response code messages.

Among them, in the current standard SIP protocol, only the SIP SUBSCRIBE, SIPNOTIFY, and SIP PUBLISH messages can carry event packets, and other message carrying event packets is an extension of the embodiment of the present invention.

In the embodiment of the present invention, the difference between using the information input event package and the other three methods is: using the event package to carry the service request information, or the foregoing use of the event package and the information input body, indicating that the service request is initiated. A subscription request, a business requester that initiates a business request, and a business controller that accepts and processes the business need to create and maintain a subscription instance ( subscription ) corresponding to the event package.

In addition, in the foregoing embodiment, the service identifier and the like are input when the user initiates the communication request, and may actually be generated by the network, for example, the network receives the communication request message initiated by the user, according to the service subscription information of the user, in the message. The service identifier corresponding to the service subscription information, such as the called service identifier, or the like, or the network actively initiates the communication request message, and carries the service identifier and the like in the message, and the embodiment of the present invention is also applicable to the situation.

The foregoing describes various carrying manners of the service request information in the SIP protocol. Generally, as a preferred embodiment, an information input header field or an information input body may be used, in which keyboard input information and menu input are distinguished by different parameters. Information, or use different information input header fields to distinguish, or use different information input body to distinguish, keyboard input information is used to carry information about user service data operations (such as the aforementioned "*40*26500000"), business call information ( For example, the service feature code such as "800" mentioned above, for example, the information input body is used as the logical fixed information segment:

Content-Type: application/info-input <keypad-input>*40*26500000</key-input>

Or

Content-Type: application/info-input

<keypad-input>800</keyboard-input>

Among them, "keypad-input" means keyboard input information parameters. It can be seen that the keyboard input information may be complete information input by the user's key, or may be part of the information input by the user, such as the request destination user identifier input by the user is carried by the Request-URI information segment, and the information of the input service is invoked. It is carried by the keyboard input information parameters.

The menu input information can be further divided into two types of parameters: one type of parameter carries different service type information. As described above, the service type can be distinguished according to the service identifier (that is, the foregoing menu item identifier indicates the service identifier), and the operation mode is distinguished. Calls to the business, such as:

Content-Type: application/info-input

<menu-input>

<service-id>REV_CHARGING</service-id>

<op-mode>active</ op-mode>

</menu-input>

Among them, "menu-input" means the menu input information parameter, "servie-id" is the service identification parameter (that is, identifies different service types:), "REV-CHARGING" is the identifier of the called payment service, "op-mode "For the operation mode parameter, "active" is the value of an operation mode; or, the service type and its operation mode can be used to distinguish the service type (that is, the aforementioned menu item identification indicates the operation of the service identification and service) Mode), such as:

Content-Type: application/info-input

<menu-input>

<service-op>activeREV__CHARGING</servie-op>

</menu-input>

Among them, "service-op," indicates the service identifier and its operation mode parameter, "activeREV_CHARGING" indicates that the operation mode of the called payment service is "activate the called payment service, and the service-op parameter can be regarded as the above-mentioned servie- Type and op-mode two parameters Combination.

Another type of parameter in the menu input information carries the auxiliary information of different attributes (such as the request destination user ID, the dialog identifier, etc.), and distinguishes the operation of the auxiliary information by the operation mode, such as:

Content-Type: application/info-input

<menu-input>

<user-identity>28780000</ user-identity>

<op-mode>add</ op-mode>

</menu-input>

Where "user-identity," indicates the request destination user ID parameter, and "add" (add) is the value of an operation mode.

It can be seen that the menu input information may also include different service type parameters (service identification parameters, service identifiers and their operation mode parameters), operation mode parameters, and service auxiliary information parameters of different attributes (such as user identification parameters, dialog identification parameters). Wait).

As mentioned above, the difference between the keyboard input information and the menu input information is that the service identifier is obtained in a different manner, the former is obtained by the user's key input, and the latter is obtained by the user selecting the menu displayed by the user terminal interface, and the menu display information can be preset in In the user terminal, it can also be pushed to the user terminal by the network side device, such as an application server, for example, by HTTP message push, after the user operates the menu and inputs the corresponding parameter value, the SIP message is transmitted, generally, except that the above XML description can be used. The information input body is transmitted in the SIP message body, and the SIP message may be used to carry a SOAP (Simple Object Access Protocol) or an XCAP (XML Configuration Access Protocol). SOAP or XCAP is a standardized application of XML. For details, please refer to the relevant standards. Use the SOAP or XCAP format for the information input body, or define a generic MIME media type for SOAP or XCAP applications, such as "application/xcap+xml"; or define a MIME media type that indicates the specific application scenario of SOAP or XCAP. For example, "application/xcap-srvinfo+xml" indicates that the XCAP is applied to the service information of the embodiment of the present invention; or the MIME media type of the information input body is still maintained, and the application format of the SOAP or XCAP is SIP-agent-to-SIP. Message body parsing Obtained.

It should be further noted that the information pushed by the network side device to the user's terminal may be complete service request information, including the service identifier and the service affiliate information, and after the user operates the service request, the SIP message sent by the user terminal is requested by Request- The URI information segment carries the service identifier, and the logical fixed information segment represented by the menu input information carries the service attached information, or the Request-URI information segment carries the request destination user identifier, and the logical fixed information segment represented by the menu input information carries the service identifier and Other possible service auxiliary information. For this reason, the information pushed by the network side device to the user terminal may identify which information is carried by the Request-URI information segment, which information is carried by the logical fixed information segment, or may be operated by the user. Time distinction and so on.

The service request information is generally initiated by the user terminal. The embodiment of the present invention further provides a user terminal device for initiating service request information. Referring to FIG. 2, the device includes a service request information interface unit and service request information that are sequentially connected. a receiving unit and a service request information sending unit, wherein:

The service request information interface unit is configured to provide an operation interface for inputting service request information to the user, where the interface is composed of a display interface for displaying information to the user and an input interface for inputting information by the user, and the display interface may be at least the following three. One of the modes: pre-stored in the user terminal device, the network side device is pushed into the user terminal device, and the user is preset in the user terminal device, wherein the user is preset in the user terminal device The interface can be completed by the user through the interface operations provided by the other two methods, such as a telephone directory preset by the user in the user terminal device.

The service request information receiving unit is configured to receive service request information input by the user on the service request information interface unit, and the user input mode may be at least one of the following two methods:: inputting information by a button, selecting a service request built in the service Information input in the information interface unit, such as a phone number or service identifier displayed by the user in the service request information interface unit.

The service request information sending unit is configured to construct the service request information received by the service request information receiving unit into a fixed information segment in the SIP message, and send the SIP message. The configuration manner may be at least one of the following three ways: the request received by the service request information receiving unit The destination user identifier is configured as a Request-URI information segment, and the service identifier received by the service request information receiving unit and other possible service attachment information are configured into logical fixed information segments; the service identifier received by the service request information receiving unit Constructing a request-URI information segment, constructing the service attached information received by the service request information receiving unit into a logical fixed information segment; constructing the request destination user identifier and the service identifier received by the service request information receiving unit into a Request-URI Information segment. The logical fixed information segment includes a keyboard input information segment and/or a menu input information segment, which may be a uri-parameters parameter, or a header field, an event packet, or a message body.

• Details of the service notification information and service coordination information are as follows.

In addition to requesting information, the service information may also have notification information. After the service is requested, the corresponding service notification information may notify the service requester of the current service usage. At this time, the service controller may pass the SIP NOTIFY message, SIP PUBLISH. The message, the SIP INFO message, the SIP MESSAGE message, and various SIP response code messages, etc., carry the service notification information to the service requester.

Generally, the current usage of the service can be directly described in the text output body. For example, when the conference service is in use, if the user alice exits the conference, the network element as the service controller will be sent to the service. The requester transmits a service notification message, and the service requester user A is notified of the fact in the message output body by the text "Alice has quitted the conference".

The receiver of the service notification information may be a participant or a related party of the service, and notify the user of the current service usage. If the conference service is in use, the user alice withdraws from the conference as the service control. In addition to sending a service response message to the service requester, the network element of the user may also send a service notification message to another conference participant mary.

The notification content in the service notification information, a ^: is generated by the network, or it can be entered by the user.

The manner in which the service notification information describes the current usage of the service, in addition to the text mode described above, may also be a notification mode of other media types, such as voice (signal tone or voice notification, etc.), etc., when the aforementioned conference service is in use, The user alice exits the conference, except the network element as the service controller. It is possible to send a text-based service notification message, and also send a service notification message carrying a voice notification of "Alice exiting the conference".

For the voice service service notification information content, it may be a link address of the voice media, a voice type indication, or a voice description (such as signal to audio rate, intermittent ratio, etc.).

For the same service usage, the service notification information can carry only one notification method, and can also carry notification methods of different media types. Generally, due to the different capabilities of the user terminal, if some terminals do not have the text display capability, the notification mode carrying different media types at the same time can be more versatile.

In addition, the service information may be service coordination information in addition to the service request information and the service notification information, and the receiver of the service coordination information uses the information to process the service. For example, one communication may trigger multiple different services. When services are handled by different service control NEs in the network, and there are conflicts such as compatibility or priority between these services, the service usage of different services needs to be transmitted between these service control NEs to coordinate these services. Call.

Although the service coordination information and the service notification information are both the current usage of the delivery service, the latter represents only a kind of notification information. For example, when the text description is used, the receiver of the service notification information only displays the notification content, instead of going. The specific business meaning is analyzed; for the former, since the coordination information is to be used to process the call of the service, the receiver of the service coordination information must be able to parse the information content, and extract the type of the service and the current usage of the service. Therefore, in the service coordination message, the specific service type and the current status of the service must be defined. For example, the foregoing service identifier can be used to indicate the type of the service. The current status of the service can be defined as "waiting for activation" and "already activated." ", "waiting for undo", "temporary undo", "already revoked", "deactivated", "paused", etc., in the form of a textual string. Of course, instead of a specific service identifier, the type of the service may be represented. Instead, the same service feature is extracted from the services with similar characteristics, and the specific service is classified into different types to represent the type of the service, that is, the type of the service. It is a type of business with the same business characteristics.

When the aforementioned conference service is in use, the user John calls the conference service requester user A, User A sends a SIP INVITE message, which may trigger a certain service, and the service and conference services cannot conflict with each other. Therefore, after receiving the SIP INVITE message, User A can return the SIP response code message. The service coordination information is carried, and the current usage of the conference service is delivered to the service control network element of the service, where the coordination information includes: the conference service identifier and the current status of the "already activated" service.

Similarly, the service coordination information can be applied to all of the aforementioned SIP messages.

In the embodiment of the present invention, the service notification information and the service coordination information may be carried by the information input body shared by different services in a fixed position in the SIP message by defining another information input media type in the SIP message body. Or define another information input header field shared by different services in the SIP message, and carry the service notification information and the service coordination information through the header field.

The information input body and the information input header field are only logically defined, and may be a new extended message body application or a header field defined in the SIP protocol, or may be an extended use of a message body application or a header field existing in the SIP protocol. The service notification information and the service coordination information may be respectively carried by different information input bodies or information input header fields, and the service notification information and the service coordination information may be carried in the same information input body or the information input header field.

In some cases, the service notification information and the service coordination information may be the same information segment in the SIP protocol, indicating that it can be used as a service notification or as a service coordination, such as the following, in the SIP packet domain and other When the protocol domain is interconnected, the service notification information is to be carried between different protocols. Obviously, the network needs to parse the service notification information for processing, and convert it into the information carried by the peer network protocol, and also according to the peer network protocol. The bearer information generates service notification information. At this time, the service notification information is also service coordination information. For example, a call transfer indicating "call transfer" can be sent to the user terminal in the SIP packet domain. (the service notification information receiver) performs display, and when interworking with the circuit domain, the interworking network element needs to parse the information segment assignment and convert it into an integrated service digital network user part (Ategrated Services Digital Network User Part) protocol. The message segment indicating "call transfer" is assigned, that is, "call transferred" Service notification information is coordinate information service, i.e. the exchange NE service notification information receiver is also coordinated service information receiver. Alternatively, there is a situation, the user terminal needs The service information is displayed on the terminal interface according to the received service information, and the corresponding service processing is performed according to the received service information. At this time, the service information is the service notification information and the service coordination information. For example, the user terminal receives the call. To a new incoming call, the incoming message carries a "call waiting" message segment, and the user terminal parses the information segment, and accordingly displays "new incoming call" on the terminal interface, and processes the call accordingly. Waiting for a call to the business.

In addition, the information input body or the information input header field carrying the service notification information and the service coordination information, and the information input body or the information input header field carrying the service request information also share a message body or a header domain application, and are distinguished by different parameters. , of course, can also be different message body or header domain applications. Further, for the service request information and the service coordination information, the service identification parameter may be carried, and the operation mode of the service and the current state of the service have similarities, so that the same information input body or information input head may be In the domain, the same parameters are used to represent the service request information and the service coordination information carried in the menu input information. Examples are as follows:

Content-Type: application/info-input

<service-info>

<service-id>REV_CHARGING</service-id>

<service-status>require-active</service-status>

</service-info>

'Which, since the same parameters are used to represent the service request information and the business coordination information, the above parameter "menu-input" indicating the menu input information cannot be used instead.

The "service-info" parameter indicates the service information related to the service type. "service-status" is the current state parameter of the service. It can also be used to indicate the operation mode for the service. "require-active" is a service. The current state parameter takes a value, which is equivalent to the value of the aforementioned operation mode parameter.

"active", which means the current status of the "waiting for activation" service, of course, can also represent the operation mode of the service and the current status of the service.

In addition, the SIP message carrying the service information is previously exchanged between the SIP user agents to implement the delivery of the service information. In fact, according to the SIP standard, the SIP user agent is a type of SIP entity, which is obviously defined according to the standard. SIP messages carrying service information in fixed information segments are also available. It is passed between other SIP entities, such as Redirect Server, Proxy Server, Registrar, and between SIP user agents and these SIP entities.

Finally, it should be noted that the information input parameter, or the information input header field, or the information input event package, or the information input body defined by the embodiment of the present invention includes various service identifiers, names of service auxiliary information, and description formats. For example, if there are other such definitions, although the names and formats are different, the characteristics of the SIP protocol carrying service information (service identification, service attachment information, and service notification information) of the embodiment of the present invention are included. The service coordination information is transmitted in the fixed information segment of the message, and will be within the scope of the claimed invention.

In summary, the embodiment of the present invention does not use different header fields or event packets to indicate different services, but carries the service information in the fixed information segment of the SIP message. That is, the Request-URI can still be used to carry the service identifier and/or the request destination user identifier, and other service information is fixed by the information section (information input parameter, information input header field, information input event package, or information input body). ) to carry, and the service control network element identifies different services according to the service identifier. The embodiment of the present invention does not need to add a header field or an event package correspondingly when a service is added, so that the method of the embodiment of the present invention can be used as a general solution for all services and conforms to the SIP standard protocol.

It is apparent that those skilled in the art can make various modifications and variations to the invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of the inventions

Claims

Rights request

A method for delivering business information, comprising the steps of:

Carrying the service information in a fixed information segment of the SIP message;

The SIP message is exchanged between SIP user agents to implement delivery of service information.

The method according to claim 1, wherein the service information is service request information, service notification information, or service coordination information.

The method according to claim 2, wherein, if the service information is service request information, the service information includes: a service identifier and a service affiliate information.

The method according to claim 3, wherein the fixed information segment comprises: a Request-URI information segment and/or a logical fixed information segment in the SIP message.

The method according to claim 4, wherein the service affiliate information comprises at least one of the following elements: a request destination user identifier, user service data, and a dialog identifier.

The method of claim 5, wherein the Request-URI information segment in the SIP message carries the request destination user identifier; and the logical fixed information segment in the SIP message carries at least one service identifier.

7. The method according to claim 6, wherein the logical fixed information segment further carries other service attached information other than the request destination user identifier.

The method according to claim 4, wherein the Request-URI information segment in the SIP message carries the service identifier; and the logical fixed information segment in the SIP message carries at least one service attachment information.

The method according to claim 8, wherein the logical fixed information segment further carries a service identifier other than the service identifier carried in the Request-URI information segment.

10. The method according to claim 5, wherein the Request-URI information segment in the SIP message carries the request destination user identifier and the service identifier.

The method according to claim 10, wherein the service identifier is used as a domain name prefix of the request destination user identifier.

12. The method according to claim 10, wherein the logical fixed information segment in the SIP message carries other service attached information except the request destination user identifier.

The method according to any one of claims 4 to 12, wherein the logical fixed information segment is at least one of the following elements: an information input parameter, an information input header field, an information input event package, and Information input body.

14. The method of claim 13, wherein the information input parameter is located in a uri-parameters parameter.

15. The method of claim 13, wherein the information input body is located in a SIP message body.

16. The method of claim 15, wherein the information input body is described in XML or text format.

17. The method according to claim 13, wherein the logical fixed information segment refers to a service information segment defined in a SIP standard protocol.

The method according to claim 13, wherein if the Request-U I information segment carries the request destination user identifier, the information input parameter, the information input header field, or the information input event packet carries the service. Identifying, by the information input body, other service accessory information other than the request destination user identifier; or the information input parameter, the information input header field, or the information input event packet carrying service is requested to be used, and is carried by the information input body Other business information than the request destination user ID.

The method according to claim 13, wherein if the Request-URI information segment carries the service identifier, the information input parameter, the information input header field, or the information input event packet carries an indication that the service is requested to be used. , the service input body carries the service subsidiary information.

The method according to any one of claims 4 to 12, characterized in that the logical fixed information piece carrying the service identification and the service attachment information is distinguished.

The method according to any one of claims 4 to 12, characterized in that the logical fixed information piece carrying different types of service attached information is distinguished.

22. The method of claim 21, wherein the method is based on at least one of the following Differentiating the different types of service affiliate information: attributes of service affiliate information, business operation mode, and business operation purpose.

The method according to any one of claims 4 to 12, characterized in that the service identifier and/or the service affiliate information are carried in the same fixed information segment.

24. The method of claim 23, wherein the service identification and the service attachment information are differentiated within the logically fixed information segment by different parameters.

25. The method of claim 23, wherein different types of service affiliate information are distinguished within the logical fixed information segment by different parameters.

The method according to claim 25, wherein the different types of service affiliate information are distinguished according to at least one of the following: an attribute of the service attached information, a service operation mode, a business operation purpose, and a service type.

The method according to claim 26, wherein the logical fixed information segment includes at least one of the following parameters: a keyboard input information parameter, and a menu input information parameter.

28. The method of claim 27, wherein the menu input information parameters comprise different service type parameters.

29. The method of claim 27, wherein the menu input information parameter comprises a service ancillary information parameter of a different attribute.

30. The method of claim 27, wherein the menu input information parameter comprises an operational mode parameter.

The method according to any one of claims 4 to 12, wherein the logical fixed information piece carries the service attached information and/or the service identifier, and carries the information and/or the service separately for the service. Description of the identified operating mode.

The method according to any one of claims 1 to 12, wherein the service related to the service information comprises: a called pay service application, a conference service application, a user service data operation, and a message service.

33. The method according to claim 32, wherein if the service is a called pay service application, the network, according to the called pay service identifier, indicates to the charging system that the call charge is used by the called party. The user bears.

The method according to claim 32, wherein, if the service is a conference service application, the network applies for the conference resource according to the conference service identifier, and adds the request destination user identifier carried in the service accessory information to the conference resource.

The method according to claim 2, wherein if the service information is service notification information or service coordination information, the fixed information segment is a logical fixed information segment.

36. The method of claim 35, wherein the logically fixed information segment is at least one of the following: an information input header field, and an information input body.

37. The method of claim 36, wherein the service notification information describing a current usage of the service is generated by a network or a user.

38. The method of claim 37, wherein the recipient of the service notification information is a requester, participant or affiliate of a service.

39. The method of claim 37, wherein the service notification information is described in at least one media type.

40. The method of claim 39, wherein the media type comprises: text and voice.

The method according to claim 36, wherein, if the service information is service coordination information describing a current usage of the service, the service information includes: a type of the service and a current status of the service.

The method according to claim 41, wherein the type of the service is a service identification, or represents a type of service.

43. The method of claim 41, wherein the service coordination information is communicated between service control network elements of the processing service.

The method according to any one of claims 36 to 43, wherein at least two of the service notification information, the service coordination information, and the service request information are input into the header field or the information input body through the same information. carry.

45. The method of claim 44, wherein the service coordination information and service The request information carries the service identifier and the current state of the service through the same parameters in the information input header field or the information input body.

The method according to any one of claims 36 to 43, wherein at least two of the service notification information, the service coordination information, and the service request information are distinguished by different parameters, and the same information is used. The input header field or the information input body is carried.

The method according to any one of claims 36 to 43, wherein at least two of the service notification information, the service coordination information, and the service request information are input into a header field or an information input body through different information. carry.

48. The method of claim 1, wherein the SIP message can interact between SIP entities other than the SIP user agent or between the SIP entity and the SIP user agent.

49. The method according to claim 3, wherein the service control network element that processes the service sets the service accessory information when the user requests to input the service accessory information.

50. A user terminal device for initiating service request information, comprising: a service request information interface unit, configured to provide an operation interface for inputting service dependency information to a user;

a service request information receiving unit, configured to receive service request information input by a user on an operation interface provided by the service request information interface unit;

The service request information sending unit is configured to construct the service request information received by the service request information receiving unit into a fixed information segment in the SIP message, and send the SIP message.