Communication method and device

Abstract

The invention provides a communication method and device, and relates to the technical field of communication. In the method, a communication entity can determine whether a created connection (such as an SCTP coupling) can carry an IMS data channel before creating the IMS data channel. If there is a created connection capable of carrying the IMS data channel, the communication entity does not create a new connection, but instructs to carry the IMS data channel with the created connection. And if the created connection capable of bearing the IMS data channel does not exist, the communication entity instructs to use a new connection to bear the IMS data channel and creates the new connection. Therefore, when the IMS data channel is created through the method, the created connection can be reused, so that the resource overhead can be reduced.

Description

Technical Field

[0001] The present application relates to the field of communication technologies, and in particular to communication methods and devices. Background Art

[0002] To enable service innovation in fifth-generation (5G) call scenarios, 5G calls introduce a data channel (DC), also known as an IMS data channel, in addition to the audio and video channels in the Internet Protocol Multimedia Subsystem (IMS) network. Terminals in the same IMS session can negotiate a data channel and transmit application data over it.

[0003] Currently, a terminal can negotiate at least one data channel for an application to transmit the application's data. An IMS session typically involves multiple applications, and using existing methods to negotiate data channels for these applications results in high resource overhead. Summary of the Invention

[0004] The present application provides a communication method and apparatus that can reuse already created connections when creating a data channel, thereby reducing resource overhead.

[0005] To achieve the above objectives, this application adopts the following technical solutions:

[0006] In a first aspect, a communication method is provided. The method can be performed by a communication entity. The communication entity here can refer to the communication entity itself, or to a processor, circuit, module, logical node, chip, or chip system within the communication entity that implements the method. Optionally, the communication entity is deployed in a terminal.

[0007] The method includes: receiving a first request for requesting to create a first data channel, the first data channel being a data channel between a first communication device (such as the above-mentioned terminal) and a second communication device, and being used to carry data of a first application; the first data channel being associated with an IMS session between the first communication device and the second communication device; if there is an established connection that can carry the first data channel, sending a response to the first request, the response including first media description information, the first media description information including first indication information, the first indication information indicating a first connection, the first connection being a connection corresponding to the first data channel in the established connection; or, if there is no established connection that can carry the first data channel, sending a response to the first request and creating a second connection, the response including second media description information, the second media description information including second indication information, the second indication information indicating a second connection, the second connection being a connection corresponding to the first data channel.

[0008] Based on the method provided in the first aspect above, before creating the first data channel, the terminal can determine whether there is a connection among the established connections that can carry the first data channel. If there is a connection that can carry the first data channel, the first data channel can reuse the connection, thereby reducing resource overhead.

[0009] In a possible implementation manner, the first indication information includes: Internet Protocol address information, User Datagram Protocol port information, and Stream Control Transmission Protocol port information.

[0010] Based on the above possible implementation, if there is an established connection that can carry the first data channel, the first data channel can reuse Internet Protocol address information, User Datagram Protocol port information, and Stream Control Transmission Protocol port information to reduce resource overhead.

[0011] In one possible implementation, the method also includes: receiving a second request, the second request is used to request the creation of a second data channel, the second data channel is used to carry data of a second application, and the second application is different from the first application; if the created connection cannot carry the second data channel, sending a response to the second request and creating a third connection, the response to the second request includes third media description information, the third media description information includes third indication information corresponding to the second data channel, and the third indication information indicates the third connection; or, if the first connection can carry the second data channel, sending a response to the second request, the response to the second request includes fourth media description information, and the fourth media description information includes the first indication information; or, if the second connection can carry the second data channel, sending a response to the second request, the response to the second request includes fifth media description information, and the fifth media description information includes the second indication information.

[0012] Based on the above possible implementations, before creating the second data channel, the terminal can determine whether there is a connection among the already established connections that can carry the second data channel, thereby reducing resource overhead. In addition, if the first connection (or the second connection) can carry the second data channel, it means that a single connection can carry data channels for two different applications, so the connection can transmit data from different applications.

[0013] In a possible implementation, the second connection can carry the second data channel, including: the quality of service requirement of the second data channel is the same as the quality of service requirement of the first data channel; or the quality of service requirement of the second data channel is lower than the quality of service requirement of the first data channel.

[0014] Based on the possible implementation manner described above, it may be determined whether the second connection can carry the second data channel based on the quality of service requirement of the second data channel and the quality of service requirement of the first data channel.

[0015] In a possible implementation, the second connection can carry a second data channel, further comprising: the second data channel is a data channel between the first communication device and the second communication device.

[0016] Based on the foregoing possible implementation manner, it may be determined whether the second connection can carry the second data channel based on the second data channel endpoint information.

[0017] In a possible implementation, the method further includes: sending sixth media description information to the network side, where the sixth media description includes information about the connection corresponding to the first data channel and information about the connection corresponding to the second data channel.

[0018] Based on the foregoing possible implementation manner, the sixth media description information may be sent to negotiate the second data channel.

[0019] In a possible implementation, the sixth media description information further includes identification information of the first data channel and identification information of the second data channel.

[0020] Based on the above possible implementation manners, it can be determined that the data channels corresponding to the sixth media description information are the first data channel and the second data channel.

[0021] In one possible implementation, the method further includes: if the first request includes information about the first connection, determining that the first connection can carry the first data channel; or, if the first request does not include information about the connection corresponding to the first data channel, determining that none of the created connections can carry the first data channel.

[0022] Based on the above possible implementation manner, it can be determined whether the created connection can carry the first data channel according to whether the first request includes information about the connection corresponding to the first data channel.

[0023] In a second aspect, a communication device is provided for implementing the above-mentioned method. The communication device may be the terminal described in the first aspect. The communication device includes modules, units, or means corresponding to implementing the above-mentioned method. The modules, units, or means may be implemented in hardware, software, or by hardware executing corresponding software implementations. The hardware or software includes one or more modules or units corresponding to the above-mentioned functions.

[0024] In one possible implementation, the communication device may include a processing module and an interface module. The processing module may be configured to implement the processing functions described in the first aspect and any possible implementation thereof. The processing module may, for example, be a processor. The interface module, also referred to as an interface unit, may be configured to implement the sending and / or receiving functions described in the first aspect and any possible implementation thereof. The interface module may be comprised of an interface circuit, a transceiver, a transceiver, or a communication interface.

[0025] In a possible implementation, the interface module includes a sending module and a receiving module, which are respectively used to implement the sending and receiving functions in the above-mentioned first aspect and any possible implementation thereof.

[0026] In a third aspect, a communication device is provided, comprising: a processor configured to execute a computer program (or computer-executable instructions) stored in a memory and / or a logic circuit, causing the communication device to perform the method described in the first aspect. The communication device may be the terminal described in the first aspect. Optionally, the number of the processors may be one or more.

[0027] In a possible implementation manner, the communication device further includes a memory.

[0028] In a possible implementation, the processor and the memory are integrated together; or the memory is independent of the processor.

[0029] In one possible implementation, the communication device further includes a communication interface, which is used for the communication device to communicate with other devices, such as sending or receiving data and / or signals. Exemplarily, the communication interface can be a transceiver, circuit, bus, module, or other type of communication interface.

[0030] In one possible implementation, the communication device is a chip or a chip system. Optionally, when the communication device is a chip system, it can be composed of a chip or include a chip and other discrete devices.

[0031] In a fourth aspect, a communication device is provided, comprising: a processor and an interface circuit; the interface circuit is configured to receive a computer program or instruction and transmit it to the processor; and the processor is configured to execute the computer program or instruction, thereby causing the communication device to perform the method described in the first aspect. The communication device may be the terminal described in the first aspect. Optionally, the number of the processors may be one or more.

[0032] In one possible implementation, the communication device is a chip or a chip system. Optionally, when the communication device is a chip system, it can be composed of a chip or include a chip and other discrete devices.

[0033] In a fifth aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium. When the computer-readable storage medium is run on a computer, the computer can execute the method described in the first aspect.

[0034] In a sixth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the method described in the first aspect above.

[0035] In a seventh aspect, a communication system is provided, comprising: at least two terminals for executing the method described in the first aspect above.

[0036] Among them, the technical effects brought about by any possible implementation method of the second to seventh aspects can be referred to the technical effects brought about by the above-mentioned first aspect or different possible implementation methods of the first aspect, and will not be repeated here.

[0037] It is understandable that, provided that the solutions are not contradictory, the solutions in each aspect can be combined. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1A A schematic diagram of the protocol stack for the Web Real-Time Communication (WebRTC) data channel;

[0039] Figure 1B Schematic diagram of an IMS session;

[0040] Figure 1C A schematic diagram of the protocol stack for an IMS session;

[0041] Figure 1D A schematic diagram of obtaining a data channel application for terminal 1 and terminal 2;

[0042] Figure 1E A diagram illustrating the interaction between a Session Description Protocol (SDP) proposer and an SDP responder.

[0043] Figure 1F This is a schematic diagram of the WebRTC user agent architecture;

[0044] Figure 1G This is a schematic diagram of the WebRTC signaling model;

[0045] Figure 1H Schematic diagram of the SDP exchange process for WebRTC;

[0046] Figure 1I Schematic diagram of the media negotiation process for the WebRTC data channel;

[0047] Figure 2 Schematic diagram of the media negotiation process of the IMS data channel;

[0048] Figure 3A Schematic diagram 1 of a communication scenario;

[0049] Figure 3B A communication scenario Figure 2 ;

[0050] Figure 3C This is a schematic diagram of the DCMTSI client architecture;

[0051] Figure 3D Schematic diagram 1 of the logical architecture of a data channel supported by a terminal;

[0052] Figure 3E A diagram showing the logical architecture of a data channel supported by a terminal Figure 2 ;

[0053] Figure 4 A schematic diagram of the hardware structure of the communication device provided in this application;

[0054] Figure 5 Flowchart 1 of the communication method provided in this application;

[0055] Figure 6 Schematic diagram of the communication method provided in this application Figure 2 ;

[0056] Figure 7 Flowchart 3 of the communication method provided in this application;

[0057] Figure 8 Schematic diagram of the communication method provided in this application Figure 4 ;

[0058] Figure 9 Schematic diagram of the communication method provided in this application Figure 5 ;

[0059] Figure 10 This is a schematic diagram of the structure of the communication device provided in this application. DETAILED DESCRIPTION

[0060] Before introducing the technical solution of this application, the relevant technical terms involved in this application are explained. It is understood that these explanations are intended to make this application easier to understand and should not be regarded as limiting the scope of protection claimed in this application.

[0061] 1. Terminal

[0062] A terminal can be referred to as user equipment (UE), terminal device, terminal apparatus, access terminal, subscriber unit, subscriber station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, wireless communication device, user agent, or user device. It is a device with wireless or wired communication capabilities. For example, a terminal can connect to a wireless access device via an air interface, or it can connect to a wired access device via a wired interface. In terms of product form, terminals can include handheld devices, vehicle-mounted devices, wearable devices, or computing devices with communication capabilities. Exemplarily, the terminal may be a mobile phone, a tablet computer, a computer with wireless communication function (such as a laptop computer, a PDA, etc.), a mobile internet device (MID), a virtual reality (VR) terminal, an augmented reality (AR) terminal, a smart watch, a smart bracelet, smart glasses, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical care, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, a cellular phone, a cordless phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless communication function, other processing devices connected to a wireless modem, the Internet of Things (IoT), or a wireless communication terminal. Terminals in the IoT (Internet of Things) system, desktop computers, or UEs defined in the 3rd Generation Partnership Project (3GPP) standards and specifications are not restricted.

[0063] 2. WebRTC

[0064] WebRTC is a real-time communication technology that allows web applications or websites (or sites) to establish peer-to-peer (P2P) connections between browsers without the need for an intermediary, enabling the transmission of audio streams, video streams, or any other data besides audio and video streams. The audio and / or video streams can be transmitted via a media channel, and the data can be transmitted via a data channel (DC), which is referred to as a WebRTC data channel.

[0065] The WebRTC data channel is a channel created by the WebRTC user agent to transmit any data other than audio and video between browsers. The WebRTC data channel can use the stream control transmission protocol (SCTP) superimposed with datagram transport layer security (DTLS), and then superimposed with the user datagram protocol (UDP) as the bearer protocol, and use interactive connectivity establishment (ICE) to implement network address translation (NAT) traversal, allowing the communicating parties to perceive each other's Internet Protocol (IP) address and port. For example, the protocol stack of the WebRTC data channel can be as follows Figure 1A As shown. SCTP is a connection-oriented transport protocol, and its connection can be called an association. An SCTP association can include multiple unidirectional streams, each of which is independent of each other and marked with a stream ID. It can be understood that each stream can send data independently without being affected by other streams. In other words, the WebRTC data channel is essentially two streams in different directions on an SCTP association, and these two streams can use the same stream ID.

[0066] To transmit data other than audio and video streams within the IMS network, the 3rd Generation Partnership Project (3GPP) introduced a data channel for the IMS network, called the IMS data channel (IMSDC). The IMS network is an open system that provides various multimedia services to users based on IP bearer. The data channels described in the following embodiments of this application all refer to IMS data channels. To better understand the IMS data channel, we first explain the call services related to the IMS data channel and the IMS session.

[0067] 3. Call service

[0068] A call service refers to a voice call or video call service in which a terminal participates as a caller or a called party, and connects to one or more other terminals via a communication network (such as an IMS network). A call service may cover the entire process from the start of dialing to the end of the call, or it may cover part of the process from the start of dialing to the end of the call, such as the process from the time when the parties involved in the call service enter the call state to the end of the call. A call service may be a one-to-one call service or a one-to-many (such as a conference) call service; this application takes a one-to-one call service as an example, but related solutions can be used for one-to-many call services.

[0069] 4. IMS Session

[0070] In this application, an IMS session refers to a session for multimedia communication established between people, people and things, or things and things, and is used to transmit multimedia data between the communicating parties, such as data between terminals, and / or data between a terminal and a communication network, etc. An IMS session can be understood as a logical connection between communication devices in multimedia communication. For example, it can be understood as a logical connection between terminals in multimedia communication, which can transmit data between terminals; or it can be understood as a logical connection between a terminal and a communication network in multimedia communication, which is used to transmit data between the terminal and the communication network. In specific applications, an IMS session can be negotiated (or established) based on SIP / SDP. It should be understood that an IMS session can also be replaced by a communication session, an IMS communication session, a session or a call service session, etc., without limitation.

[0071] It will be appreciated that multimedia communication may correspond to at least one IMS session. For example, multimedia communication between terminal 1 and terminal 2 corresponds to one IMS session, such as the IMS session between terminal 1 and terminal 2. For example, multimedia communication between terminal 1, terminal 2, and terminal 3 corresponds to one IMS session, such as the IMS session between terminal 1, terminal 2, and terminal 3. Alternatively, multimedia communication may correspond to three IMS sessions, such as the IMS session between terminal 1 and terminal 2, the IMS session between terminal 1 and terminal 3, and the IMS session between terminal 2 and terminal 3.

[0072] As will be appreciated, to transmit various types of data, channels for transmitting the corresponding data types can be established within an IMS session. For example, channels can be categorized into media channels and data channels based on data type. In some scenarios, media channels can be further categorized into audio channels and video channels. Audio channels can be used to transmit voice, video channels can be used to transmit video, and data channels can be used to transmit any data other than voice and video. Of course, data channels can also transmit voice and / or video, without limitation.

[0073] For example, Figure 1B As shown, terminal 1 and terminal 2 can communicate through the IMS network, and the IMS session between terminal 1 and terminal 2 includes a data channel, an audio channel, and a video channel. It should be understood that Figure 1B This is only an example of an IMS session. In a specific application, the IMS session may include a data channel but not an audio channel and a video channel, or the IMS session may include at least one of an audio channel and a video channel and a data channel, without limitation.

[0074] 5. IMS Session Protocol Stack

[0075] The protocol stack of an IMS session is used to indicate the sum of media transmission protocols applicable to the IMS session, which can reflect the data transmission process in the IMS session. An IMS session can transmit voice, video, text, and data other than voice, video, and text. Therefore, in order to match the transmission requirements of different types of data, different protocols can be configured for different types of data channels. For example, the protocol stack of an IMS session can be as follows: Figure 1C As shown. Figure 1CIn [1], the lowest-level protocol for audio, video, and data channels is IP, and above IP is UDP. For these channels, the protocols above UDP vary, as described below. For audio or video channels, above UDP is the Real-time Transport Protocol (RTP) or the RTP Control Protocol (RTCP). RTP can encapsulate payloads such as voice, video, or text. Above this is the conversational multimedia application, and above RTCP is also a conversational multimedia application. For data channels, above UDP is the DTLS protocol, and above DTLS is SCTP. SCTP can encapsulate information that can be transmitted by data channels, such as application data or applications. Above the application data or applications is the conversational multimedia application.

[0076] Understandably, Figure 1C This is only an example of a media transmission protocol stack for an IMS session. In specific applications, the protocol stack for an IMS session may also be in other forms. For example, the protocol stack for an IMS session may not include the DTLS protocol.

[0077] 6. Data Channel

[0078] The data channels described in the following embodiments of this application, unless otherwise specified, refer to data channels in the IMS network, that is, IMS data channels, which are associated with the IMS session of the terminal, or are created during the IMS session of the terminal, and can be used to transmit application data or applications related to the terminal (for generating / consuming application data) during the duration of the IMS session.

[0079] Illustratively, based on the relationship between the data channel and the audio / video call, the data channel in the embodiment of the present application can be divided into at least the following types.

