WO2007095855A1

WO2007095855A1 - A method and network entity for negotiating media type parameter

Info

Publication number: WO2007095855A1
Application number: PCT/CN2007/000562
Authority: WO
Inventors: Lei Zhu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-02-23
Filing date: 2007-02-15
Publication date: 2007-08-30
Also published as: CN101026614B; CN101026614A

Abstract

The present invention comprises a method and network entity for negotiating media type parameter, the method comprises: the network entity for controlling session sending the media type parameter that can be selected in the multiparty session to all or part of the called party participating in the session; the network entity for controlling the session receiving the ACK message including all or part of media type parameter selected by the all or part of the called party participating in the multiparty session from the media type parameter sent by the network entity for controlling the session. The method and network entity providing in the present invention can realize to negotiate the media type parameter in SIP message.

Description

Method for negotiating media type parameters and network entity

The present invention relates to a technique for processing media parameters in a mobile communication system, and more particularly to a method for negotiating media type parameters and a network entity. Background of the invention

With the development of broadband networks, mobile communication systems are not limited to traditional voice communication, but can also combine multiple media services such as audio, video, pictures and text. Multiple media services The combination of data services such as presence, short message, web browsing, location information, push service (PUSH) and file sharing can meet the diverse needs of user terminals.

Driven by various data service applications, standards organizations such as 3GPP and 3GPP2 have launched an Internet Protocol (IP)-based Multimedia Subsystem (IMS) architecture, which aims to achieve a multi-standard open architecture in mobile communication systems. A variety of multimedia business applications provide users with more choices and richer feelings.

In the 3GPP Release 5 (R5 Release) phase, IMS is introduced, which is superimposed on the packet domain network by the Call Control Function Entity (CSCF), the Media Gateway Control Function Entity (MGCF), the Media Resource Function Entity (MRF) and the Ownership. It consists of functional entities such as the Subscriber Server (HSS). The CSCF can be divided into three logical entities: the service CSCF (S-CSCF), the proxy CSCF (P-CSCF), and the 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 user terminal information, and generates charging information. The P-CSCF is an access point for the UE to access the IMS, completes user terminal registration, and is responsible for services. Quality (QoS) control and security management; I-CSCF is responsible for interworking between IMS domains, managing the allocation and selection of S-CSCFs, and hiding network topology and configuration. Generate billing data, etc. The MGCF controls the gateway to implement interworking between the IMS and other networks. MRF provides media resources. The HSS stores subscription data and configuration information of the user terminal.

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 type of user terminal. Therefore, the IMS network is not limited to be applied 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.

