IMS-session media renegotiation method and apparatus, and communication device and storage medium

Abstract

The present application relates to an IMS-session media renegotiation method and apparatus, and a communication device, a storage medium and a computer program product. The method comprises: sending an SIP request to a receiving end (S202); receiving an SIP answer returned by the receiving end for the SIP request, wherein the SIP request and the SIP answer comprise media description information of an initiating end for a plurality of data channels and media description information of the receiving end for the plurality of data channels, respectively, and at least two data channels associated with different applications can multiplex an SDP m-row of a single SCTP link (S204); and setting up or updating the plurality of data channels between the initiating end and the receiving end on the basis of the SIP request and the SIP answer (S206).

Description

IMS session media renegotiation method, apparatus, communication device, and storage medium

[0001] Related applications

[0002] This application claims priority to Chinese patent application number 2023115856517, filed on November 24, 2023, entitled “IMS session media renegotiation method, apparatus, communication equipment and storage medium,” the entire text of which is hereby incorporated by reference. Technical Field

[0003] The present application relates to the field of wireless communication technology, and in particular to an IMS (IP Multimedia Subsystem) session media renegotiation method, apparatus, communication equipment, storage medium, and computer program product. Background Art

[0004] With the development of wireless communication technology, technologies have emerged that enable real-time interaction during audio and video calls by establishing one or more data channels for parallel transmission alongside audio and video in an IMS session. Accordingly, multiple DCs (Data Channels) are established between the communicating parties.

[0005] In traditional technologies, each DC negotiation requires a separate SDP m=line (media line or m-line). When a service requires multiple DCs, multiple SDP m=lines are required, which will occupy a large amount of end network resources and lead to excessive end network resource consumption.

[0006] Summary of the Invention

[0007] In a first aspect, the present application provides an IMS session media renegotiation method, applied to an initiating end, the method comprising:

[0008] Sending a SIP request to the receiving end; the SIP request includes the SDP media description information of the initiator for multiple data channels, and at least two data channels can reuse the SDP m line of a separate SCTP link in the SIP request;

[0009] receiving a SIP response returned by the receiving end in response to the SIP request; wherein the SIP response includes SDP media description information of the receiving end for the multiple data channels, and at least two data channels can reuse an SDP m line of a separate SCTP link in the SIP response;

[0010] Establishing or updating the plurality of data channels between the initiating end and the receiving end based on the SIP request and the SIP response;

[0011] Wherein, in the SIP request and the SIP response, the at least two data channels multiplexing one m line are associated with at least two data channel applications.

[0012] In one embodiment, in the SIP request and the SIP response, the dcmap attribute information corresponding to each data channel of m multiplexed lines occupies a separate line, and the flow ID filled in each line is different.

[0013] In one embodiment, both the initiator and the receiver support at least two m-lines for the SCTP link, where the at least two m-lines include a first m-line and a second m-line. The method further includes: for at least two data channels matching a GBR-type bearer, multiplexing one first m-line in a SIP request and a SIP response; and for at least two data channels matching a Non-GBR-type bearer, multiplexing one second m-line in a SIP request and a SIP response.

[0014] In one embodiment, in a SIP request and a SIP response, the rules followed for multiplexing at least two data channels of an m-line include at least one of the following:

[0015] At least two data channels of one m-row are multiplexed and have the same 3GPP QoS hint attributes;

[0016] Multiplexing at least two data channels of an m-row with the same 3GPP bandwidth modification;

[0017] At least two data channels multiplexing one m-row have the same transmission address parameters of the m-row.

[0018] In one embodiment, when at least two data channels multiplexing an m-row have the same m-row transmission address parameters, the m-row transmission address multiplexed by the at least two data channels includes a real transmission address or an anchor transmission address.

[0019] In one embodiment, the 3GPP QoS hint attribute includes at least two parameters:

[0020] Wherein, when all QoS parameters corresponding to at least two data channels multiplexing one m line are the same, unique parameters are filled in the parameter line used to describe QoS attributes in the SIP request and the SIP response;

[0021] In the case that some QoS parameters of the at least two data channels multiplexing one m line are the same, the most stringent QoS parameters are filled in the parameter lines for describing QoS attributes in the SIP request and the SIP response.

[0022] In one embodiment, sending a SIP request to a receiving end includes:

[0023] If the initiating end is the terminal before the call is connected, a SIP UPDATE message is sent to the receiving end for media renegotiation; and receiving a SIP response returned by the receiving end in response to the SIP request includes: receiving a renegotiation response message returned by the receiving end in response to the SIP UPDATE message.

[0024] In one embodiment, sending a SIP request to a receiving end further includes:

[0025] If the initiating end is a terminal after the call is connected, a SIP re-INVITE message is sent to the receiving end for media re-negotiation; receiving a SIP response returned by the above receiving end for the SIP request includes: receiving a re-negotiation response message returned by the above receiving end for the SIP re-INVITE message.

[0026] In one embodiment, before sending the SIP request to the receiving end, the method further includes:

[0027] If it is determined that the initiating end supports the SDP m line of multiplexing multiple data channels on a single SCTP link, the SIP request is sent to the receiving end.

[0028] In a second aspect, the present application provides an IMS session media renegotiation method, which is applied to an IMS communication system, wherein the IMS communication system includes an initiating end and a receiving end, and the method includes:

[0029] The initiator generates a SIP request and sends it to the receiver; the SIP request includes the SDP media description information of the initiator for multiple data channels, and at least two data channels can reuse the SDP m line of a separate SCTP link in the SIP request;