[0080] (1) During an IMS session, when an audio or video call is being conducted between the terminal and another session participant (which can be another terminal or a network element), a data channel also exists. This data channel can be called an auxiliary data channel or a dependent data channel.

[0081] (2) During an IMS session, when a data channel exists between the terminal and other session participants, and there is no traditional voice call or video call, the data channel at this time can be called a standalone data channel or an independent data channel.

[0082] Both auxiliary and independent data channels can be used to transmit any type of application data or applications between session participants.

[0083] Exemplarily, the application data transmitted by the data channel may be interactive application data (interactive data). Interactive application data may be application data used to support interactive operations (e.g., data or code / script used to generate a graphical user interface (GUI) for users to perform interactive operations, such as a "Like" button or a "Red Envelope" button). It may also be application data generated by executing such interactive operations (e.g., control instructions, control signals, or output files generated after a conversation participant performs an interactive operation, such as the number of "Likes" or the amount in a "Red Envelope"). It may also be data collected or stored by the terminal, for example, data collected by the terminal through an input / output (I / O) module, such as images or videos captured by a camera, voice captured by a microphone, text, symbols, or emoticons entered through a keyboard, or data generated by actions such as clicking or sliding on a touch screen.

[0084] Exemplarily, the application data transmitted by the data channel may also be communication enhancement application data (communication enhancement data for short); communication enhancement data may be data generated based on the content of an audio call / video call, such as converting the voice in an audio call / video call into text, or converting sign language in a video call into text or voice, or data superimposed on the audio call / video call, such as AR special effects images, etc., or data independent of the audio call / video call, such as geographic location data, screen sharing data, etc.

[0085] Exemplarily, the application data transmitted by the data channel can also be a remote control command, which can provide remote control services or remote IOT device connection services for users. It can be understood that in the above situation, the data channel can also be used to transmit remote control commands.

[0086] Exemplarily, the application transmitted by the data channel can be an application installation package, executable code or script. The application can be an interactive enhancement application or a communication enhancement application used to enhance the interactive effect / communication effect of traditional voice calls / video calls, or it can be a remote control application / IoT communication application. This application does not impose any restrictions.

[0087] In some scenarios, depending on their purpose, auxiliary data channels or independent data channels can be divided into: bootstrap data channels (BDC) or application data channels (ADC). In this application, BDC is used by the terminal to obtain applications from the data channel server (DCS), such as obtaining data channel applications (DC apps). ADC is used to transmit application data, such as interactive data or application data generated by data channel applications running on both communicating parties. It can be understood that the application transmitted in BDC can logically control the sending or receiving of application data in ADC. The stream ID value of BDC is less than 1000, and the stream ID value of ADC is greater than or equal to 1000.

[0088] 7. Data channel application

[0089] The data channel application can be used to transmit application data through the data channel between multiple terminals in the same call service. For example, the data channel application includes at least one of the following: hypertext markup language (HTML), JavaScript script, image or cascading style sheets (CSS). The data channel application can describe a graphical user interface (UI) and can implement interactive business logic. The data channel application can exist in the form of a web page or run in a browser environment, such as in the UI mode of an HTML web page, or in the form of a mini-program / quick application / light application.

[0090] Data channel applications can transmit various data such as text, images, locations, and files through data channels before and after a call is established, enabling real-time data exchange between the two parties, greatly enhancing the call experience for both parties. For example, if Terminal 1 and Terminal 2 are in the same call service and Terminal 1 wishes to share its phone screen with Terminal 2 during a call to guide Terminal 2 through phone settings, Terminal 1 and Terminal 2 can each obtain a data channel application for screen sharing and then run it to interact with the other party in real time.

[0091] Please refer to Figure 1D , obtain a schematic diagram of the data channel application for terminal 1 and terminal 2. The specific process is as follows: 1. The developer completes the development of the data channel application through the offline process, and then uploads the developed data channel application to the operator's DCS. 2. The DCS stores the data channel application in the data channel application repository (DCAR). 3. The DCS downloads the data channel application from the DCAR when needed. 4. Terminal 1 establishes a BDC with the DCS and obtains the required data channel application from the DCS through the BDC. 5. Terminal 2 establishes a BDC with the DCS and obtains the required data channel application from the DCS through the BDC. 6. Terminal 1 and terminal 2 establish an ADC to transmit the interactive data of the data channel application.

[0092] Understandably, the data channel doesn't care about the content or communication format it transmits, but both parties must agree on the communication format. Using Internet technologies, such as the Hypertext Markup Language (HTML) 5 interface and JavaScript scripts (e.g., Web applications), diverse application content can be transmitted over the data channel, supporting rapid innovation, deployment, and rollout of call services.

[0093] To ensure that all parties in an IMS session agree on the communication format, such as the media type and / or encoding scheme, media negotiation can be performed during the IMS session establishment process. For example, this can be accomplished using SDP. SDP is used to transmit session messages to session participants. SDP defines a unified format for session descriptions. The following describes the session description information defined by SDP.

[0094] 8. Session description information

[0095] In this application, session description information includes session information and media description information. For example, session information may indicate the session name, session connection, session activity time (such as the start and end time of the session), and information about the session owner. Media description information may indicate the media type, transmission protocol, and media format. For IP multicast sessions, the media description also indicates the multicast address and media transmission port. For IP unicast sessions, the media description also indicates the remote address of the media and transmission port used for the contact address, etc.

[0096] For example, the content of the session description information may be as shown in Table 1. In Table 1, "v=0" to "t=28733974962873404696" represent session information. The content after "t=2873397496 2873404696" represents media description information. For example, the content from one "m=" to the next "m=" represents one media description information. "v=0" indicates the protocol version. "o=mhandley 2890844526 2890842807IN IP4126.16.64.4" indicates information about the session owner, such as the name of the session initiator (mhandley), the caller's session identifier (2890844526), ​​the caller's session version (2890842807), the caller's network type (IN), the address type (IP4), and the session initiator's IP address (126.16.64.4). "s=SDP Seminar" indicates the session name. "c=INIP4 224.2.17.12 / 127" indicates the session connection, which is the IP address used for media streams. "t=28733974962873404696" indicates the start and end times of the session. "m=application 10001 UDP / DTLS / SCTPwebrtc-datachannel" is the media description of the data channel, which can indicate the media type (m=application), UDP port number (10001), transport protocol (UDP / DTLS / SCTP), and supported payload types (webrtc-datachannel). "c=IN IP4 192.0.2.1" indicates media-level connection information. "a=sctp-port:57483" indicates the SCTP port number (57483). "a=setup:actpass" indicates the role of this endpoint in the DTLS negotiation process (it can both initiate and receive DTLS link establishment requests). "a=fingerprint:SHA-1\4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB" indicates the certificate fingerprint signature used by DTLS. "a=tls-id:abc3de65cddef001be82" indicates the DTLS port number. "a=dcmap:1001subprotocol="bfcp";label="bfcp"" indicates a data channel, where "bfcp" refers to the name of the application layer protocol used by the data channel application to transmit data through the data channel.

[0097] Table 1

[0098]

[0099]

[0100] 9. SDP offerer and SDP answerer

[0101] In order to negotiate the SDP parameters to be used by the IMS session participants, such as the above-mentioned media description information, the SDP proposer and SDP responder are introduced. The SDP proposer is the party that wants to create or modify an IMS session, and the SDP responder is the party that responds to the SDP proposer. Figure 1E As shown in Table 1, an SDP proposer may issue an SDP offer message (SDP Offer). The SDP offer message may include a set of media streams and encoding methods that the SDP proposer wishes to use, as well as the IP address and port number used by the SDP proposer to receive and send media streams. For example, the SDP offer message may include the content shown in Table 1. The SDP responder receives the SDP offer message and sends an SDP response message. The SDP response message may indicate whether the media streams and encoding methods in the SDP offer message are accepted, as well as the IP address and port number used by the SDP responder to send and receive media streams.

[0102] In summary, the SDP proposer and SDP responder can determine the IP addresses and ports used for data transmission between the two parties, as well as the media information corresponding to the data channels, through the SIP / SDP media negotiation process, thereby establishing one or more data channels in an IMS session. The SDP proposer and SDP responder can be two terminals in the same IMS session; alternatively, the SDP proposer can be a terminal in the IMS session, and the SDP responder can be a network device in the communication network, such as an IMS application server (AS); alternatively, the SDP proposer can be a network device in the communication network, and the SDP responder can be a terminal in the IMS session.

[0103] 10. WebRTC User Agent

[0104] WebRTC user agents can be deployed on terminals for media negotiation. Figure 1FThe figure shows the architecture diagram of the WebRTC user agent. The WebRTC user agent can open the API to web application developers through the web application programming interface (API) layer. Therefore, web application developers do not need to worry about complex underlying technologies. By understanding the general principles of WebRTC, they can develop web applications. A web application refers to software that runs in a web browser, and a standard browser can be used as a client. A web application is, for example, an HTML web page, usually written in a mixed form of HTML5, CSS, and JavaScript. The WebRTC C++API layer can provide an API used by browsers to support the WebRTC specification. Its main function is to expose the core functions of WebRTC, such as device functions, audio and video stream data collection, etc., to facilitate browser manufacturers to integrate them into their own applications. PeerConnection is the core module of the WebRTC C++API layer, which is used to implement P2P wall penetration, communication link establishment and optimization, streaming data transmission, non-audio and video data transmission, transmission quality reporting and statistics, etc. The session management / abstract signaling layer is the session layer of WebRTC, providing session management functionality, such as session creation, session management, and context management. This layer also involves various protocols, such as the SDP protocol for signaling servers, primarily for signaling interaction and managing the connection state of RTCPeerConnections. The audio engine, video engine, and transport modules reside in the engine layer and are responsible for audio and video processing and file transmission. The audio capture / rendering module, video capture module, and network I / O module reside in the driver layer and transmit captured audio and video to the engine layer for further processing.

[0105] 11. WebRTC Signaling Model

