WO2007068206A1

WO2007068206A1 - A method and network entity for operating the session capability information

Info

Publication number: WO2007068206A1
Application number: PCT/CN2006/003395
Authority: WO
Inventors: Long Luo; Lei Zhu; Yajuan Wu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2005-12-13
Filing date: 2006-12-13
Publication date: 2007-06-21
Also published as: CN1984135A; CN100550908C

Abstract

A method and network entity is used in operating the session capability information. The method includes: the session capability message carried in the session information is operated after the network entity of the session initiate protocol SIP network receives the session information, which carries on the session capability message. The method and the network entity provided in the invention can make process of the service capability negotiation between the calling party and the called party simply, so as to reduce the relay the setting up the session.

Description

Method and network entity for performing session capability information operation

Technical field

The present invention relates to session establishment techniques in a Session Initiation Protocol (SIP) network, and more particularly to a method and network entity for performing session capability information operations during session establishment. Background of the invention

With the development of broadband networks, mobile communications are not limited to traditional voice communications, but can also combine multiple media services such as audio, video, pictures and text. A variety of media services can meet the diverse needs of user equipment (UE) by combining data services such as presence, short message, web browsing, location information, push service (PUSH) and file sharing.

Driven by various data service applications, standards organizations such as 3GPP and 3GPP2 have successively launched IMS architectures. The purpose is to implement a variety of multimedia service applications using a standardized open architecture in mobile networks, providing more to the UE. Choice and richer feelings.

In the 3GPP Release 5 (R5, Release) phase, IMS is introduced, which is superimposed on the packet domain network, by Call Control Function (CSCF), Media Gateway Control Function (MGCF), Media Resource Function (MRF) and Home Subscriber A functional entity such as a server (HSS). The CSCF can be divided into three logical entities: service CSCF (S-CSCF), proxy CSCF (P-CSCF) and query CSCF (I-CSCF). The S-CSCF is a service switching center of the IMS, performs session control, maintains session state, is responsible for managing UE information, and generates charging information. The P-CSCF is an access point for the UE to access the IMS, completes UE registration, and is responsible for quality of service ( QoS) Control and security management; The I-CSCF is responsible for interworking between IMS domains, managing the allocation and selection of S-CSCFs, hiding network topology and configuration, and generating billing data. The MGCF controls the gateway to implement interworking between the IMS and other networks. MRF provides media resources. The HSS stores subscription data, configuration information, and the like of the UE.

The IMS network defined by 3GPP can also be applied to the packet network defined in 3GPP2, providing interworking with multiple types of networks, and achieving independence from the use of terminal types. Therefore, there is no restriction on IMS being applied only to 3GPP related networks and applications. Other types of access networks and bearer network services and applications can also be implemented by the IMS architecture.

SIP is an IP telephony signaling protocol proposed by the Internet Engineering Task Force (IETF). SIP is used to initiate a session. It can control the establishment and termination of multimedia sessions attended by multiple participants, and can dynamically adjust and modify session attributes such as session bandwidth requirements, media types (voice, video, text, etc.), media. Codec format, support for multicast and unicast, etc. In IMS, the SIP protocol is used as the signaling control protocol for IP multimedia sessions.

The service platform of the IMS network is a service platform based on SIP established Internet Protocol (IP) telephony sessions. When the terminal needs to enjoy the application service on the IMS network, a session needs to be established between the terminal and the terminal or the AS. In the process of establishing the session, the calling and called terminals need to negotiate the service capability, and the IMS in the process of the service capability negotiation. Network entities on the network may participate in the process of business capability negotiation. The service capability of a session refers to the ability to implement the required business needs after the negotiation of the session is completed. The information of the business capability can be carried by the message body of the SIP message, and can be through Content/sdp, Content/application or Content/mime.

In the existing 3GPP IMS specification, when the calling and called terminals negotiate the session through the IMS network, the calling terminal sends a session establishment request message to the called terminal through the IMS network, and the request uses the SIP message and carries the session capability information, and the request passes the Processing of network entities in an IMS network. The network entity in the IMS network forwards the request to the called terminal. When the called terminal determines that it does not support the service capability of the calling terminal according to the session capability information carried in the request, it returns to the network entity or the master in the IMS network. Calling the terminal error response message, the network entity or the calling terminal in the IMS network receives the error response message and then re-executes the main called terminal. Negotiation and conversion of end business capabilities.

The service capability described herein refers to various capabilities required by the network entity of the IMS network or the calling and called terminal to implement the service, such as codec capability, multimedia processing capability, media parameter capability, and application, etc. Information refers to the description of service capabilities, such as the method specified by the Session Description Protocol (SDP), and can also be described in the message body using XML voice and SCRIPT methods.

1 is a flow chart of media parameter capability negotiation stipulated by the existing IMS specification. The network entity included in the process includes: a calling terminal UE1, a P-CSCF#1 to which the UE1 belongs, an S-CSCF#1 to which the UE1 belongs, and a called terminal. UE2, P-CSCF #2 to which the called terminal UE2 belongs, and S-CSCF#1 to which UE1 belongs, the specific process is as follows:

Step 101: The UE1 adds an encoding parameter to the load of the SDP, where the encoding parameter reflects the service capability of the UE1 and the encoding parameters expected in the session.

Step 102: Carry an SDP in the session establishment request (INVITE) sent by UE1, and send it to P-CSCF#1.

Step 103: The P-CSCF#1 checks the media parameter information in the SDP. If the P-CSCF#1 cannot allow the media parameter information to be used in the session due to local policy reasons or QoS authorization reasons, the service capability negotiation is denied. . The rejection message will contain enough information to inform UE1 so that UE1 initiates the next session negotiation based on this information.

Step 104: P-CSCF#1 allows media parameter information to be used in the session, and CSCF #1 forwards the INVITE to S-CSCF #1.

Step 105: The S-CSCF#1 checks the media parameter information described in the SDP. If the S-CSCF#1 cannot allow the media parameter information to be used in the session due to the local policy reason or the UE1 subscription, the service capability negotiation is rejected. The rejection message will contain enough information to inform UE1 so that UE1 initiates the next session negotiation based on this information.

Step 106, S-CSCF#1 allows media parameter information to be used in the session, S-CSCF# 1 Forward the INVITE to S-CSCF # 2.

Step 107: The S-CSCF #2 checks the media parameter information described in the SDP. If the S-CSCF #2 cannot allow the media parameter information to be used in the session due to the local policy reason or the UE2 subscription, the service capability negotiation is rejected. In the rejection message, sufficient information is sent to UE1 so that 'UE1 initiates the next session negotiation based on this information.

Step 108: S-CSCF#2 allows the media parameter information to be used in the session, and S-CSCF#2 forwards the INVITE to P-CSCF #2.

Step 109: The P-CSCF#2 checks the media parameter information described in the SDP. If the P-CSCF #2 cannot allow the media parameter information to be used in the session due to local policy reasons or QoS authorization reasons, the service capability negotiation is rejected. . The rejection message will contain enough information to inform UE1 so that UE1 initiates the next session negotiation based on this information.

At this time, P-CSCF # 2 generates an authorization token (Authentication-Token).

Step 110: P-CSCF#2 allows media parameter information to be used in the session, P-CSCF#2 forwards the INVITE to UE #2, and the authorization token is included in the INVITE.

Step 111: UE#2 determines a complete set of encodings for completing the session, and compares the intersection of the encoded information in the SDP in the message. If any media is not supported, the port number of the media description is set to 0, for the supporting media. The port number of the media description is inserted to assign a port number.

Step 112: UE2 returns an SDP response to P-CSCF #2, that is, a description of a group of media streams and codes.

Step 113: P-CSCF#2 authorizes retaining these media streams and encoded QoS resources. Step 114: P-CSCF # 2 forwards the SDP response to S-CSCF #2.

Step 115: S-CSCF#2 forwards the SDP response to S-CSCF#1.

Step 116: S-CSCF#1 forwards the SDP response to P-CSCF#1.

Step 117, P-CSCF#1 authorizes retaining these media streams and encoded QoS resources. Step 118: The authorization token is included in the SDP description, and the P-CSCF forwards the SDP response to UE # 1.

Step 119: UE1 determines which media streams are used in the session, and UE1 determines which encoding parameters are used in the media stream. If more than one media stream can be selected in a session, or if more than one encoding parameter can be selected in a media stream, then UE1 needs to negotiate with UE2 again to reduce the number of encoding parameters to one.

Steps 120-124, UE1 sends a proposed SDP (sold SDP) to UE2.

Using this method, the coding parameters used in the session can be negotiated during the session negotiation process, and the coding parameters are the service capabilities negotiated by the called terminal.

During the negotiation of the session, the network entity decides whether to accept the negotiation request according to the local policy, the quality of service (QoS) authorization, or the subscription of the user. If the network entity rejects the session negotiation, it returns a rejection response, and in the response of the rejection. Provide sufficient information to the calling terminal so that the calling terminal decides how to proceed to the next session negotiation.

2 is a flow chart of intercepting a signaling part of a multiparty call session established by a calling and a called terminal in an IMS network. The IMS network entity involved in this process includes: an S-CSCF, an AS in the IMS network, and an MRF that provides IMS network media resources. The specific steps are as follows:

Step 200: The calling terminal UE1 sends an INVITE request carrying the session capability information of the UE1 to the S-CSCF, where the request carries a service identifier, which is used to identify the service type of the current service request.

Step 201: The S-CSCF returns, to the UE1, a response that receives the INVITE request, that is, a 100 Trying message.

For each INVITE request, there will be a response to a 100 Trying message, which is not identified in the following flow.

Step 202: The S-CSCF determines, according to the service identifier carried in the INVITE request, the AS that processes the current service request, and forwards the INVITE request that carries the session capability information of the UE1 to the determined AS. Step 203: The AS returns a response of the INVITE request to the S-CSCF.

Step 204: The S-CSCF sends an INVITE request carrying the session capability information of the UE1 to the called terminal UE2.

Step 205: The UE2 determines, according to the session capability information of the UE1 that is carried by the INVITE request, that it does not support the service capability of the UE1, and returns an error message that the S-CSCF carries the session capability information supported by the UE2, and the error message indicates that the UE1 service capability is not supported. , 606 Response ( Not Acceptable, UA SDP ) in the 3GPP IMS specification.

Step 206: The S-CSCF sends an acknowledgement message, that is, an ACK message, to the UE2 that receives the error message.

Step 207: The S-CSCF forwards an error message, that is, a 606-2 message, to the AS.

Step 208: After the AS that receives the error message determines the service capability conversion, it is determined that the service capability needs to be converted, and the process proceeds to step 209.

Step 209: The AS returns an acknowledgement message, that is, an ACK-2 message, to the S-CSCF that receives the error message.

Step 210: The AS sends, to the S-CSCF, session capability information that is supported by the UE2.

The INVITE request, the SDP of the UE2 is obtained by the AS from an error message carrying the session capability information supported by the UE2.

Step 211: The S-CSCF forwards the INVITE request carrying the SDP supported by the UE2 to the step 212, and the MRF determines the session capability information supported by the UE2 carried by the INVITE request according to the media resource stored by the MRF, and determines that the UE2 supports the session carried by the INVITE request. The capability information is sent to the S-CSCF, which is a 200 OK response carrying the media parameter.

Steps 213 to 214: The S-CSCF sends a 200 OK response to the AS, and the AS returns an acknowledgement message, that is, an ACK-3 message, to the S-CSCF to receive the 200 OK message. Step 215: The S-CSCF returns an acknowledgement message, that is, an ACK-3 message, to the MRP that receives the 200 OK message.