[0030] The receiving end generates a SIP response in response to the SIP request and sends it to the initiating end; the SIP response includes the receiving end's SDP media description information for the multiple data channels, and at least two data channels can multiplex an SDP m line of a separate SCTP link in the SIP response;

[0031] Establishing or updating the plurality of data channels between the initiating end and the receiving end based on the SIP request and the SIP response;

[0032] Wherein, in the SIP request and the SIP response, the at least two data channels multiplexing one m line are associated with at least two data channel applications.

[0033] In a third aspect, the present application further provides an IMS session media renegotiation device, comprising:

[0034] A request sending module is configured to send a SIP request to a receiving end; the SIP request includes SDP media description information supported by the initiator for multiple data channels, and an SDP m line of a single SCTP link in the SIP request supports multiplexing of at least two data channels;

[0035] a response receiving module, configured to receive a SIP response returned by the receiving end in response to the SIP request; the SIP response including the receiving end's SDP media description information for multiple data channels, and an SDP m line for a single SCTP link in the SIP response supporting multiplexing of at least two data channels;

[0036] A channel establishment module is used to establish / update multiple data channels between the initiator and the receiver based on SIP requests and SIP responses;

[0037] Wherein, in the SIP request and the SIP response, the at least two data channels multiplexing one m line are associated with at least two data channel applications.

[0038] In a fourth aspect, the present application further provides a communication device, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the IMS session media renegotiation method as described in any one of the above embodiments of the present application is implemented.

[0039] In a fifth aspect, the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the IMS session media renegotiation method of the present application as described in any one of the above embodiments is implemented.

[0040] In a sixth aspect, the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the IMS session media renegotiation method as described in any one of the above embodiments of the present application is implemented.

[0041] The details of one or more embodiments of the present application are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the present application will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0043] FIG1 is a diagram illustrating an application environment of an IMS session media renegotiation method according to an embodiment;

[0044] FIG2 is a schematic diagram of a process of an IMS session media renegotiation method according to an embodiment;

[0045] FIG3 is a schematic diagram of a flow chart of an IMS session media renegotiation method according to another embodiment;

[0046] FIG4 is a structural block diagram of an IMS session media renegotiation apparatus according to an embodiment;

[0047] FIG5 is a diagram showing the internal structure of a communication device in one embodiment. DETAILED DESCRIPTION

[0048] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0049] The IMS session media renegotiation method provided in the embodiments of the present application can be applied in the application environment shown in Figure 1. Initiating end 102 communicates with receiving end 104 via a network. A data storage system can store data to be processed by initiating end 102 and / or receiving end 104. The data storage system can be integrated with initiating end 102 and / or receiving end 104, or it can be located in the cloud or on other network servers. In the application scenario of the present application, the initiator 102 sends a SIP request to the receiver 104, where the SIP request includes SDP media description information supported by the initiator for multiple DCs, and at least two DCs can reuse the SDP m line of a separate SCTP link in the SIP request, wherein at least two DCs are associated with at least two data channel applications; then the initiator 102 receives a SIP response returned by the receiver 104 for the SIP request; the SIP response includes SDP media description information of the receiver 104 for the multiple DCs, and at least two DCs can reuse the SDP m line of a separate SCTP link in the SIP response; finally, based on the SIP request and the SIP response, multiple DCs are established or updated between the initiator 102 and the receiver 104.

[0050] The initiating end 102 and the receiving end 104 may be, but are not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices may include smart speakers, smart TVs, smart air conditioners, and smart car devices. Portable wearable devices may include smart watches, smart bracelets, and head-mounted devices. The initiating end 102 and the receiving end 104 may also be IMS networks.

[0051] First, the relevant terms involved in this application are explained as follows:

[0052] DC (Data Channel): A data channel defined in the 3GPP IMS audio and video communication architecture. That is, by establishing one or more data channels in parallel with audio and video transmission in an IMS session, any type of data can be transmitted, thereby enabling real-time interaction in audio and video calls, including BDC and ADC. Among them, 1) BDC (Bootstrap Data Channel) is established between the terminal and the IMS network, and is used by the terminal to obtain the data channel application list from the IMS network and download the required data channel application. 2) ADC (Application Data Channel) is established between the terminal and the IMS network or between the terminals, and is used to transmit application data of the data channel application.

[0053] SDP (Session Description Protocol) is a general session description protocol, mainly used to describe multimedia sessions, including session declaration, session invitation, session initialization, etc.

[0054] SIP (Session Initiation Protocol) is a text-based application layer control protocol developed by the Internet Engineering Task Force (IETF). It is used to create, modify, and release sessions between one or more participants. It is an IP voice session control protocol originating from the Internet and is flexible, easy to implement, and easy to expand.

[0055] IMS Application Service (IMS AS) is an enhanced network element of the legacy IMS network. It is responsible for providing session event subscription and notification services, media control services, sending service discovery requests, processing data channel media lines in SDP, and applying for the allocation, update, and release of media resources.

[0056] DCSF (Data Channel Signaling Function) is a new network element in the IMS network, responsible for the management and control of data channels, and the connection with data channel application servers.

[0057] P2P (Person-to-Person, terminal to terminal) refers to the ADC established between terminals.

[0058] P2A (Person-to-Application, terminal to server) refers to the ADC established between the terminal and the server.

[0059] P2A2P (Person-to-Application and Application-to-Person, terminal-to-server and server-to-terminal) refers to the ADC established between terminal-server-terminal.