[0106] WebRTC can use SDP for media negotiation, such as exchanging SDP parameters through SDP proposal information and SDP response information. The protocol stipulates that WebRTC JavaScript applications (a type of web app) use interfaces specified in the W3C API (such as Figure 1FThe WebRTC signaling layer is controlled by the WebRTC API in the WebRTC framework, and assumes that the WebRTC JavaScript application runs in an environment that includes the WebRTC API. In addition, WebRTC focuses more on the media layer, leaving the signaling layer to the application as much as possible. For example, the WebRTC signaling model can be as follows: Figure 1G As shown. Figure 1G In the JSEP protocol, web apps can interact with each other through signaling (e.g., sending app-specific signaling), and JavaScript session establishment protocol (JSEP) can be used to implement the JSEP protocol (e.g., Figure 1F The session management / abstract signaling layer in the media negotiation layer) can be responsible for maintaining the signaling state machine, which is used to indicate the media negotiation status during the media negotiation process. The JSEP implementation provides the interface required by the web app, and the web app calls the API at the right time to drive the signaling state machine. The JSEP implementation mainly creates the SDP based on the information provided by the web app, including the media type, format and all related media configuration parameters required to establish the media path, and processes the negotiated local and remote session descriptions. Different web apps can use different protocols in the signaling layer, such as standardized signaling protocols (for example, SIP), or custom signaling protocols to interact with the peer web app for media description information. For example, the JSEP implementation is an implementation of WebRTC injected into the browser, which provides a JS API (corresponding to Figure 1F A web app is an application that runs in a browser and calls the JS API to implement functions such as online video chat.

[0107] 12. WebRTC SDP exchange process

[0108] Figure 1HThe following example illustrates the WebRTC SDP exchange process between peer#1 and peer#2. Specifically, WebRTC uses the RTCPeerConnection class to establish a connection. It contains two methods for generating SDP: CreateOffer() and CreateAnswer(). The former is called by the session initiator (e.g., Peer#1) to generate an offerSdp and send it to the signaling server. The latter is called by the session answerer (e.g., Peer#2) after receiving the offerSdp to generate an answerSdp. The answerSdp is then sent to the session initiator via the signaling server. RTCPeerConnection also contains two methods for setting the SDP: SetLocalDescription() and SetRemoteDescription(). The former is used to set the local SDP (i.e., localSdp), while the latter is used to set the received remote SDP (i.e., remote). For the session initiator, localSdp is the offerSdp, and remoteSdp is the answerSdp. For the session responder, localSdp is the answerSdp, and remoteSdp is the received offerSdp. The ordered combination of the above four methods constitutes the SDP exchange process between WebRTC devices. This is also a negotiation process, as the session responder needs to decide how to respond based on the SDP provided by the initiator (such as ICE server information, audio and video codec information, etc.).

[0109] 13. Media negotiation for WebRTC data channels

[0110] WebRTC applications can implement media negotiation of WebRTC data channels by calling the RTCPeerConnection API. The following takes the negotiation of WebRTC data channels between Terminal 1 (calling terminal) and Terminal 2 (called terminal) as an example. Figure 1I As shown, the media negotiation process of the WebRTC data channel may include the following steps:

[0111] S101: The WebRTC application in terminal 1 calls the RTCPeerConnection API to request the WebRTC user agent in terminal 1 (which can also be replaced by JSEP implementation) to create an RTCPeerConnection instance.

[0112] As can be understood, when Terminal 1 starts a WebRTC application and needs to perform media negotiation, Terminal 1 initiates media negotiation, such as calling the RTCPeerConnection API. The new RTCPeerConnection instance created by the WebRTC user agent represents a connection between Terminal 1 and Terminal 2.

[0113] As you can understand, RTCPeerConnection corresponds to the session level of SDP. An RTCPeerConnection instance corresponds to an SCTP coupling. For example, an RTCPeerConnection instance can correspond to the media description of a data channel in SDP. The media description of a data channel consists of the content starting from "m=application..." and ending before the next "m=...".

[0114] S102: The WebRTC application in terminal 1 calls the createDataChannel method to request the creation of a WebRTC data channel on the RTCPeerConnection instance (or object).

[0115] As will be appreciated, the createDataChannel method can also carry WebRTC data channel-related information, such as the WebRTC data channel's name (label). Optionally, the createDataChannel method can also carry WebRTC data channel parameters, such as one or more of reliable, ordered, maxRetransmitTime, maxRetransmits, protocol, negotiated, or id. Reliable, ordered, maxRetransmitTime, and maxRetransmits can be used to indicate whether the transmission is reliable, how to retransmit if it's unreliable, and whether packets must arrive in order. protocol indicates the subprotocol used to transmit data in the WebRTC data channel and is transparent to WebRTC. negotiated and id indicate whether negotiation is performed out-of-band or within the data transmitted within the WebRTC data channel itself. For example, when negotiated is true, it indicates out-of-band data negotiation via SDP. In this case, id can provide a valid SID value. When negotiated is false, it indicates that the WebRTC data channel is established through in-band negotiation by sending an Open message after the underlying channel link is established.

[0116] It is understood that if the createDataChannel method does not take parameters for a WebRTC data channel, the WebRTC user agent MAY set the parameters to default values ​​or select a set of parameters for the WebRTC data channel.

[0117] It is understandable that WebRTC data channels on the same RTCPeerConnection can share the same SCTP coupling, or that WebRTC data channels on the same RTCPeerConnection correspond to the same WebRTC data channel media description (such as an m line). Therefore, WebRTC data channels created by the WebRTC user agent on the RTCPeerConnection instance can share an SCTP coupling. In other words, each time the WebRTC user agent creates a WebRTC data channel on an RTCPeerConnection, it creates a new WebRTC data channel on the SCTP coupling corresponding to the RTCPeerConnection, such as adding an SCTP Stream. This SCTP Stream can correspond to an "a=dcmap" attribute line under the m line.

[0118] For example, a WebRTC application previously creates a WebRTC data channel through RTCPeerConnection, and the media description of the WebRTC data channel is shown in Table 1 (such as the content including "m=application 10001UDP / DTLS / SCTPwebrtc-datachannel" to "a=dcmap:1001subprotocol="bfcp";label="bfcp""). As an example, if the WebRTC application creates another WebRTC data channel on RTCPeerConnection, the newly created WebRTC data channel shares the same SCTP coupling with the previous WebRTC data channel. The "a=dcmap" attribute line can be added after "a=dcmap:1001subprotocol="bfcp";label="bfcp"" to obtain the media description shown in Table 2.

[0119] Table 2

[0120]

[0121]

[0122] S103: The WebRTC application in terminal 1 calls the createOffer method to request the WebRTC user agent in terminal 1 to generate a new SDP description and return it to the WebRTC application.

[0123] As can be understood, the WebRTC user agent also adds an SDP description to the RTCPeerConnection. The SDP description is the media information that needs to be negotiated with Terminal 2. The SDP description includes session description information, which can be shown in Table 3 as an example.

[0124] Table 3

[0125]

[0126] S104: The WebRTC application of terminal 1 calls the setLocalDescription API to trigger the WebRTC user agent in terminal 1 to parse the SDP description and create local resources for receiving and decoding media.

[0127] It is understandable that the WebRTC user agent of terminal 1 can trigger the WebRTC data channel to send parameter settings, thereby triggering SCTP Streams creation, setting data source, etc.

[0128] S105: The WebRTC application of terminal 1 uses a signaling mechanism (such as SIP) to send an SDP offer to the WebRTC application of terminal 2 through a signaling server. Correspondingly, the WebRTC application of terminal 2 receives the SDP offer.

[0129] It can be understood that the SDP offer may include the above SDP description.

[0130] S106: The WebRTC application of terminal 2 calls the RTCPeerConnection API, causing the WebRTC user agent in terminal 2 to create an RTCPeerConnection instance.

[0131] S107: The WebRTC application of terminal 2 calls the setRemoteDescription API to apply the received SDP offer, parse the SDP offer and configure the local resources for sending and encoding.

[0132] S108: The WebRTC application of terminal 2 creates an RTCDataChannel object on the local RTCPeerConnection object. For example, the WebRTC application of terminal 2 calls the createDataChannel method to create a WebRTC data channel on the RTCPeerConnection object.

[0133] S109: The WebRTC application of terminal 2 calls the createAnswer API to generate an SDP answer.

[0134] The SDP answer can include information about the media connected to the session and the codecs supported by the browser.

[0135] S110: The WebRTC application of terminal 2 calls the setLocalDescription API to set the local SDP for configuring the local resources for receiving and decoding.

[0136] S111: The WebRTC application of terminal 2 returns the SDP Answer to the WebRTC application of terminal 1 through the signaling server. Correspondingly, the WebRTC application of terminal 1 receives the SDP Answer.

[0137] S112: The WebRTC application of terminal 1 calls the setRemoteDescription API to set the remote SDP, which is used to configure the local resources to be sent and encoded. At this point, the initial setup is complete.

[0138] S113: The WebRTC user agent of terminal 1 and the WebRTC user agent of terminal 2 establish an SCTP / DTLS coupling and its corresponding stream.

[0139] S114: The WebRTC user agent of terminal 1 notifies the WebRTC application of terminal 1 of the completion of connection creation through the onDataChannel() event, and the WebRTC user agent of terminal 2 notifies the WebRTC application of terminal 2 of the completion of connection creation through the onDataChannel() event.

[0140] S115-S118: The WebRTC application of terminal 1 and the WebRTC application of terminal 2 send media data through the send() interface, and notify the other end to receive the media data through the onmessage() event.

[0141] 14. Media negotiation of IMS data channels

[0142] Communication devices in the same IMS session (such as between a calling terminal and a called terminal, or between a terminal and the network side) can use the IMS SIP / SDP media negotiation process to determine the IP address and port used by both parties to transmit data, the communication protocol used, the parameters required by the transport layer, and the description information corresponding to the IMS data channel, thereby establishing one or more IMS data channels in the IMS session.

[0143] As you can understand, the data channel application can create an IMS data channel through the WebRTC API, so the media negotiation process for the IMS data channel is similar to that for the WebRTC data channel. Taking the negotiation of an IMS data channel between terminal 1 (calling terminal) and terminal 2 (called terminal) as an example, terminal 1 and terminal 2 can first negotiate the BDC and download the data channel application through the BDC. Subsequently, terminal 1 and terminal 2 run the data channel application. If the user of terminal 1 triggers terminal 1 to initiate media negotiation, terminal 1's data channel application can sequentially call the RTCPeerConnection API, createDataChannel method, createOffer method, and setLocalDescription API to obtain an SDP offer (for details, please refer to the corresponding descriptions in S101 to S104 above). Subsequently, terminal 1 can carry the SDP offer in a SIP request, such as an invite request (INVITE), update request (UPDATE), or re-INVITE request, and route the request to terminal 2 through the IMS network. After receiving the SDP offer, Terminal 2 calls the RTCPeerConnection API, setRemoteDescriptionAPI, createDataChannel method, createAnswer API, and setLocalDescription API in sequence to obtain the SDP answer (for details, please refer to the corresponding descriptions in S106 to S110 above), and carries the SDP answer in the SIP response, such as the 18x response / 200OK response, and routes the above response to Terminal 1 through the IMS network, thereby realizing media negotiation of the IMS data channel.

[0144] As can be understood, when an IMS session is created, the initially generated SDP can be sent via INVITE. Subsequently, if the SDP needs to be updated, the updated SDP can be sent via UPDATE. After the IMS session is successfully established, if the SDP needs to be updated, the updated SDP can be sent via re-INVITE.

[0145] In addition, the media description of the IMS data channel is similar to the media description of the WebRTC data channel. For example, the media description of the IMS data channel may include the content shown in Table 4.

[0146] Table 4

[0147]

[0148] The above describes the process of a data channel application triggering the negotiation of an IMS data channel. In actual applications, there are usually multiple data channel applications in an IMS session. Therefore, there will be situations where multiple data channel applications trigger the negotiation of an IMS data channel. The following uses data channel application 1 (hereinafter referred to as application 1) and data channel application 2 (hereinafter referred to as application 2) as an example to explain the triggering of the negotiation of an IMS data channel. Figure 2 As shown, application 1 and application 2 can be respectively used as follows Figure 1I The method shown in the figure negotiates an IMS data channel. Therefore, both applications have their own session contexts, and the WebRTC user agent creates separate SCTP connections for each application. Each application uses a different SCTP connection to send and receive data. For example, when two applications call the createOffer method, the WebRTC user agent can create the SDP shown in Table 5 for each application.

[0149] Table 5

[0150]

[0151]

[0152] The above method of creating data channels for multiple data channel applications will result in large resource overhead.

[0153] To address the above-mentioned issues, the present application provides a communication method. In this method, after receiving a first request for creating a first data channel, a communication entity can determine whether an already created connection (such as an SCTP coupling) can carry the first data channel. If an already created connection exists that can carry the first data channel, the communication entity instructs the first connection to be used to carry the first data channel, where the first connection is the connection corresponding to the first data channel in the already created connection. If no already created connection exists that can carry the first data channel, the communication entity instructs the new connection to be used to carry the first data channel, and creates the new connection.

[0154] In the above process, before creating a data channel, the communication entity can determine a connection that can carry the data channel from the already created connections. In other words, when creating a data channel using the above method, the already created connections can be reused, thereby reducing resource overhead.

[0155] It is understandable that the method provided in this application can be used in various communication systems. For example, the communication system can be a long term evolution (LTE) system, a 5G communication system, a wireless fidelity (WiFi) system, a 3GPP-related communication system, a communication system evolved after 5G (such as: a sixth generation (6G) communication system), or a system integrating multiple systems, etc., without limitation. Among them, 5G can also be called new radio (NR). The following is Figure 3A and Figure 3B Taking the communication scenario shown as an example, the method provided in this application is described. Figure 3A and Figure 3B It is only a schematic diagram and does not constitute a limitation on the applicable scenarios of the technical solution provided in this application.

[0156] Figure 3A and Figure 3B A schematic diagram of a communication scenario applicable to this application. Figure 3A This shows a communication scenario when the calling terminal and the called terminal are in the same IMS network. Figure 3B The figure shows a communication scenario in which the calling terminal and the called terminal are in different IMS networks.

[0157] exist Figure 3A In the figure, terminal 302 and terminal 303 can communicate through IMS network 301, which is both the call originating network and the call terminating network. Terminal 302 is the calling terminal and terminal 303 is the called terminal, or terminal 302 is the called terminal and terminal 303 is the calling terminal. IMS network 301 includes a data channel application server (DC AS), a network exposure function (NEF) entity and DCS communicating with the DC AS, an IMS home subscriber server (HSS) entity and IMS AS communicating with the DCS, a call session control function (CSCF) entity communicating with the IMS AS and IMS HSS entity, and an IMS access media gateway (IMS-AGW) communicating with the CSCF entity.

[0158] The DCS may include a data channel signaling function (DCSF) entity and a media function (MF) entity. Optionally, the DCS may also include a data channel application repository (DCAR) entity. Figure 3A The DCSF and DCAR are deployed on the same entity, while the MF is deployed on a separate entity. In specific applications, the deployment of the DCSF, DCAR, and MF is not limited. For example, the DCSF, DCAR, and MF can be deployed on different entities, or at least two of the DCSF, DCAR, and MF can be deployed on the same entity.

[0159] The CSCF entity is a functional entity within the IMS and serves as the core of the entire IMS. It is primarily responsible for signaling control during multimedia call sessions. It manages IMS user authentication, IMS bearer plane quality of service (QoS), and collaborates with other network elements to control SIP sessions, as well as service negotiation and resource allocation. Depending on their functionality, CSCF entities can be categorized as proxy CSCF (P-CSCF), interrogating CSCF (I-CSCF), and serving CSCF (S-CSCF). Figure 3A The I-CSCF and S-CSCF are deployed on the same entity, while the P-CSCF is deployed on a separate entity. In specific applications, the deployment methods of the I-CSCF, S-CSCF, and P-CSCF are not limited. For example, the I-CSCF, S-CSCF, and P-CSCF can be deployed on different entities, or at least two of the I-CSCF, S-CSCF, and P-CSCF can be deployed on the same entity.

[0160] Understandably, in Figure 3AIn the communication scenario shown, terminal 302 and terminal 303 may adopt the method provided in the present application to negotiate the data channel in the IMS session in which terminal 302 and terminal 303 participate. Alternatively, terminal 302 and IMS AS (or DCSF entity) may adopt the method provided in the present application to negotiate the data channel in the IMS session in which terminal 302 and IMS AS (or DCSF entity) participate. Alternatively, terminal 303 and IMS AS (or DCSF entity) may adopt the method provided in the present application to negotiate the data channel in the IMS session in which terminal 303 and IMS AS (or DCSF entity) participate. Alternatively, terminal 302 and DC AS may adopt the method provided in the present application to negotiate the data channel in the IMS session in which terminal 302 and DC AS participate. Alternatively, terminal 303 and DC AS may adopt the method provided in the present application to negotiate the data channel in the IMS session in which terminal 303 and DC AS participate.

[0161] exist Figure 3B In the example, terminal 313 and terminal 314 can communicate via IMS network 311 and IMS network 312. One of IMS network 311 and IMS network 312 is a call originating network, and the other is a call terminating network. For example, if terminal 313 is a calling terminal and terminal 314 is a called terminal, IMS network 311 is the call originating network and IMS network 312 is the call terminating network. If terminal 313 is a called terminal and terminal 314 is a calling terminal, IMS network 311 is the call terminating network and IMS network 312 is the call originating network. The entities included in the IMS network 311 and the IMS network 312 are similar. For example, the IMS network 311 or the IMS network 312 includes a DC AS, an NEF entity and a DCS communicating with the DC AS, an IMS HSS entity and an IMS AS communicating with the DCS, a CSCF entity communicating with the IMS AS, an IMS-AGW and an interconnection border control function (IBCF) entity communicating with the CSCF entity, and a transition gateway (TrGW) communicating with the IMS-AGW. For an introduction to the DCS and CSCF entities, please refer to Figure 3A The corresponding description in .

[0162] Understandably, in Figure 3BIn the communication scenario shown, terminal 313 and terminal 314 may use the method provided in this application to negotiate the data channel in the IMS session in which terminal 313 and terminal 314 participate. Alternatively, terminal 313 and the IMS AS (or DCSF entity) in IMS network 311 may use the method provided in this application to negotiate the data channel in the IMS session in which terminal 313 and the IMS AS (or DCSF entity) in IMS network 311 participate. Alternatively, terminal 313 and the IMS AS (or DCSF entity) in IMS network 312 may use the method provided in this application to negotiate the data channel in the IMS session in which terminal 313 and the IMS AS (or DCSF entity) in IMS network 312 participate. Alternatively, terminal 314 and the IMS AS (or DCSF entity) in IMS network 312 may use the method provided in this application to negotiate the data channel in the IMS session in which terminal 314 and the IMS AS (or DCSF entity) in IMS network 312 participate. Alternatively, terminal 314 and the IMS AS (or DCSF entity) in IMS network 311 may use the method provided in this application to negotiate the data channel in the IMS session in which terminal 314 and the IMS AS (or DCSF entity) in IMS network 311 participate. Alternatively, terminal 313 and the DC AS may use the method provided in this application to negotiate the data channel in the IMS session in which terminal 313 and the DC AS participate. Alternatively, terminal 314 and the DC AS may use the method provided in this application to negotiate the data channel in the IMS session in which terminal 314 and the DC AS participate.

[0163] In order to more clearly understand the communication scenario provided by this application, Figure 3A and Figure 3B The functions of various entities in it are explained in detail.

[0164] DC AS can be used to provide data channel business logic. Figure 3A or Figure 3B In the current implementation, the DC AS is deployed in the IMS network and can directly connect to other entities in the IMS network through interfaces (such as service-oriented interfaces). In specific applications, the DC AS can also be deployed outside the IMS network and connected to other network elements in the IMS network through the NEF entity (or IMS edge network management).

[0165] The NEF entity can be used to securely open various services of the core network (such as the 5G core network) to third parties.

[0166] The DCSF entity can provide data channel signaling control functions.

[0167] DCAR can be used to store data channel applications. For example, after a developer completes a data channel application, they upload it to the operator's DCS, which then saves it to DCAR. When needed, the DCS downloads the data channel application from DCAR to its local server for subsequent processing.

[0168] The IMS HSS entity may be responsible for storing IMS user subscription data.

[0169] The IMS AS is the top-level application layer device in the IMS network, providing a variety of services, including basic and supplementary IMS services, multimedia conferencing, converged communications, SMS gateways, and standard attendant consoles. The IMS AS interacts with the CSCF entity to trigger and execute various network services. The IMS AS negotiates data channels with terminals. For example, the IMS AS can be a Multimedia Telephony Application Server (MMTEL AS) or a Telephony Application Server (TAS).

[0170] The MF entity can be used to provide data channel media resource management functions.

[0171] The S-CSCF entity is responsible for IMS user registration, authentication, session management, routing, and service triggering.

[0172] The I-CSCF entity is the unified entry point of the IMS user's home network and is responsible for allocating or querying the S-CSCF that serves the user.

[0173] The P-CSCF entity is the entry point for users to access the IMS network and is responsible for forwarding SIP signaling between IMS users and their home network.

[0174] IMS AGW can provide IMS network access gateway and media gateway functions.

[0175] The IBCF entity can implement signaling intercommunication, topology hiding, and IP security protection functions for voice, video, and multimedia services.

[0176] The TrGW entity can implement media intercommunication, topology hiding, and IP security protection for voice, video, and multimedia services, and also supports voice codec format conversion and other functions.

[0177] It is understandable that the introduction of the terminal can refer to the explanation of the technical terms involved in this application in the previous text. In addition, since the terminal in this application supports data channels, the terminal in this application can deploy an IMS multimedia telephony service (MTSI) client (MTSI client) that supports data channels. The MTSI client that supports data channels can also be called a DCMTSI client. The architecture of the DCMTSI client can be as follows: Figure 3C shown.

[0178] exist Figure 3C In the DCMTSI client, a data packet-based network interface is provided, and an audio decoder, a video decryptor, a text media for processing downlink data (hereinafter referred to as text media 1), a data channel module for processing downlink data (hereinafter referred to as data channel module 1), a session creation and control module, a data channel module for processing uplink data (hereinafter referred to as data channel module 2), an audio encoder, a video encoder, and a text media for processing uplink data (hereinafter referred to as text media 2). The data packet-based network interface can be connected to the network interface through Figure 1C The protocol stack implementation in .

[0179] The packet-based network interface can communicate with the 3GPP network using 3GPP Layer 2 protocols for media transmission. The 3GPP Layer 2 protocols include the Packet Data Convergence Protocol (PDCP) or the Service Data Adaptation Protocol (SDAP). For example, the DCMTSI client can receive media data from the network or send media data to the network via the packet-based network interface.

[0180] As will be appreciated, the audio encoder can encode the sound captured by the microphone and send the encoded audio via a packet-based network interface to be received by another DCMTSI client. After receiving the encoded audio, the other DCMTSI client can use an audio decoder to decode the audio and play it through a speaker. The video encoder can encode images captured by the camera and send the encoded images via a packet-based network interface to be received by another DCMTSI client. After receiving the encoded images, the other DCMTSI client can use a video decoder to decode the images and render them on a display. Text media 2 can capture characters entered on the keyboard or drawn on the screen and send these characters via a packet-based network interface to be received by another DCMTSI client. After receiving these characters, the other DCMTSI client can render them in real time on a display. Furthermore, the encoded audio, encoded images, and character information can be sent via the packet-based network interface after being activated. Activation is an operation performed on pre-activated users, which allows them to enter a normal state and begin using the services provided by the operator.

[0181] As will be appreciated, the audio decoder is used to decode audio data received via the packet-based network interface, and the decoded audio can be played through the speaker. The video decoder is used to decode images received via the packet-based network interface and render the images on a display. The text media 1 is used to process character information received via the packet-based network interface, and the processed characters can be rendered in real time on the display. It will be appreciated that the decoded audio, decoded images, and processed characters can be played or displayed after synchronization processing.

[0182] It will be appreciated that other data related to multimedia telephony sessions used for real-time interaction does not require any codecs and can be generated or consumed by the DCMTSI client. For example, this data can be processed by data channel module 2 and transmitted via a packet-based network interface. Alternatively, data channel module 1 can control the data to play corresponding sounds through speakers, display corresponding images on a display, or present corresponding effects on a user interface. Furthermore, the user interface can receive interactive data via the downlink data channel, interact with the web interface and related scripts, and synchronize with the voice, video, and text data received by the user to handle data channel I / O and data formatting.

[0183] It is understandable that in order for the data channel application to run between different terminals and / or different networks, the terminals need to support the corresponding data channel logical architecture.

[0184] For example, Figure 3D The figure shows a logical architecture diagram of a data channel supported by a terminal. Figure 3DIn the data channel application, the data channel runtime, DCMTSI client, and related functions of the human-machine interface can be deployed on the terminal. Among them, JavaScript application interactive logic and HTML / CSS document can be deployed in the data channel application. The human-machine interface can implement the functions of the data channel application, such as playing sound, displaying images, collecting sound, and taking images. In addition, the data channel application can also call domain-specific APIs to implement AR functions, artificial intelligence functions, or query the native system library. The data channel runtime environment can provide APIs for the data channel application. For example, it can provide RTCPeerConnection API, RTCDataChannel API, RTCSignallingServiceAPI, etc., for creating data channels, and can also be used to send and receive application layer data through data channels. Among them, RTCPeerConnection API and RTCDataChannel API can be provided by the WebRTC user agent. RTCSignallingService API can be provided by the terminal's operating system. The DCMTSI client can provide IMS media plane support and IMS signaling plane support for data channels. For example, a data channel application can call an API to trigger media negotiation for the data channel. After receiving the corresponding instructions, the data channel runtime environment can interact with the media module (such as the data channel media module) and signaling module (such as the data channel description module) in the DCMTSI client. The media module and signaling module can be responsible for implementing the media protocol stack and signaling protocol stack, respectively, and perform signaling negotiation and media intercommunication with the remote terminal through the IMS network to create a data channel and send and receive application layer data through the data channel. In summary, the data channel runtime environment can serve as a bridge between the data channel application and the DCMTSI client, passing the signaling operations triggered by the data channel application to the terminal's underlying signaling module for corresponding media negotiation, and parsing the signaling messages sent by the remote terminal to notify the data channel application.The data channel operating environment can also send the media data to be sent by the data channel application through the media module at the bottom layer of the terminal, and distribute the media data sent by the remote terminal to the data channel application.

[0185] It is understandable that the data channel operating environment, DCMTSI client and related functions of the human-computer interaction interface may be capabilities supported by the terminal before leaving the factory, and the data channel application is obtained from the network as needed after the terminal leaves the factory.

[0186] Apart from Figure 3D In addition to the architecture shown, this application also provides a logical architecture diagram of a data channel supported by a terminal, specifically, Figure 3E As shown. Data channel applications, intermediate agents, WebRTC user agents and IMS components can be deployed on the terminal. Among them, the intermediate agent can manage the connections corresponding to the data channels created by the terminal, such as SCTP coupling. For example, after the data channel application initiates a request to create a first data channel, the intermediate agent can determine whether there is a connection in the created connections that can carry the connection of the first data channel. If there is a first connection that can carry the first data channel, the intermediate agent requests the WebRTC user agent to add the stream corresponding to the first data channel to the first connection; if there is no connection that can carry the first data channel, the intermediate agent requests the WebRTC user agent to create a new connection. After receiving the request from the intermediate agent, the WebRTC user agent can perform corresponding operations, such as adding the stream corresponding to the first data channel to the first connection, or creating a new connection. The intermediate agent can also interact with the IMS component to realize the sending and receiving of SIP signaling. The IMS component can have the functions of the IMS signaling plane.

[0187] It is understood that the WebRTC user agent and IMS components may be factory-supported capabilities of the terminal, while the data channel application is acquired from the network as needed after the terminal leaves the factory. The intermediate agent can be either factory-supported capabilities of the terminal or acquired as needed after the terminal leaves the factory (e.g., from the network), without limitation.

[0188] It should be understood that Figure 3A or Figure 3B This is only an example of a communication scenario to which the method provided in this application can be applied. In specific applications, the communication scenario to which the method provided in this application can be applied can also be in other forms, for example, it can include Figure 3A or Figure 3B More or fewer entities, without restriction.

[0189] Optional, this application Figure 3A or Figure 3BThe terminal in the communication device may also be referred to as a communication apparatus, which may be a general device or a dedicated device, and this application does not make any specific limitation on this.

[0190] Optional, this application Figure 3A or Figure 3B The relevant functions of the terminal in the present application may be implemented by a single device, by multiple devices, or by one or more functional modules within a single device, and this application does not impose any specific restrictions on this. It is understood that the above functions may be network elements in a hardware device, software functions running on dedicated hardware, or a combination of hardware and software, or virtualized functions instantiated on a platform (e.g., a cloud platform).

[0191] In the specific implementation, Figure 3A or Figure 3B The terminals in the Figure 4 The structure shown, or including Figure 4 Parts shown. Figure 4 The figure shows a hardware structure diagram of a communication device applicable to the present application. The communication device 40 includes at least one processor 401 and at least one communication interface 404 for implementing the method provided in the present application. The communication device 40 may also include a communication circuit 402 and a memory 403.

[0192] The processor 401 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0193] The communication link 402 may include a path for transmitting information between the above components, such as a bus.

[0194] Communication interface 404 is used to communicate with other devices or communication networks. Communication interface 404 can be any transceiver-like device, such as an Ethernet interface, a radio access network (RAN) interface, a wireless local area network (WLAN) interface, a transceiver, a pin, a bus, an interface circuit, or a transceiver circuit.

[0195] The memory 403 can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), a cache or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to this. The memory can be independent and coupled to the processor 401 via the communication line 402. The memory 403 can also be integrated with the processor 401. The memory provided in this application can generally be non-volatile.