The Session Initiation Protocol (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 the IMS network, the SIP protocol is used as the signaling control protocol for IP multimedia sessions.

In the control-based multi-party session communication technology, the media parameters in the SIP message need to be negotiated between the network entities of the multi-party session communication system. According to the existing protocol, the media parameter package includes a body type parameter and an encoding parameter. During session communication, parties participating in the session can also choose different media type parameters to use in the same multiparty session. Therefore, the media type parameters of the SIP message must be negotiated between the network entities in the communication system, especially among the network entities in the multi-party session communication system. However, in the multi-party session communication system, there is no SIP message yet. The technique of media type parameter negotiation. Summary of the invention

The embodiment of the invention provides a method for negotiating media type parameters, which can be implemented

Negotiation of media type parameters in SIP messages.

The embodiment of the present invention further provides a negotiation network entity of a media type parameter, where the network entity can implement negotiation of media type parameters in a SIP message. The technical solution of the embodiment of the present invention is implemented as follows:

A method for negotiating a media type parameter, the method comprising: controlling a network entity of a session to send a media type parameter selectable by the multiparty session to all or part of the called party participating in the multiparty session;

The network entity controlling the session receives the response message sent by the called party that participates in all or part of the current multi-party session, and the response message includes the called party that participates in all or part of the current multi-party session from the control All or part of the media type parameter selected in the media type parameter sent by the network entity of the session.

A negotiation network entity of a media type parameter, the network entity includes: the network entity includes: a transceiver module and a media type parameter setting module, where

The transceiver module is configured to: after receiving the message carrying the media type parameter, send the message to the media type parameter setting module; and send the message carrying the updated media type parameter from the media type parameter setting module, and send the message;

The media type parameter setting module is configured to: after receiving the message from the transceiver module, determine, according to the policy, the media type parameter update carried by the message, and carry the updated media type parameter in the message and send the message to the transceiver module.

As can be seen from the foregoing solution, when establishing a multi-party session, the calling party first initiates a session to the network entity of the control session. Second, the network entity controlling the session participates in all or part of the multi-party session according to the policy. The called party provides the media type parameter that can be selected in this session. Finally, the called party that participates in this multiparty session in whole or in part selects the media type parameter provided by the network entity of one or more control sessions. In this way, the method and the network entity provided by the embodiment of the present invention can implement negotiation of media type parameters in the SIP message. BRIEF DESCRIPTION OF THE DRAWINGS

1 is a flowchart of a method 1 for negotiating media type parameters according to an embodiment of the present invention; 2 is a flowchart of a second method for negotiating media type parameters according to an embodiment of the present invention; FIG. 3 is a flowchart of a third method for negotiating media type parameters according to an embodiment of the present invention; FIG. FIG. 5 is a schematic diagram of a network structure for implementing a method for negotiating media type parameters according to an embodiment of the present invention;

FIG. 6 is a schematic structural diagram of a negotiating network entity of a media type parameter according to an embodiment of 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 multi-party conversation communication system of the embodiment of the present invention may be a multimedia-based Push to talk over Cellular (PoC) communication system or a multimedia-based full-duplex conference communication system.

In a multi-party session communication system that introduces a multimedia type, when a multi-party session is established, first, the network entity that initiates the session control session initiates a session, such as sending a SIP message to the network entity controlling the session, which is generally carried in the SIP message. Establish media type parameters for the session. The media type parameter carried in the SIP message may be all media types supported by the calling party, or may be part of the media type supported by the calling party, that is, a subset of the supported media types. The media type parameter carried in the SIP message may also be all or a subset of the media types supported by the network entity controlling the session in the network. Secondly, the network entity controlling the session provides the media type parameters that can be selected in this session to all or part of the called party participating in the multi-party session according to the session capability and the multi-party session communication system setting policy, such as participating in all the multi-party sessions. The called party sends a SIP message carrying a media type parameter. Finally, the called party participating in the multiparty session selects one or more media type parameters according to its own requirements, and the media parameter selected by the called party is received by the called party. The media class carried in the incoming SIP message All or a subset of the type parameters, such as selecting one or more media type parameters carried by the received SIP message. Therefore, the method provided by the embodiment of the present invention can enable multiple parties in a session to use different media types according to their requirements during the session establishment phase.

The process of carrying the media type parameter in the SIP message is: setting the media type in the SIP message, and setting the information of each media type corresponding to each media type in the SIP message. The media type information can also be set according to the method specified by the IETF RFC3264 standard, and can also be set according to other rules regarding the media type parameters. Other rules can include the RPC document and the IETF draft specified in the IETF standard.

In the embodiment of the present invention, the multi-party session may also be initiated by the calling party, but the multi-party session is directly initiated by the network entity controlling the session, and the network entity controlling the session participates in the session when initiating the multi-party session. All or part of the called party sends a SIP message carrying a media type parameter that can be selected in this session, such as an INVITE request.

FIG. 1 is a flowchart of a method for negotiating a media type parameter according to an embodiment of the present invention. The application scenario of the embodiment is a multimedia-based PoC communication system, and the specific steps are as follows:

Step 100: The calling party PoC Client A sends an INVITE request to the PoC server A of the PoC server. The PoC Server A is used to establish a multi-party multimedia PoC session. The media type parameters carried by the request are voice and non-contiguous media. Continuous media can be text, pictures, and files. At this time, PoC Client A requests PoC Server A to establish a multimedia connection of voice and non-contiguous media types.

The INVITE request is a SIP message.

Step 101: The PoC Server A forwards the request to the server PoC Server X of the control session through the SIP network.

Step 102: The PoC Server X as a control function entity of the session can support multiple media types, including voice, video, and non-contiguous types. The PoC Server X determines support according to a pre-set policy of the multi-party session communication system and the session capability provided by itself. Video media The body type, the video media type parameter is added to the INVITE request, and an INVITE request carrying the video, voice, and non-contiguous media type parameters is sent to a called party PoC Client B of the multiparty session. At this time, the INVITE request sent by PoC Server X to PoC Client B includes media parameters for establishing voice, video, and non-contiguous media types.

Step 103: The PoC Server X as a control function entity of the session can support multiple media types, including voice, video, and non-contiguous media types. The PoC Server X determines the support video according to the preset policy of the multi-party session communication system and the session capability provided by the peer. This media type adds the video media type parameter to the INVITE request, and sends an INVITE request carrying the video, voice, and non-contiguous media type parameters to another called party PoC Client C of the multiparty session. At this time, the INVITE request sent by PoC Server X to PoC Client C includes media parameters for establishing voice, video, and non-contiguous media types.

Step 102 and step 103 are both sent by the PoC Server X to the INVITE request, but are sent to different called parties participating in the multi-party session. It must be noted that the two steps are not in the order, and the step 103 may be performed first. Step 102 is performed again, or step 103 and step 102 are performed simultaneously.

Step 104: The PoC Client B selects to receive the complete set or subset of the media types in the INVITE request, and returns the selected media type parameter in the response message.

In this step, the response message may also carry the media type parameter that is not selected by the PoC Client B. The media type parameter that is not selected by the PoC Client B needs to be separately identified when carrying the response message, for example, marked as inactive.

Step 105: The PoC Client C selects to receive the complete set or subset of the media types in the INVITE request, and returns the selected media type parameter in the response message.

In this step, the response message can also carry the media class that PoC Client C does not select. For the type parameter, the media type parameter that is not selected by the PoC Client B needs to be separately identified when carrying the response message, such as marked as inactive.

Step 106: The PoC Server X, as the control function entity of the session, receives the response message carrying the selected media type parameter of the PoC Client B and the PoC Client C, and then returns a response message to the PoC Client A.

According to the PoC system, after receiving the response message returned by the first called party, the PoC Server X returns a response message for successfully establishing the session to the calling party PoC Client A, and the response message carries the main support according to the preset policy. The media type parameter used by the calling party in the session. The response message is finally sent to the PoC Client A through the PoC Server A to which the PoC Client A belongs.

The response message may also carry all or part of the media type parameters supported by the PoC Server X as the control function entity of the session as the information provided to the PoC Client A. The control function entity provides all or part of the media type parameters, which can be determined according to the set policy. The type parameter is carried in two response messages and sent to PoC Server A.

2 is a flowchart of a second method for negotiating media type parameters according to an embodiment of the present invention. The application scenario of the embodiment is a multimedia-based PoC communication system, and the specific steps are as follows:

Step 200: The calling party PoC Client A sends an INVITE request to the PoC Server A of the PoC server to request to establish a multi-party multimedia PoC session, and the media type parameters carried by the request are voice and text.

If the media type supported by the calling party is voice, video and text, the video can also be carried in the INVITE request. However, since the PoC Client A does not want to use the video during this multi-party session, the video will be such a media. Types are identified separately, as marked as inactive. At this time, PoC Client A requests PoC Server A to establish a connection between voice and non-contiguous media types.

Step 201: The PoC Server A forwards the request to the server PoC Server X that controls the session.

Step 202: The PoC Server X determines the media type of the supported video according to the preset policy of the multi-party session communication system and the session capability provided by the PoC Server X, and adds the media type parameter of the video to the INVITE request, which is carried, including video, voice, and The INVITE request of the media type parameter of the text is sent to a called party PoC Client B of the multiparty session.

If PoC Client A does not want to use video during this multi-party session, PoC Server X can also identify the media type of video separately. It can be identified as not supported during the multi-party session. For example, the video media type is inactive. Indicates that the called party of this session cannot select the video media type.

Step 203: The PoC Server X determines the media type of the supported video according to the preset policy of the multi-party session communication system and the session capability provided by the PoC Server X, and adds the media type parameter of the video to the INVITE request, and carries the video, the voice, and the text. The INVITE request of the media type parameter is sent to another called party PoC Client C of the multiparty session.

If PoC Client A does not want to use video during this multi-party session, PoC Server X can also identify the media type of video separately. It can be identified as not supported during the multi-party session, such as the video media type is inactive.

Steps 202 and 203 are both sent by the PoC Server X to the INVITE request, but are sent to different called parties participating in the multi-party session. It must be noted that the two steps are not in the order, and the step 203 may be performed first. Step 202 is performed again, or steps 203 and 202 are performed simultaneously.

Step 204: After receiving the INVITE request, the PoC Client B selects according to its own requirements. After the one or more media type parameters provided by the SIP message used in the multi-party session, the response message carries the selected one or more media type parameters, and sends a response message to the PoC Server X.

For example, PoC Client B chooses to use voice, video, and text as the media type to participate in this multi-party conversation, and carries the media type parameters of the selected voice, video, and text in the response message. The response message can be a 200 OK message, which is also a SIP message.

If the media type parameter of the video in the INVITE request is not supported by the PoC Client B, the PoC Client B cannot select the media type of the video.

Step 205: After receiving the INVITE request, the PoC Client C selects one or more media type parameters provided by the SIP message used in the current multi-party session according to the requirements, and carries the selected one or more media in the response message. The type parameter sends a reply message to PoC Server X.

For example, PoC Client C chooses to use voice and text as the media type to participate in this multi-party session, and carries the media type parameters of the selected voice and text in the response message. The reply message can be a 200 OK message, which is also a SIP message.

If the media type parameter of the video in the INVITE request is not supported by the PoC Client C, the PoC Client C cannot select the media type of the video.

Step 206: The PoC Server X determines the media type selected by the PoC Client C and the PoC Client B according to the response message received from the PoC Client C and the PoC Client B, and uses the media types selected by the PoC Client C and the PoC Client B as PoC Clients respectively. The media type parameter of the C and the PoC Client B is carried in the response message and sent to the PoC Server A. The PoC Server A forwards the received response message to the PoC Client A.

In the PoC system, after receiving the response message returned by the first called party, the PoC server returns a response message for successfully establishing the session to the calling party.

PoC Server X can also use PoC Client C and PoC Client B media classes. The type parameter is carried in two response messages and sent to PoC Server A. The reply message can be a 200 O message, which is also a SIP message.

Thus, in the method described in FIG. 2, the calling party selects voice and text as the media type of the session in this multi-party session, and a called party selects voice, video, and text as the media of the session in this multi-party session. Type, another called party selects voice and text as the media type of the session in this multi-party session.

3 is a flowchart of Embodiment 3 of a method for negotiating a media type parameter according to the present invention. The application scenario of the embodiment is a multimedia-based PoC communication system, and the specific steps are as follows:

Step 300: The calling party PoC Client A sends an INVITE request to the PoC server A of the PoC server to request to establish a multi-party multimedia PoC session, and the media type parameter carried in the request is voice.

At this time, PoC Client A requests PoC Server A to establish a voice media type connection. Step 301: The PoC Server A forwards the request to the server PoC Server X that controls the session.

Step 302: The PoC Server X determines, according to the preset policy of the multi-party session communication system and the session capability provided by itself, the voice, video, and non-contiguous media types, and determines to select the supported voice, video, and discontinuous media parameters to the INVITE request. The INVITE request carrying the video, voice, and non-contiguous media type parameters is sent to a called party PoC Client B of the multiparty session.

If PoC Client A does not want to use video during this multi-party session, PoC Server X can also identify the video media type separately. It can be identified as not supported during the multi-party session, such as the video media type is inactive.

Step 303: The PoC Server X determines, according to the preset policy of the multi-party session communication system and the session capability provided by itself, the supported voice, video, and discontinuous media types, and determines the selected video and voice media type parameter settings to be sent to another called party. PoC Client C In the INVITE request, the PoC Server X will carry an INVITE request containing the video and voice media type parameters to another called party PoC Client C of the multiparty session.

Step 304: After receiving the INVITE request, the PoC Client B selects one or more media type parameters provided by the SIP message used in the current multi-party session according to the requirements, and carries the selected one or more media in the response message. The type parameter sends a reply message to PoC Server X.

For example, the PoC Client B selects the voice, video, and non-contiguous media types as the media types participating in the multi-party session, and carries the media type parameters of the selected voice, video, and non-contiguous media in the response message. Message may be a 200 OK response message, the message is a SIP message 200 OK ₀

Step 305: After receiving the INVITE request, the PoC Client C selects one or more media type parameters provided by the SIP message used in the current multi-party session according to the requirements, and carries the selected one or more media in the response message. The type parameter sends a reply message to PoC Server X.

For example, PoC Client C chooses to use voice and video as the media type to participate in this multi-party session, and carries the media type parameters of the selected voice and video in the response message. The reply message can be a 200 OK message, which is also a SIP message.

Step 306: The PoC Server X determines, according to the response message received from the PoC Client C and the PoC Client B, the media type selected by the PoC Client C and the PoC Client B, and the media type parameter of the PoC Client B is carried in the response message and sent to the PoC. Server A, PoC Server A forwards the response message received to PoC Client A.

It is stipulated in the PoC system that after receiving the response returned by the first called party, the PoC server returns a response message for successfully establishing the session to the calling party.

PoC Server X can also use PoC Client C separately.

The type parameter is carried in two response messages and sent to PoC Server A. The response message can be a 200 OK message, which is also a SIP message.

Thus, in the method described in FIG. 3, the calling party selects voice and picture as the media type of the session in this multiparty session; PoC Server X carries voice, video, and non in the INVITE request sent to a called party. The continuous media type carries the voice and video media types in the INVITE request sent to another called party; a called party selects voice, video, and non-contiguous media as the media type of the session in this multiparty session, and the other is The calling party selects voice and video as the media type of the session in this multi-party session.

The method described in FIG. 1 , FIG. 2 and FIG. 3 only describes the media type selection of the three-party multi-party session, and the embodiment of the present invention can also perform more than three parties according to the methods described in FIG. 1 , FIG. 2 and FIG. 3 , for example, ten. The media type selection for the party's multiparty session. The method described in FIG. 1, FIG. 2 and FIG. 3 only describes the multi-party session media type selection of the multimedia-based PoC communication system, and the embodiment of the present invention can also be based on the conference communication according to the methods described in FIG. 1, FIG. 2 and FIG. The system performs media type selection for multiparty sessions.

4 is a flowchart of a fourth method for negotiating a media type parameter according to an embodiment of the present invention. The application scenario of the embodiment is a multimedia-based PoC communication system, where a media type parameter of the multi-party session is initiated by a server PoC Server X that controls the session. The specific steps are as follows: Steps 400 - 401, the PoC Server X determines the media type parameters (video, language) supported by the session according to the pre-set policy of the multi-party session communication system and the session capability provided by the PoC Server X.

Parameter), the INVITE request carrying the media type parameter including video, voice and text is sent to the participant PoC Client A of the multi-party session and PoC Client B.