[0060] The QoS class identifier (QCI) is a parameter used by the system to identify the transmission characteristics of service data packets. 3GPP TS 23.203 defines the QCI values ​​corresponding to different bearer services. It is important to note that IMS signaling services with a QCI of 5 are classified as non-GBR and have a higher priority than GBR bearers. Based on the QCI, bearers can be divided into two categories: GBR (Guaranteed Bit Rate) bearers and non-GBR bearers. 1) GBR bearers are used for services with high real-time requirements and require the scheduler to guarantee a minimum bit rate for these bearers. Their QCI range is 1-4. For GBR bearers, the maximum bit rate (MBR) is used to limit the bearer's maximum rate, defining the upper limit of the rate that a GBR bearer can achieve if sufficient RB resources are available. 2) Non-GBR bearers are used for services that do not require high real-time performance. The scheduler does not need to guarantee a minimum bit rate for these bearers. Their QCI range is 5-9. In congested network conditions, services need to be able to withstand the requirement of reduced rates. For Non-GBR, the UE-AMBR (Aggregate Maximum Bit Rate) is used to limit the maximum rate of all Non-GBR bearers. This is based on the UE level rather than a specific Non-GBR bearer. GBR represents the transmission data bit rate of each bearer, while UE-AMBR represents the transmission data bit rate of each group of bearers.

[0061] m=line, also called media line or m-line, describes information such as supported media types.

[0062] In related technologies, 3GPP TS 23.228 AC.7.2 can be used to define the signaling process for establishing a separate DC. The application method of the dcmap attribute is defined in accordance with IETF RFC8864 5.1. The definition explicitly does not include the content related to multiple dcmap attributes sharing an m=line. Therefore, in a scenario where there are multiple DCs between the terminal and the network, according to the current standard solution, each DC negotiation needs to occupy a separate SDP m=line. For example, each DC negotiation needs to include the following SDP information (for illustration only, not for all):

[0063] m=****

[0064] a=max-message-size:****

[0065] a=sctp-port:****

[0066] a=setup:****

[0067] a=tls-id:****

[0068] a=dcmap:****.

[0069] Among them, the information in line m includes the media type, communication protocol type, data channel type, and connected network type. The information in line a includes the maximum message size, the port number used by the protocol, the communication setting mode (passive or active), and other communication-related parameters and configurations.

[0070] Regarding the aforementioned related technologies, when multiple DCs exist between communicating parties, each DC negotiation requires a separate SDP m=line. Consequently, multiple m lines of information must be created in multiple DC negotiations, resulting in excessive resource consumption (e.g., CPU resources, memory resources, etc.) on the terminal and network. Furthermore, multiple DC negotiations can lead to longer transmission delays and a poor user experience.

[0071] Regarding the above-mentioned related technologies, in an exemplary embodiment of the present application, as shown in FIG2 , a method for renegotiation of IMS session media is provided. The method is described by taking the application of the method to the initiating terminal 102 in FIG1 as an example, and includes the following S202 to S206 . In which:

[0072] S202, sending a SIP request to the receiving end; the SIP request includes SDP media description information of the initiator for multiple data channels, and at least two data channels can reuse an SDP m line of a single SCTP link in the SIP request.

[0073] The SIP request sent by the initiator to the receiver can be an SDP offer based on the SCTP protocol, and the SIP response sent by the receiver to the initiator can be an SDP answer based on the SCTP protocol. SDP refers to the Session Description Protocol, a general session description protocol that is mainly used to describe multimedia sessions. Its uses include session declaration, session invitation, and session initialization. SDP itself is not a transport protocol and needs to rely on other transport protocols (such as SIP, HTTP, and WebSocket) to exchange necessary media information for media negotiation between two session entities. Related RFCs include: 1998, RFC2327, 2006, and RFC4566.

[0074] In the above SIP request, at least two data channels are associated with at least two data channel applications (hereinafter also referred to as DC applications).

[0075] S204, receiving a SIP response returned by the receiving end in response to the SIP request; the SIP response includes SDP media description information for multiple data channels of the receiving end, and the at least two data channels can reuse an SDP m line of a separate SCTP link in the SIP response.

[0076] Among them, the SIP response can be 200 OK: indicating that the request has been successfully processed and the corresponding result is returned; 202 Accepted: indicating that the request has been accepted, but the processing has not yet been completed. The server may return the result in a subsequent request; 400 Bad Request: indicating that the request is invalid and the server cannot understand or process the request; 401 Unauthorized: indicating that the request requires authentication or authorization, but the user did not provide valid credentials; 403 Forbidden: indicating that the server refuses to provide the requested resource, possibly because the user does not have permission to access it; 404 Not Found: indicating that the requested resource does not exist; and 500 Internal Server Error: indicating that an internal error occurred on the server while processing the request.

[0077] Specifically, when the initiator is a terminal, the receiver can be an IMS network, and the corresponding DC established is a P2A DC. The receiver can be another terminal, and the corresponding DC established is a P2P DC. When the initiator is an IMS network, the receiver can be another terminal, and the corresponding ADC established is a P2A DC. Multiple DCs can correspond to one DC application or multiple DC applications.

[0078] S206: Establish or update the multiple DCs between the initiating end and the receiving end based on the SIP request and the SIP response.

[0079] For example, a SIP request includes the SDP media description information for multiple DCs supported by the initiator. The m lines in the SIP request specify the media type, protocol, and other related parameters, such as port numbers and network connection information. The SIP response includes the SDP media description information for multiple DCs supported by the receiver, and the m lines in the SIP response correspond to the m lines in the SIP request. By negotiating and exchanging SDP information, the initiator and receiver determine the media type, protocol, and other related parameters to use, establish or update multiple DCs, and communicate application data through these multiple DCs.