[0196] Among them, the memory 403 is used to store computer-executable instructions involved in executing the solution provided by this application, and is controlled by the processor 401. The processor 401 is used to execute the computer-executable instructions stored in the memory 403, thereby implementing the method provided by this application. Alternatively, optionally, in this application, the processor 401 may also perform the processing-related functions of the method provided below in this application, and the communication interface 404 is responsible for communicating with other devices or communication networks, which is not specifically limited in this application.

[0197] Optionally, the computer-executable instructions in this application may also be referred to as application code, which is not specifically limited in this application.

[0198] The coupling in this application is an indirect coupling or communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.

[0199] As an embodiment, the processor 401 may include one or more CPUs, such as Figure 4 CPU0 and CPU1 in.

[0200] As an embodiment, the communication device 40 may include multiple processors, such as Figure 44 and 5. The processors 401 and 407 are shown in FIG. Each of these processors may be a single-CPU processor or a multi-CPU processor. A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0201] As an embodiment, the communication device 40 may further include an output device 405 and / or an input device 406. The output device 405 is coupled to the processor 401 and can display information in a variety of ways. For example, the output device 405 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 406 is coupled to the processor 401 and can receive user input in a variety of ways. For example, the input device 406 can be a mouse, a keyboard, a touch screen device, or a sensor device.

[0202] Understandably, Figure 4 The structure shown in the figure does not constitute a limitation on the communication device, except Figure 4 In addition to the components shown, the communication device may include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0203] The method provided by this application will be described below with reference to the accompanying drawings. Figure 4 The components shown are not described in detail here.

[0204] It can be understood that the message names between network elements or the names of parameters in the messages in the following embodiments of the present application are only examples, and other names may be used in specific implementations, and the present application does not make any specific limitations on this.

[0205] It is understood that in this application, " / " can indicate that the objects associated with each other are in an "or" relationship, for example, A / B can mean A or B; "and / or" can be used to describe that there are three relationships between the associated objects, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In addition, expressions similar to "at least one of A, B and C" or "at least one of A, B or C" are usually used to indicate any of the following: A exists alone; B exists alone; C exists alone; A and B exist at the same time; A and C exist at the same time; B and C exist at the same time; A, B and C exist at the same time. The above uses A, B and C as an example to illustrate the optional items of the item. When there are more elements in the expression, the meaning of the expression can be obtained according to the above rules.

[0206] In order to facilitate the description of the technical solutions of the present application, in the present application, words such as "first" and "second" may be used to distinguish between technical features with the same or similar functions. The words such as "first" and "second" do not limit the quantity and execution order, and the words such as "first" and "second" do not necessarily limit them to be different. In the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" should not be interpreted as being more preferred or more advantageous than other embodiments or design. The use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0207] It is understood that the "embodiment" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, the various embodiments in the entire specification do not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It is understood that in the various embodiments of the present application, the size of the sequence number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the present application.

[0208] It can be understood that in this application, "when...", "in the case of...", "if" and "if" all mean that corresponding processing will be taken under certain objective circumstances, and do not limit the time, nor do they require judgment actions when implementing them, nor do they mean that there are other limitations.

[0209] It is understood that some optional features in this application may, in certain scenarios, be implemented independently of other features, such as the solution on which they are currently based, to solve corresponding technical problems and achieve corresponding effects. They may also be combined with other features in certain scenarios as needed. Accordingly, the devices provided in this application may also implement these features or functions accordingly, which will not be described in detail here.

[0210] It is understandable that the same step or steps or technical features with the same function in different embodiments of the present application can be referenced to each other.

[0211] It should be understood that the communication entities in the following embodiments of the present application may perform some or all of the steps in the present application. These steps are merely examples, and the present application may also perform other steps or variations of various steps. In addition, the steps may be performed in a different order than those presented in the present application, and it is possible that not all of the steps in the present application need to be performed.

[0212] It is understood that the methods provided below in this application use a communication entity as an example to illustrate the method, but this application does not limit the execution entity. For example, the communication entity in the methods provided in the following embodiments of this application may also be a chip, chip system, or processor that supports the communication entity to implement the method, or a logical node, logic module, or software that can implement all or part of the functions of the communication entity.

[0213] like Figure 5 As shown, a communication method provided by this application may include the following steps:

[0214] S501: The communication entity receives a first request.

[0215] In the present application, the first request is used to request the creation of a first data channel. The first data channel is a data channel between the first communication device and the second communication device, and the first data channel can be used to carry data of the first application. The first data channel is associated with the IMS session between the first communication device and the second communication device. For example, the first data channel is a logical connection in the IMS session, which is used to transmit data of the first application during the duration of the IMS session. It can be understood that the first data channel is an ADC, the first application is a data channel application, and the first application is deployed on the first communication device. For the introduction of the IMS session, ADC, and data channel application, please refer to the corresponding description above and will not be repeated here.

[0216] For example, Figure 3ATaking the communication scenario shown as an example, the first communication device is terminal 302, the second communication device is terminal 303, IMS AS, DCSF entity or DC AS, or the first communication device is terminal 303, the second communication device is terminal 302, IMS AS, DCSF entity or DC AS.

[0217] For example, Figure 3B Taking the communication scenario shown as an example, the first communication device is terminal 313, and the second communication device is terminal 314, an IMS AS in IMS network 311 or IMS network 312, a DCSF entity in IMS network 311 or IMS network 312, or a DC AS in IMS network 311 or IMS network 312. Alternatively, the first communication device is terminal 314, and the second communication device is terminal 313, an IMS AS in IMS network 311 or IMS network 312, a DCSF entity in IMS network 311 or IMS network 312, or a DC AS in IMS network 311 or IMS network 312.

[0218] In this application, the first request may be triggered or sent by the first application on the first communication device. Accordingly, the WebRTC user agent on the first communication device receives the first request. In this case, the communication entity may be the WebRTC user agent on the first communication device or other functional modules on the first communication device. Figure 3D If the terminal architecture shown in FIG. 1 is used, the first request may be sent by the first application to the WebRTC user agent in the data channel operating environment. Figure 3E In the terminal architecture shown, the first request may be sent by the first application triggering the intermediate proxy to the WebRTC user agent.

[0219] It is understandable that the first communication device can be an SDP proposer or an SDP responder when creating the first data channel. The following takes the first communication device as an SDP proposer or an SDP responder as an example to introduce the process of the communication entity receiving the first request.

[0220] Scenario 1: The first communication device is the SDP proposer.

[0221] It is understandable that the first application can call an API to trigger the first request. The following methods 1.1 to 1.3 are used as examples for description.

[0222] Method 1.1: The first application calls the RTCPeerConnection API, the createDataChannel method, and the createOffer method to request the WebRTC user agent to create a first data channel.

[0223] The specific process of method 1.1 is Figure 1I The first request may include at least one of the RTCPeerConnection command, the createDataChannel command, or the createOffer command.

[0224] Method 1.2: The first application calls the RTCPeerConnection API, the createDataChannel method, and the createOffer method to request the WebRTC user agent to create a first data channel and indicate whether there is an existing connection that can carry the first data channel. In this case, the first request may specifically include at least one of the createDataChannel command and the createOffer command.

[0225] Here, an established connection can refer to a coupling established by a communication entity, such as an SCTP coupling or a DTLS / SCTP coupling. A coupling can be associated with a set of protocol address information and protocol port information. For example, a coupling can be associated with IP address information, UDP port information, and SCTP port information. Therefore, a connection being able to carry a first data channel can be understood as meaning that the first data channel can use the IP address, UDP port, and SCTP port associated with the connection, or that the IP address, UDP port, and SCTP port corresponding to the first data channel are identical to the IP address, UDP port, and SCTP port associated with the connection. A connection being unable to carry a first data channel can be understood as meaning that the first data channel cannot use the IP address, UDP port, and SCTP port associated with the connection, or that the IP address, UDP port, and SCTP port corresponding to the first data channel are not identical to the IP address, UDP port, and SCTP port associated with the connection. It should be understood that, in this application, a coupling can also be associated with one or both of the IP address information, UDP port information, and SCTP port information, without limitation. For ease of description, the following embodiments of the present application are described using an example of a coupling associated with IP address information, UDP port information, and SCTP port information.

[0226] In one possible design, a connection capable of carrying a first data channel includes: the quality of service requirement of the first data channel is the same as the quality of service requirement of the connection, or the quality of service requirement of the first data channel is lower than the quality of service requirement of the connection. Optionally, a connection capable of carrying the first data channel further includes: the endpoint corresponding to the connection is the same as the endpoint corresponding to the first data channel, that is, the endpoint corresponding to the connection is also the first communication device and the second communication device, or the connection is established through negotiation between the first communication device and the second communication device. A connection incapable of carrying the first data channel includes: the quality of service requirement of the first data channel is greater than the quality of service requirement of the connection. Optionally, a connection incapable of carrying the first data channel further includes: the endpoint corresponding to the connection is not identical to the endpoint corresponding to the first data channel. For example, the endpoints corresponding to the connection are the first communication device and a communication device other than the second communication device. The quality of service requirements in this application (such as the quality of service requirement of the first data channel, the quality of service requirement of the connection, and the quality of service requirement of the second data channel in the following embodiments, etc.) may include requirements for packet loss rate and / or requirements for latency, etc.

[0227] In one possible implementation, the first application obtains information about the established connection from the WebRTC user agent and determines whether the established connection can carry the first data channel. If the established connection can carry the first data channel, the first application includes information about the connection used to carry the first data channel when requesting to create the first data channel. If the established connection cannot carry the first data channel, the first application does not include information about the connection corresponding to the first data channel when requesting to create the first data channel.

[0228] Exemplarily, the first application calls the RTCPeerConnection API and also calls an API provided by the WebRTC user agent for querying established connections. The WebRTC user agent sends information about the established connections to the first application. The information about the established connections may indicate each established connection, for example, the IP address, UDP port number, and SCTP port number associated with each connection. The first application may query the established connections for a connection that can carry the first data channel. If the first connection is found to be able to carry the first data channel (i.e., the first connection is the connection corresponding to the first data channel among the established connections), the first application may indicate the first connection to the WebRTC user agent. For example, when calling the createDataChannel method or the createOffer method, the first application includes information about the first connection, such as at least one of the first connection identifier, the IP address associated with the first connection, the UDP port number associated with the first connection, or the SCTP port number associated with the first connection. If no connection is found that can carry the first data channel, the first application does not include information about the connection corresponding to the first data channel when calling the createDataChannel method or the createOffer method.

[0229] Method 1.3: The first application requests the WebRTC user agent to create a first data channel through the intermediate proxy.

[0230] In one possible implementation, the first application calls an API provided by the intermediate proxy, triggering the intermediate proxy to request the WebRTC user agent to create a first data channel.

[0231] Exemplarily, a first application calls the createDataChannel and createOffer methods in the RTCPeerConnection API provided by the intermediary proxy to request the intermediary proxy to create a first data channel. After receiving the first application's request, the intermediary proxy determines whether the established connection can carry the first data channel. If the first of the established connections can carry the first data channel, the intermediary proxy may request the WebRTC user agent to add the stream corresponding to the first data channel to the first connection. For example, the intermediary proxy calls the createDataChannel and createOffer methods to request the addition of the stream corresponding to the first data channel to the first connection. If the established connection cannot carry the first data channel, the intermediary proxy may request the WebRTC user agent to create a new connection. For example, the intermediary proxy calls the RTCPeerConnection API, the createDataChannel and createOffer methods to request the WebRTC user agent to create a new connection, namely, a connection corresponding to the first data channel. In this case, the first request may specifically include at least one of the RTCPeerConnection command, the createDataChannel command, or the createOffer command sent by the intermediary proxy.

[0232] Scenario 2: The first communication device is the SDP responder.

[0233] As will be appreciated, after receiving the SDP proposal from the SDP proposer, the communication entity can send the SDP information related to the first application in the SDP proposal to the first application. After receiving the SDP information, the first application can invoke the API to trigger the first request. This is described below using Methods 2.1 to 2.3 as examples.

[0234] Method 2.1: The first application calls the RTCPeerConnection API, the createDataChannel method, and the createAnswer method to request the WebRTC user agent to create a first data channel. In this case, the first request may specifically include at least one of the RTCPeerConnection command, the createDataChannel command, or the createAnswer command.

[0235] The specific process of method 2.1 is Figure 1I The steps S106 to S109 are similar, and you can refer to the corresponding introductions in the above S106 to S109, which will not be described here.