Step 216: Determine that the data transmitted between the UE1 and the UE2 is to be converted according to the SDP supported by the UE1 and the service capability supported by the UE2, and then continue to perform the subsequent establishment session according to the 3GPP IMS specification until the UE1 and the UE2 Establish a session between.

It can be seen from the schemes shown in FIG. 1 and FIG. 2 that during the process of negotiating the calling and called terminal capabilities, the network entity on the called terminal does not support the service capability of the calling terminal or the session negotiation transmission path does not support the master. When the service capability of the terminal is called, an error message is sent. When the network entity or the calling terminal on the session negotiation transmission path receives the error message of the called terminal, the service capability negotiation between the calling and the called terminal is re-established. The session of the secondary master called terminal.

When the called terminal cannot establish a session when receiving the session establishment request, it returns an error response message to the calling terminal, and notifies the reason that the session negotiation cannot be accepted, and the calling terminal re-schedules the session according to the prompt of the error response message. After receiving the error response message, the calling terminal re-negotiates the service capability between the calling and called terminals, which causes a delay in session establishment, thereby affecting the session quality between the calling and called terminals. Further, in some IMS network-based service applications, for example, a cellular network-based push-to-talk (PoC, PTT over Cellular) service has strict requirements on the delay of session establishment, when the called terminal returns an error message. At this time, the renegotiation service capability between the calling and the called terminals increases the delay of the session processing and reduces the satisfaction of the user, which hinders the development of the PoC service in the IMS network.

Further, with the development of multimedia applications of a Session Initiation Protocol (SIP)-based packet switched network, multiple network entities may participate in the establishment of a session at the same time, and multiple network entities jointly provide a service, for example, by different The media resource processing entity processes the audio and video media separately, and the media parameters described by the SDP protocol may include participation services. The media formats and coding parameters of multiple network entities or terminals of different carrier networks will increase in both quantity and type. However, the description methods supported by the existing SDP protocol cannot distinguish the media descriptions from different sources in the description of the media parameters by the SDP protocol, and the SIP used by the receiver of the session negotiation does not support the SIP message body. Carrying the requirements of multiple different SDP descriptions from different network entities or terminals. These requirements, which emerge with the development of technology, make it necessary to technically define the priority and attributes of the session capability information of a session described, and to expand the use of session capability information by SIP. Summary of the invention

The embodiment of the invention provides a method for performing session capability information operation, which can process the negotiation process of the service capability of the calling and called terminals, thereby reducing the delay of session establishment. Further, the method can also simplify the service capability negotiation process when the SIP network provides the PoC service, and reduce the delay of the session establishment.

The embodiment of the present invention further provides a network entity that performs session capability information operation, and the network entity can simplify the process of negotiating service capability of the calling and called terminals, thereby reducing the delay of session establishment. Further, the method can also simplify the service capability negotiation process when the SIP network provides the PoC service, and reduce the delay of the session establishment.

According to the above objective, the technical solution of the embodiment of the present invention is implemented as follows:

A method for performing session capability information operations, the method comprising:

Session Initiation Protocol After receiving the session message carrying the session capability information, the network entity in the SIP network operates the session capability information carried in the session message.

A network entity that operates with session capability information, the network entity includes: a receiving module, a policy acquiring module, and a processing module that are sequentially connected, a response module and a forwarding module respectively connected to the processing module; wherein, the receiving module, the response module, and the forwarding Module is also in the SIP network Each terminal is connected;

The calling party sends the session message to the receiving module, and after obtaining the policy for processing the session message, the policy obtaining module transparently transmits the session message received by the receiving module to the processing module and sends the policy for processing the session message to the processing module, and the processing module After the session message is processed by the policy for processing the session message, the session establishment request message is sent to the forwarding module, or the session establishment response message is sent to the response module, and the forwarding module sends the session establishment request message to the called party, and the response module establishes the session. A response message is sent to the called party.

As can be seen from the foregoing solution, in the process of the service capability negotiation between the calling and the called terminal, when the calling party sends a session establishment request message carrying the service capability of the calling party to the SIP network, the network entity in the SIP network The content of the message body of the session establishment request message can be directly changed, and the session capability information supported by the SI network is carried in the request message and sent to the called party, and the sent session capability information is distinguished by the attribute information. The information can be used as the basis for the operation of the session capability information by the network entity. The called party selects the service capability it supports and sends it to the network entity in the SIP network. The network entity in the SIP network according to the received service capability supported by the called party. Follow up. In addition, in the process of the service capability negotiation between the calling and the called terminal, the called party may also return a session establishment response message carrying the service capability of the calling party to the SIP network, and the network entity in the SIP network may directly change the session. The content of the message body of the request message is set, and the session capability information supported by the SIP network is carried in the request message and sent to the calling party, and the calling party selects the service capability supported by the calling party and sends it to the SIP network. The network entity, the network entity in the SIP network performs subsequent processing according to the accepted service capabilities supported by the calling party.

Because the calling terminal in the embodiment of the present invention does not wait for the called terminal to re-request the service capability between the calling and called terminals after returning the reject message, as in the prior art, but directly provides the SIP network session to the called terminal. The capability information is selected by the called terminal, thereby the process of negotiating the service capability of the calling and called terminals, and reducing the delay of session establishment. The service capability operation network entity and method according to the embodiment of the present invention may also be performed.

It is used in the PoC session establishment process. Therefore, when the SIP network provides the PoC service, the method simplifies the service capability negotiation process, reduces the delay of session establishment, and improves the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a flow chart of media parameter capability negotiation stipulated by the existing IMS specification;

2 is a flow chart of intercepting a signaling part of a multiparty call session established by a calling and a called terminal in an existing IMS network;

FIG. 3 is a signaling flowchart of performing service capability negotiation according to the present invention;

4 is a signaling flowchart of Embodiment 1 of a service capability negotiation performed by a terminal when the IMS network adopts a PoC service according to the present invention;

FIG. 5 is a signaling flowchart of Embodiment 2 of the service capability negotiation performed by the terminal when the IMS network adopts the PoC service according to the present invention;

FIG. 6 is a schematic diagram of the service capability conversion of the SDP supported by the called terminal by the application server in the IMS network according to the present invention;

7 is a flow chart of a signaling embodiment of performing service capability negotiation in an IMS network according to the present invention;

8 is a flow chart of Embodiment 2 of signaling for performing service capability negotiation in an IMS network according to the present invention;

FIG. 9 is a signaling flow chart of a network entity in a SIP network to a session establishment request message according to the present invention: a signaling scheme for adding a ringtone and modifying a ringtone;

10 is a signaling flowchart of a description of adding a media type supporting media type to a message body in a session establishment request message in a SIP network according to the present invention;

11 is a schematic structural diagram of a session capability information operation according to the present invention;

FIG. 12 is a schematic structural diagram of a network entity according to the present invention. Mode for carrying out the invention

The present invention will be further described in detail below with reference to the accompanying drawings.

The method provided by the embodiment of the present invention can be used in an IMS network, but is not limited to an IMS network, and the embodiment of the present invention can be applied to any SIP network.

In the embodiment of the present invention, the calling party is the calling terminal, the AS performing the client proxy UA, or the border gateway of the SIP network; the called party is the called terminal or the network entity in the SIP network. Of course, the entities in the IMS network as the calling party's SIP network and the entities in the IMS network as the SIP network of the called party are different from each other.

In the process of the service capability negotiation, the operation of the session message by the network entity includes the setting and information negotiation in the service capability negotiation process, which prompts the service capability negotiation process to be performed effectively. The operation of the session message by the network entity may be an operation of a session establishment request message or an operation of a session establishment response message.

In the embodiment of the present invention, the session message may be a session establishment request message, a session establishment response message, a session establishment negotiation message, a session establishment negotiation confirmation message, a session update message, or a session update confirmation message. The session establishment request message is an INVITE message or a REFER message; the session establishment response message is a 200 OK message; the session establishment negotiation message is a 183 message; and the session establishment negotiation confirmation message is a PRACK message. The session update message is an UPDATE message or a REINVITE message; the session update confirmation message is a 200 OK message.

During the session negotiation process, the network entity in the SIP network may add, delete, or/and modify the content in the session capability information in the session message sent by the calling party, and set the attribute information in the session capability information. The modification of the message by the network entity further includes adding, deleting, or/and modifying the attribute information of the session capability information, and the session message is a session establishment request message or a session establishment response message. The session capability information in the session message can be used. The method description specified by the SDP protocol can also be described by describing a media information language (XML), or a scripting language (SCRIPT). The modification of the session capability information specified by the SDP protocol may be extended to the description method specified by the SDP protocol.

In the embodiment of the present invention, the session capability information described by the SDP is used as a description, and the network entity adds the session capability information supported by the SIP network to the message body of the session establishment request message, and the session capability information in the message uses the attribute information to distinguish , provided to the called party to choose. After receiving the session establishment request message, the called party can select the desired service capability from the message as the result of the service capability negotiation for the session. The response message returned by the called party carries the service capability of the selected session. The network entity on the SIP network determines whether the service capability needs to be converted according to the service capability carried in the returned session establishment response message. The network entity on the SIP network can also add, delete, or/and modify the service capabilities based on the service capabilities in the session establishment response message, and send the returned session establishment response message to the calling party.

The network entity adds the session capability information supported by the SIP network to the session establishment request message, which may be a preset of the network on the network entity, and adds and modifies the session capability information and the attribute information according to a fixed manner, which may be based on the network entity. The session capability support capability of the obtained network, the decision to add and modify the session capability information of the network

.

It should be noted that during the session negotiation process, there are more than one SIP network of the session message path, and there may be more than one. The SIP network is a SIP network to which the calling party and the called party belong; or the SIP network belongs to the SIP network to which the calling party belongs and the SIP network to which the called party belongs; or the SIP network is called The SIP network to which the party belongs, the SIP network to which the called party belongs, and the SIP network to which the calling party belongs and one or more SIP networks traversed by the SIP network to which the called party belongs. The attribute information of the session capability information may reflect the session message path or the information of the SIP network participating in the process capability information, such as the called network. Network, central control network, central traversal network, and can also reflect the logo information of the SIP network or the network involved in processing session capability information.

In the embodiment of the present invention, the service capability supported by the SIP network may be pre-stored in the network entity of the SIP network, or may be stored in a separate capability server (Capability Server). The Capability Server is a logical functional entity on the SIP network. The Capability Server stores the service capabilities of the network entities on the SIP network. These service capabilities can be stored on the Capability Server according to different network entities. When the network entity on the SIP network modifies the session capability information in the session establishment request message or the session establishment response message, the network entity may query the Capability Server for the service capability supported on the SIP network, and the Capability Server returns the session capability information to the queried network entity. . The network entity adds the queried session capability information to the session establishment request message or the session establishment response message, and provides the called party or the calling party to select.

Of course, Capability Server can also be replaced by Capability Provide Function.

The session capability information in the embodiment of the present invention is described by taking the SDP as an example. In actual implementation, it may be any protocol session information negotiated by SIP, and the information varies according to the protocol used by the session, for example, when negotiating When the RTP protocol is used, the session capability information may be a codec type or/and a coding rate, etc., and when the MSRP is negotiated, the session capability information may be a media stream rate or the like. When negotiating some applications, the session capability information may also include various information such as location information, presence information, and ringtones. The SDP includes session information, session initiator contact information, time information, connection information, codec type, bandwidth information, encapsulation password, description of transport protocol session attributes, coding rate, rate of media stream, packet interval, and tablet direction. Description of multi-party session type, font settings, media description language, encoding quality, or/and formatting parameter media properties; applications include text, ringtones, video media, audio media, animation Or / and execute the program.