[0080] In the SIP response corresponding to the above SIP request, at least two data channels of m rows are multiplexed and associated with at least two data channel applications.

[0081] In the above-mentioned IMS session media renegotiation method, first, the initiator sends a SIP request to the receiver, and the above-mentioned SIP request contains SDP media description information supported by the initiator for multiple DCs, and the SDP m line of a separate SCTP link in the SIP request supports the multiplexing of at least two DCs associated with different data channel applications; then the initiator receives the SIP response returned by the above-mentioned receiver in response to the SIP request; the above-mentioned SIP response contains SDP media description information supported by the receiver for multiple DCs, and the SDP m line of a separate SCTP link in the SIP response supports the multiplexing of at least two DCs associated with different data channel applications; finally, based on the SIP request and the SIP response, multiple DCs are established or updated between the initiator and the receiver. The initiator and the receiver in this application can both be selected as terminals or IMS networks. Through the above-mentioned embodiment of this application, the method of using multiple DCs associated with different data channel applications to share a single m line between the initiator and the receiver can save terminal and network resources, reduce transmission delay, and also meet the business needs of multiple DCs.

[0082] In one embodiment, in a SIP request and a SIP response, the dcmap attribute information corresponding to each data channel of m multiplexed lines occupies a separate line, and the stream ID (also called streamID) filled in each line is different.

[0083] The multiplexing of multiple data channels into a single SCTP link SDP m line can be achieved by having each data channel dcmap attribute information occupy a separate line, and different data channels are distinguished in each dcmap attribute information line by parameters that can uniquely identify the data channel (such as streamID, label, etc.).

[0084] The dcmap attribute uniquely identifies and distinguishes different DCs and provides them with specific configuration information. By using different dcmap attribute values ​​in SDP, each DC can be independently identified and configured, enabling the simultaneous establishment and management of multiple DCs.

[0085] In this application, there is no order requirement for the DCMAP attributes corresponding to each DC reused in an m-line, and the supported parameters and syntax comply with RFC8864 5.1.SDP DCMAP Attribute.

[0086] In one embodiment, although multiple DCs can reuse the SDP m line of a single SCTP link, the dcmap attribute information corresponding to each DC occupies a separate line, so that the initiator and the receiver can identify and distinguish different DCs based on the dcmap attribute value, and perform corresponding configuration and management, thereby achieving reliable transmission and processing of application layer data.

[0087] In an exemplary embodiment, the initiator and the receiver both support at least two m rows, where the at least two m rows include a first m row and a second m row, and the method further includes:

[0088] Case 1: For at least two DCs matching the GBR bearer class, one first m lines are multiplexed in the SIP request and the SIP response.

[0089] GBR bearers are guaranteed bit rate (GBR) bearers, used for services with high real-time requirements. They require the scheduler to guarantee a minimum bit rate for these bearers, and their QCI range is 1-4. For GBR bearers, the maximum bit rate (MBR) is used to limit the maximum rate of the bearer, defining the upper limit of the rate that the GBR bearer can achieve if sufficient RB resources are available.

[0090] For example, when establishing a DC, the first m lines can be reused for at least two DCs matching the GBR bearer, indicating that these DCs share the same media line-related parameters and can be transmitted through the same port and network connection.

[0091] Case 2: For at least two DCs matching the Non-GBR bearer class, a second m line is multiplexed in the SIP request and the SIP response.

[0092] Among them, Non-GBR bearers are used for services that do not require high real-time performance. The scheduler does not need to guarantee a minimum bit rate for this type of bearer. Its QCI range is 5-9, and its priority is set higher than that of GBR bearers. In the case of network congestion, services need to withstand the requirement of reducing the rate. For Non-GBR, UE-AMBR (Aggregate Maximum Bit Rate) is used to limit the maximum rate of all Non-GBR bearers, targeting the UE level rather than a specific Non-GBR bearer. The UE-AMBR represents the transmission data bit rate of each group of bearers.

[0093] Both the initiator and the receiver support at least two m lines, each used to support media negotiation with different real-time requirements. It is understood that the number of m lines supported by the initiator and the receiver is not less than the number of levels of real-time requirements.

[0094] For example, for at least two DCs matching the Non-GBR bearer class, the second m rows can be multiplexed. These DCs also share the same media type and related parameters and can be transmitted through the same port and network connection.

[0095] Through the above embodiment, at least two DCs of different types of bearers reuse one first m line or one second m line in the SIP request and SIP response. On the one hand, this reduces the duplication of media description information and saves bandwidth and resources. On the other hand, it can also meet different real-time requirements, more effectively manage and control multiple DCs, and improve communication efficiency and reliability.

[0096] DC refers to a data channel, which is established between a terminal and an IMS network or another terminal. When the data channel is an ADC, it is used to transmit application data.

[0097] QCI refers to the quality of service level identifier, which is a parameter used by the system to identify the transmission characteristics of service data packets. In this application, QCI levels include at least GBR-class bearers (such as QCI-7x) and Non-GBR-class bearers (such as QCI-9).

[0098] Through the above embodiments, multiple DCs can be multi-DCs for multiple DC applications, and the QCI level includes at least GBR-type bearers (such as QCI-7x) and Non-GBR-type bearers (such as QCI-9), and corresponding configuration and management are performed to achieve reliable transmission and processing of application layer data.

[0099] In one embodiment, in a SIP request and a SIP response, the rules followed by at least two DCs multiplexing an SDP m line of a single SCTP link include at least one of the following:

[0100] (1) At least two DCs multiplexing an m row have the same 3GPP QoS hint attributes;