Step 401 and step 402 are both sent by the PoC Server X to the INVITE request, but are sent to different participants participating in the multi-party session. It must be noted that the two steps are not in the order, and the step 402 may be performed first. Step 401 is performed, or steps 401 and 402 are performed simultaneously.

Step 403: After receiving the INVITE request, the PoC Client A selects one or more media type parameters provided by the SIP message used in the current multi-party session according to the requirements, and carries the selected one or more media in the response message. The type parameter sends a reply message to PoC Server X.

For example, PoC Client A chooses to use voice, video, and text as the media type to participate in this multi-party conversation, and carries the media type parameters of the selected voice, video, and text in the response message. The response message can be a 200 OK message, which is also a SIP message.

Step 404: After receiving the INVITE request, the PoC Client B selects one or more media type parameters provided by the SIP message used in the current multi-party session according to the requirements, and carries the selected one or more media in the response message. The type parameter sends a reply message to PoC Server X.

The self-session capability and the pre-set policy of the multi-party session communication system in the embodiments of the present invention are used to determine the media type supported by all or part of the multi-party session communication system, or/and to determine to participate in all or part of the multi-party session. The called party sends all or part of the media type parameters supported by this session.

The self-session capability described in the embodiment of the present invention refers to related information such as a session description, a media type, and a format description. The policy set in the embodiment of the present invention is: The strategy of the party communication system. The operator's policy may be that the network entity controlling the session provides all or part of the media type parameters to all called parties; the network entity controlling the session provides all or part of the media type parameters to the part of the called party. The policy of the multi-party communication system may be that the network entity controlling the session provides all or part of the media type parameters to all called parties; the network entity controlling the session provides all or part of the media type parameters to the part of the called party.