In the embodiment of the present invention, the network entity that can modify the service capability in the session negotiation on the SIP network is the AS, the CSCF, the MRF, and the SIP server in the SIP network. The AS is a control button, that is, a PoC service function PoC Server (Controlling), a PoC service (Postation), a Conference Server, a Service Capability Interaction Manager (SCIM), or / and presence server (Presence Server); CSCF can be P-CSCF, S-CSCF or / and I-CSCF; SIP server can be an outbound border gateway control function (BGCF) or / and SIP protocol application layer gateway (SIP- ALG).

In the embodiment of the present invention, the UE is mainly used as a calling party that initiates session negotiation as an example. In the implementation process, the calling party that initiates the session and the called party that terminates the session may be the UE, or may be the border gateway of the AS or SIP network that performs the client agent (UA). That is, the calling and called UEs in the SIP network can use the service capability negotiation method of the embodiment of the present invention as the calling party and the called party to perform session negotiation; a calling UE and an AS in the SIP network can serve as the calling party and the calling party. The called party uses the service capability negotiation method of the embodiment of the present invention to perform session negotiation. The two ASs in the SIP network can also use the service capability negotiation method of the embodiment of the present invention to perform session negotiation.

The descriptions of SDP1, SDP2, and the like used in the following embodiments refer to the session capability information described by the SDP, and the SDP1 and SDP2 may further include attribute information of the session capability information.

FIG. 3 is a signaling flowchart of a service capability negotiation according to the present invention. The network entity involved includes: a calling party, a called party, a calling party side network entity, a session negotiation processing entity, a Capability Server, and a called party side network entity. , the specific steps are:

Step 300: The calling party sends a session establishment request message to the calling party side network entity, where the request message carries the session capability information of the calling party.

The session capability information can be described by SDP1, and the SDP1 includes the service capability type. Parameters related to business capabilities such as media parameters and encoding parameters. The attribute information of the SDP1, including the session capability information, is from the calling party, the priority of the service information, and the network identifier to which the service information belongs.

Step 301: The calling party side network entity returns a response of the request message to the calling party, that is, a 100 Trying message.

For each session establishment request message, there will be a response of 100 Trying messages, which is not identified in the following process.

Step 302: The calling party side network entity determines, according to the request message, how to process the session establishment request message, and determines how to provide the session establishment request message to the session negotiation processing entity that supports the service capability negotiation function specified in the embodiment of the present invention. The request message is sent to the session negotiation processing entity.

The embodiment of the present invention may set a service identifier in the session establishment request message to identify the service capability negotiation to be performed by the request message, and the calling party side network entity may also set the same according to the request message, and the calling party side network entity may also be based on The service identifier set in the request message determines what service is provided to the calling party that initiated the request message.

Step 303: The session negotiation processing entity may send a service capability query request supported by the SIP network to the Capability Server.

Step 304: The Capability Server returns a service capability query request response supported by the SIP network to the session negotiation processing entity, where the response carries the session capability information supported by the SIP network, for example, the description of the session capability information supported by the SIP network, SDP1, SDP2, and SDP3. And SDP4.

Step 305: The session negotiation processing entity may add, delete, or/and modify the session capability information and the attribute information in the session message according to the preset setting, and send the session capability information supported by the IMS network to the calling party side network entity, for example, SDP1, SDP2, SDP3 and Session establishment request message of SDP4.

Step 306 - 307: The calling party side network entity sends the received session establishment request message to the called party through the called party side network entity, where the session capability information SDP1, SDP2, SDP3, and SDP4 are included, and the calling party The side network entity needs to set the attribute information of the session capability information, and can form the attribute information of the session capability information according to the attributes of the source of the multiple SDPs, the priority determined by the network, and the like.

Steps 308-309: The called party that receives the session establishment request message carries the session capability information, such as the service capabilities described by SDP1, SDP2, SDP3, and SDP4, according to the service capability, and selects the service capability supported by itself, such as the service described by SDP4. The capability, by the called party side network entity, returns a response to the SDP4 carrying the session capability information of the calling party side network entity.

Step 310: The calling party side network entity forwards the received response of the SDP4 carrying the session capability information to the session negotiation processing entity.

Step 311: The session negotiation processing entity compares the description SDP4 of the session capability information carried in response with the description SDP1 of the session capability information supported by the calling party to determine whether the two are the same. If yes, determine the transmission between the calling party and the called party. The data is directly sent to the party through the session negotiation processing entity, and step 312 is performed; if not, the data transmitted between the calling party and the called party is converted into a service capability and then sent to the other party, and step 312 is performed.

Step 312 313: The session negotiation processing entity sends a 200 OK response to the calling party by using the calling party side network entity, and the service capability negotiation between the calling party and the called party is completed.

Of course, if the session negotiation processing entity itself stores all the service capabilities supported by the SIP network, the embodiment of the present invention may omit steps 303-304. In step 305, the session negotiation processing entity directly carries the stored service capability in the session establishment request. Sent in the message.

The session negotiation processing entity described herein may exist independently or may be integrated in any one of the network entities in the SIP network, when the session negotiation processing entity is integrated in one network entity. Medium time, the network is real

Line session negotiation process.

The service capability interaction process of the session negotiation in the embodiment of the present invention may be applied to multiple scenarios, such as the calling party network and the called party network, and the session service capability negotiation method of the embodiment of the present invention is supported; the calling party network supports the present invention. The session service capability negotiation method of the embodiment, the called party network does not support the session service capability negotiation method of the embodiment of the present invention; the calling party network does not support the session service capability negotiation method of the embodiment of the present invention, and the called party network supports the present invention. The session service capability negotiation method of the embodiment; does not distinguish the primary called party network.

Both the calling party network and the network entities in the called party network support embodiments of service capability negotiation.

In the IMS network, the case where the calling party network and the called party network support the service capability negotiation is described. The calling party here may be a UE or a network entity in an IMS network. When the calling party and the called party belong to different IMS networks, the CSCF, the AS, the MRF, and the like in the different IMS networks may use the method in the embodiment of the present invention to modify the session capability information in the message body of the session message. And joining the session capability message supported by the IMS network. In this example, the IMS network where the calling party is located and the network entity in the IMS network where the called party is located can use the method described in this embodiment of the present invention to modify the session in the session negotiation. Capability information and provided to the called party. The session capability information may include attribute information for processing session capability information, and may include attribute information of session capability information, and may also be information of a network entity that processes session capability information. The calling party sends a session establishment request message to the IMS network in which it is located, and the request message carries a description SDP1 of the session capability information expected by the calling party. The P-CSCF #1 and the S-CSCF #1 in the IMS network where the calling party is located are based on the description of the session capability information of the received session establishment request message, SDP1 and the local policy of the operator. The local policy includes pre-setting, and According to the capabilities of the network, built in the conversation The message body of the request message is added to the description SDP2 of the session capability information supported by the IMS network where the calling party is located, and the session establishment request message is sent to the IMS network where the called party is located. After receiving the session establishment request message describing the SDP1 and SDP2 carrying the session capability information, the P-CSCF #2 and the S-CSCF #2 on the IMS network where the called party is located are localized according to the operator of the IMS network where the called party is located. The policy adds the descriptions SDP3 and SDP4 of the session capability information supported by the IMS network where the called party is located in the session establishment request message. The descriptions SDP1, SDP2, SDP3, and SDP4 of the session capability information added to the session establishment request message by the IMS network where the calling party is located and the network entity on the IMS network where the called party is located are provided to the called party for selection. .

The network entity on the IMS network where the calling party is located and the IMS network where the called party is located can also query the Capability Server on the IMS network where it supports the session capability information supported by the IMS network. The Capability Server returns the supported IMS network. Description of session capability information SDP. When the network entity on the IMS network where the primary and called parties are located joins the session capability information supported by the IMS network, it needs to follow the carrier's local policy and under the control of the operator. The local policy is derived from the carrier's local settings and can be saved. On the Capability Server, it can also be saved on other network entities.

The session establishment request message received by the called party carries the descriptions SDP1, SDP2, SDP3 and SDP4 of the session capability information added by the calling party and the network entity on the IMS network that has passed, and the called party is based on the called party. The service capability selects the description SCP2 of the desired session capability information, and carries the description SDP2 of the session capability information in the returned response message. Therefore, in the process in which both the calling party IMS network and the called party IMS network support the service capability of the embodiment of the present invention, the process of service capability negotiation is completed.

When the calling party and the called party belong to different SIP networks, and the AS is required to join the session control and processing, the embodiment of the present invention is described by performing a session establishment process in the IMS network. During the signaling interaction established by the session, there is a P-CSCF in the IMS network where the calling party is located. #1, S-CSCF#1 and AS#1, P-CSCF#2, S-CSCF#2 and AS#2 in the IMS network where the called party is located participate. The S-CSCF #1 in the IMS network where the calling party is located can modify the session capability information in the session establishment request message sent by the calling party according to the local policy, and add the description SDP2 of the session capability information supported by the calling party's IMS network. In the message body, AS#1 in the IMS network where the calling party is located can change the session establishment request message, and add the descriptions SDP3 and SDP4 of the session capability information supported by the IMS network where the calling party can be obtained by AS#1. In the body of the conversation negotiation.

Description of other session capability information supported by the IMS network obtained by AS#1 The methods of SDP3 and SDP4 can be saved in AS#1 in advance, can be obtained from other ASs participating in the session, or can be saved from the session capability information. The query is obtained on Capability Server.