[0101] (2) at least two DCs multiplexing an m row have the same 3GPP bandwidth modification;

[0102] (3) At least two DCs that reuse an m-row have the same transmission address parameters of the m-row.

[0103] Among them, the 3GPP QoS hint attribute refers to the attribute used to describe the service quality requirements of the media stream in the SDP. It provides hint information about the service quality level required for the media stream. This application includes at least two parameters: packet loss and latency. The 3GPP bandwidth modification refers to the attribute used to describe the bandwidth requirements of the media stream in the SDP. The average bit rate of the media stream, that is, the number of bits transmitted per second, provides hint information about the bandwidth level required for the media stream. The transport address parameter refers to the parameter used to specify the network address and port number of the media stream transmission in the SDP. It contains the transport protocol of the media stream (such as UDP or TCP) and the corresponding network address and port number information.

[0104] Specifically, the 3GPP QoS hint attribute and the 3GPP bandwidth modifier may include information such as media type, media encoder, media decoder, media parameters, and service quality level, and the transport address parameter may include transport protocol, IP address, and port number information.

[0105] Through the above embodiments, the network and the device can perform appropriate resource allocation and processing according to the three rules, and correctly transmit and receive information.

[0106] In one embodiment, when at least two DCs multiplexing an m-row have the same m-row transmission address parameters, the m-row transmission address multiplexed by the at least two DCs includes a real transmission address or an anchor transmission address.

[0107] The real transport address refers to the network address and port number actually used to transmit the media stream, which can be a specific IP address and port number. The anchor transport address is a virtual transport address used to identify the transmission location and path of the media stream. It is not a real network address and port number, but an identifier or reference.

[0108] For example, for a network with an anchor transmission address, the data of the DC application in the downlink direction can first be transmitted from the actual server to the anchor transmission address, and then transmitted to the terminal by the anchor transmission address; the data of the DC application in the uplink direction can first be transmitted from the terminal to the anchor transmission address, and then distributed to the actual server by the anchor transmission address.

[0109] Through the above embodiments, data transmission through the anchor transmission address does not depend on a specific network or device, thereby improving flexibility and reducing transmission overhead and delay, simplifying management and configuration complexity, and reducing configuration errors and maintenance work.

[0110] In one embodiment, the 3GPP QoS hint attribute includes at least two parameters; wherein,

[0111] Case 1: When all QoS parameters corresponding to at least two DCs that reuse one m row are the same, unique parameters are filled in the parameter row used to describe QoS attributes in the SIP request and SIP response.

[0112] 3GPP QoS hint attributes include at least two parameters: packet loss and latency. Unique parameters provide a unified QoS attribute for the multiplexed m lines, avoiding duplicate QoS parameter information and simplifying SDP description and transmission.

[0113] Case 2: When some QoS parameters of at least two DCs that reuse one m line are the same, the most stringent QoS parameters are filled in the parameter lines used to describe QoS attributes in the SIP request and SIP response.

[0114] It is understandable that in different scenarios, the most stringent QoS parameters depend on the specific QoS requirements of multiple DCs. For example, in one embodiment, the QoS latency parameters of two DCs are the same, but the packet loss parameters are different. Accordingly, when these two DCs reuse one m-line, the latency parameter can be filled in with the same one, and the packet loss parameter can be filled in with the one with the lower packet loss rate. For example, if one DC requires a maximum packet loss rate of 1%, and the other DC requires a maximum packet loss rate of 0.1%, then the most stringent parameter is a packet loss rate of 0.1%.

[0115] Through the above embodiments, both Scenario 1 and Scenario 2 provide a multiplexing of QoS attributes to avoid repeated QoS parameter information, thereby further simplifying the SDP message. The introduction of the strictest parameter concept in Scenario 2 also provides a highest QoS guarantee to ensure transmission quality and stability.

[0116] In one embodiment, the initiating end sends a SIP request to the receiving end, including:

[0117] If the initiating end is the terminal before the call is connected, a SIP UPDATE message is sent to the receiving end for media renegotiation; correspondingly, a SIP response returned by the receiving end in response to the SIP request is received, including: receiving a renegotiation response message returned by the receiving end in response to the SIP UPDATE message.

[0118] The SIP UPDATE message has no effect on the dialog state and is used to negotiate and adjust media parameters before a call is established. It contains a SIP request that describes the desired media parameter changes, such as changing the codec or adding or removing media streams. Upon receiving the SIP UPDATE message, the receiving end processes the media parameter changes in the SIP request and returns a SIP Response message as a renegotiation response. This SIP Response message can be encapsulated in a SIP 200OK message and returned to the sending end as a renegotiation response.

[0119] Through the above embodiment, the initiating end can send a SIP UPDATE message to the receiving end before the call is established to propose the media parameters it wishes to change, thereby negotiating and adjusting the media parameters. This ensures that both parties use media parameters that meet their needs when the call is established, thereby improving the quality and adaptability of the call.

[0120] In one embodiment, the initiating end sends a SIP request to the receiving end, further comprising:

[0121] If the initiating end is a terminal after the call is connected, a SIP re-INVITE message is sent to the receiving end for media re-negotiation; correspondingly, a SIP response returned by the above-mentioned receiving end for the SIP request is received, including: receiving a renegotiation response message returned by the above-mentioned receiving end for the SIP re-INVITE message.

[0122] The SIP re-INVITE message can also be used to change the state of a conversation, dynamically adjusting media parameters during a call. It also contains a SIP request describing the desired media parameter changes. Upon receiving the SIP re-INVITE message, the receiving end processes the media parameter changes in the SIP request and returns a SIP response message as a renegotiation response. This SIP response message can be encapsulated in a SIP 200 OK message and returned to the sending end as a renegotiation response.