[0236] Method 2.2: The first application calls the RTCPeerConnection API, the createDataChannel method, and the createAnswer method to request the WebRTC user agent to create a first data channel and indicate whether there is an existing connection that can carry the first data channel. In this case, the first request can specifically include at least one of the createDataChannel command and the createAnswer command.

[0237] As you can understand, the process of method 2.2 is similar to that of method 1.2, and you can refer to the corresponding description in the above method 1.2. The difference is that in method 1.2, the first application calls the createOffer method to create the SDPoffer, while in method 2.2, the first application calls the createAnswer method to create the SDP answer.

[0238] Method 2.3: The first application requests the WebRTC user agent to create a first data channel through the intermediate proxy.

[0239] One possible implementation method is that the first application calls the API provided by the intermediate proxy, triggering the intermediate proxy to request the WebRTC user agent to create a first data channel. For details, please refer to the corresponding description in the above method 1.3. The difference is that in method 1.2, the first application and the intermediate proxy call the createOffer method to create an SDP offer, and in method 2.2, the first application and the intermediate proxy call the createAnswer method to create an SDP answer. At this time, the first request can specifically include at least one of the RTCPeerConnection command, createDataChannel command or createAnswer command sent by the intermediate proxy.

[0240] In one possible implementation, after receiving the first request, the WebRTC user agent may determine whether the established connection can carry the first data channel.

[0241] For example, in the above-described methods 1.1 and 2.1, the WebRTC user agent may search for a connection among the established connections that can carry the first data channel. If a first connection that can carry the first data channel is found, the WebRTC user agent determines that the first connection can carry the first data channel. If no connection that can carry the first data channel is found, the WebRTC user agent determines that none of the established connections can carry the first data channel.

[0242] For example, with respect to Methods 1.2 and 2.2 above, if the first request includes information about the first connection, such as when the first application calls the createDataChannel method, the WebRTC user agent determines that the first connection can carry the first data channel. If the first request does not include information about the connection corresponding to the first data channel, such as when the first application calls the createDataChannel method, the WebRTC user agent determines that none of the created connections can carry the first data channel.

[0243] For example, with respect to Methods 1.3 and 2.3 above, if the WebRTC user agent detects that the intermediate proxy does not call the RTCPeerConnection API but instead directly calls the createDataChannel method corresponding to the first connection, the WebRTC user agent determines that the first connection can carry the first data channel. If the WebRTC user agent detects that the intermediate proxy calls the RTCPeerConnection API, the WebRTC user agent determines that none of the established connections can carry the first data channel.

[0244] It is understood that if there is an established connection, such as the first connection described above, that can carry the first data channel, the communication entity can instruct the first connection to be used to carry the first data channel. For example, the communication entity can execute S502A described below. If there is no established connection that can carry the first data channel, the communication entity can instruct the use of a new connection to carry the first data channel and create a new connection. For example, the communication entity can execute S502B described below.

[0245] S502A: The communication entity sends a response to the first request.

[0246] In one possible implementation, the WebRTC user agent sends a response to the first request. The response to the first request includes first media description information, the first media description information includes first indication information, and the first indication information indicates the first connection. For example, the first indication information includes IP address information, UDP port information, and SCTP port information. It is understandable that the first indication information indicates the IP address information, UDP port information, and SCTP port information associated with the first connection.

[0247] The following uses the above-mentioned methods 1.1 to 2.3 as examples to introduce the content included in the first media description information.

[0248] Exemplarily, for the above-mentioned methods 1.1, 1.2, 2.1, and 2.2, the WebRTC user agent sends the first media description information to the first application. The content included in the first media description information may be as shown in Table 6. The IP address in the first media description information is IN IP4192.0.2.1 (also the IP address associated with the first connection), the UDP port information is 10001 (also the UDP port information associated with the first connection), and the SCTP port information is 57483 (also the SCTP port information associated with the first connection). The first media description information shown in Table 6 also includes that the stream identifier (streamID) of the first data channel is 7384, and the first data channel is associated with application#1 (i.e., the first application).

[0249] Table 6

[0250]

[0251]

[0252] Exemplarily, for the above-mentioned methods 1.3 and 2.3, the WebRTC user agent sends the first media description information to the intermediate agent. The content included in the first media description information may be as shown in Table 7. The IP address in the first media description information is IN IP4 192.0.2.1 (also the IP address associated with the first connection), the UDP port information is 10001 (also the UDP port information associated with the first connection), and the SCTP port information is 57483 (also the SCTP port information associated with the first connection). The first media description information shown in Table 7 also includes the stream identifier of the first data channel as 7384, and the first data channel is associated with application#1 (i.e., the first application). It can be understood that the first connection is a connection created before S501, so before S501, the first connection has a corresponding data channel, such as the third data channel, which is used to transmit data of the third application. Therefore, the first media description information shown in Table 7 also includes the stream identifier of the third data channel as 7216, and the third data channel is associated with application#3 (i.e., the third application). That is, the third data channel and the first data channel share the first connection, or share one m-row (i.e., the media description information shown in Table 7). After receiving the first media description information, the intermediate proxy can send the seventh media description information to the first application. For example, the intermediate proxy deletes the information of applications other than the first application from the first media description, resulting in the seventh media description information shown in Table 8.

[0253] Table 7

[0254]

[0255] Table 8

[0256]

[0257] It is understood that after S502A, the communication entity may send the eighth media description information to the network side, and the network side may send the eighth media description information to the second communication device. The eighth media description information may include information about the connection corresponding to the first data channel and information about the connection corresponding to the third data channel. The eighth media description information also includes identification information (such as a flow identifier) ​​of the first data channel and identification information (such as a flow identifier) ​​of the third data channel. For example, the eighth media description information includes the content shown in Table 7. In Table 7, the connection information corresponding to the first data channel and the connection information corresponding to the third data channel both correspond to the content from "m=application 10001UDP / DTLS / SCTP webrtc-datachannel" to "a=tls-id:cd3bea56dced0f35d224". In other words, the data channel with flow ID 7216 (i.e., the third data channel) and the data channel with flow ID 7384 (i.e., the first data channel) can share the content from "m=application 10001UDP / DTLS / SCTP webrtc-datachannel" to "a=tls-id:cd3bea56dced0f35d224". Therefore, the number of media lines included in the eighth media description information can be reduced, thereby reducing the signaling overhead of the eighth media description information.

[0258] It is understood that for scenario 1 above, the eighth media description information is SDP offer information, which can be carried in a SIP request, such as an INVITE, UPDATE, or re-INVITE. For scenario 2 above, the eighth media description information is SDP answer information, which can be carried in a SIP response, such as an 18x response or a 200 OK response.

[0259] The following describes a situation where no established connection exists that can carry the first data channel.

[0260] S502B: The communication entity sends a response to the first request and creates a second connection.

[0261] In one possible implementation, the WebRTC user agent sends a response to the first request. The response to the first request includes second media description information. The second media description information includes second indication information. The second indication information indicates a second connection. For example, the second indication information includes IP address information, UDP port information, and SCTP information associated with the second connection. The second connection is the connection corresponding to the first data channel.

[0262] The following uses the above-mentioned methods 1.1 to 2.3 as examples to introduce the content included in the second media description information.

[0263] Exemplarily, for the above-mentioned methods 1.1, 1.2, 2.1, and 2.2, the WebRTC user agent sends the second media description information to the first application. The content included in the second media description information may be as shown in Table 9. The IP address in the second media description information is IN IP4 192.0.2.132 (also the IP address associated with the second connection), the UDP port information is 10011 (also the UDP port information associated with the second connection), and the SCTP port information is 57486 (also the SCTP port information associated with the second connection). The second media description information shown in Table 9 also includes that the stream identifier of the first data channel is 7388, and the first data channel is associated with application#1 (i.e., the first application). After receiving the second media description information, the first application calls an API, such as the setLocalDescription API, to trigger the WebRTC user agent to parse the second media description information and create a second connection.

[0264] Table 9

[0265]

[0266] For example, for the above methods 1.3 and 2.3, the WebRTC user agent sends the second media description information shown in Table 9 to the intermediate proxy. After receiving the second media description information, the intermediate proxy sends the second media description information to the first application. After receiving the second media description information, the first application can call an API to establish a second connection. For example, if the first application calls an API, such as the setLocalDescription API, the intermediate proxy can transparently pass the first application's call command to the WebRTC user agent, triggering the WebRTC user agent to parse the second media description information and establish a second connection.

[0267] It is understood that after S502B, the communication entity may send the ninth media description information to the network side, and the network side may send the ninth media description information to the second communication device. The ninth media description information may include information about the connection corresponding to the first data channel. The ninth media description information also includes identification information (such as a flow identifier) ​​of the first data channel. For example, the ninth media description information includes the content shown in Table 9.

[0268] It is understood that for scenario 1 above, the ninth media description information is SDP offer information, which can be carried in a SIP request, such as an INVITE, UPDATE, or re-INVITE. For scenario 2 above, the ninth media description information is SDP answer information, which can be carried in a SIP response, such as an 18x response or a 200OK response.

[0269] based on Figure 5 In the method shown, before establishing a first data channel, a communication entity can determine whether there is a connection among already established connections that can carry the first data channel. If there is a connection that can carry the first data channel, the first data channel can reuse that connection, thereby reducing resource overhead. It will be understood that the above-mentioned connection can be an SCTP coupling. SCTP coupling is associated with media resources, bandwidth resources, and port resources (such as port resources required for NAT traversal and firewall management). Therefore, reusing SCTP coupling can reduce media resource overhead, bandwidth resource overhead, and port resource overhead.

[0270] Optional, in Figure 5 In a possible implementation of the method shown, a second application different from the first application can request to create a second data channel, and the communication entity can determine whether to create a new connection based on whether the established connection can carry the second data channel, so as to reduce resource overhead. Figure 6 As shown, Figure 5 The method shown may further include the following steps:

[0271] S503: The communication entity receives the second request.

[0272] In the present application, the second request is used to request the creation of a second data channel. The second data channel is used to carry data of the second application. It can be understood that the second data channel is an ADC, the second application is a data channel application, and the second application is deployed on the first communication device. Optionally, the second data channel is a data channel between the first communication device and the second communication device. The second data channel is associated with the IMS session between the first communication device and the second communication device. For example, the second data channel is a logical connection in the IMS session, which is used to transmit data of the second application during the duration of the IMS session. For the introduction of the IMS session, ADC, and data channel application, please refer to the corresponding description above and will not be repeated here.

[0273] In this application, the second request may be triggered or sent by the second application on the first communication device, and accordingly, the WebRTC user agent on the first communication device receives the first request. In this case, the communication entity may be the WebRTC user agent on the first communication device, or other functional modules on the first communication device, without limitation. Assume that the first communication device adopts Figure 3DIf the terminal architecture shown in FIG. 1 is used, the second request may be sent by the second application to the WebRTC user agent in the data channel operating environment. Figure 3E In the terminal architecture shown, the second request may be sent by the second application triggering the intermediate proxy to the WebRTC user agent.

[0274] The following describes a process in which the communication entity receives the second request, taking the first communication device as an SDP proposer or an SDP responder as an example.

[0275] Scenario 3: The first communications device is the SDP proposer.

[0276] It is understandable that the second application can call the API to trigger the second request. The following methods 3.1 to 3.3 are used as examples for description.

[0277] Method 3.1: The second application calls the RTCPeerConnection API, the createDataChannel method, and the createOffer method to request the WebRTC user agent to create a second data channel. In this case, the second request may specifically include at least one of the RTCPeerConnection command, the createDataChannel command, or the createOffer command.

[0278] Method 3.2: The second application calls the RTCPeerConnection API, the createDataChannel method, and the createOffer method to request the WebRTC user agent to create a second data channel and indicate whether there is an existing connection that can carry the second data channel. In this case, the second request can specifically include at least one of the createDataChannel command and the createOffer command.

[0279] Method 3.3: The second application requests the WebRTC user agent to create a second data channel through the intermediate proxy. In this case, the second request may specifically include at least one of the RTCPeerConnection command, the createDataChannel command, or the createOffer command sent by the intermediate proxy.

[0280] It can be understood that the processes of the above-mentioned methods 3.1 to 3.3 are similar to the processes of methods 1.1 to 1.3 in scenario 1, and reference may be made to the corresponding descriptions in methods 1.1 to 1.3.

[0281] It is understandable that scenario 3 can be combined with scenario 1 above, indicating that when creating the first data channel and the second data channel, the first communication device is the party that sends the SDP offer. Scenario 3 can also be combined with scenario 2 above, indicating that when creating the first data channel, the first communication device is the party that sends the SDP answer, and when creating the second data channel, the first communication device is the party that sends the SDP offer. In addition, when scenario 3 is combined with scenario 1, methods 3.1 to 3.3 above can be combined with methods 1.1 to 1.3 respectively, and when scenario 3 is combined with scenario 2, methods 3.1 to 3.3 above can be combined with methods 2.1 to 2.3 respectively, without limitation.

[0282] Scenario 4: The first communication device is the SDP responder.

[0283] As will be appreciated, after receiving the SDP proposal from the SDP proposer, the communication entity can send the SDP information related to the second application in the SDP proposal to the second application. After receiving the SDP information, the second application can invoke the API to trigger the second request. This is described below using Methods 4.1 to 4.3 as examples.

[0284] Method 4.1: The second application calls the RTCPeerConnection API, the createDataChannel method, and the createAnswer method to request the WebRTC user agent to create a second data channel. In this case, the second request may specifically include at least one of the RTCPeerConnection command, the createDataChannel command, or the createAnswer command.

[0285] Method 4.2: The second application calls the RTCPeerConnection API, the createDataChannel method, and the createAnswer method to request the WebRTC user agent to create a second data channel and indicate whether there is an existing connection that can carry the second data channel. In this case, the second request can specifically include at least one of the createDataChannel command and the createAnswer command.

[0286] Method 4.3: The second application requests the WebRTC user agent to create a second data channel through the intermediate proxy. In this case, the second request may specifically include at least one of the RTCPeerConnection command, the createDataChannel command, or the createAnswer command sent by the intermediate proxy.

[0287] It can be understood that the processes of the above-mentioned methods 4.1 to 4.3 are similar to the processes of methods 2.1 to 2.3 in scenario 1, and reference may be made to the corresponding descriptions in methods 2.1 to 2.3.

[0288] It is understandable that scenario 4 can be combined with scenario 1 above, indicating that when creating the first data channel, the first communication device is the party that sends the SDP offer, and when creating the second data channel, the first communication device is the party that sends the SDP answer. Scenario 4 can also be combined with scenario 2 above, indicating that when creating both the first data channel and the second data channel, the first communication device is the party that sends the SDP answer. In addition, when scenario 4 is combined with scenario 1, methods 4.1 to 4.3 above can be combined with methods 1.1 to 1.3, respectively, and when scenario 4 is combined with scenario 2, methods 4.1 to 4.3 above can be combined with methods 2.1 to 2.3, respectively, without limitation.

[0289] It is understood that after receiving the second request, the WebRTC user agent can determine whether the established connection can carry the second data channel. This process is similar to the process in S501 where the WebRTC user agent determines whether the established connection can carry the first data channel after receiving the first request. Please refer to the corresponding description in S501 and will not be repeated here.

[0290] It is understandable that the communication entity may perform different operations for S502A and S502B. Specifically, for S502A, if there is an established connection, such as the first connection described above, that can carry the second data channel, the communication entity may instruct the first connection to carry the second data channel. For example, the communication entity may execute S504A described below. If there is no established connection that can carry the second data channel, the communication entity may instruct the use of a new connection to carry the second data channel and create a new connection. For example, the communication entity may execute S504C described below. For S502B, if there is an established connection, such as the second connection described above, that can carry the second data channel, the communication entity may instruct the use of the second connection to carry the second data channel. For example, the communication entity may execute S504B described below. If there is no established connection that can carry the second data channel, the communication entity may instruct the use of a new connection to carry the second data channel and create a new connection. For example, the communication entity may execute S504C described below. This is explained in detail below.

[0291] First, the case where the first connection can carry the second data channel is introduced.

[0292] Regarding S502A, if the first connection can carry the second data channel, the communication entity can execute S504A. That is, in the communication method provided in this application, the communication entity can execute S501, S502A, S503, and S504A. It will be understood that the first connection being able to carry the second data channel includes: the quality of service requirement of the second data channel being the same as the quality of service requirement of the first connection, or the quality of service requirement of the second data channel being lower than the quality of service requirement of the first connection. Optionally, the first connection being able to carry the second data channel also includes: the endpoint corresponding to the first connection is the same as the endpoint corresponding to the second data channel. The specific process of S504A is described below.

[0293] S504A: The communication entity sends a response to the second request, wherein the response to the second request includes fourth media description information.

[0294] In one possible implementation, the WebRTC user agent sends a response to the second request. The fourth media description information includes first indication information. The first indication information indicates a first connection. The first connection is a connection corresponding to the second data channel in the established connection.

[0295] Exemplarily, for the above-mentioned methods 3.1, 3.2, 4.1, and 4.2, the WebRTC user agent sends fourth media description information to the second application. The content included in the fourth media description information may be as shown in Table 10. The IP address in the fourth media description information is IN IP4 192.0.2.1 (also the IP address associated with the first connection), the UDP port information is 10001 (also the UDP port information associated with the first connection), and the SCTP port information is 57483 (also the SCTP port information associated with the first connection). The fourth media description information shown in Table 10 also includes that the stream identifier of the second data channel is 7380, and the second data channel is associated with application#2 (i.e., the second application).