The network entities on the IMS network where the calling party is located (including P-CSCF#1, S-CSCF #1 and AS#1) need to follow the carrier's local policy and the carrier when joining the service capabilities supported by the IMS network. Under the control of the local policy, the local policy comes from the carrier settings, and can be saved on the Capability Server or on other network entities. The S-CSCF #1 in the IMS network where the calling party is located is responsible for forwarding the session negotiation processed by the AS #1 to the IMS network where the called party is located. The description of the session capability information of the session negotiation may include SDP1, SDP2, SDP3, and SDP4. You can also set the attribute information of session capability information for SDP1, SDP2, SDP3, and SDP4.

The P-CSCF # 2 and S-CSCF # 2 on the IMS network where the called party is located are responsible for checking the session capability information and attribute information of the session negotiation, and deleting the session capability prohibited on the IMS network where the called party is located according to the operator's local policy. The information, the description SDP5 of the session capability information supported by the IMS network of the called party is added to the session establishment request message according to the operator local policy, and the attribute information is set for the session capability information SDP5, and the session establishment request is set according to the content of the session negotiation. The message is forwarded to AS#2 of the IMS network where the called party is located. Called party The AS #2 on the IMS network can change the session establishment request message, and add the SDP6 and SDP7 descriptions of the session capability information supported by the IMS network where the calling party can obtain the AS #2 to the session message. The session capability information SDP6 and SDP7 set attribute information.

Description of other session capability information supported by the IMS network obtained by AS # 2 The methods of SDP6 and SDP7 are pre-stored on AS #1 and can be obtained from other ASs participating in the session on the IMS network where the called party is located. It can also be queried from the Capability Server that holds these session capability information.

The network entity on the IMS network where the called party is located (including P-CSCF # 2, S-CSCF # 2 and AS # 2) must comply with the carrier's local policy and the carrier when joining the service capabilities supported by the IMS network. Under the control, the local policy is derived from the carrier's settings, and can be saved on the Capability Server or on other network entities. Description of the session capability information carried in the session establishment request message SDP1, SDP2, SDP3, SDP4, SDP5, SDP6, and SDF7. These session capability information are divided into a plurality of session capability information blocks in the message using the method specified by the SDP protocol, and the plurality of session capability information blocks are distinguished using the session capability information attribute.

P-CSCF #1, S-CSCF #1 and AS #1 of the IMS network where the calling party is located and P-CSCF # 2, S-CSCF # 2 and AS # 2 of the IMS network where the called party is located are in the message body The description of the session capability information in SDP2, SDP3, SDP4, SDP5, SDP6, and SDP7 is provided to the called party for selection.

The IMS network where the called party is located sends a session establishment request message to the called party, and the called party selects the description SDP1 of the desired session capability information according to the session capability information of the session establishment request message and its service capability, and returns a response message. A description of the SCP1 carrying the selected session capability information. Therefore, in the session negotiation process in which both the calling party IMS network and the called party IMS network support the service capability of the embodiment of the present invention, the AS participates in the session protocol. The process of business has completed the process of negotiating business capabilities.

In the above example, P-CSCF #1, S-CSCF #1 and AS #1 of the IMS network where the calling party is located and P-CSCF # 2, S-CSCF # 2 and AS of the IMS network where the called party is located #2 The session capability information of the session establishment request message is changed according to the method of the embodiment of the present invention.

The following details how the Capability Server is used in the business capability interaction of the SIP network.

Capability Server preserves the service capabilities that can be supported in a SIP network. The specific service capabilities are stored in different functional entities for use in the IMS network. The network entities that store service capabilities on the IMS network may be CSCF, AS or MRF, including but not limited to these network entities. The embodiment of the present invention uses the service capability described by the SDP as an example to describe how to use the Capability Server in the process of saving the session capability information and negotiating the service capability.

The network entity on the SIP network can save the service capability for supporting the service on the Capability Server, and the service capability is saved according to different network entities. When other network entities on the SIP network query the Capability Server for the session capability required to provide the service. In the information, the Capability Server retrieves the service capabilities that can be supported on the saved SIP network, and returns the description of the session capability information to the querying network entity in the query response message using the description format specified by the SDP protocol in accordance with the operator's local policy. Different network entities in the IMS network may be querying network entities supporting the service capabilities in the IMS network.

During the IMS 'network session negotiation process, the specific process of using the Capability Server by network entities such as CSCF, AS, and MRF is as follows.

When the calling party and the called party belong to different SIP networks, taking the use situation in the IMS network as an example, in the signaling interaction process of the session negotiation, there is a P-CSCF #1 in the IMS network where the calling party is located. S-CSCF #1 and AS #1, P-CSCF #2, S-CSCF #2, and AS #2 in the IMS network where the called party is located participate. P-CSCF in the IMS network where the calling party is located #1, S-CSCF#1 can modify the description of the session capability information in the session establishment request message sent by the calling party, SDP1, and add the description SDP2 of the session capability information supported by the IMS network where the calling party is located according to the local policy of the operator. Go to the message body and set the attribute information for the session capability information SDP2. The P-CSCF#1 and the S-CSCF#1 may obtain the session capability information supported by the IMS network by sending a service capability query to the Capability Server #1, and receiving the service capability query result in the Capability Server #1 return message. The next step. The AS #1 in the IMS network where the calling party is located can determine the message body of the session establishment request message according to the pre-set and AS #1 capability, and the session supported by the IMS network where the calling party can be obtained by AS#1. The capability information SDP3 and SDP4 are added to the message of the session negotiation, and attribute information is set for the session capability information SDP3 and SDP4. Descriptions of other session capability information supported by the IMS network obtained by AS#1 SDP3 and SDP4 can be pre-stored on AS #1, can be obtained from other ASs participating in the session, or can send service capability query requests to Capability Server#1. Query the session capability information supported by the IMS network saved on Capability Server#1. The message returned by Capability Server #1 is the description of the session capability information supported by the IMS network. SDP3 and SDP4o CSCF in the IMS network where the calling party is located. Responsible for forwarding the session negotiation processed by AS #1 to the IMS network where the called party is located, and describing the session capability information of the session negotiation SDP1, SDP2, SDP3, and SDP4.

The S-CSCF #2 on the IMS network where the called party is located is responsible for checking the session capability information of the session negotiation, and adding the description SDP5 of the session capability information supported by the IMS network of the called party to the session establishment request message according to the carrier local policy. And the attribute information is set for the session capability information SDP5, and the message is forwarded to the AS#2 of the IMS network where the called party is located according to the content of the session negotiation. The local policy of the operator may be pre-set, may be determined according to the service capability of the network entity, or may be determined by combining pre-setting and service capabilities of the network entity. P-CSCF#2, S-CSCF#2 obtain the service capabilities supported by the IMS network The method may be to send a service capability query to Capability Server #2, and perform the next operation after receiving the service capability query result in the Capability Server #2 return message. The AS # 2 on the IMS network where the called party is located can change the session establishment request message according to the local policy of the operator. The local policy of the operator can be preset, and can be determined according to the service capability of the network entity. It is judged by combining the pre-set and the business capabilities of the network entity. The descriptions SDP6 and SDP7 of the session capability information supported by the IMS network where the calling party can be obtained by the AS #2 are added to the message of the session negotiation, and the attribute information is set for the session capability information SDP6 and SDP7. The descriptions of other session capability information supported by the IMS network obtained by AS # 2, SDP6 and SDP7, may be pre-stored on AS #2, and may be obtained from other ASs participating in the session on the IMS network where the called party is located, or may be Capability Server # 2 of the IMS network where the calling party is located sends a service capability query request, and queries the service capability supported by the IMS network saved on Capability Server # 2, and the session capability information supported by the IMS network is obtained from the message returned by Capability Server # 2 Describe SDP6 and SDP7. At this time, the descriptions of the session capability information carried in the session establishment request message are SDP1, SDP2, SDP3, SDP4, SDP5, SDP6, and SDP7. The session capability information may be divided into a plurality of session capability information blocks according to attributes of the business capability.

The descriptions of the session capability information of the CSCF # 1 and AS # 1 of the IMS network where the calling party is located and the CSCF # 2 and AS # 2 of the IMS network where the called party is located in the message body are SDP2, SDP3, SDP4, SDP5, SDP6 and SDP7, provided to the called party to make a selection.

The S-CSCF #2 on the IMS network where the called party is located sends a session establishment request message to the called party, and the called party can select a description of the desired session capability information according to the session capability information of the session establishment request message and its service capability. SDP1, and carries a description SDP1 of its selected session capability information in the returned response message. In this way, the network entity on the IMS network uses the session service capability negotiation method in the embodiment of the present invention to query the Capability Server for the session capability information on the IMS network, thereby completing the session negotiation process. As a shared multimedia resource processing function entity in the IMS network, the MRF can be called by other network entities. The MRF can also directly communicate with the calling and called parties as a SIP Proxy and SIP B2BUA. In the existing specification, the MRF can directly communicate with the calling party and the called party. The scenario in which the MRF interacts with the calling party and the called party mainly occurs in the Ad-hoc conference. The calling party and the called party join the MRF controlled session and the MRF. The calling party is required to join the session. Therefore, the MRF can also modify the service capability in the session establishment request message during the session negotiation process.

In the embodiment of the present invention, the network entity may further determine whether to perform service media data routing according to the operation of the session capability information carried in the session message.

The process of determining whether to perform the service media data routing is as follows: The network entity determines whether the session capability information of the terminal carried by the session message cannot be operated, and if yes, sets the service media data route, and routes to the media resource function MRF. The session capability information carried by the session message is operated by the MRF; otherwise, the session capability information carried by the session message is directly operated by the network entity.

The method provided by the embodiment of the present invention can also be applied to the PoC service. The following specific embodiments illustrate the application of the service capability negotiation in the PoC service.

When the PoC service is implemented in the IMS network, the method described in this embodiment of the present invention may also be used for service capability negotiation. The PoC server provides the PoC service for the UE as the AS in the IMS platform. The PoC server, when the PoC server (Controlling) and the PoC Server (the Participating) receive the service negotiation request message, is called the INVITE request, and is in the INVITE request. Adding the business capabilities supported by the PoC server is provided to the called party to select. PoC Server (Controlling) and PoC Server (Parting) may belong to the same IMS network or belong to different IMS networks. PoC Server (Controlling) and PoC Server (Parting) may change the call request information of the session request by a PoC server. The operation describing the content of the SDP can also be performed to change the call request. The description of the speech capability information describes the operation of the content of the SDP. After receiving the INVITE request, the called party selects the service capability described by the SDP according to its own service capability, and carries the service capability described in the selected SDP in the 200 OK response. After receiving the 200 OK response sent by the called party, the PoC server obtains the description SDP of the session capability information selected by the called party, determines whether the service capability needs to be converted, and performs subsequent processing steps.

4 is a signaling flowchart of Embodiment 1 of a service capability negotiation performed by a terminal when an IMS network adopts a PoC service, where the entity involved includes: a calling terminal UE1, a called terminal UE2, and an S to which the UE1 in the IMS network belongs. -CSCF1, the S-CSCF2 to which the UE2 in the IMS network belongs, the PoC service control function (PoC Server (Controlling)) that governs the group in which the UE1 and the UE2 are located in this session, and the PoC service function entity (PoC) that governs the UE2. Server ( Participating ) ), assuming that the PoC Server (Controlling) stores a description of the supported session capability information, the specific steps are:

Step 400: The UE1 sends a PoC session request to the S-CSCF1, that is, an INVITE request, where the request carries the session capability information SDP1 of the UE1, and may include attribute information.

Step 401: The S-CSCF1 determines, according to the INVITE request, that the current service is configured by the PoC Server.

(Controlling) Processes and forwards the INVITE request to the PoC Server (Controlling).

Step 402: The PoC Server (Controlling) sends an INVITE request describing the attributes of the SDP1, SDP2, SDP3, and SDP4 and the session capability information of the session capability information supported by the PoC Server (Controlling) to the S-CSCF1 according to the PoC service, where the service The capability support information includes information about the network to which the PoC Server (Controlling) belongs, information indicating the PoC server, priority information, and other information used to identify the session capability information.

Step 403: The S-CSCF1 sends the received INVITE request to the S-CSCF2.

Steps 404 ~ 405, S-CSCF2 sends the received INVITE request to the jurisdiction UE2 PoC Server (Parting), PoC Server (Parting) returns the response to the INVITE request to S-CSCF2.

Step 406: The S-CSCF2 sends an INVITE request to the UE2.

Step 407: The UE2 that receives the INVITE request selects the SDP, which is supported by the SDP1, SDP2, SDP3, and SDP4, according to the description of the session capability information carried by the request, such as SDP4, and returns to the S-CSCF2 a 200 OK description SDP4 carrying the session capability information. response.

Steps 408 to 409, the S-CSCF2 sends the 200 OK response of the SDP4 to the PoC Server (Parting), and the PoC Server (Parting) returns a response to receive the 200 OK response to the S-CSCF2.

Step 410: The S-CSCF2 sends a description of the session capability information, and the 200 OK response of the SDP4 is sent to the S-CSCF1.

Step 411: The S-CSCF1 forwards the received 200 OK response of the SDP4 that carries the session capability information to the PoC Server (Controlling).

Step 412: The PoC Server (Controlling) compares the SDP4 description of the session capability information carried by the 200 OK response with the description SDP1 of the session capability information supported by the UE1, and determines whether the two are the same. If yes, the PoC Server determines the UE1 and The data transmitted between the UE2 is directly sent to the other terminal through the PoC Server (Controlling), and step 413 is performed; otherwise, the PoC Server (Controlling) determines that the data transmitted between the UE1 and the UE2 is converted into a service capability and then sent to the other terminal. 413.

Steps 413 to 414, the PoC Server (Controlling) sends a 200 OK response to the UE1 through the S-CSCF1 according to the procedure specified by the PoC service specification, and the service capability negotiation between the UE1 and the UE2 is completed.

In this way, the PoC Server (Controlling) implements the IMS-based PoC service capability negotiation process by using the interaction optimization process of the service capability negotiation in the embodiment of the present invention.

FIG. 5 is a diagram showing a service capability association of a terminal when an IMS network adopts a PoC service according to the present invention; The signaling flow chart of the second embodiment includes: the calling terminal UE1, the called terminal UE2, the S-CSCF1 to which the UE1 in the IMS network belongs, and the S-CSCF2 to which the UE2 in the IMS network belongs. The PoC Server (Controlling) of the group in which the UE1 and the UE2 are located, the PoC Server (the Participating) that governs the UE2, and the PoC Server (the Participating) are supported by the SDP. In this embodiment, the session capability information has attribute information. The PoC server processes the session capability information according to the attribute information. The specific steps are:

Step 500: The UE1 sends a PoC session request to the S-CSCF1, that is, an INVITE request, where the request carries the description SDP1 of the session capability information of the UE1. The SDP1 may include attribute information, and the attribute information describes that the SDP1 is from the initiator terminal, and the priority is the highest level. Since UE1 sends the initiator terminal, it can also be specified that SDP1 does not add attribute information.

Step 501: The S-CSCF1 determines, according to the INVITE request, that the current service is processed by the PoC Server (Controlling), and forwards the INVITE request to the PoC Server (Controlling). In this process, the P-CSCF and the S-CSCF may perform a session. Ability information is checked.

Step 502: PoC Serve Controlling) sends a response to the S-CSCF 1 to receive the INVITE request.