[0123] Through the above embodiment, the initiating end can propose the media parameters that it wishes to change to the receiving end by sending a SIP re-INVITE message after the call is established, thereby dynamically adjusting the media parameters to adapt to different business requirements and network conditions, thereby improving the quality and flexibility of the call.

[0124] In one embodiment, the initiator needs to determine in advance whether it supports multiple data channels multiplexing the SDP m line of a single SCTP link. If it determines that it supports multiple data channels multiplexing the SDP m line of a single SCTP link, it sends the SIP request to the receiving end.

[0125] Specifically, the initiator sends a SIP request to the receiver. The SIP request includes the initiator's SDP media description information for multiple data channels. If the initiator determines in advance that it supports multiple data channels multiplexing the SDP line m of a single SCTP link, it sends a SIP request to the receiver. In this case, the at least two data channels associated with the at least two data channel applications can reuse the SDP line m of the single SCTP link in the SIP request. If the initiator determines in advance that it does not support multiple data channels multiplexing the SDP line m of a single SCTP link, the SDP line m of the single SCTP link in the SIP request can only be used by one data channel, and therefore the SIP request cannot be sent to the receiver. The receiver can be an IMS network or other communication terminal. Both the initiator and the receiver can report to their respective networks whether they support multiple data channels multiplexing the SDP line m of a single SCTP link. If the receiver supports multiple data channels multiplexing the SDP line m of a single SCTP link, it can directly receive the SIP request. If the receiving end does not support the SDP m-line for multiple data channels over a single SCTP connection, the receiving end's network first demultiplexes the SIP request and then passes the demultiplexed SIP request to the receiving end. The receiving end's network can detect in advance whether the receiving end supports the SDP m-line for multiple data channels over a single SCTP connection.

[0126] In one embodiment, the present application provides an IMS session media renegotiation method, which is applied to an IMS communication system. As shown in FIG3 , the IMS session media renegotiation method includes the following steps:

[0127] S302: The IMS network sends or receives a SIP request or SIP response message of an IMS session media renegotiation process, and processes data channel related information.

[0128] The IMS AS (IMS Application Service) is responsible for providing session event subscription and notification services, media control services, sending service discovery requests, processing the data channel media line in the SDP, and applying for the allocation, update, and release of media resources. The m=line of the SDP message supports the dcmap attribute (attribute) "a=dcmap:" containing multiple DCs. The dcmap attribute "a=dcmap:" corresponding to each DC occupies a separate line.

[0129] The IMS communication system may include an initiating end and a receiving end. Accordingly, step S302 may include: the initiating end generates a SIP request and sends it to the receiving end; the receiving end generates a SIP response in response to the SIP request and sends the SIP response to the initiating end.

[0130] In one example, media renegotiation between the initiating end and the receiving end includes: the initiating end may initiate a renegotiation request (i.e., a SIP request) through a SIP Update / SIP re-INVITE message; the receiving end may return a renegotiation response (i.e., a SIP answer) through a SIP 200 OK message; the IMS AS network element of the network may update / modify the SDP Offer or SDP Answer based on the obtained DC-related information and the processing requirements of the data channel media line issued by the DCSF network element, and send a SIP re-INVITE / SIP Update message or respond to a SIP 200OK message.

[0131] The DCSF refers to the Data Channel Signaling Function, a new network element in the IMS network, responsible for the management and control of the data channel and the connection with the data channel application server.

[0132] In this application, the maximum number of DCs that the terminal can support does not exceed a fixed value, which can be determined based on experience or discussed and decided by manufacturers in the industry chain, for example, not more than 32. Of course, the specific value can be determined according to demand.

[0133] Among them, multiple DCs belonging to the same GBR class can share one m-line, and multiple DCs belonging to the same non-GBR class can share another m-line, because the GBR and non-GBR class bearers have different requirements for QoS flows. If the same m-line is used, it is necessary to consider the bearer with higher QoS requirements (latency or loss), which will relatively waste a certain amount of wireless resources.

[0134] S304: A data channel is established between the initiating end and the receiving end through IMS session negotiation.

[0135] The following are some examples:

[0136] Assuming that DC1 and DC2 associated with different data channel applications have the same transport address, bandwidth, and quality of service (QoS), the corresponding SIP request or response message can be:

[0137] m=application 53790 UDP / DTLS / SCTP webrtc-datachannel

[0138] / / Shared m rows

[0139] b=AS:500

[0140] a=3gpp-qos-hint:loss=0.0002;latency=600

[0141] a=dcmap:1002label="remote_fileShare_1_dc1";priority=256ordered=tr terminal

[0142] / / Identify the first DC of the shared m=line

[0143] a=dcmap:1004label="remote_fileShare_1_dc2"; priority=256ordered=tr terminal

[0144] / / Identify the second DC of the shared m=line

[0145] Assuming that DC3 and DC4 associated with different data channel applications have the same transport address, BW, and QoS, the corresponding SIP request or response message can be:

[0146] m=application 53780 UDP / DTLS / SCTP webrtc-datachannel

[0147] / / Shared m rows

[0148] b=AS:5000

[0149] a=3gpp-qos-hint:loss=0.0002;latency=600

[0150] a=dcmap:8001 label="remote_fileShare_2_dc3"; priority=256; ordered=tr terminal

[0151] / / Identify the third DC of the shared m=line

[0152] a=dcmap:8003 label="remote_fileShare_2_dc4"; priority=256; ordered=tr terminal

[0153] / / Identify the fourth DC of the shared m=line