The invention is illustrated by the following specific examples. FIG. 5 is a schematic diagram of a network structure for implementing a method for negotiating media type parameters according to an embodiment of the present invention, as shown in the following figure: The PoC Server supports voice, video, and non-contiguous media types. The calling party establishes a session and uses the media types of voice and non-contiguous media in the established session.

PoC Client A, PoC Client B, PoC Client C, and PoC Client D are called parties. In this session, you want to use voice, voice/video, voice/video/discontinuous media, and voice as the media type.

First, when the PoC Server receives the INVITE request sent by the calling party and carries the media type parameter of the voice and the non-contiguous media, the PoC Server sends an INVITE request to the multiple called methods according to the preset policy, and the request is carried in the request. The media type parameter is all media types supported by the PoC Server, such as voice, video, and non-contiguous media types supported by the PoC Server; then, multiple called parties, namely, PoC Client A, PoC Client B, PoC Client C, and PoC The client D receives the INVITE request of all media types supported by the PoC server, selects all or a subset of the media types carried in the INVITE request according to the requirements, and returns the selected media type parameter to the PoC Server in the response message 200 OK. For example, PoC Client A selects the voice, and carries the media type parameter of the voice in the response message 200 OK to return to the PoC Server; PoC Client B selects the voice/video, and carries the media type parameter of the voice/video in the response message 200 OK Return ^ PoC Server; PoC Client C selects voice/video/discontinuous media, and will voice/view / Non-connected The media type parameter of the continuation media is returned to the PoC Server in the response message 200 OK; the PoC Client D selects the voice, and carries the media type parameter of the voice in the response message 200 OK and returns it to the PoC Server.