Step 503: According to the PoC service specification, the S-CSCF1 sends the INVITE request to the S-CSCF2 according to the PoC service specification.

Step 504: The S-CSCF2 sends the INVITE request to the PoC Server that governs UE2.

( Participating ).

Step 505: The PoC ServerC Participating sends an INVITE request describing the SDP1, SDP2, SDP3, and SDP4 of the service capability supported by the PoC Server (Parting) to the S-CSCF2.

Of course, the description of session capability information supported by PoC Server (Parting) SDP The description of the session capability information supported by the PoC Server (Controlling) may be different.

Step 506: The S-CSCF2 sends an INVITE request to the UE2.

Step 507: The UE2 that receives the INVITE request according to the description of the session capability information carried by the request SDP1, SDP2, SDP3, and SDP4 selects the SDP supported by itself, such as SDP4, and returns the S-CSCF2 with the description of the SDP4 carrying the session capability information. Response to S-CSCF2.

Step 508: The S-CSCF2 sends a 200 OK response carrying the SDP4 to the PoC Server (Parting).

Step 509: The PoC Server (Parting) compares the SDP4 description of the session capability information carried by the 200 OK response with the description SDP1 of the session capability information supported by the UE1, and determines whether the two are the same. If yes, the PoC Server (Parting) determines the UE1 and The data transmitted between the UE2 is directly sent to the opposite terminal through the PoC Server (Controlling), and step 510 is performed; otherwise, the PoC Server (Parting) determines that the data transmitted between the UE1 and the UE2 is converted into a service capability and then sent to the other terminal, and the steps are performed. 510.

Step 510: The PoC Server (Parting) returns a response to the 200 OK response to the S-CSCF2.

Step 511: The S-CSCF2 sends a 200 OK response to the S-CSCFL.

Step 512: The S-CSCF1 forwards the 200 OK response to the PoC ServerC Controlling. Steps 513-514, PoC Server (Controlling) sends a 200 OK response to UE1 through S-CSCF1 according to the procedure specified by the PoC service specification, and the service capability negotiation between UE1 and UE2 is completed.

In this way, the PoC Server (Parting) implements the IMS-based PoC service capability negotiation process by using the interaction optimization process of the service capability negotiation in the embodiment of the present invention.

PoC Server ( Controlling ) and PoC Server ( Participating ) are respectively controlled The AS of the network where the PoC service is located and the AS of the network where the calling and called terminals are located. It should be noted that after receiving the INVITE message, the PoC Server (Controlling) and the PoC Server (Parting) can add the description SDP of the session capability information supported by the network to the INVITE request to provide the called terminal for selection. When PoC Server (Controlling) and PoC Server (Parting) add session capability information, you can describe the attribute information of session capability information. PoC Server (Controlling) can add the attributes of session capability information to belong to the initiator network and control session network. Lower than the session capability information of the terminal. The PoC Server (Parting) can add the session capability information attribute to the called party network. The priority of setting the session capability information can be higher or lower than the priority of the session capability information added by the PoC Server (Controlling). After receiving a session request message carrying multiple session capability information and multiple attribute information, the PoC server may first check attribute information of multiple session capability information, and according to priority information, home network information, and other information, multiple One or more of the session capability information is selected in the session capability information. Selecting a corresponding parameter describing the session capability information among the selected one or more session capability information.

The following provides a specific embodiment to illustrate the method provided by the embodiments of the present invention.

FIG. 6 is a schematic diagram of the service capability conversion supported by the called terminal in the IMS network according to the present invention, as shown in the following figure: The session between the UE1 and the UE2 is established through the AS of the IMS network, and the AS can be based on the type of service provided and The service capability provided by itself determines whether the server needs to provide service capability support. If yes, the data transmission between UE1 and UE2 is respectively transmitted by the AS and the server after the service capability is converted.

It can be seen that, in the embodiment of the present invention, the data transmission between the UE1 and the UE2 is performed by the AS, and the service capability conversion in the process of sending the data to the other party may be performed independently by the AS, or the AS may authorize other services in the IMS network. The entity of the capability conversion function is completed, and can also be completed by other entities in the AS and IMS networks that have the capability conversion function. to make.

For example, when the description SDP of the session capability information selected by the called party is different from the description SDP of the session capability information supported by the calling party, and the description SDP of the session capability information selected by the called party is the SDP supported by other servers. , the other server provides the service capability conversion of the data transmitted by the calling party and the called party; when the description of the session capability information selected by the called party is different from the description SDP of the session capability information supported by the calling party, and the called party In the selected SDP, there is a description of the session capability information supported by the AS, and the description of the session capability information supported by the other server. When the SDP is described by the other server, the AS and the other server jointly provide the service capability conversion of the data transmitted by the calling party and the called party.

A specific embodiment will be described below to illustrate the service capability negotiation process that ultimately provides service conversion capabilities by other servers and ASs. Figure 的 is a flowchart of a signaling embodiment of a terminal for performing service capability negotiation in an IMS network, where the network entity includes: a calling terminal UE1, a called terminal UE2, and an S-CSCF1 to which the UE1 in the IMS network belongs. The S-CSCF to which the UE2 belongs in the IMS network, the AS in the IMS network, and the Capability Server that provides the service capability supported by the IMS network. The specific steps are as follows:

Step 700: The UE1 initiates a session negotiation to the S-CSCF1, that is, an INVITE request, and the request carries a description of the session capability information of the UE1. The SDP1 includes parameters about the service capability, such as a service capability type, a media parameter, and an encoding parameter.

Step 701: The S-CSCF1 returns, to the UE1, a response that receives the INVITE request, that is, a 100 Trying message.

Step 702: The S-CSCF1 determines, according to the INVITE request, an AS that provides a service capability negotiation function, and forwards the INVITE request to the AS.

Step 703: The AS sends a service capability query request to the Capability Server. Step 704: The Capability Server returns a service capability query request response to the AS, where the response carries a description SDP of the session capability information supported by the IMS network, for example, SDP1, SDP2, SDP3, and SDP4.

SDP1 and SDP2 are descriptions of service capabilities supported by the AS, and SDP1, SDP2, SDP3, and SDP4 are descriptions of service capabilities supported by other servers.

Step 705: The AS sends an INVITE request carrying the service capability descriptions SDP1, SDP2, SDP3, and SDP4 to the S-CSCF1.

Steps 706 ~ 707, S-CSCF1 sends the received INVITE request to UE2 through S-CSCF2.

Steps 708 to 709, the UE2 that receives the INVITE request, according to the description of the session capability information carried by the request, SDP1, SDP2, SDP3, and SDP4 selects the service capabilities supported by the UE, such as SDP4 and SDP2, and returns to the S-CSCF1 through the S-CSCF2. 200 OK response for SDP4 and SDP2.

The service capability described by the selected SDP4 is the service capability supported by the application server, and the service capability described by the selected SDP2 is the service capability supported by the AS.

Step 710: The S-CSCF1 forwards the received 200 OK response of the SDP4 and SDP2 carrying the service capability to the AS.

Step 711: The AS compares the description of the session capability information carried by the 200 OK response with the SDP4 and the SDP1 supported by the UE1 to determine whether the two are the same. If yes, the AS determines that the data transmitted between the UE1 and the UE2 directly passes through the AS and the application. The server sends the signal to the other party, and performs step 712. If not, the data transmitted between the UE1 and the UE2 is determined to be converted to a service capability, and then sent to the other party through the AS and other servers. Step 712.

Steps 712-713, the AS sends a 200 OK response to the UE1 through the S-CSCF1, and the service capability negotiation between the UE1 and the UE2 is completed. A specific embodiment is used to describe the operations of the network entity of the SIP network to add, delete, or/and modify the session establishment request message and the session establishment response message for session establishment, so as to implement the session capability of the embodiment of the present invention. Information operation.

FIG. 8 is a flow chart of Embodiment 2 of signaling for performing service capability negotiation in an IMS network according to the present invention. The network entity involved includes: a calling terminal UE1, a called terminal UE2, a network entity in a SIP network to which UE1 belongs, a network entity to which UE2 belongs, a processing entity in a SIP network to which UE1 belongs, and a SIP network to which UE2 belongs. Processing entity 2 in . In this embodiment, the processing entity 1 and the processing entity 2 respectively add, delete, and modify the session capability information in the message body of the session establishment request message and the session establishment response message, and implement the session negotiation process. The processing entity may be an independent network entity, or may be a logical function integrated on the network entity, and the network entity may be an AS, a CSCF, an MRF, a SIP-ALG, or the like. The specific steps are:

Step 800: The UE1 sends an INVITE request message to the network entity 1, where the request message carries the session capability information of the UE1.

Step 801: The network entity 1 forwards the INVITE request message to the processing entity 1. Step 802 803: The processing entity 1 checks the session capability information in the message body of the INVITE request message, and adds the session capability information supported by the SIP network where the ΌΈ1 is located, and then sends the INVITE request message to the network entity 1.

Step 804: The network entity 1 transmits an INVITE request message to the processing entity 2. Step 805 806: Processing the entity 2, checking the session capability information in the message body of the INVITE request message, deleting the session capability information that is not supported by the SIP network to which the UE2 belongs, adding the session capability information supported by the SIP network to which the UE2 belongs, and modifying the INVITE After requesting the session capability information in the message body of the message, the INVITE request message is sent to the network entity 2. ,

Step 807: The network entity 2 forwards the INVITE request message to the UE2. Steps 808 - 809, the UE2 receives the INVITE request message, checks the session capability information in the message body of the INVITE request message, selects the session capability information supported by the UE2, and sends a session establishment response message carrying the session capability information supported by the UE2 to the network. Entity 2.

Step 810: The network entity 2 sends a session establishment response message response carrying the session capability information supported by the UE2 to the processing entity 2.