[0154] For the first DC, Transport Address represents the transport address of DC1. BW stands for bandwidth limit, indicating that the DC's bandwidth limit is 500 bits per second. QoS stands for Quality of Service, indicating that the DC's QoS requirements are a packet loss rate of 0.0002 and a latency of 600 milliseconds. dcmap stands for DC mapping, which maps DC identifiers to relevant information such as labels and priorities. The DC identifier is 1002, the label is "remote_fileShare_1_dc1", the priority is 256, and the transmission is in order.

[0155] For the second DC: Transport Address represents DC2's transport address, the same as DC1. BW represents bandwidth limit, the same as DC1. QoS represents quality of service, the same as DC1. dcmap represents DC mapping, which maps DC identifiers to relevant information such as tags and priorities. The DC identifier is 1004, the tag is "remote_fileShare_1_dc2", the priority is 256, and ordered transmission is performed.

[0156] For the third DC: Transport Address represents the transport address of DC3. BW stands for bandwidth limit, indicating that the bandwidth limit for this DC is 5000 bps (bits per second). QoS stands for quality of service, indicating that the quality of service requirements for this DC are a packet loss rate of 0.0002 and a latency of 600 milliseconds. dcmap stands for DC mapping, which maps DC identifiers with relevant information such as labels and priorities. The DC identifier is 8001, the label is "remote_fileShare_2_dc3", the priority is 256, and the transmission is in order.

[0157] For the fourth DC: Transport Address represents the transport address of DC4, the same as DC3. BW represents bandwidth limit, the same as DC3. QoS represents quality of service, the same as DC3. dcmap represents DC mapping, which maps DC identifiers to relevant information such as tags and priorities. The DC identifier is 8003, the tag is "remote_fileShare_2_dc4", the priority is 256, and the transmission is in order.

[0158] The preceding content describes four DCs. DC1 and DC2 share the same transport address, bandwidth limit, and quality of service (QoS), and thus share one m row. DC3 and DC4 share the same transport address, bandwidth limit, and QoS, and thus share another m row. Each DC's dcmap occupies a separate row, meaning each DC has a unique identifier and associated mapping information.

[0159] Through the above-described embodiments, the present application establishes or updates multiple DCs between the initiating and receiving ends through media renegotiation, by sending a SIP request at the initiating end and receiving a SIP response at the receiving end. This enables multiple DCs to share a single m=line, resolving issues such as excessive terminal and network resource usage caused by multiple DC negotiations and improving transmission delays caused by multiple negotiations.

[0160] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0161] Based on the same inventive concept, an embodiment of the present application further provides an IMS session media renegotiation apparatus for implementing the aforementioned media renegotiation method. The solution provided by this apparatus is similar to the solution described in the aforementioned method. Therefore, the specific limitations in one or more of the following embodiments of the media renegotiation apparatus can be found in the aforementioned limitations on the media renegotiation method and will not be further elaborated here.

[0162] In an exemplary embodiment, as shown in FIG4 , an IMS session media renegotiation apparatus is provided, comprising: a request sending module 401 , a response receiving module 402 , and a channel establishing module 403 , wherein:

[0163] Request sending module 401 is configured to send a SIP request to a receiving end. The SIP request includes SDP media description information for multiple DCs supported by the initiating end, and an SDP m-line of a single SCTP link in the SIP request supports multiplexing of at least two DCs. In the SIP request, at least two data channels multiplexed in an m-line are associated with at least two data channel applications.

[0164] Response receiving module 402 is configured to receive a SIP response returned by the receiving end in response to the SIP request. The SIP response includes the receiving end's SDP media description information for multiple DCs, and an SDP m-line for a single SCTP link in the SIP response supports multiplexing of at least two DCs. In the SIP response, the at least two data channels multiplexed in the m-line are associated with at least two data channel applications.

[0165] The channel establishing module 403 is configured to establish / update multiple DCs between the initiating end and the receiving end based on the SIP request and the SIP response.

[0166] In one embodiment, the request sending module 401 is used for the initiator to send the SIP request to the receiver after the initiator determines in advance that the receiver supports multiple data channels multiplexing an SDP m line of a single SCTP link before sending the SIP request to the receiver.

[0167] In one embodiment, if the initiating end is the terminal before the call is connected, the request sending module 401 is specifically configured to send a SIP UPDATE message to the receiving end for media re-negotiation.

[0168] In one embodiment, if the initiating end is the terminal before the call is connected, the response receiving module 402 is specifically configured to receive the renegotiation response message returned by the receiving end in response to the SIP UPDATE message.

[0169] In one embodiment, if the initiating end is a terminal after the call is connected, the request sending module 401 is further configured to send a SIP re-INVITE message to the receiving end for media re-negotiation.

[0170] In one embodiment, if the initiating end is a terminal after the call is connected, the response receiving module 402 is further configured to receive a re-negotiation response message returned by the receiving end in response to the SIP re-INVITE message.

[0171] In one embodiment, when it is determined that the initiating end supports the SDP m-line of multiple data channels multiplexing a single SCTP link, the SIP request is sent to the receiving end.

[0172] Each module in the aforementioned IMS session media renegotiation apparatus may be implemented in whole or in part via software, hardware, or a combination thereof. Each module may be embedded in or independent of a processor within a communication device in hardware form, or may be stored in a memory within the communication device in software form, so that the processor can call and execute the corresponding operations of each module.