[0296] Table 10

[0297]

[0298] Exemplarily, for the above-mentioned methods 3.3 and 4.3, the WebRTC user agent sends the fourth media description information to the intermediate agent. The content included in the fourth media description information can be as shown in Table 11. The IP address in the fourth media description information is IN IP4 192.0.2.1 (also the IP address associated with the first connection), the UDP port information is 10001 (also the UDP port information associated with the first connection), and the SCTP port information is 57483 (also the SCTP port information associated with the first connection). The fourth media description information shown in Table 11 also includes that the flow identifier of the second data channel is 7380, and the second data channel is associated with application#2 (i.e., the second application). The fourth media description information shown in Table 11 also includes that the flow identifier of the first data channel is 7384 and the flow identifier of the third data channel is 7216, and the first data channel is associated with application#1 (i.e., the first application), and the third data channel is associated with application#3 (i.e., the third application). That is, the first data channel, the second data channel, and the third data channel share the first connection, or share one m row (i.e., the media description information shown in Table 11). After receiving the fourth media description information, the intermediate agent can send the tenth media description information to the second application. For example, the intermediate agent deletes the information of applications other than the second application from the fourth media description, resulting in the tenth media description information shown in Table 12.

[0299] Table 11

[0300]

[0301] Table 12

[0302]

[0303] It can be understood that after S504A, the communication entity can send the eleventh media description information to the network side, and the network side can send the eleventh media description information to the remote endpoint, such as the second communication device. The eleventh media description information can include information about the connection corresponding to the first data channel, information about the connection corresponding to the second data channel, and information about the connection corresponding to the third data channel. The eleventh media description information also includes identification information (such as a flow identifier) ​​of the first data channel, identification information (such as a flow identifier) ​​of the second data channel, and identification information (such as a flow identifier) ​​of the third data channel. For example, the eleventh media description information includes the content shown in Table 11. In Table 11, the connection information corresponding to the first data channel, the connection information corresponding to the second data channel, and the connection information corresponding to the third data channel all correspond to the content from "m=application10001UDP / DTLS / SCTP webrtc-datachannel" to "a=tls-id:cd3bea56dced0f35d224". Therefore, the number of media lines included in the eleventh media description information can be reduced, thereby reducing the signaling overhead of the eleventh media description information.

[0304] It is understood that for scenario 3 above, the eleventh media description information is SDP offer information, which can be carried in a SIP request, such as an INVITE, UPDATE, or re-INVITE. For scenario 4 above, the eleventh media description information is SDP answer information, which can be carried in a SIP response, such as an 18x response or a 200OK response.

[0305] The following describes a situation where the second connection can carry the second data channel.

[0306] For S502B, if the second connection can carry the second data channel, the communication entity can execute S504B. That is to say, in the communication method provided in the present application, the communication entity can execute S501, S502B, S503 and S504B. It can be understood that the second connection can carry the second data channel, including: the quality of service requirement of the second data channel is the same as the quality of service requirement of the first data channel (or the quality of service requirement of the second connection); or, the quality of service requirement of the second data channel is lower than the quality of service requirement of the first data channel (or the quality of service requirement of the second connection). Optionally, the second connection can carry the second data channel, and also includes: the endpoint corresponding to the second data channel is the same as the endpoint corresponding to the first data channel (or the endpoint corresponding to the second connection), for example, the endpoint corresponding to the second data channel is also a communication entity and a second communication device. The specific process of S504B is introduced below.

[0307] S504B: The communication entity sends a response to the second request, wherein the response to the second request includes the fifth media description information.

[0308] In one possible implementation, the WebRTC user agent sends a response to the second request. The fifth media description information includes second indication information. The second indication information indicates a second connection. The second connection is a connection corresponding to the second data channel in the established connection.

[0309] Exemplarily, for the above-mentioned methods 3.1, 3.2, 4.1, and 4.2, the WebRTC user agent sends fifth media description information to the second application. The content included in the fifth media description information may be as shown in Table 13. The IP address in the fifth media description information is IN IP4 192.0.2.132 (also the IP address associated with the second connection), the UDP port information is 10011 (also the UDP port information associated with the second connection), and the SCTP port information is 57486 (also the SCTP port information associated with the second connection). The fifth media description information shown in Table 13 also includes that the stream identifier of the second data channel is 7485, and the second data channel is associated with application#2 (i.e., the second application).

[0310] Table 13

[0311]

[0312] Exemplarily, for the above-mentioned methods 3.3 and 4.3, the WebRTC user agent sends the fifth media description information to the intermediate agent. The content included in the fifth media description information can be as shown in Table 14. The IP address in the fifth media description information is IN IP4 192.0.2.132 (also the IP address associated with the second connection), the UDP port information is 10011 (also the UDP port information associated with the second connection), and the SCTP port information is 57486 (also the SCTP port information associated with the second connection). The fifth media description information shown in Table 14 also includes that the flow identifier of the second data channel is 7485, and the second data channel is associated with application#2 (i.e., the second application). The fifth media description information shown in Table 14 also includes that the flow identifier of the first data channel is 7388, and the first data channel is associated with application#1 (i.e., the first application). In other words, the first data channel and the second data channel share the second connection, or share one m row (i.e., the media description information shown in Table 14). After receiving the fifth media description information, the intermediate agent can send the twelfth media description information to the second application. For example, the intermediate agent deletes the information of the applications other than the second application in the fifth media description, and obtains the twelfth media description information as shown in Table 13 above.

[0313] Table 14

[0314]

[0315]

[0316] It can be understood that after S504B, the communication entity can send the sixth media description information to the network side, and the network side can send the sixth media description information to the remote endpoint, such as the second communication device. The sixth media description information may include the connection information corresponding to the first data channel and the connection information corresponding to the second data channel. The sixth media description information also includes identification information of the first data channel (such as a flow identifier) ​​and identification information of the second data channel (such as a flow identifier). For example, the sixth media description information includes the content shown in Table 14. In Table 14, the connection information corresponding to the first data channel and the connection information corresponding to the second data channel both correspond to the content from "m=application 10011UDP / DTLS / SCTPwebrtc-datachannel" to "a=tls-id:abc3de65cddef001be82". Therefore, the number of media lines included in the sixth media description information can be reduced, thereby reducing the signaling overhead of the sixth media description information.

[0317] It is understood that for scenario 3 above, the sixth media description information is SDP offer information, which can be carried in a SIP request, such as an INVITE, UPDATE, or re-INVITE. For scenario 4 above, the sixth media description information is SDP answer information, which can be carried in a SIP response, such as an 18x response or a 200OK response.

[0318] The following describes a situation where none of the created connections can carry the second data channel.

[0319] For S502A and S502B, if the created connection does not carry the second data channel, the communication entity can execute S504C. That is, in the communication method provided in the present application, the communication entity can execute S501, S502A, S503 and S504C; or the communication entity can execute S501, S502B, S503 and S504C. It can be understood that the second connection (or the first connection) cannot carry the second data channel, including: the service quality requirement of the second data channel is higher than the service quality requirement of the second connection (or the first connection). Optionally, the second connection (or the first connection) cannot carry the second data channel, and also includes: the endpoint corresponding to the second data channel is not exactly the same as the endpoint corresponding to the second connection (or the first connection). The specific process of S504C is introduced below.

[0320] S504C: The communication entity sends a response to the second request and creates a third connection, wherein the response to the second request includes the third media description information.

[0321] In one possible implementation, the WebRTC user agent sends a response to the second request. The third media description information includes third indication information corresponding to the second data channel. The third indication information indicates a third connection. For example, the third indication information includes IP address information, UDP port information, and SCTP information associated with the third connection. The third connection is the connection corresponding to the second data channel.

[0322] Exemplarily, for the above-mentioned methods 3.1, 3.2, 4.1, and 4.2, the WebRTC user agent sends third media description information to the second application. The content included in the third media description information may be as shown in Table 15. The IP address indicated by the third media description information is IN IP4 192.0.2.156 (also the IP address associated with the third connection), the UDP port information indicated is 10010 (also the UDP port information associated with the third connection), and the SCTP port information indicated is 57576 (also the SCTP port information associated with the third connection). The third media description information shown in Table 15 also indicates that the stream identifier of the second data channel is 7596, and the second data channel is associated with application#2 (i.e., the second application). After receiving the third media description information, the second application calls an API, such as the setLocalDescription API, to trigger the WebRTC user agent to parse the third media description information and create a third connection.

[0323] Table 15

[0324]

[0325] For example, for the above methods 3.3 and 4.3, the WebRTC user agent sends the third media description information shown in Table 15 to the intermediate proxy. After receiving the third media description information, the intermediate proxy sends the third media description information to the second application. After receiving the third media description information, the second application can call an API to establish a third connection. For example, if the second application calls an API, such as the setLocalDescription API, the intermediate proxy can transparently pass the second application's call command to the WebRTC user agent, triggering the WebRTC user agent to parse the third media description information and establish a third connection.

[0326] It is understood that after S504C, the communication entity may send the thirteenth media description information to the network side, and the network side may send the thirteenth media description information to the remote endpoint, such as the second communication device. The thirteenth media description information may include information about the connection corresponding to the second data channel. The thirteenth media description information may also include identification information (such as a flow identifier) ​​of the second data channel. For example, the thirteenth media description information includes the content shown in Table 15.

[0327] It is understood that for scenario 3 above, the thirteenth media description information is SDP offer information, which can be carried in a SIP request, such as an INVITE, UPDATE, or re-INVITE. For scenario 4 above, the thirteenth media description information is SDP answer information, which can be carried in a SIP response, such as an 18x response or a 200OK response.

[0328] Understandably, Figure 5 or Figure 6 The actions of the communication entities in the method shown can be performed by Figure 4 The processor 401 in the communication device 40 shown calls the application code stored in the memory 403 for execution, and this application does not impose any limitation on this.

[0329] The above describes the process of triggering the creation of a data channel between the first application and the second application from the perspective of a communication entity. To better understand the method provided by this application, the following describes the process of negotiating a data channel between the first terminal and the second terminal from the perspective of interaction between the two.

[0330] First, let's take the first terminal as the SDP proposer and the second terminal as the SDP responder. The first terminal uses method 1.1 to create the first data channel and method 3.1 to create the second data channel. The second terminal uses method 2.1 to create the first data channel and method 4.1 to create the second data channel as an example. Figure 3D The terminal architecture shown.

[0331] like Figure 7 As shown, another communication method provided by the present application may include the following steps:

[0332] S701: A first application in a first terminal calls an RTCPeerConnection API to request a WebRTC user agent in the first terminal to create an RTCPeerConnection instance.

[0333] S702: A first application in a first terminal calls a createDataChannel method to request creation of a data channel on an RTCPeerConnection instance (or object).

[0334] S703: The first application in the first terminal calls the createOffer method to request the WebRTC user agent in the first terminal to generate a media description and return it to the first application.

[0335] It is understood that the first request can be at least one of the RTCPeerConnection command, the createDataChannel command, or the createOffer command. After receiving the first request, the WebRTC user agent can determine whether the established connection can carry the first data channel. The specific processes of S701 to S703 are similar to those of S101 to S103. Please refer to the corresponding descriptions of S101 to S103.

[0336] S704: If there is no established connection that can carry the first data channel, the WebRTC user agent in the first terminal returns second media description information to the first application to indicate the second connection.

[0337] Illustratively, the second media description information may include content as shown in Table 9.

[0338] S705: The first application of the first terminal calls the setLocalDescription API to trigger the WebRTC user agent to parse the second media description information and create a second connection, for example, to create local resources for receiving and decoding media, set parameters of the first data channel, etc.

[0339] S706: The first application of the first terminal calls the RTCPeerSignallingService API to trigger the first terminal to send a first SDP offer to the second terminal via the IMS network. Correspondingly, the second terminal receives the first SDP offer.

[0340] The first SDP offer may include ninth media description information.

[0341] S707: The WebRTC user agent of the second terminal sends the media description information related to the first application in the ninth media description information to the first application of the second terminal through the RTCPeerSignallingService API.

[0342] Illustratively, the media description information sent by the WebRTC user agent of the second terminal to the first application may be as shown in Table 9.

[0343] S708: The first application of the second terminal calls the RTCPeerConnection API to request the WebRTC user agent in the second terminal to create an RTCPeerConnection instance.

[0344] S709: The first application of the second terminal calls the setRemoteDescription API to apply the received media description information.

[0345] S710: The first application in the second terminal calls the createDataChannel method to request creation of a data channel on the RTCPeerConnection instance (or object).

[0346] S711: The first application of the second terminal calls the createAnswer method to request the WebRTC user agent in the second terminal to generate a media description and return it to the first application.

[0347] It can be understood that the above S708 and S710 to S711 are used for the first application in the second terminal to request to create the first data channel, and the WebRTC user agent of the second terminal can determine whether the created connection can carry the first data channel.

[0348] S712: If there is no established connection that can carry the first data channel, the WebRTC user agent in the second terminal returns fourteenth media description information to the first application to indicate the second connection.

[0349] It is understandable that any connection in this application (such as the first connection, the second connection, or the third connection, etc.) is established through negotiation between the two endpoints of the connection. In other words, each endpoint can configure a set of protocol address information and protocol port information for the connection. Therefore, the connection can be associated with two sets of protocol address information and protocol port information. Taking the second connection here as an example, the two endpoints of the second connection are the first terminal and the second terminal. The first terminal configures a set of protocol address information and protocol port information for the second connection in S704 above, which is used for the first terminal to receive / send data through the second connection. The second terminal configures a set of protocol address information and protocol port information for the second connection in S712, which is used for the second terminal to receive / send data through the second connection. It is understandable that these two sets of protocol addresses can be different, and these two sets of protocol port numbers can also be different. Therefore, the content included in the fourteenth media description information is similar to the content included in the second media description information, wherein the specific values ​​of the parameters can be different, such as the IP address, UDP port number, and SCTP port number.

[0350] S713: The first application of the second terminal calls the setLocalDescription API to trigger the WebRTC user agent to parse the fourteenth media description information and create a second connection, for example, to create local resources for receiving and decoding media, set parameters of the first data channel, etc.

[0351] S714: The first application of the second terminal calls the RTCPeerSignallingService API to trigger the second terminal to send a first SDP answer to the first terminal via the IMS network. Correspondingly, the first terminal receives the first SDP answer.

[0352] The first SDP answer may include fifteenth media description information. The fifteenth media description information includes information about the second connection and identification information of the first data channel established by the second terminal. The second connection information here may include IP protocol address information, UDP port information, and SCTP port information configured by the second terminal for the second connection.

[0353] S715: The WebRTC user agent of the first terminal sends the media description information related to the first application in the fifteenth media description information to the first application of the first terminal through the RTCPeerSignallingService API.

[0354] S716: The first application of the first terminal calls the setRemoteDescription API to set the resources configured by the second terminal for the first data channel.

[0355] It is understandable that after S716, the WebRTC user agents of the first terminal and the second terminal can create a second connection and corresponding streams. The first applications of the first terminal and the second terminal can send data to the application layer or receive data from the application layer through the second connection.

[0356] S717: The second application in the first terminal calls the RTCPeerConnection API to request the WebRTC user agent in the first terminal to create an RTCPeerConnection instance.

[0357] S718: The second application in the first terminal calls the createDataChannel method to request creation of a data channel on the RTCPeerConnection instance (or object).

[0358] S719: The second application in the first terminal calls the createOffer method to request the WebRTC user agent in the first terminal to generate a media description and return it to the second application.

[0359] It can be understood that the above S717 to S719 are used for the second application to request to create a second data channel, and the WebRTC user agent can determine whether the established connection can carry the second data channel.

[0360] S720: If the second connection can carry the second data channel, the WebRTC user agent in the first terminal returns fifth media description information to the second application, indicating the second connection.

[0361] Illustratively, the content included in the fifth media description information may be as shown in Table 13.

[0362] S721: The second application of the first terminal calls the setLocalDescription API to trigger the WebRTC user agent to apply the fifth media description information.

[0363] S722: The second application of the first terminal calls the RTCPeerSignallingService API to trigger the first terminal to send a second SDP offer to the second terminal via the IMS network. Correspondingly, the second terminal receives the second SDP offer.

[0364] The second SDP offer may include sixth media description information.

[0365] S723: The WebRTC user agent of the second terminal sends the media description information related to the second application in the sixth media description information to the second application of the second terminal through the RTCPeerSignallingService API.

[0366] Illustratively, the media description information sent by the WebRTC user agent of the second terminal to the second application may be as shown in Table 13.

[0367] S724: The second application of the second terminal calls the RTCPeerConnection API to request the WebRTC user agent in the second terminal to create an RTCPeerConnection instance.

[0368] S725: The second application of the second terminal calls the setRemoteDescription API to apply the received media description information.

[0369] S726: The second application in the second terminal calls the createDataChannel method to request creation of a data channel on the RTCPeerConnection instance (or object).

[0370] S727: The second application of the second terminal calls the createAnswer method to request the WebRTC user agent in the second terminal to generate a media description and return it to the second application.

[0371] It can be understood that the above S724, S726 to S727 are used by the second application to request to create the second data channel, and the WebRTC user agent of the second terminal can determine whether the established connection can carry the second data channel.

[0372] S728: If the second connection can carry the second data channel, the WebRTC user agent in the second terminal returns the sixteenth media description information to the second application to indicate the second connection.

[0373] It can be understood that the content included in the sixteenth media description information is similar to the content included in the fifth media description information, wherein the specific values ​​of the parameters may be different, such as the IP address, UDP port number and SCTP port number.