Step 811: The processing entity 2 checks the session capability information in the session establishment response message, and adds, deletes, and/or modifies the session capability information in the session establishment response message according to the preset policy. - Step 812: The processing entity 2 sends a session establishment response message to the processing entity 1. Steps 813 to 814, processing the entity 1, and adding, deleting, or/and modifying the session capability information in the session establishment response message, and sending the session establishment response message to the network entity 1.

Step 815: The network entity 1 transmits a response message to the UE1, and the process of the service capability negotiation is completed.

The method for negotiating the service capability provided by the embodiment of the present invention may be not limited to the network used by the network, that is, the functional entity used in the network where the calling party is located, and may be CSCF, AS, MRP, and SIP-ALG, and may be the above. The network entity is not limited to these network entities; it can also be used for the SIP network where the called party is located. The method for negotiating the service capability in the embodiment of the present invention may be used at the same time as the service network where the calling party and the called party are located, or may be separately used. In addition, in some applications, the calling party network may not be distinguished, and may also be used. This method of business capability negotiation.

In the embodiment of the present invention, when the calling party performs the service capability negotiation process, the network entity in the SIP network can directly change the session establishment request message when the calling party sends a session establishment request message carrying the service capability of the calling party to the SIP network. In the content, the information of the service capability supported by the SIP network is carried in the request message and sent to the called party, and the called party selects the service capability supported by the called party and sends the response to the SIP network through the session establishment response message. The network entity, the network entity in the SIP network performs subsequent processing according to the accepted service capability supported by the called party, and the network entity in the SIP network can also add, delete, and modify the service capability of the session establishment response message. In the embodiment of the present invention, the calling terminal does not wait until the called terminal returns the reject message, and then re-negotiates the service capability between the calling and called terminals, and directly provides the session capability information of the SIP network for the called party. The terminal selects, thereby the process of negotiating the service capability negotiation between the calling and called terminals, and reducing the delay of session establishment.

How to carry the service support capability information in the session message is as follows.

The session capability information can be described by using the SDP protocol, that is, the session message adopts SDP. In the embodiment of the present invention, the session capability information carried in the session message may be divided into multiple session capability information blocks, and the SDP adds a number and an attribute definition to the session capability information block, so that multiple session capability information blocks carried by the session message can be Identifying, and determining which session capability information block to select for processing based on the number and attributes of the session capability information block.

The session capability information block is identified by a number, for example, the number is defined as Series, or is defined as SDP ID, etc., and series is used as the number of the session capability information block. The numbering enables multiple session capability information blocks in the message body of the same session message to be distinguished from each other. After the version information of the session capability information block defined by the SDP is identified by a number, the method of the identification may be:

In the V field of the version information of the session capability information block, the number is added. For example: v=0 series: <series number from 0-n>.

The specific usage method is: if the current session capability information block is the third session capability information block in the current session message, the session capability information block is identified. The sequence number is defined from 0 - n, and the message body that does not support a session message in the embodiment of the present invention contains more than n different session capability information blocks. In the embodiment of the present invention, it is not desirable that one session message is too large, so I hope that the session capability information block in the message body of a session message cannot exceed one. The range, for example, cannot exceed n=10. Of course, the range of the number can also be determined according to the processing capability of the SIP network.

The embodiment of the present invention may set the end flag information to the session capability information block: Since the message body of the session message may include multiple session capability information blocks, it is necessary to increase the end flag of the session capability information block at the end of each session capability information block. The information enables the network entity of the SIP network to identify the end flag information of the session capability information block. The end flag information is defined as the end flag of a complete session capability information block. Once the network entity of the SIP network finds the end flag, it can be determined that a session capability information block has ended. The embodiment of the present invention can define the end flag of the session capability information block in the ^finished manner.

The embodiment of the present invention may further set the start flag information to the session capability information block, and the start flag information may be the first character string V = starting from the session capability information block, or may be the start flag of the session capability information block.

The format of the session message with a complete session capability information block in the embodiment of the present invention is as follows:

v=0 series :3

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s^SDP Seminar

i=A Seminar on the session description protocol u=http://www s.ucl.ac.uk staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

a=recvonly

m=audio 49170 RTP/AVP 0

m=video 51372 RTP/AVP 31

m=application 32416 udp wb a=orient:portrait

f=finished

Embodiment 1 The embodiment of the present invention defines a message body content in a session message as follows. In the embodiment of the present invention, a definition of a message body content attribute is newly added in a message header of a session message, and a message body content attribute describes a content attribute of a message body content of the session message, and the message body content attribute is provided to the network entity and the session initiator. , or / and message recipients. There may be multiple descriptions of the message body content attributes, and the description of the multiple content attributes corresponds to the session capability information block in the message body of the session message, and the network entity can determine the session message by using the message content attribute in the message header of the session message. Which session capability information blocks, attributes of these session capability information blocks, and priority levels are carried in the message body. In the embodiment of the present invention, the content attribute of the message body of the session message is defined as follows. The message header of the session message is defined as Content, and the definition of the Content field is as follows:

Content: series 1 : <belong<which network belong to>|entity< which entity belong to>|priority<value>

Content: series2: <belong<which network belong to>| entity<which entity belong to>|priority<value>

Content: series3: <belong<which network belong to>| entity<which entity belong to>|priority<value>

The message header Content indicates that the session capability information block carried in the message body of the session message is described in this field. Series[x] represents the number of the session capability information block. After each series[x], it is necessary to include the attribution attribute of the session capability information block, the priority level, and the description attribute attribute of the media information of the session capability information block.

The attribution attribute identifies which network entity the session capability information block belongs to. The home attribute of the session capability information block is the terminal, the session initiator, the network where the calling terminal is located, the network where the session controller is located, or/and the called terminal is located. The internet. The following defined method is used in the embodiment of the present invention: Define the attribution attribute of the session capability information block, that is, Belong is endpoint, origination network:, focus network:, or / and termination network.

The description of the media information of the session capability information block, that is, the Entity specifies which network entity the description of the media information belongs to, and may belong to an AS, a Session Controller, such as a PoC CF, Conference Server, etc., or/and a resource controller, such as MRF, media gateway, etc. The following defined method is used in the embodiment of the present invention:

Define Entity as Application Server ^ Session Controller or / and Resource Controller.

The priority determination process of the session capability information block is as follows.

The priority may be included in the message body content attribute set in the message header of the session message. Since the called party determines which network the session capability information block belongs to and which network entity belongs to, by analyzing the session capability information block, the priority order of the plurality of session capability information blocks in the session message body can be determined, and each session capability information is The priority of the block is set in the message body content attribute in the message header of the session message.

The embodiment of the present invention also defines the content length in the message body of the session message. After the description of the attribute of the session capability information block in the message body in the session message ends, the session capability information block should be identified by the method of counting the number of bytes in decimal. The specific definition is that if a session capability information block is 518 bytes long, the length is defined as: Content-length: 518.

The specific method for extending the message header of the session message in the embodiment of the present invention is as follows. The message header of the session message in the embodiment of the present invention performs content attribute setting on the content part in the message body of the session message, thereby expanding the message header. The extended method is to add a description Content field of the message body content attribute in the message header of the session message for each session capability information block or other message body content in the message body of the session message, and to view this in the Content field. The type, format, content length, etc. of some message body contents are described. In this way, all session capability information blocks or message body contents in the message body of the session message are set with a content attribute in the message header of the session message, and the content attribute defines the session capability information block or the number of the message body content, the network to which it belongs, or the network to which it belongs or The terminal, which network entity it belongs to, the priority of the option, the type of content, such as SDP, picture or audio, etc., encoding format or/and message body content length.

The format of the header of a complete session message with multiple session capability information blocks and message body content in a session message is as follows:

Content: series :0 <belong: endpoint | entity: |priority:0>

Content-type: Application/SDP

c: text/html; charset=ISO-8859-4

Content-length: 333

Content: series: 1 <belong: endpoint |entity: |priority:0>

Content-type: Image/jpeg

Content-length: 1024

Content: series :2 <belong: origination network | entity: MRPx |priority: i|

Content-type: Application/SDP

Content-length: 412

Content: series :3 <belong: focus network | entity: controller |priority: 0| Content-type: Application/SDP

Content-length: 388

The first message body content carried by the session message is a session capability information block desired by the calling party, and the second message body content is that the calling party adds a personal photo to the session message, and the third message body The content is a session capability information block provided by the SIP network where the calling party is located; The fourth message body content is the session capability information block provided by the network where the session controller is located. After the called party receives the session message, the body content added by the calling party and the network entity in the session message can be obtained. From these message body contents, the called party selects the supported message body content and can continue to process other steps related to the session message.

Embodiment 2: The definition of the message body type is added to the message body of the session message, and the message body content attribute of the session message is expanded, and the rest is the same as that of Embodiment 1.

In the Content-type field of the message header of the session message, you can use the existing message body content type, which is Content-type: Application/MIME.

The message body content attribute including the message body type is used in the session message as described below.

The message body of the session message can contain multiple session capability information blocks, then the type of the Content-type identifier in the message header of the session message should be, Content-type: Application/MIME.

Below the Content-type field, each session capability information block in the message body of the session message should be described. The session capability information block in the message body of the session message needs to be used in the message header. The field describes the message body type.

The format of a message header for a session message containing 4 session capability information blocks is as follows:

Content-type: Application/MIME

Content: series 1 : <belong: endpoint |entity: |priority: 0

Content: series2: <belong: origination network | entity: session controller |priority:

Content: series3: <belong: focus network | entity: application server Ipriority

Content: series3: <belong: focus network | entity: resource controller Ipriority

The called party's use of the message body type in the message header of the session message is: The calling party is received in the message header of the session message.

Content-type=Application/MIME, then the message body representing the session message received by the called party carries multiple complete session capability information blocks. The called party needs to view the content of the Content field in the message header of the session message, and based on the content attribute of each session capability information block in the Content field, determines which session capability information block selects the media parameter desired by the called party.

In Embodiment 2, the content in the message body of the session message includes:

v=0 series: 1

o=caller 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar

i=A Seminar on the session description protocol

u ⁼⁼ http://www.huawei.com

e=caller@huawei . com (Caller)

c=IN IP4 10.1.1.10/127

t=2873397496 2873404696

a=sendrecv

m=audio 49170 RTP/AVP 0

m=video 51372 RTP/AVP 31

m=application XXXXX XXX XX

a=orient:portrait

f=finished series :2

o=caller 2890844526 2890842807

s=SDP Seminar

i=A Seminar on the session description protocol

u=http:〃 www.huawei.com e=caller@huawei . com (caller)

c=IN IP4 11.1.1.10/127

t=2873397496 2873404696

a=sendrecv

m=audio XXXX RTP/AVP 0

m=video XXXX RTP/AVP 31

Misapplication 32416 udp wb

a=orient:portrait

F^finished series :3

o=caller 2890844526 2890842807

s=SDP Seminar

i=A Seminar on the session description protocol u=http:〃 www.huawei.com

E=caller@huawei.com (caller)

c=IN IP4 192.168.1.10/127

t=2873397496 2873404696

a=sendrecv

m=audio XXXX RTP/AVP 0

m=video XXXX RTP/AVP 31

m=application XXXXX XXX XX

a=orient:portrait

f=finished series :4

o=caller 2890844526 2890842807

s=SDP Seminar i=A Seminar on the session description protocol u=http:〃 www.huawei.com

E=caller@huawei.com (caller)

c=IN IP4 193.168.1.10/127

t=2873397496 2873404696

a=sendrecv

m=audio XXXX RTP/AVP 0

m=video XXXX RTP/AVP 31

m=application XXXXX XXX XX