[0173] In an exemplary embodiment, a communication device is provided, which may be a server, and its internal structure diagram may be shown in Figure 5. The communication device includes a processor, a memory, an input / output interface (I / O) and a communication interface. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the communication device is used to provide computing and control capabilities. The memory of the communication device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the communication device is used to store media renegotiation data. The input / output interface of the communication device is used to exchange information between the processor and an external device. The communication interface of the communication device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, it implements an IMS session media renegotiation method.

[0174] Those skilled in the art will understand that the structure shown in Figure 5 is merely a block diagram of a partial structure related to the scheme of the present application, and does not constitute a limitation on the communication device to which the scheme of the present application is applied. The specific communication device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0175] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0176] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0177] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0178] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, and the like.

[0179] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0180] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. An IMS session media renegotiation method, applied to an initiating end, the method comprising: Send a SIP request to the receiving end; The SIP request includes SDP media description information of the initiator for multiple data channels, and at least two data channels can reuse an SDPm line of a separate SCTP link in the SIP request; Receiving a SIP response returned by the receiving end in response to the SIP request; The SIP response includes SDP media description information of the receiving end for the multiple data channels, and at least two data channels can multiplex an SDPm line of a separate SCTP link in the SIP response; Based on the SIP request and the SIP response, establishing or updating the multiple data channels between the initiating end and the receiving end; Wherein, in the SIP request and the SIP response, the at least two data channels multiplexing one m line are associated with at least two data channel applications.

2. The method according to claim 1, wherein: In the SIP request and the SIP response, the dcmap attribute information corresponding to each data channel of the multiplexed m lines occupies a single line, and each line contains a different stream ID.

3. The method according to claim 1, wherein: The initiator and the receiver both support at least two m lines for the SCTP link, the at least two m lines include a first m line and a second m line, and the method further includes: For at least two data channels matching the GBR class bearer, multiplexing a first m lines in the SIP request and the SIP response; For at least two data channels matched to the Non-GBR bearer, a second m line is multiplexed in the SIP request and the SIP response.

4. The method according to claim 1, wherein: In the SIP request and the SIP response, the rules followed by multiplexing the at least two data channels of one m-line include at least one of the following: The at least two data channels multiplexed into one m row have the same 3GPP QoS hint attribute; The at least two data channels multiplexing one m row have the same 3GPP bandwidth modification; The at least two data channels multiplexing one m-row have the same m-row transmission address parameters.

5. The method according to claim 4, wherein: In the case that the at least two data channels multiplexing one m-row have the same m-row transmission address parameters, the m-row transmission address multiplexed by the at least two data channels includes a real transmission address or an anchor transmission address.

6. The method according to claim 4, wherein: The 3GPP QoS hint attribute includes at least two parameters; wherein, In the case where all the QoS parameters corresponding to the at least two data channels multiplexed into one m row are the same, filling in a unique parameter in a parameter row for describing QoS attributes in the SIP request and the SIP response; In the case that some parameters of the QoS of the at least two data channels multiplexing one m line are the same, the most stringent QoS parameters are filled in the parameter lines for describing QoS attributes in the SIP request and the SIP response.

7. The method according to claim 1, wherein: The sending of the SIP request to the receiving end comprises: If the initiating end is the terminal before the call is connected, a SIP UPDATE message is sent to the receiving end for media re-negotiation; The receiving a SIP response returned by the receiving end in response to the SIP request includes: receiving a re-negotiation response message returned by the receiving end in response to the SIP UPDATE message.

8. The method according to claim 1, wherein: The sending of the SIP request to the receiving end also includes: If the initiating end is a terminal after the call is connected, a SIP re-INVITE message is sent to the receiving end for media re-negotiation; The receiving a SIP response returned by the receiving end in response to the SIP request includes: Receive a re-negotiation response message returned by the receiving end in response to the SIP re-INVITE message.

9. The method according to any one of claims 1 to 8, wherein: Before sending the SIP request to the receiving end, the method further includes: In case it is determined that the initiating end supports the SDPm line of multiple data channels multiplexing a single SCTP link, the SIP request is sent to the receiving end.

10. An IMS session media renegotiation method, applied to an IMS communication system, the IMS communication system comprising an initiating end and a receiving end, the method comprising: The initiating end generates a SIP request and sends it to the receiving end; The SIP request includes SDP media description information of the initiator for multiple data channels, and at least two data channels can reuse an SDPm line of a separate SCTP link in the SIP request; The receiving end generates a SIP response in response to the SIP request and sends it to the initiating end; The SIP response includes SDP media description information of the receiving end for the multiple data channels, and at least two data channels can multiplex an SDPm line of a separate SCTP link in the SIP response; Based on the SIP request and the SIP response, establishing or updating the multiple data channels between the initiating end and the receiving end; Wherein, in the SIP request and the SIP response, the at least two data channels multiplexing one m line are associated with at least two data channel applications.

11. An IMS session media renegotiation device, wherein: The device comprises: The request sending module is used to send a SIP request to the receiving end; the SIP request contains the initiator's The SDP media description information of the data channels, and at least two data channels can multiplex the SDPm line of a single SCTP link in the SIP request; A response receiving module, configured to receive a SIP response returned by the receiving end in response to the SIP request; the SIP response includes SDP media description information of the receiving end for the multiple data channels, and at least two data channels can reuse an SDPm line of a separate SCTP link in the SIP response; A channel establishment module, used to establish / update the multiple data channels between the initiating end and the receiving end based on the SIP request and the SIP response; Wherein, in the SIP request and the SIP response, the at least two data channels multiplexing one m line are associated with at least two data channel applications.

12. A communication device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 10 are implemented.

13. A computer-readable storage medium having a computer program stored thereon, wherein: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

14. A computer program product comprising a computer program, wherein: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

Images