After receiving the response message sent by the called party, the PoC Server will return a response message to the calling party. At this time, the response message returned by the PoC Server to the calling party includes, in addition to accepting the voice and non-contiguous media requested by the calling party as the media type, a media type supported by the PoC Server, such as a video, for the calling party. For reference. In the embodiment of the present invention, the PoC Server may further include a media type parameter corresponding to each called party in the response message returned by the calling party, that is, a media type parameter selected by each called party, for example, including a PoC Client. A selected voice; PoC Client B selected voice/video; PoC Client C selected voice/video/discontinuous media and PoC Client D selected voice.

The embodiment of the present invention further provides a negotiation network entity of a media type parameter. As shown in FIG. 6, the network entity includes: a transceiver module and a media type parameter setting module, where the transceiver module is configured to receive a SIP carrying a media type parameter. After the message is sent to the media type parameter setting module, the SIP message carrying the updated media type parameter is received from the media type parameter setting module, and is sent.

The media type parameter setting module is configured to: after receiving the SIP message from the transceiver module, determine, according to the policy, the parameter of the media type parameter that is carried, and the updated media type parameter is carried in the SIP message and sent to the transceiver module.

In this embodiment of the present invention, the network entity may be a network entity that controls a session.

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 negotiating a media type parameter, the method comprising: the network entity controlling the session sending the media type parameter selectable by the multiparty session to the called party participating in the multiparty session in whole or in part;