a=orient:portrait

f=finished

Embodiment 3, a plurality of media parameters may be present in a session capability information block. Therefore, a description of the media parameter attribute and the priority information is added to a session capability information block carried in the session message, according to the description of the media parameter attribute. It can be obtained which type of network entity or terminal the media parameter belongs to, and the priority level of the media parameter is determined according to the priority information of the media parameter. In this way, the called party of the session message can obtain the service attribute information of the media by viewing the media parameter attribute, and can effectively select the media parameter.

The media parameters of the session capability information block include three types: The first category belongs to the session information, including the session identifier and other session-level parameters, such as the IP address of the session initiator, the topic, the contact information of the session or the creator, etc.; Timing description information, including start and stop time, number of repetitions, and one or more media level descriptions; third category belongs to media type and format description information, including transport protocol and transport address, such as IP address and port number, type of media, Encoding type and other media parameters.

In the media parameter description of the session capability information block, the definition of the media parameter attribution attribute and the priority is added, and a method for how the called party selects the media parameter according to the attribution attribute and priority of the media parameter is provided. In the embodiment of the present invention, multiple media parameters from different networks and network entities are added in the session capability information block. In order to enable the called party to identify the network entities, the description of the media parameters needs to be distinguished in different media parameters. . The description of the media parameter may be a description of the network parameter belonging to which network in the session negotiation process, the type of network entity to which the media parameter belongs, the priority parameter to which the network entity or the called party joins, or/and other attributes.

The description of the media parameter in the message body of the session message received by the called party, including the network parameter belonging to the network in the session negotiation process, the network entity to which the media parameter belongs, the priority of the network entity or the receiver. A description of the parameters, or/and other attributes, the called party uses the description of these media parameters to select the media parameters for this session negotiation.

The format of the message body of the session message is as follows.

v= (protocol version)

o= (owner/creator and session identifier).

s= (session name)

i=* (session information)

u=* (URI of description)

e=* (email address)

p=* (phone number)

c=* (connection information - not required if included in all media)

b=* (bandwidth information)

One or more time descriptions (see below)

z=* (time zone adjustments)

k=* (encryption key)

a=* (zero or more session attribute lines)

Zero or more media descriptions (see below)

The parameters defined by the timing level are:

t= (time the session is active) r=* (zero or more repeat times)

The parameters defined at the media level are:

m= (media name and transport address)

i=* (media title)

C=* (connection information - optional if included at session-level)

b=* (bandwidth information)

k=* (encryption key)