[0374] S729: The second application of the second terminal calls the setLocalDescription API to trigger the WebRTC user agent to apply the sixteenth media description information.

[0375] S730: The second application of the second terminal calls the RTCPeerSignallingService API to trigger the second terminal to send a second SDP answer to the first terminal via the IMS network. Correspondingly, the first terminal receives the second SDP answer.

[0376] The second SDP answer may include seventeenth media description information. The seventeenth media description information includes information about the second connection, identification information of the first data channel created by the second terminal, and identification information of the second data channel created by the second terminal. The second connection information here may include IP protocol address information, UDP port information, and SCTP port information configured by the second terminal for the second connection.

[0377] S731: The WebRTC user agent of the first terminal sends the media description information related to the second application in the seventeenth media description information to the second application of the first terminal through the RTCPeerSignallingService API.

[0378] S732: The second application of the first terminal calls the setRemoteDescription API to set the resources configured by the second terminal for the second data channel.

[0379] S733: The WebRTC user agent of the first terminal updates the second connection and adds a stream corresponding to the second data channel to the second connection. The WebRTC user agent of the second terminal updates the second connection and adds a stream corresponding to the second data channel to the second connection.

[0380] It is understandable that after S733, the first application and the second application in the first terminal can both send data to the application layer or receive data from the application layer through the second connection. Similarly, the first application and the second application in the second terminal can both send data to the application layer or receive data from the application layer through the second connection.

[0381] It is understandable that the actions of the first terminal or the second terminal in the above steps can be Figure 4 The processor 401 in the communication device 40 shown calls the application code stored in the memory 403 for execution, and this application does not impose any limitation on this.

[0382] based on Figure 7 In the method shown, before creating a data channel, the WebRTC user agents of the first terminal and the second terminal can determine whether there is a connection that can carry the data channel among the established connections, so as to reduce resource overhead.

[0383] The following example illustrates the first terminal as the SDP proposer and the second terminal as the SDP responder. The first terminal uses method 1.2 to create the first data channel, and the second terminal uses method 2.2 to create the first data channel. Figure 3D The terminal architecture shown.

[0384] like Figure 8 As shown, another communication method provided by the present application may include the following steps:

[0385] S801: A first application in a first terminal calls an RTCPeerConnection API to request a WebRTC user agent in the first terminal to create an RTCPeerConnection instance.

[0386] S802: The WebRTC user agent in the first terminal sends information about the created connection to the first application.

[0387] For example, the WebRTC user agent in the first terminal can provide a query interface to the first application for querying established connections. When the first application calls the query interface, the WebRTC user agent returns information about established connections to the first application. The established connection information indicates each established connection, such as the IP address, UDP port information, and SCTP port information associated with each connection.

[0388] It is understandable that the first application may also call the interface to query the created connection before S801 without limitation.

[0389] S803: The first application in the first terminal determines whether the created connection can carry the first data channel.

[0390] S804: If the first connection among the created connections can carry the first data channel, the first application in the first terminal calls the createDataChannel method and carries information about the first connection when calling the method.

[0391] S805: The first application in the first terminal calls the createOffer method to request the WebRTC user agent in the first terminal to generate a media description and return it to the first application.

[0392] It is understandable that because the first application carries the first connection information when calling the createDataChannel method, the WebRTC user agent determines to use the first connection to carry the first data channel. It is also understandable that in a specific application, the first application may not carry the first connection information when calling the createDataChannel method, but instead carry the first connection information when calling the createOffer method.

[0393] S806: The WebRTC user agent in the first terminal returns first media description information to the first application to indicate the first connection.

[0394] Illustratively, the content included in the first media description information may be as shown in Table 6.

[0395] S807: The first application of the first terminal calls the setLocalDescription API to trigger the WebRTC user agent to apply the first media description information.

[0396] S808: The first application of the first terminal calls the RTCPeerSignallingService API to trigger the first terminal to send a first SDP offer to the second terminal via the IMS network. Correspondingly, the second terminal receives the first SDP offer.

[0397] The first SDP offer may include eighth media description information.

[0398] S809: The WebRTC user agent of the second terminal sends the media description information related to the first application in the eighth media description information to the first application of the second terminal through the RTCPeerSignallingService API.

[0399] Illustratively, the media description information sent by the WebRTC user agent of the second terminal to the first application may be as shown in Table 6.

[0400] S810: The first application of the second terminal calls the RTCPeerConnection API to request the WebRTC user agent in the second terminal to create an RTCPeerConnection instance.

[0401] S811: The first application of the second terminal calls the setRemoteDescription API to apply the received media description information.

[0402] S812: The WebRTC user agent in the second terminal sends information about the created connection to the first application.

[0403] For example, the WebRTC user agent in the second terminal can provide a query interface to the first application for querying established connections. When the first application calls the query interface, the WebRTC user agent returns information about established connections to the first application. The established connection information indicates each established connection, such as the IP address, UDP port information, and SCTP port information associated with each connection.

[0404] It is understandable that the first application may also call the interface to query the created connection before S811 without limitation.

[0405] S813: The first application in the second terminal determines whether the created connection can carry the first data channel.

[0406] S814: If the first connection among the created connections can carry the first data channel, the first application in the second terminal calls the createDataChannel method and carries information about the first connection when calling the method.

[0407] It can be understood that the first connection is a connection corresponding to the first data channel in the connections created by the second terminal.

[0408] S815: The first application of the second terminal calls the createAnswer method to request the WebRTC user agent in the second terminal to generate a media description and return it to the first application.

[0409] It is understandable that because the first application carries the first connection information when calling the createDataChannel method, the WebRTC user agent determines to use the first connection to carry the first data channel. It is also understandable that in a specific application, the first application may not carry the first connection information when calling the createDataChannel method, but instead carry the first connection information when calling the createAnswer method.

[0410] S816: The WebRTC user agent in the second terminal returns the eighteenth media description information to the first application to indicate the first connection.

[0411] It can be understood that the content included in the eighteenth media description information is similar to the content included in the first media description information, and the specific values ​​of the parameters may be different, such as the IP address, UDP port number and SCTP port number.

[0412] S817: The first application of the second terminal calls the setLocalDescription API to trigger the WebRTC user agent to apply the eighteenth media description information.

[0413] S818: The first application of the second terminal calls the RTCPeerSignallingService API to trigger the second terminal to send a first SDP answer to the first terminal via the IMS network. Correspondingly, the first terminal receives the first SDP answer.

[0414] The first SDP answer may include nineteenth media description information. The nineteenth media description information includes information about the first connection and identification information of the first data channel established by the second terminal. The information about the first connection may include IP protocol address information, UDP port information, and SCTP port information configured by the second terminal for the first connection.

[0415] S819: The WebRTC user agent of the first terminal sends the media description information related to the first application in the nineteenth media description information to the first application of the first terminal through the RTCPeerSignallingService API.

[0416] S820: The first application of the first terminal calls the setRemoteDescription API to set resources configured by the second terminal for the first data channel.

[0417] S821: The WebRTC user agent of the first terminal updates the first connection and adds a stream corresponding to the first data channel to the first connection. The WebRTC user agent of the second terminal updates the first connection and adds a stream corresponding to the first data channel to the first connection.

[0418] It can be understood that after S821, the first application in the first terminal can send data to the application layer or receive data from the application layer through the first connection, and the first application in the second terminal can send data to the application layer or receive data from the application layer through the first connection.

[0419] It is understandable that the actions of the first terminal or the second terminal in the above steps can be Figure 4 The processor 401 in the communication device 40 shown calls the application code stored in the memory 403 for execution, and this application does not impose any limitation on this.

[0420] based on Figure 8 In the method shown, the WebRTC user agents of the first terminal and the second terminal can open interfaces to the first application for the first application to query the established connection so that the first application can determine whether the established connection can carry the data channel requested to be created, thereby reducing resource overhead. Figure 8 This description uses the example of a first application determining that the first of the established connections can carry the data channel it requested. It will be appreciated that if the first application determines that the established connection cannot carry the data channel it requested, the WebRTC user agent can generate a new "m line" (such as the second media description information shown in Table 9) and return it to the first application.

[0421] The following example illustrates the first terminal as the SDP proposer and the second terminal as the SDP responder. The first terminal uses method 1.3 to create the first data channel and method 3.3 to create the second data channel. The second terminal uses method 2.3 to create the first data channel and method 4.3 to create the second data channel. Figure 3E The terminal architecture shown.

[0422] like Figure 9 As shown, another communication method provided by the present application may include the following steps:

[0423] S901: A first application in a first terminal calls an RTCPeerConnection API to request an intermediate agent in the first terminal to create an RTCPeerConnection instance.

[0424] S902: A first application in a first terminal calls a createDataChannel method to request creation of a data channel on an RTCPeerConnection instance (or object).

[0425] S903: The first application in the first terminal calls the createOffer method to request the intermediate agent in the first terminal to generate a media description and return it to the first application.

[0426] It can be understood that the RTCPeerConnection API, the createDataChannel method, and the createOffer method are used to request the creation of the first data channel. The specific process of S901 to S903 is similar to the process of S101 to S103, and reference can be made to the corresponding descriptions of S101 to S103.

[0427] S904: The intermediate agent of the first terminal determines whether the established connection can carry the first data channel.

[0428] S905: If there is no established connection that can carry the first data channel, the intermediate agent in the first terminal calls the RTCPeerConnection API to request the WebRTC user agent of the first terminal to create an RTCPeerConnection instance.

[0429] S906: The intermediate agent of the first terminal calls the createDataChannel method to request creation of a data channel on the RTCPeerConnection instance (or object).

[0430] S907: The intermediate agent of the first terminal calls the createOffer method to request the WebRTC user agent in the first terminal to generate a media description and return it to the first application.

[0431] It is understandable that the first request may be at least one of the RTCPeerConnection command, the createDataChannel command, or the createOffer command. The specific processes of S905 to S907 are similar to those of S101 to S103, and reference may be made to the corresponding descriptions of S101 to S103.

[0432] S908: The WebRTC user agent of the first terminal sends second media description information to the first application through the intermediate proxy to indicate the second connection.

[0433] Illustratively, the second media description information may include content as shown in Table 9.

[0434] S909: The first application of the first terminal calls the setLocalDescription API to trigger the WebRTC user agent to parse the second media description information and create a second connection, for example, to create local resources for receiving and decoding media, set parameters of the first data channel, etc.

[0435] It is understandable that the intermediate agent of the first terminal can transparently transmit the calling command of the first application to the WebRTC user agent.

[0436] S910: A first application of a first terminal calls an RTCPeerSignallingService API to trigger the first terminal to send a first SDP offer to a second terminal via an IMS network. Correspondingly, the second terminal receives the first SDP offer.

[0437] The first SDP offer may include ninth media description information.

[0438] It is understandable that S910 may also be triggered by an intermediate agent without limitation.

[0439] S911: The WebRTC user agent of the second terminal sends the media description information related to the first application in the ninth media description information to the first application of the second terminal through the RTCPeerSignallingService API.

[0440] Illustratively, the media description information sent by the WebRTC user agent of the second terminal to the first application may be as shown in Table 9.

[0441] It is understandable that the intermediate agent of the second terminal can transparently transmit the information sent by the WebRTC user agent to the first application.

[0442] S912: The first application of the second terminal calls the RTCPeerConnection API to request the intermediate agent of the second terminal to create an RTCPeerConnection instance.

[0443] S913: The first application of the second terminal calls the setRemoteDescription API to apply the received media description information.

[0444] It is understandable that the setRemoteDescription command called by the first application can be transparently transmitted to the WebRTC user agent through the intermediate proxy.

[0445] S914: The first application in the second terminal calls the createDataChannel method to request the intermediate agent of the second terminal to create a data channel on the RTCPeerConnection instance (or object).

[0446] S915: The first application of the second terminal calls the createAnswer method to request the intermediate agent of the second terminal to generate a media description and return it to the first application.

[0447] It can be understood that the above S912, S914 to S915 are used by the first application of the second terminal to request to create the first data channel.

[0448] S916: The intermediate agent of the second terminal may determine whether the created connection can carry the first data channel.

[0449] S917: If there is no established connection that can carry the first data channel, the intermediate agent of the second terminal calls the RTCPeerConnection API to request the WebRTC user agent in the second terminal to create an RTCPeerConnection instance.

[0450] S918: The intermediate agent of the second terminal calls the createDataChannel method to request to create a data channel on the RTCPeerConnection instance (or object).

[0451] S919: The intermediate agent of the second terminal calls the createAnswer method to request the WebRTC user agent in the second terminal to generate a media description and return it to the first application.

[0452] S920: The WebRTC user agent in the second terminal returns the fourteenth media description information to the first application through the intermediate proxy to indicate the second connection.

[0453] It can be understood that the content included in the fourteenth media description information is similar to the content included in the second media description information, and the specific values ​​of the parameters may be different, such as the IP address, UDP port number and SCTP port number.

[0454] S921: The first application of the second terminal calls the setLocalDescription API to trigger the WebRTC user agent to parse the fourteenth media description information and create a second connection, for example, to create local resources for receiving and decoding media, set parameters of the first data channel, etc.

[0455] It is understandable that the intermediate proxy can transparently transmit the setLocalDescription call command of the first application to the WebRTC user agent.

[0456] S922: The first application of the second terminal calls the RTCPeerSignallingService API to trigger the second terminal to send a first SDP answer to the first terminal via the IMS network. Correspondingly, the first terminal receives the first SDP answer.

[0457] The first SDP answer may include fifteenth media description information. The fifteenth media description information includes information about the second connection and identification information of the first data channel established by the second terminal. The second connection information here may include IP protocol address information, UDP port information, and SCTP port information configured by the second terminal for the second connection.

[0458] It is understandable that S922 may also be triggered by an intermediate agent without limitation.

[0459] S923: The WebRTC user agent of the first terminal sends the media description information related to the first application in the fifteenth media description information to the first application of the first terminal through the RTCPeerSignallingService API.

[0460] It is understandable that the intermediate agent of the first terminal can transparently transmit the information sent by the WebRTC user agent to the first application.

[0461] S924: The first application of the first terminal calls the setRemoteDescription API to set resources configured by the second terminal for the first data channel.

[0462] It is understandable that the setRemoteDescription command of the first application can be transparently transmitted to the WebRTC user agent through the intermediate proxy.

[0463] It is understood that after S924, the WebRTC user agents of the first terminal and the second terminal can establish a second connection and corresponding streams. The intermediate agent of the first terminal can receive data through the second connection and distribute the data to the first application, and the intermediate agent of the second terminal can receive data through the second connection and distribute the data to the first application.

[0464] S925: The second application in the first terminal calls the RTCPeerConnection API to request the intermediate agent of the first terminal to create an RTCPeerConnection instance.

[0465] S926: The second application in the first terminal calls the createDataChannel method to request creation of a data channel on the RTCPeerConnection instance (or object).

[0466] S927: The second application in the first terminal calls the createOffer method to request the intermediate agent of the first terminal to generate a media description and return it to the second application.

[0467] It can be understood that the RTCPeerConnection API, createDataChannel method and createOffer method are used to request the creation of the second data channel. The specific process of S925 to S927 is similar to the process of S101 to S103, and reference can be made to the corresponding descriptions of S101 to S103.

[0468] S928: The intermediate agent of the first terminal determines whether the established connection can carry the second data channel.

[0469] S929: If the second connection can carry the second data channel, the intermediate agent of the first terminal calls the createDataChannel method to request the WebRTC user agent to create a data channel on the second connection.

[0470] S930: The intermediate agent of the first terminal calls the createOffer method to request the WebRTC user agent in the first terminal to generate a media description and return it to the second application.

[0471] S931: The WebRTC user agent in the first terminal returns fifth media description information to the intermediate proxy.

[0472] Illustratively, the content included in the fifth media description information may be as shown in Table 14.

[0473] S932: The intermediate agent in the first terminal sends the twelfth media description information to the second application. For example, the intermediate agent deletes the information of the applications other than the second application in the fifth media description to obtain the twelfth media description information as shown in Table 13.

[0474] S933: The second application of the first terminal calls the setLocalDescription API to trigger the WebRTC user agent to apply the fifth media description information.

[0475] It is understandable that the intermediate agent of the first terminal can transparently transmit the setLocalDescription command of the second application to the WebRTC user agent.

[0476] S934: The second application of the first terminal calls the RTCPeerSignallingService API to trigger the first terminal to send a second SDP offer to the second terminal via the IMS network. Correspondingly, the second terminal receives the second SDP offer.

[0477] The second SDP offer may include sixth media description information.

[0478] S935: The WebRTC user agent of the second terminal sends the media description information related to the second application in the sixth media description information to the second application of the second terminal through the RTCPeerSignallingService API.

[0479] Illustratively, the media description information sent by the WebRTC user agent of the second terminal to the second application may be as shown in Table 13.

[0480] It is understandable that the intermediate agent of the second terminal can transparently transmit the information sent by the WebRTC user agent to the second application.

[0481] S936: The second application of the second terminal calls the RTCPeerConnection API to request the intermediate agent in the second terminal to create an RTCPeerConnection instance.

[0482] S937: The second application of the second terminal calls the setRemoteDescription API to apply the received media description information.

[0483] It is understandable that the intermediate agent of the second terminal may transparently transmit the setRemoteDescription command of the second application to the WebRTC user agent.

[0484] S938: The second application in the second terminal calls the createDataChannel method to request the intermediate agent to create a data channel on the RTCPeerConnection instance (or object).