The method of claim 1 , wherein before the network entity of the control session sends the media type parameter that can be selected by the multi-party session, the method further includes: the network entity that controls the session receives A message to the calling party to initiate a multiparty session.

The method according to claim 2, wherein the message that the calling party initiates the multi-party conversation includes one or more media type parameters selected by the calling party.

The method according to claim 1 or 3, wherein at least one selected media type parameter of the calling party, the called party, and the network entity controlling the session is carried in a session initiation protocol SIP message. .

The method of claim 2, after the network entity of the control session receives the response message sent by the called party, the method further includes:

The network entity of the control session sends a response message to the calling party, where the response message includes the network entity of the control session according to its own session capability and the multi-party session communication system setting policy, and the calling party supported by itself is in the session. The selected media type parameter.

The method of claim 5, wherein the response message sent to the calling party further comprises: a media type parameter selected by the called party that participates in all or part of the multiparty session.

7. The method according to claim 5 or 6, wherein the sending to the calling party The response message further includes a media type parameter selected by the network entity of the control session according to its own session capability and the multi-party session communication system setting policy, which is supported by itself and not selected by the calling party.

The method according to claim 5 or 6, wherein the response message sent to the calling party is a SIP message. ,

The method of claim 1, wherein: the response message sent by the called party of the multi-party session, which is received by the network entity of the control session, further includes: The called party that participates in all or part of this multiparty session is identified as an inactive media type parameter.

The method according to claim 1, wherein the network entity controlling the session determines a media type parameter that can be selected by the current multi-party session according to the self-session capability and the multi-party session communication system setting policy.

The method according to claim 10, wherein the setting policy is a policy of an operator or a policy of a multi-party session communication system;

The policy of the operator is: the network entity controlling the session provides all or part of the media type parameter to all called parties; the network entity controlling the session provides all or part of the media type parameter to the part of the called party;

The policy of the multi-party session communication system is: the network entity controlling the session provides all or part of the media type parameters to all called parties; the network entity controlling the session provides all or part of the media type parameters to the part of the called party.

12. The method of any of claims 1, 2, 3, 5, 6, 9, and 10, wherein the network entity controlling the session is a multimedia-based push-to-talk over cellular PoC communication system A server that controls the session or the control session of the multimedia-based full-duplex conference conference communication system.

13. A negotiating network entity of a media type parameter, characterized in that the network entity The method includes: a transceiver module and a media type parameter setting module, where