a=* (zero or more media attribute lines

The specific meaning of the media parameters of the session capability information block can be referred to the RFC 2327 standard.

In the media level parameter description, the actual travel example of the present invention uses the a parameter to increase the media parameter attribution attribute, the media parameter type, and the media parameter priority definition.

The media parameter attribution attribute is defined as the network entity or terminal where the media parameter is located. The format of the definition is:

a* =b elong: <value=which entity belong to>

The belonging may be the end point of the session, the network where the session initiator is located, the network where the message receiver is located, or/and the network where the controller is located, and the specific definition may be endpoint origination networks termination network:, or / and focus network :. The endpoint indicates the media parameter provided by the calling party; the origination network indicates the media parameter provided by the calling party's network; the termination network indicates the media parameter provided by the called party's network; and the focus network identifies the media provided by the session controller's network. parameter.

The media parameter priority attribute is defined as the priority order of the media parameters provided by the network. For example, it is specified that the smaller the number between 0 and n, the higher the priority. The specified format can be: a* =priority: <value=priorit property from 0 to n> Priority is a value from 0-n. The parameter 0 indicates that the media parameter belongs to a type of media parameter that is preferentially supported by the service, and belongs to the most commonly used media parameter. The media parameter of parameter 0 may be one or more, and is a media parameter recommended by the network entity. Parameter 1 represents, in addition to the recommended media parameters, other media parameters provided by the network.

It is worth noting that multiple media parameters of the session capability information block can be considered as multiple media parameters within a group. Since the default group is unique in the session capability information block in RFC 3388 describing the definition of the media parameter grouping, it is extended on the basis of which a plurality of media parameter groups are included in one session capability information block.

When a session capability information block includes multiple media parameter groups, the media parameter attribution attribute and priority attribute may be defined in units of media parameter groups. You can join the media parameter group attribution attribute and priority attribute on the next line of a=group:< >. Such as:

a=group:LS 1 2

a=belong:< >

a=priority:< >

m=audio 30000 RTP/AVP 0

a=mid: 1

m=video 30002 RTP/AVP 31

a=mid:2

m=audio 30004 RTP/AVP 0

i=This media stream contains the Spanish translation

a=mid:3

The method of using the media attribution attribute and priority of the calling party in the message body of the session message is as follows.

The calling party is the initiator of the session, and the session capability information block that sends the session establishment request message to the network in which it is located carries the expected media parameters of the session initiator, and the media parameters are in addition to the normal media parameter attributes. Includes media parameter attribution attributes ( a=belong: Endpoint ), since the session capability information block carries only one or a group of media parameters, it is not required to carry the priority attribute.

The method of using the media parameter attribution attribute and priority in the message body of the session message by the network side is as follows.

Adding media parameter attribution attribute and priority attribute on the network side can be divided into three parts, namely, the network where the calling party is located, the network where the controlling party is located, and the network where the called party is located. The three parts of the network may separately add media parameters supported by the network, or may provide media parameters supported by the network by a certain network. The schematic diagram of the network is shown in FIG. 6.

After receiving the session establishment request message, the network where the calling party is located processes the content in the session establishment request message according to the normal process of the IMS specification, and can also add the service capability supported by the network where the calling party is located to the session establishment request message. in. At this time, the session capability information block of the session establishment request message is added with multiple or more sets of media parameters, and the network where the session initiator is located needs to set the media parameter attribution attribute and the priority attribute for the plurality or groups of media parameters.

At this time, the session capability information block includes the calling party media parameter, and a=belong:endpoint and a=priority:0 are added; the network recommendation including one or more calling parties is selected, the media parameter a=belong: Origination network and a=priority: 0; contains one or more media parameters supported by the calling party to the supported media parameters a=belong:origination network and a=priority: 1„

The network where the calling party is located processes the session establishment request message according to the normal flow of the IMS specification. After receiving the session establishment request message, the network where the service controller is located processes the content in the session establishment request message according to the normal process of the IMS specification, and can also add the service capability supported by the network where the service controller is located to the session establishment request. . At this time, the session capability information block of the session establishment request message is added with multiple or more sets of media parameters, and the network where the controller is located needs to set the media parameter attribution attribute and the priority attribute for the added plurality or groups of media parameters. At this time, the session capability information block includes media parameters a=belong: focus network and a=priority:0 recommended by the network where one or more controllers are located; and media parameters supported by the network where one or more controllers are supported =belong:focus network and a=priority: 1. It should be noted that in some application scenarios, such as PoC services, the network where the calling party is located and the network where the controlling party is located may be the same network, that is, the network where the PoC server (Controlling) is located is both the network where the calling party is located and the network where the calling party is located. The network where the controlling party is located.

The network where the controller is located processes the session establishment request message according to the normal flow of the IMS specification. After receiving the session establishment request, the network where the called party is located processes the content in the session establishment request according to the normal process of the IMS specification, and can also add the service capability supported by the network of the called party to the session establishment request. At this time, the SDP description of the session establishment request is added with multiple or multiple sets of media parameters, and the network where the message receiver is located needs to set the media parameter attribution attribute and the priority attribute for the multiple or multiple sets of media parameters. Since the judgment of the priority is made on the AS, and the other network entities cannot determine the priority of the current media parameter, the criterion for the priority of the AS judgment can be considered to be uniform and no conflict occurs.

At this time, the session capability information block includes one or more media parameters recommended by the network where the called party is located a=belong:termination network and a=priority:0; media containing one or more networks supported by the called party The parameters a=belong:termination network and a=priprity: 1.

The network where the called party is located processes the session establishment request message according to the normal flow of the IMS specification. The process of adding the media parameters supported by the network side in the call setup request message may be optional. The network where the calling party is located, the network where the controlling party is located, and the network where the called party is located may select whether to join the network supported by the network. Media parameters. The condition for judging whether to join the media parameters supported by the network may be the service f or the like.

The processing procedure of the session capability information block in the session establishment request message by the AS is as follows. The AS acts as a service processing network entity in the IMS network and can be responsible for the IMS network. Query the media parameters supported by the IMS network, and add the media parameters of the query to the session establishment request. In this case, the media parameter attribution attribute and the priority parameter need to be added to the media parameters in the added media parameters.

Before the AS queries the media parameters supported by the IMS network, the media parameters are stored on the network entity on the IMS platform. The media parameters do not need to carry the parameter attribution attribute and the priority parameter before being sent to the AS. After the AS obtains the media parameters supported by the IMS network, the priority attributes of the media parameters are added to the obtained media parameters according to the services to be provided by the AS. The method of determining the media parameter priority attribute by the AS may be determined according to the description of the media parameter attribute in the message body of the session negotiation message.

In addition to modifying the session capability information carried in the session establishment request message, the entity in the SIP network may also edit or add or delete the application information carried in the request message, and the application information includes ringtones, pictures, messages, videos, and executable programs. And so on. After receiving the request message, the called party can execute or delete the application information according to the settings of the called party.

FIG. 9 is a signaling flowchart of a method for a network entity to add a ringtone and modify a ringtone to a message body in a session establishment request message according to the present invention. The entities involved include: a calling terminal UE1, a called terminal UE2, and a SIP network. S-CSCF #1 in the SIP network to which UE1 belongs, S-CSCF in the SIP network to which UE2 belongs, 2, AS #1 in the SIP network to which UE1 belongs, and AS #2 in the SIP network to which UE2 belongs, assuming AS #1 The ringtone playing program Sound #1, AS #2, which is supported in the SIP network where the UE1 is located, stores the ringtone playing program Sound #2 supported by the SIP network where the UE2 is located, and the specific steps are as follows:

Step 900: The UE1 sends a session establishment request message, that is, an INVITE request, to the S-CSCF #1, where the request carries the session capability information of the UE1, and the UE1 may also add the ringtone playback program Sound to the message body of the request message.

Step 901: The S-CSCF #1 determines, according to the INVITE request, that the current service is by AS #1. Processing, forwarding the INVITE request to AS #1.

Step 902: AS #1 determines, according to the policy of the operator, whether to add, modify, or delete the ringtone player Sound saved on the AS #1 supported by the SIP network in the message body of the session message. If the operator's policy requires AS #1 to join the ringtone player Sound # l and delete the original ringtone player Sound, AS #1 sends an INVITE request carrying Sound #1 to S-CSCF #1.

Step 903: The S-CSCF #1 sends the received INVITE request to the S-CSCF #2. Steps 904 ~ 905, S-CSCF # 2 sends the received INVITE request to AS # 2 , and AS # 2 can select whether to add, change, or delete the content in the message body of the session request message according to the policy of the operator, and return to receive. The response to the INVITE request is given to S-CSCF #2, and the message body of the session request message may include Sound #1 and/or Sound #2.

Step 906, S-CSCF # 2 sends an INVITE request to the UE.

Steps 907-908: The ringtone playing program carried by the UE2 that receives the INVITE request according to the request, in addition to the session negotiation, plays a ringtone to the user who uses the UE2. At this time, UE2 returns a 200 OK response to S-CSCF #2 and performs other operational steps of the session negotiation process.

In such a session negotiation process, AS #1 and AS #2 modify the content of the message body of the session establishment request message according to the policy of the operator, and may add, modify, or delete the ringtone player Sound in the message body of the request message. In addition to the session negotiation mechanism provided in the session establishment request message, other application information is provided.

The network entity that edits or adds or deletes the application information in the message body of the session establishment request message may be one or more of the S-CSCF, the P-CSCF, the AS, and the MRF, and is not limited to the above network entity. The application information of the network entity to edit or add or delete application information may include, but is not limited to, ringtones, pictures, messages, videos, and program content. The process of editing or adding or deleting application information by a network entity can be performed simultaneously with the process of session negotiation. Conducting does not affect the process of business capability negotiation.

FIG. 10 is a signaling flowchart of a description of a media entity in a SIP network in a SIP network that adds a video type to a message body in a session establishment request message, and the network entity involved is: a session initiator terminal UE1, a session access The party terminal UE2, the AS #1 in the SIP network to which the UE1 belongs, and the AS#2 in the SIP network to which the UE2 belongs, the specific steps are as follows:

Step 1000: UE1 sends a session establishment request message to AS#1. Since UE1 only supports audio, only the description of the media information of the audio media type supported by UE1 is carried in the session request setup message.

Steps 1001 to 1003, after receiving the session establishment request message, AS#1 adds a description of the media information of the video media type supported by AS#1 to the message, and then sends a session establishment request message to UE2 through AS#2.

AS# 1 may also add priority level and attribute information to the description of each media information in the session establishment request message, and provide it to UE2 for reference.

Step 1004: After receiving the session establishment request message, the UE2 selects the audio and video media type in the description of the media information carried in the session establishment request message as the result of the session establishment.

Since AS#1 adds priority level and attribute information to the description of each media information in the session establishment request message, UE2 can first determine that UE1 only supports audio, UE2 must select an audio media type; then UE2 can determine that AS#2 supports video, UE2 selects the video media type, and video communication can be established between AS#2 and AS#1.

If there are other terminals that are supported by the network to which AS#1 supports video joins this session, audio and video communication can be performed through AS#2 and AS#1 and UE2.

Steps 1005 ~ 1006, UE2 returns a 200 OK message through AS#2, which carries a description of the media information of the audio and video media type selected by UE2.

Step 1007: After receiving the 200 OK message, AS#1 determines that UE2 selects audio and The video media type is used as the media type of the session. AS#1 establishes an audio media type connection between AS#1 and UE1, and establishes an audio and video media type connection between AS#1 and UE2 via AS#1. A 200 OK message is returned to UE1, which carries a description of the media information of the audio media type supported by UE1.

In the method of FIG. 10, the description of the media information of the audio and video media type selected by the UE2 may or may not be carried in the 200 OK message returned by the AS1 to the UE1. When carrying, the UE1 may determine the present. The media type of the secondary session, if not carried, does not affect UE1's use of audio as a media type in this session.

In order to implement the operation of the session capability information, the embodiment of the present invention further adds a system for session capability information operation. As shown in FIG. 11, the terminals in the SIP network are connected by one or more network entities set by the present invention.

A terminal in a SIP network can be a receiver or a sender.

12 is a schematic structural diagram of a network entity provided by the present invention. The network entity includes: a receiving module 120, a policy obtaining module 121, and a processing module 122, which are sequentially connected, and a response module 123 and a forwarding module 124 respectively connected to the processing module 122; The receiving module 120, the response module 123, and the forwarding module 124 are also connected to respective terminals in the SIP network.

The terminal, that is, the sender of the session message, sends the session message to the receiving module 120. After obtaining the policy for processing the session message, the policy obtaining module 121 transparently transmits the session message received by the receiving module 120 to the processing module 122 and processes the session message. The policy is sent to the processing module 122. After the processing module 122 processes the session message by using the policy of processing the session message, the generated session establishment request message is sent to the forwarding module 124, or the session establishment response message is sent to the response module 123, and the forwarding module 124 The session establishment request message is sent to the terminal, and the response module 123 sends a session establishment response message to the corresponding terminal, that is, the receiver of the session message.

The network entity in the embodiment of the present invention further includes a Capability Provide Function and a policy. The obtaining module is connected, configured to store a policy for processing the session message, and send the stored policy for processing the session message to the policy acquiring module. The Capability Provide Function can also exist independently of the network entity.

The above described specific embodiments of the present invention are described in detail, and are not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the invention are intended to be included within the scope of the invention.

Claims

Claim

A method for performing session capability information operation, the method comprising: a session initiation protocol, a network entity in a SIP network, after receiving a session message carrying session capability information, performing session capability information carried by the session message operating.

2. The method according to claim 1, wherein the session message is a session establishment request message, a session establishment response message, a session establishment negotiation message, a session establishment negotiation confirmation message, a session update message, or a session update confirmation message. .

The method according to claim 2, wherein the session establishment request message is an INVITE message or a REFER message; the session establishment response message is a 200 OK message; and the session establishment negotiation message is 183. The session establishment negotiation confirmation message is a PRACK message; the session update message is an UPDATE message or a REINVITE message; and the session update confirmation message is a 200 OK message.

The method according to claim 1, wherein the session capability information is a session description protocol SDP, an application, or location information, or presentation presence information; wherein the SDP includes session information, session initiator contact information, Time information, connection information, codec type, bandwidth information, encapsulation password, description of transport protocol session attributes, encoding rate, rate of media stream, packet interval, tablet and its size and orientation, multiparty session type, font settings Description of the media properties of the media description language, encoding quality or/and formatting parameters; applications include text, ringtones, video media, audio media, animation or/and executive programs.

The method according to claim 4, wherein the process of operating the session capability information carried by the session message is:

The network entity modifies, adds, or/and deletes different pieces of information in the session capability information carried by the session message.

The method of claim 5, wherein the adding operation is: the network entity adds session capability information and/or configuration information supported by the SIP network to the session message.

The method according to claim 6, wherein the process of acquiring session capability information and/or configuration information supported by the SIP network is: storing session capability information or/and configuration in a capability providing function Capability Provide Function Information, the network entity obtains session capability information or/and configuration information by querying the Capability Provide Function.

8. The method according to claim 6, wherein the process of acquiring session capability information and/or configuration information supported by the SIP network is:

The network entity pre-stores session capability information and/or configuration information supported by the SIP network, and the network entity directly obtains session capability information and/or configuration information supported by the SIP network.

The method according to claim 1, wherein the process of operating the session capability information carried by the session message is:

The network entity modifies, adds, or/and deletes different pieces of information in the attribute information of the session capability information carried by the session message.

The method according to claim 1, wherein before the operating the session capability information carried by the session message, the determining step is further included:

Determining whether the network entity operates the session capability information carried by the session message, and if yes, performing the step of operating the session capability information carried by the session message; otherwise, ending the process.

The method according to claim 10, wherein the determining whether the network entity operates the session capability information carried by the session message is based on a capability of the network entity, or/and a session capability information of the network entity, or / and the configuration information is judged, the session capability information of the network entity is acquired or pre-stored.

12. The method of claim 1 wherein: when the session message is session established When the request message, the session establishment negotiation message, or the session update message is set, the process of operating the session capability information carried by the session message is:

The network entity confirms the session capability information and the session capability information carried in the session message, and confirms that the carried session capability information is supported by the SIP network;

The network entity obtains the stored session capability information and/or configuration information from itself or other network entities, and adds the session capability information and the session capability information carried in the session message according to the obtained session capability information and/or configuration information. , delete or / and modify the operation.

The method according to claim 1, wherein when the session message is a session establishment response message, a session establishment confirmation message, or a session update confirmation message, the process of operating the session capability information carried by the session message is performed. For:

The network entity confirms the service support capability information carried in the session message and the attribute information in the service support capability information, and identifies the session capability information selected by the called party and the attribute information in the selected session capability information;

The network entity confirms that the session capability information selected by the called party and the attribute information in the selected session capability information are valid selections according to the preset policy or/and the capability of the network, and modify or/and delete the selected content of the called party. Effectively selected session capability information and attribute information in session capability information.

The method according to claim 6, 7, 8, 11, or 12, wherein the session capability information and/or configuration information includes a media type, a transport protocol, a format of the media, a transport address of the media, Port number, or / and attribute information.

The method according to claim 1, wherein after the session capability information carried by the session message is operated, the session message includes one or more session capability information blocks.

The method according to claim 15, wherein the session capability information block is summarized by attribute information, and the session capability information block is recognized by the network entity by attribute information to which the session capability information block belongs. do not.

The method according to claim 15, wherein the session capability information block is distinguished by a number, session capability information start flag information, service capability end flag information, or/and length information.

The method according to claim 9, 12, 13 or 16, wherein the attribute information comprises: operator information, network entity type information, network entity identity for performing the change, and session capability information operation. Type, session capability information operation flag, importance of session capability information after operation, or/and priority information.

The method according to claim 9, 12, 13 or 16, wherein the attribute information is carried in a session message using a session description protocol SDP, or carried in a message header of a session message using SIP or In the body of the message.

The method according to claim 9, 12, 13 or 16, wherein the attribute information identifies network entity information of the session capability information block, or/and priority information identifying the session capability information block.

The method according to claim 15, wherein the session message is a session message using an SDP, and the session capability information carried by the session message is described by using a description medium information language XML or a script language SCRIPT.

The method according to claim 1, wherein the network entity is an application server AS, or a call control function CSCF, or a media resource function MRF or a SIP server;

The AS is a control button, that is, a PoC service function PoC Server (Controlling), a PoC service (Postation), a Multi-party conference server, a Service Capability Interaction Manager (SCIM), or a presence service server Presence. Server, or interworking gateway IWF; CSCF is proxy call control function P-CSCF, service call control function S-CSCF, Or query the call control function I-CSCF; the SIP server is the call control function CSCF or the outgoing border gateway control function BGCF or the application layer gateway SIP-ALG of the SIP protocol; the MR is the media resource control MRFC or the media resource processing MRFP.

The method according to claim 1, wherein the SIP network comprises a SIP network to which the calling party and the called party belong;

Or the SIP network includes a SIP network to which the calling party belongs and a SIP network to which the called party belongs; or the SIP network includes a SIP network to which the calling party belongs, a SIP network to which the called party belongs, and a calling party. One or more SIP networks traversed by the associated SIP network and the SIP network to which the called party belongs.

A network entity that operates with session capability information, wherein the network entity comprises: a receiving module, a policy acquiring module, and a processing module that are sequentially connected, and a response module and a forwarding module respectively connected to the processing module; wherein, receiving The module, the response module, and the forwarding module are also connected to each terminal in the SIP network;

The network entity according to claim 24, wherein the network entity further comprises a Capability provide Function, which is connected to the policy acquisition module in the network entity, and is configured to provide the policy acquisition module in the network entity with its own saved Processing session messages

The network entity according to claim 24, wherein the network entity is an AS, a CSCF, an MRF, and a SIP server; The AS is a PoC Server (Controlling), a PoC Server (Parting), a Conference Server, a Service Capability Interaction Manager (SCIM), or an Interworking Gateway IWF, or a Presence Server; the CSCF is a P-CSCF, an S-CSCF, or an I-CSCF; The SIP server is BGCF or SIP-ALG; MRP is MRFC or MRFP.

The network entity according to claim 24, wherein the SIP network comprises a calling terminal and a SIP network to which the called terminal belongs;

Or the SIP network includes a SIP network to which the calling terminal belongs and a SIP network to which the called terminal belongs;

Or the SIP network includes a SIP network to which the calling terminal belongs, a SIP network to which the called terminal belongs, and one or more SIP networks traversed by the SIP network to which the calling terminal belongs and the SIP network to which the called terminal belongs.