[0485] S939: The second application of the second terminal calls the createAnswer method to request the intermediate agent in the second terminal to generate a media description and return it to the second application.

[0486] It can be understood that the above S936, S938 to S939 are used by the second application to request the creation of the second data channel.

[0487] S940: The intermediate agent of the second terminal may determine whether the established connection can carry the second data channel.

[0488] S941: If the second connection can carry the second data channel, the intermediate agent of the second terminal calls the createDataChannel method to request the WebRTC user agent to create a data channel on the second connection.

[0489] S942: The intermediate agent of the second terminal calls the createAnswer method to request the WebRTC user agent in the second terminal to generate a media description and return it to the second application.

[0490] S943: The WebRTC user agent in the second terminal returns twentieth media description information to the intermediate proxy to indicate the second connection.

[0491] It can be understood that the content included in the twentieth media description information is similar to the content included in the fifth media description information, wherein the specific values ​​of the parameters may be different, such as the IP address, UDP port number and SCTP port number.

[0492] S944: The intermediate agent in the second terminal returns the twenty-first media description information to the second application. For example, the intermediate agent deletes the information of the applications other than the second application in the twentieth media description to obtain the twenty-first media description information.

[0493] S945: The second application of the second terminal calls the setLocalDescription API to trigger the WebRTC user agent to apply the twentieth media description information.

[0494] It is understandable that the intermediate agent of the second terminal can transparently transmit the setLocalDescription command of the second application to the WebRTC user agent.

[0495] S946: The second application of the second terminal calls the RTCPeerSignallingService API to trigger the second terminal to send a second SDP answer to the first terminal via the IMS network. Correspondingly, the first terminal receives the second SDP answer.

[0496] The second SDP answer may include 22nd media description information. The 22nd media description information includes information about the second connection, identification information of the first data channel created by the second terminal, and identification information of the second data channel created by the second terminal. The second connection information here may include IP protocol address information, UDP port information, and SCTP port information configured by the second terminal for the second connection.

[0497] S947: The WebRTC user agent of the first terminal sends the media description information related to the second application in the twenty-second media description information to the second application of the first terminal through the RTCPeerSignallingService API.

[0498] S948: The second application of the first terminal calls the setRemoteDescription API to set the resources configured by the second terminal for the second data channel.

[0499] It is understandable that the setRemoteDescription command of the first application can be transparently transmitted to the WebRTC user agent through the intermediate proxy.

[0500] S949: The WebRTC user agent of the first terminal updates the second connection, adds a stream corresponding to the second data channel in the second connection, and the WebRTC user agent of the second terminal updates the second connection, and adds a stream corresponding to the second data channel in the second connection.

[0501] It can be understood that after S949, the intermediate agent of the first terminal can receive data through the second connection and distribute the data to the first application or the second application, and the intermediate agent of the second terminal can receive data through the second connection and distribute the data to the first application or the second application.

[0502] It is understandable that the actions of the first terminal or the second terminal in the above steps can be Figure 4 The processor 401 in the communication device 40 shown calls the application code stored in the memory 403 for execution, and this application does not impose any limitation on this.

[0503] based on Figure 9 In the method shown, before creating a data channel, the intermediate agent in the first terminal and the second terminal can determine whether there is a connection that can carry the data channel in the created connections to reduce resource overhead. In other words, the intermediate agent can have the function of managing connections. In addition to the function of managing connections, the intermediate agent also has the function of distributing data. For example, the intermediate agent can distribute the received data to the corresponding application. When the application needs to send data, it can be sent uniformly through the intermediate agent. It can be understood that for Figure 9 The method shown does not require updating the functionality of the WebRTC user agent, so it is easy to deploy the method on the terminal.

[0504] The various embodiments mentioned above in this application can be combined without limitation if there is no contradiction between the solutions.

[0505] The above mainly introduces the solution provided by the present application from the perspective of the interaction between various network elements. Accordingly, the present application also provides a communication device, which can be the communication entity in the above method embodiment, or a device including the above communication entity, or a component that can be used for the communication entity. It can be understood that in order to implement the above functions, the above communication entity includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm operations of the various examples described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0506] The present application can divide the communication entity into functional modules based on the above method examples. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or software functional modules. It is understood that the division of modules in this application is schematic and is only a logical functional division. In actual implementation, other division methods may be used.

[0507] For example, when the functional modules are divided in an integrated manner, Figure 10 The following is a schematic diagram of the structure of a communication device 100. Communication device 100 includes a processing module 1001 and an interface module 1002. Processing module 1001, also known as a processing unit, is used to perform operations other than transceiver operations and may be, for example, a processing circuit or processor. Interface module 1002, also known as an interface unit, is used to perform transceiver operations and may be, for example, an interface circuit, a transceiver, a transceiver, or a communication interface.

[0508] In some embodiments, the communication device 100 may further include a storage module ( Figure 10 ), for storing program instructions and data.

[0509] Exemplarily, the communication device 100 is used to implement the functions of a communication entity. Figure 5 The embodiment shown or Figure 6 The communication entity described in the embodiment shown.

[0510] Interface module 1002 is configured to receive a first request. The first request is configured to request the creation of a first data channel, where the first data channel is a data channel between communication device 100 and a second communication device and is configured to carry data of a first application. The first data channel is associated with an IMS session between communication device 100 and the second communication device. For example, interface module 1002 may be configured to execute S501.

[0511] Processing module 1001 is configured to, if there is an established connection that can carry the first data channel, control interface module 1002 to send a response to the first request, the response including first media description information, the first media description information including first indication information, the first indication information indicating a first connection, the first connection being the connection corresponding to the first data channel in the established connection; for example, processing module 1001 can be configured to execute S502A. Alternatively, processing module 1001 is configured to, if there is no established connection that can carry the first data channel, control interface module 1002 to send a response to the first request and create a second connection, the response including second media description information, the second media description information including second indication information, the second indication information indicating a second connection, the second connection being the connection corresponding to the first data channel. For example, processing module 1001 can be configured to execute S502B.

[0512] In a possible implementation, the first indication information includes: Internet Protocol address information, User Datagram Protocol port information, and Stream Control Transmission Protocol port information.

[0513] In one possible implementation, the interface module 1002 is further used to receive a second request, where the second request is used to request the creation of a second data channel, where the second data channel is used to carry data of a second application, which is different from the first application. If the established connection cannot carry the second data channel, the processing module 1001 is further used to control the interface module 1002 to send a response to the second request and create a third connection, where the response to the second request includes third media description information, where the third media description information includes third indication information corresponding to the second data channel, where the third indication information indicates the third connection. Alternatively, if the first connection can carry the second data channel, the processing module 1001 is further used to control the interface module 1002 to send a response to the second request, where the response to the second request includes fourth media description information, where the fourth media description information includes the first indication information. Alternatively, if the second connection can carry the second data channel, the processing module 1001 is further used to control the interface module 1002 to send a response to the second request, where the response to the second request includes fifth media description information, where the fifth media description information includes the second indication information.

[0514] In one possible implementation, the second connection can carry the second data channel, including: the quality of service requirement of the second data channel is the same as the quality of service requirement of the first data channel; or the quality of service requirement of the second data channel is lower than the quality of service requirement of the first data channel.

[0515] In a possible implementation, the second connection can carry the second data channel, further comprising: the second data channel is a data channel between the communication device 100 and a second communication device.

[0516] In a possible implementation, the interface module 1002 is further configured to send sixth media description information to the network side, where the sixth media description includes connection information corresponding to the first data channel and connection information corresponding to the second data channel.

[0517] In a possible implementation, the sixth media description information further includes identification information of the first data channel and identification information of the second data channel.

[0518] In one possible implementation, the processing module 1001 is further used to determine that the first connection can carry the first data channel if the first request includes information about the first connection; or, the processing module 1001 is further used to determine that none of the created connections can carry the first data channel if the first request does not include information about the connection corresponding to the first data channel.

[0519] When used to implement the function of a communication entity, for other functions that the communication device 100 can implement, please refer to Figures 5 to 9 The relevant introduction of the illustrated embodiment will not be repeated in detail.

[0520] In a simple embodiment, those skilled in the art will appreciate that the communication device 100 may be configured as follows: Figure 4 For example, Figure 4 The processor 401 in the communication device 100 can call the computer-executable instructions stored in the memory 403 to enable the communication device 100 to execute the method described in the above method embodiment.

[0521] For example, Figure 10 The functions / implementation processes of the processing module 1001 and the interface module 1002 can be realized by Figure 4 The processor 401 in the embodiment calls the computer execution instruction stored in the memory 403 to implement. Or, Figure 10 The function / implementation process of the processing module 1001 can be achieved by Figure 4 The processor 401 in the embodiment calls the computer execution instruction stored in the memory 403 to implement the above. Figure 10 The function / implementation process of the interface module 1002 can be achieved by Figure 4 This is achieved by the communication interface 404 in .

[0522] It is understandable that one or more of the above modules or units can be implemented by software, hardware or a combination of the two. When any of the above modules or units is implemented in software, the software exists in the form of computer program instructions and is stored in a memory, and a processor can be used to execute the program instructions and implement the above method flow. The processor can be built into a system-on-a-chip (SoC) or ASIC, or it can be an independent semiconductor chip. In addition to the core for executing software instructions to perform calculations or processing within the processor, it can further include necessary hardware accelerators, such as field programmable gate arrays (FPGAs), programmable logic devices (PLDs) or logic circuits that implement dedicated logic operations.

[0523] When the above modules or units are implemented in hardware, the hardware can be any one or any combination of a CPU, a microprocessor, a digital signal processing (DSP) chip, a microcontroller unit (MCU), an artificial intelligence processor, an ASIC, a SoC, an FPGA, a PLD, a dedicated digital circuit, a hardware accelerator or a non-integrated discrete device, which can run the necessary software or not rely on the software to execute the above method flow.

[0524] Optionally, the present application also provides a chip system, comprising: at least one processor and an interface, wherein the at least one processor is coupled to a memory via the interface, and when the at least one processor executes a computer program or instruction in the memory, the method in any of the above method embodiments is executed. In one possible implementation, the chip system also includes a memory. Optionally, the chip system can be composed of a chip, or can include a chip and other discrete devices, which is not specifically limited in this application.

[0525] Optionally, the present application also provides a computer-readable storage medium. All or part of the processes in the above-mentioned method embodiments can be completed by a computer program to instruct the relevant hardware. The program can be stored in the above-mentioned computer-readable storage medium. When the program is executed, it can include the processes of the above-mentioned method embodiments. The computer-readable storage medium can be an internal storage unit of the communication device of any of the above-mentioned embodiments, such as a hard disk or memory of the communication device. The above-mentioned computer-readable storage medium can also be an external storage device of the above-mentioned communication device, such as a plug-in hard disk, a smart memory card (smart media card, SMC), a secure digital (secure digital, SD) card, a flash card (flash card), etc. equipped on the above-mentioned communication device. Furthermore, the above-mentioned computer-readable storage medium can also include both the internal storage unit of the above-mentioned communication device and an external storage device. The above-mentioned computer-readable storage medium is used to store the above-mentioned computer program and other programs and data required by the above-mentioned communication device. The above-mentioned computer-readable storage medium can also be used to temporarily store data that has been output or is to be output.

[0526] Optionally, the present application also provides a computer program product. All or part of the processes in the above method embodiments may be completed by a computer program instructing related hardware. The program may be stored in the above computer program product, and when executed, the program may include the processes in the above method embodiments.

[0527] Optionally, the present application also provides a computer instruction. All or part of the process in the above method embodiment can be completed by the computer instruction to instruct the relevant hardware (such as a computer, processor or terminal, etc.). The program can be stored in the above computer-readable storage medium or in the above computer program product.

[0528] Optionally, the present application also provides a communication system, including: the first terminal and the second terminal in the above embodiment.

[0529] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0530] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0531] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0532] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0533] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A communication method, characterized in that: The method comprises: receiving a first request for requesting creation of a first data channel, where the first data channel is a data channel between a first communication device and a second communication device and is used to carry data of a first application; the first data channel is associated with an Internet Protocol Multimedia Subsystem (IMS) session between the first communication device and the second communication device; If there is an established connection that can carry the first data channel, sending a response to the first request, the response including first media description information, the first media description information including first indication information, the first indication information indicating a first connection, and the first connection being a connection corresponding to the first data channel in the established connection; or If there is no established connection that can carry the first data channel, a response to the first request is sent and a second connection is created, where the response includes second media description information, the second media description information includes second indication information, and the second indication information indicates the second connection, which is the connection corresponding to the first data channel.

2. The method according to claim 1, characterized in that The first indication information includes: Internet Protocol address information, User Datagram Protocol port information, and Stream Control Transmission Protocol port information.

3. The method according to claim 1 or 2, characterized in that The method further comprises: receiving a second request, where the second request is used to request creation of a second data channel, where the second data channel is used to carry data of a second application, where the second application is different from the first application; If the established connection cannot carry the second data channel, sending a response to the second request and creating a third connection, where the response to the second request includes third media description information, the third media description information includes third indication information corresponding to the second data channel, and the third indication information indicates the third connection; or If the first connection can carry the second data channel, sending a response to the second request, where the response to the second request includes fourth media description information, and the fourth media description information includes the first indication information; or, If the second connection can carry the second data channel, a response to the second request is sent, where the response to the second request includes fifth media description information, and the fifth media description information includes the second indication information.

4. The method according to claim 3, characterized in that The second connection can carry the second data channel, including: The quality of service requirement of the second data channel is the same as the quality of service requirement of the first data channel; or The quality of service requirement of the second data channel is lower than the quality of service requirement of the first data channel.

5. The method according to claim 4, characterized in that The second connection can carry the second data channel, and further includes: The second data channel is a data channel between the first communication device and the second communication device.

6. The method according to any one of claims 3 to 5, characterized in that The method further comprises: Sending sixth media description information to the network side, where the sixth media description includes information about the connection corresponding to the first data channel and information about the connection corresponding to the second data channel.

7. The method according to claim 6, characterized in that The sixth media description information further includes identification information of the first data channel and identification information of the second data channel.

8. The method according to any one of claims 1 to 7, characterized in that The method further comprises: If the first request includes information about the first connection, determining that the first connection can carry the first data channel; or, If the first request does not include information about the connection corresponding to the first data channel, it is determined that none of the created connections can carry the first data channel.

9. A communication device, characterized in that: The communication device includes: an interface module and a processing module; The interface module is configured to receive a first request for requesting the creation of a first data channel, the first data channel being a data channel between the communication device and a second communication device, and configured to carry data of a first application; the first data channel being associated with an Internet Protocol Multimedia Subsystem (IMS) session between the communication device and the second communication device; the processing module is configured to control the interface module to send a response to the first request if there is an established connection that can carry the first data channel, the response including first media description information, the first media description information including first indication information, the first indication information indicating a first connection, the first connection being a connection corresponding to the first data channel in the established connection; or The processing module is used to control the interface module to send a response to the first request and create a second connection if there is no established connection that can carry the first data channel, the response including second media description information, the second media description information including second indication information, the second indication information indicating the second connection, and the second connection being the connection corresponding to the first data channel.

10. The communication device according to claim 9, wherein: The first indication information includes: Internet Protocol address information, User Datagram Protocol port information, and Stream Control Transmission Protocol port information.

11. The communication device according to claim 9 or 10, characterized in that: The interface module is further configured to receive a second request, where the second request is configured to request creation of a second data channel, where the second data channel is configured to carry data of a second application, where the second application is different from the first application; If the established connection cannot carry the second data channel, the processing module is further configured to control the interface module to send a response to the second request and create a third connection, where the response to the second request includes third media description information, the third media description information includes third indication information corresponding to the second data channel, and the third indication information indicates the third connection; or If the first connection can carry the second data channel, the processing module is further configured to control the interface module to send a response to the second request, where the response to the second request includes fourth media description information, and the fourth media description information includes the first indication information; or If the second connection can carry the second data channel, the processing module is further used to control the interface module to send a response to the second request, the response to the second request includes fifth media description information, and the fifth media description information includes the second indication information.

12. The communication device according to claim 11, wherein: The second connection can carry the second data channel, including: The quality of service requirement of the second data channel is the same as the quality of service requirement of the first data channel; or The quality of service requirement of the second data channel is lower than the quality of service requirement of the first data channel.

13. The communication device according to claim 12, wherein: The second connection can carry the second data channel, and further includes: The second data channel is a data channel between the communication device and the second communication device.

14. The communication device according to any one of claims 11 to 13, characterized in that: The interface module is further configured to send sixth media description information to the network side, where the sixth media description includes connection information corresponding to the first data channel and connection information corresponding to the second data channel.

15. The communication device according to claim 14, wherein: The sixth media description information further includes identification information of the first data channel and identification information of the second data channel.

16. The communication device according to any one of claims 9 to 15, characterized in that: The processing module is further configured to, if the first request includes information about the first connection, determine that the first connection can carry the first data channel; or The processing module is further configured to determine that none of the created connections can carry the first data channel if the first request does not include information about the connection corresponding to the first data channel.

17. A communication device, characterized in that: include: A processor is coupled to a memory, wherein the memory is used to store programs or instructions, and when the programs or instructions are executed by the processor, the device performs the method according to any one of claims 1 to 8.

18. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instructions are executed, the computer is caused to perform the method according to any one of claims 1 to 8.

19. A computer program product, comprising computer program code, characterized in that: When the computer program code is executed on a computer, the computer is caused to implement the method according to any one of claims 1 to 8.

Images