Communication method and device, and storage medium

Abstract

The present application provides a communication method and device, and a storage medium. The communication method is applied to a first communication device and comprises: sending a first request message to a second communication device (S110); receiving a first response message from the second communication device on the basis of the first request message (S120); and on the basis of the first response message, determining whether the second communication device has the capability of supporting a data channel independent of an audio / video (S130).

Description

Communication method, device and storage medium Technical Field

[0001] The present application relates to the field of communication technology, for example, to a communication method, device and storage medium. Background Art

[0002] The IP Multimedia Subsystem (IMS) is a key component of carrier networks, providing audio / video services. Traditional IMS sessions can only provide limited services, such as audio, video, and messaging.

[0003] Currently, a new type of application is being introduced into IMS, such as Data Channel (DC) application. The so-called Data Channel Application (DC Application) is a script-based applet (i.e., HTML+CSS+Javascript+JSON) that can be dynamically downloaded to the user terminal during an IMS session. This lightweight applet can provide an interactive user experience, high-definition audio / video content, and even augmented reality (AR) content when needed. Based on the data channel service, interactive and intelligent customer service can be provided in IMS calls, and the Communications Service Provider (CSP) can also provide social games between friends during an IMS call, etc.

[0004] According to the data channel-related processes in the relevant technology, the data channel includes a bootstrap data channel and an application data channel. Whether it is the bootstrap data channel or the application data channel, the establishment of audio / video media is required at the same time. That is, in the SDP Offer / SDP Answer, the media description (media component) of the audio / video needs to appear before the media description of the data channel. Accordingly, the media description of the audio / video should appear in the first m lines in the SDP Offer / SDP Answer. Although such restrictions can meet the compatibility of the SDP protocol, they reduce the flexibility of the data channel service, especially for those data channel applications that are not closely related to audio / video sessions. Summary of the Invention

[0005] In view of this, embodiments of the present application provide a communication method, device, and storage medium, which increase the flexibility of data channel applications.

[0006] An embodiment of the present application provides a communication method, applied to a first communication device, including:

[0007] Sending a first request message to the second communication device;

[0008] receiving a first response message from the second communication device according to the first request message;

[0009] Based on the first response message, it is determined whether the second communication device has the ability to support a data channel independent of audio and video.

[0010] An embodiment of the present application provides a communication method, applied to a second communication device, including:

[0011] receiving a first request message sent by a first communication device;

[0012] A first response message is sent to the first communication device according to the first request message, so that the first communication device determines whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message.

[0013] An embodiment of the present application provides a communication device, comprising: a memory, and one or more processors;

[0014] The memory is configured to store one or more programs;

[0015] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any one of the above embodiments.

[0016] An embodiment of the present application provides a storage medium storing a computer program. When the computer program is executed by a processor, the method described in any one of the above embodiments is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] FIG1 is a schematic diagram of an IMS architecture supporting data channel services provided by related technologies;

[0018] FIG2 is a schematic diagram of a flow chart of establishing a guide data channel provided by related art;

[0019] FIG3 is a schematic diagram of a process for establishing a P2P application data channel provided by related art;

[0020] FIG4 is a flow chart of a communication method provided in an embodiment of the present application;

[0021] FIG5 is a flow chart of another communication method provided in an embodiment of the present application;

[0022] FIG6 is a schematic diagram of a flow chart of establishing a guide data channel described by a non-audio and video media according to an embodiment of the present application;

[0023] 7 is a schematic diagram of a process for establishing a guide data channel without audio or video media description provided in an embodiment of the present application;

[0024] FIG8 is a structural block diagram of a communication device provided in an embodiment of the present application;

[0025] FIG9 is a structural block diagram of another communication device provided in an embodiment of the present application;

[0026] FIG10 is a schematic structural diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The following describes the embodiments of the present application in conjunction with the accompanying drawings. The following describes the present application in conjunction with the accompanying drawings. The examples are only used to explain the present application and are not used to limit the scope of the present application.

[0028] Figure 1 is a schematic diagram of an IMS architecture supporting data channel services provided by related technologies. The architecture shown in Figure 1 includes the following network functions:

[0029] User Equipment (UE)

[0030] Call Session Control Function (CSCF): A general term within the IMS core network that refers to a functional entity that can act as a Proxy CSCF (P-CSCF), a Serving CSCF (S-CSCF), or an Interrogating CSCF (I-CSCF).

[0031] Proxy CSCF (P-CSCF): The first contact point of the user equipment (UE) in the IMS core network.

[0032] Serving CSCF (S-CSCF): The entity that handles call session status in the IMS core network.

[0033] Home Subscriber Server (HSS): The HSS is the master database supporting IMS network entities. It contains user subscription information, supports network entities, and performs user authentication and authorization. It also provides location and IP information about subscribers.

[0034] Policy Control Function (PCF): PCF provides QoS policy rules for IMS call sessions.

[0035] IMS Application Server (IMS AS): IMS AS is a SIP-based application server that provides IMS service logic.

[0036] IMS Application Layer Gateway (IMS ALG): The IMS ALG controls the IMS AGW to establish media security between the UE and the IMS core network.

[0037] IMS Access Media Gateway (IMS AGW): The IMS AGW provides media security between the UE and the IMS core network.

[0038] Multimedia Function / Multimedia Resource Function (MF / MRF): MF and MRF provide media resource management and forwarding of data channel media traffic. When supporting data channel services, MF and MRF also provide data channel media control functions.

[0039] Data Channel Signaling Function (DCSF): DCSF is a signaling control function that provides data channel control logic. DCSF is not involved in SIP signaling.

[0040] Data Channel Application Server (DC AS): DC AS provides application logic for specific data channel applications.

[0041] Compared to audio / video services, the Data Channel Service is a specialized media service that establishes a dedicated media channel for data applications running on this dedicated media channel. Data channels include the Bootstrap Data Channel and the Application Data Channel. The Bootstrap Data Channel is a media channel dedicated to the Bootstrap Application. The Bootstrap Application (also known as the "bootstrap program") is an entry-level application used to load various specific Data Channel Applications, each of which runs on the Application Data Channel established for it.

[0042] Figure 2 is a schematic diagram of a bootstrap data channel establishment process, as provided by related art. As shown in Figure 2, the process for establishing a bootstrap data channel in a person-to-person (P2P) use case is described. The bootstrap data channel is anchored to the MF / MRF, and the originating network also provides the bootstrap data channel to the terminating UE, allowing the terminating UE to download the bootstrap application. The originating UE is UE#1, and the terminating UE is UE#2.

[0043] As shown in Figure 2, the process of establishing a boot data channel includes the following steps:

[0044] Step 1: UE#1 sends a SIP INVITE request including an initial SDP proposal (ie, SDP Offer) to the IMS AS through the P-CSCF and S-CSCF in the originating network.

[0045] The initial SDP offer includes a media description of the guided data channel to be established with the guided DC flow ID. In this example, the SDP Offer includes media description information of the guided data channel for both the originating and terminating sides.

[0046] According to the restrictions of the relevant process, the SDP proposal should include the audio / video media description as the first media description in the SDP Offer, that is, the audio / video media description should appear in the first m lines of the SDP proposal. Any media description for the data channel should appear after the audio / video media description.

[0047] The SIP INVITE may also be a SIP Re-INVITE performed after the initial IMS video session is established.

[0048] Step 2: The IMS AS makes DC routing decisions and discovers DCSF.

[0049] The IMS AS verifies the user subscription data to determine whether the call request for the data channel should be notified to the DCSF.

[0050] If the IMS AS determines, based on a user profile, that a call request for a data channel needs to be notified to the DCSF, the IMS AS selects a DCSF for the user based on local configuration or discovery and selection of a DCSF instance via the NRF.

[0051] If the IMS AS determines based on the user profile that the call request for the data channel does not need to be notified to the DCSF, or the DCSF decides not to allow the DC request, the IMS AS continues the normal IMS procedure to establish the MMTel session without establishing the bootstrapped data channel by deleting the DC-related media information and sending the updated SIP INVITE to the originating S-CSCF.

[0052] Step 3: The IMS AS sends a Nimsas session event notification to the DCSF.

[0053] The Nimsas_SessionEventControl_Notify message, also known as the Session Establishment Request Event, is sent by the IMS AS to the DCSF. The message includes the following parameters: Session ID, Calling ID, Called ID, Session Status, Event Initiator, Media Information List, and DC Flow ID. This message notifies the DCSF of a DC call event.

[0054] Step 4: DCSF determines a processing strategy for the bootstrap data channel establishment request.

[0055] After receiving the DC control request, the DCSF determines a policy on how to process the directed data channel establishment request based on relevant parameters in the data channel control request (eg, caller ID, called ID, DC flow ID) and / or a specific policy of the DCSF.

[0056] Step 5: DCSF creates DC media information between the originating side and the terminating side.

[0057] Since the Session Establishment Request Event indicates that a local guided media channel is provided for the served user, the DCSF retains the MDC1 media information on the originating side and the remote guided media channel of the MDC1 on the terminating side (targeting the remote UE) based on its policy, which is used to receive the UE's request to download an application from the MF or MRF.

[0058] Step 6: DCSF calls the Nimsas media control media instruction.

[0059] The DCSF invokes the Nimsas Media Control Media Instruction operation based on its policy.

[0060] The Nimsas_Media Control_Media Instruction instructs the IMS AS how to establish the guided data channel for the originating and terminating sides through the MF. The MediaInstructionSet provided by the DSCF includes its MDC1 media endpoint address created in step 5, the DC flow ID, and the replacement HTTP URL representing the application list provided via the MDC1 interface.

[0061] In this scenario, the DCSF instructs the IMS AS to terminate the guided data channel establishment request on the originating MF, initiate a remote guided data channel establishment request (targeting the remote UE), and forward the served user's remote guided data channel establishment request to the terminating network (targeting the remote DCSF).

[0062] Step 7: The IMS AS discovers and selects DCMF or enMRF.

[0063] The IMS AS selects an MF based on local configuration, or discovers and selects an MF instance or MRF that supports the DC media function via the NRF.

[0064] Step 8: The IMS AS calls the Nmf_MRM_Create service operation to instruct the MF to allocate the required data channel media resources.

[0065] The IMS AS requests the creation of two different media terminations: one for local bootstrapping and one for remote bootstrapping, intended for the remote UE. Each media termination includes information needed to allocate resources on the Mb and MDC1 interfaces. The MF responds to the IMS AS with the negotiated data channel media resource information. If MRF is used, the IMS AS uses Mr' / Cr to the MRF to reserve data channel media resources.

[0066] Step 9: The IMS AS sends a Nimsas media control media instruction response to the DCSF.

[0067] The IMS AS responds to the media instruction request received in step 6. The response may include an atomic success result of the operation and also include negotiated data channel media resource information for MDC1.

[0068] Step 10: DCSF sends a Nimsas session event notification response to the IMS AS.

[0069] The DCSF stores the media resource information and returns a notification response to the notification request received in step 3 .

[0070] Step 11: The IMS AS sends a SIP INVITE to the I / S-CSCF.

[0071] Step 12: The IMS AS sends a SIP INVITE to the terminating network and UE#2.

[0072] In steps 11-12, the SIP INVITE includes an updated SDP Offer, in which the media information of the MF or MRF is added. In this step, the SDP offer for the guided data channel of UE#2 is included, that is, the SDP offer includes the media description of the guided data channel for UE#2.

[0073] In step 13, the terminating network and UE#2 negotiate whether to accept the SDP proposal.

[0074] Upon receiving the SDP offer, the terminating network UE#2 determines whether it can accept the SDP offer.

[0075] In step 14, the terminating network and UE#2 return an 18X, PRACK, or 200OK response to the originating network.

[0076] The 18X response includes an SDP answer to the bootstrapped data channel. Based on the received SDP answer, the IMS AS can instruct the MF or MRF to update the media resource information of the data channel for UE#2.

[0077] Step 15: The terminating network and UE#2 return a 200 OK response to the I / S-CSCF.

[0078] Step 16: The I / S-CSCF returns a 200 OK response to the IMS AS.

[0079] Step 17: The IMS AS sends a Nimsas session event notification to the DCSF.

[0080] The IMS AS notifies the DCSF of a successful session establishment event Nimsas_SessionEventControl_Notify (SessionEstablishmentSuccessEvent, session ID, media information list).

[0081] Step 18: DCSF feeds back a Nimsas session event notification response.

[0082] Step 19: The I / S-CSCF forwards the 200 OK to UE#1.

[0083] The 200 OK is forwarded to UE#1, indicating that the bootstrap data channel has been established.

[0084] Step 20-1: Establish a guided data channel between the originating MF / MRF and UE#1.

[0085] Step 20-2: Download the DC application list.

[0086] Step 20-3: Request and download a dedicated DC application from the DCSF on the originating side.

[0087] Step 21-1: Establish a guided data channel between the originating MF / MRF and UE#2.

[0088] Step 21-2, download the DC application list.

[0089] Step 21-3: Request and download a dedicated DC application from the originating DCSF.

[0090] Step 22-1: Establish a guided data channel between the MF / MRF on the terminating side and UE#1.

[0091] Step 22-2, download the DC application list.

[0092] Step 22-3: Request and download a dedicated DC application from the DCSF on the terminating side.

[0093] Step 23: The terminating network side and UE#2 establish a bootstrap data channel between the terminating MF / MRF and UE#2, download the DC application list, and download the dedicated DC application.

[0094] In steps 20-23, a guided data channel is established between the originating MF or MRF and UE#1 / UE#2. The UE sends an application request message (if multiple DC applications are available) to the MF or MRF via the established guided data channel with its data channel capabilities, requesting a data channel application or application list. The MF or MRF replaces the root URL with the replacement URL received in step 8 and forwards the message to the receiving media point of the DCSF. Based on the data channel capabilities of UE#1 and UE#2 and their selection by the MF or MRF, the DCSF further provides the application list and appropriate data channel applications to UE#1 and UE#2.

[0095] The bootstrapped data channel has been established between the terminating MF or MRF and UE#1 / UE#2. The data channel application is requested from the terminating DCSF and downloaded to UE#1 and UE#2.

[0096] If the SDP response in the 200 OK to the PRACK and UPDATE messages contains the information required to establish the bootstrap data channel, steps 20-23 may be performed after step 14.

[0097] Step 24, continue with the subsequent process.

[0098] In the process of Figure 2 above, when sending a SIP INVITE / reINVITE (i.e., steps 1 / 11 / 12), the SDP offer for the audio / video media description should be presented in the first m lines. When sending a response to the SIP INVITE / reINVITE (i.e., steps 14 / 15 / 16 / 19), the SDP response for the audio / video media description should be presented in the first m lines.

[0099] Using the process described in Figure 2, the originating UE initiates the establishment of a guided data channel with the terminating UE, and then both the originating UE and the terminating UE can download the DC application from the established guided data channel. Later, the originating UE can initiate the establishment of an application data channel with the terminating UE to run a specific data channel application between the two parties.

[0100] FIG3 is a schematic diagram of a P2P application data channel establishment process provided by related art. As shown in FIG3 , the process of establishing an application data channel in a person-to-person (P2P) use case is described. In this scenario, MF is not used to anchor the application data channel.

[0101] In the call flow, the UE has already established an IMS audio session, and the originating UE is updating the IMS audio / video session to an IMS data channel session.

[0102] As shown in Figure 3, the process of establishing a P2P application data channel includes the following steps:

[0103] In step 0, the IMS session and the bootstrap data channel have been established.

[0104] The selected data channel application(s) have been downloaded to UE#1 and UE#2.

[0105] Step 1: UE#1 sends a SIP reINVITE request with an updated SDP offer to the IMS AS through the originating network P-CSCF and S-CSCF.

[0106] The updated SDP offer contains the bootstrap data channel information, as well as the requested application data channel and associated DC application binding information.

[0107] According to the restrictions of the relevant process, the updated SDP proposal should include the audio / video media description as the first media description in the SDP Offer, that is, the audio / video media description appears in the first m lines of the SDP proposal. Any media description for the data channel should appear after the audio / video media description.

[0108] Step 2: The IMS AS makes a DC routing decision.

[0109] The IMS AS verifies the user subscription data to determine whether the media change request event should be notified to the DCSF.

[0110] Step 3: The IMS AS sends a Nimsas session event notification to the DSCF.

[0111] The IMS AS sends a session event notification to the DSCF, that is, sends Nimsas_SessionEventControl_Notify (SessionEstablishmentRequestEvent, Session ID, event direction, event initiator, media information list), to notify the DCSF of the media change request event.

[0112] Step 4: DCSF determines a processing strategy for the bootstrap data channel establishment request.

[0113] After receiving the session event notification, the DCSF determines a policy on how to handle the application data channel establishment request based on relevant parameters in the notification (ie, the associated DC application binding information) and / or DCSF service-specific policies.

[0114] Step 5: DSCF allows the DC e2e application flow to be sent to the remote party.

[0115] The DCSF determines that the newly added application data channel media description information proposed by the SDP targets UE#2 and does not need to be anchored on the local MF or MRF. If the MF or MRF needs to anchor the application data channel, the DCSF will use the Nimsas_MediaControl service operation to instruct the IMS AS to allocate the data channel media resources of the MF or MRF.

[0116] Step 6: DCSF sends a Nimsas session event notification response to the IMS AS.

[0117] The DCSF responds to the notification received in step 3 .

[0118] Step 7: The IMS AS sends the re-INVITE to the I / S-CSCF.

[0119] Step 8: The I / S-CSCF sends the re-INVITE to the terminating network / UE#2.

[0120] In steps 7 and 8, the IMS AS sends the re-INVITE to the originating S-CSCF, and then to the terminating network and UE#2. In this step, the SDP offer for the application data channel of UE#2 is included.

[0121] Step 9: The terminating network and UE#2 negotiate whether to accept the SDP proposal.

[0122] Step 10: The terminating network and UE#2 send a 200 OK to the I / S-CSCF.

[0123] Step 11: The I / S-CSCF sends a 200 OK to the IMS AS.

[0124] In steps 9-11, UE#2 and the terminating network return a 200OK to the originating network, which contains the SDP answer for the application data channel. Based on the DC application binding information received in the SDP offer from the re-INVITE, UE#2 may need to download the corresponding DC application in the SDP offer (if not already downloaded) and associate it with the requested application DC.

[0125] Step 12: The IMS AS sends a Nimsas session event notification to the DCSF.

[0126] It can be understood that the IMS AS notifies the DCSF that the data channel modification is successful.

[0127] Step 13: DCSF feeds back a Nimsas session event notification response.

[0128] Step 14: The IMS AS sends a 200 OK response to the I / S-CSCF.

[0129] Step 15: The I / S-CSCF sends a 200 OK response to the P-CSCF.

[0130] Step 16: The I / S-CSCF and the originating network perform a QoS process.

[0131] The originating network and the P-CSCF perform QoS procedures for the application data channel media based on the SDP answer information from the 200 OK response.

[0132] Step 17: The P-CSCF returns a 200 OK response to UE#1.

[0133] Step 18: UE#1 sends an ACK to the terminating network.

[0134] In step 19, the application data channel between UE#1 and UE#2 is established. In this example, it is not anchored in the MF / MRF.

[0135] In the process of Figure 3 above, when sending a SIP reINVITE / Update (i.e., steps 1 / 7 / 8), the SDP offer for the audio / video media description should be present in the first media line (m line). When sending a response to the SIP reINVITE / Update (i.e., steps 10 / 11 / 14 / 15), the SDP response for the audio / video media description should be present in the first media line.

[0136] As described in the above process (i.e., the process in Figures 2 and 3), the establishment of a data channel (i.e., whether it is a bootstrap data channel or an application data channel) requires the simultaneous establishment of audio / video media. That is, in the SDP Offer / SDP Answer, the audio / video media description should appear as the first media line (m line) before the data channel media description. This limitation reduces the flexibility of data channel services, especially for those data channel applications that are not closely associated with audio / video call sessions. To increase the flexibility of data channel applications, the close association between the data channel media description and the audio / video media description should be removed from the SDP Offer / Answer.

[0137] In order to support the removal of this close association, the originating UE and the terminating UE need to support a new function of establishing a data channel without audio / video (ie, a "dc without audio / video" feature).

[0138] An embodiment of the present application provides a communication method for negotiating a “data channel without audio / video” (i.e., “DC without Audio / Video”) capability between an originating UE and a terminating UE.

[0139] In one embodiment, Figure 4 is a flowchart of a communication method provided by an embodiment of the present application. This embodiment is applicable when a communication device is capable of supporting data channels independent of audio and video. This embodiment can be performed by a first communication device. The first communication device can also be referred to as a first communication node. For example, the first communication device can be an originating UE, and the second communication device can be a terminating UE. As shown in Figure 4, this embodiment includes: S110-S130.

[0140] S110. Send a first request message to the second communication device.

[0141] In one example, the first request message may be a SIP request message; the SIP request message may be a SIP INVITE or a SIP reINVITE.

[0142] S120. Receive a first response message from the second communication device according to the first request message.

[0143] In an example, when the first request message is a SIP request message, the corresponding first response message is a SIP response message.

[0144] S130: Determine, based on the first response message, whether the second communication device has the capability of supporting a data channel independent of audio and video.

[0145] In one embodiment, the first request message carries at least one of the following: a multimedia session proposal for a data channel unrelated to the audio and video media description; and a feature tag indicating that the first communication device supports a data channel independent of audio and video.

[0146] In one embodiment, the multimedia session proposal includes a media description for a data channel and does not include a media description for audio or video.

[0147] In one embodiment, receiving a first response message from a second communication device based on a first request message includes: receiving a first-type response message from the second communication device; wherein the multimedia session response in the first-type response message includes at least one of the following: a valid media description for the requested data channel; or an invalid media description for the requested data channel. In one example, if the first request message is a SIP request message, the corresponding first response message may be a SIP response message, and the first-type response message may be a SIP 183 Session Progress Response message or a SIP 200 OK response message.

[0148] In one embodiment, receiving a first response message from a second communication device in response to a first request message includes: receiving a second-type response message from the second communication device; wherein the second-type response message is used to indicate that the requested multimedia session proposal is unacceptable. In one example, when the first request message is a SIP request message, the corresponding first response message may be a SIP response message, and the second-type response message may be a SIP 4xx response. For example, the SIP 4xx response may be a SIP 488 response, and the 488 response is used to indicate that the SDP proposal is unacceptable.

[0149] In one embodiment, determining whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message includes: determining whether the second communication device has the ability to support a data channel independent of audio and video based on the multimedia session response in the first response message.

[0150] In one embodiment, determining whether the second communication device has the capability of supporting a data channel independent of audio and video based on the first response message includes:

[0151] In a case where the first response message includes a multimedia session response, and the multimedia session response includes a valid media description for the requested data channel, determining that the second communication device has a capability of supporting a data channel independent of audio and video; or

[0152] In a case where the first response message includes a multimedia session answer, and the multimedia session answer includes an invalid media description for the requested data channel, it is determined that the second communication device does not have a capability of supporting a data channel independent of audio and video.

[0153] In one embodiment, determining whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message includes: when the first response message indicates that the request is unacceptable, determining that the second communication device does not have the ability to support a data channel independent of audio and video.

[0154] In one embodiment, receiving a first response message from a second communications device based on a first request message includes: receiving a third-type response message from the second communications device; wherein the third-type response message carries a feature tag indicating that the second communications device supports a data channel independent of audio and video. In one example, when the first request message is a SIP request message, the corresponding first response message may be a SIP response message, and the third-type response message may be a SIP 183 session progress response message or a SIP 200 OK response message. Furthermore, the SIP 183 session progress response message or the SIP 200 OK response message carries a feature tag indicating that the terminating UE supports a data channel without audio / video.

[0155] In one embodiment, determining whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message includes: determining that the second communication device has the ability to support a data channel independent of audio and video when the first response message includes a feature tag indicating that the second communication device supports a data channel independent of audio and video.

[0156] In one embodiment, the data channel includes at least one of the following: a boot data channel; and an application data channel.

[0157] In one embodiment, Figure 5 is a flowchart of another communication method provided by an embodiment of the present application. This embodiment is applicable to situations where a communication device has the capability to support a data channel independent of audio and video. This embodiment can be performed by a second communication device. The second communication device can also be referred to as a second communication node. Exemplarily, the second communication device can be a terminating UE. As shown in Figure 5, this embodiment includes: S210-S220.

[0158] S210: Receive a first request message sent by a first communication device.

[0159] S220. Send a first response message to the first communication device according to the first request message, so that the first communication device determines whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message.

[0160] In one embodiment, the first request message carries at least one of the following: a multimedia session proposal for a data channel unrelated to the audio and video media description; a feature tag indicating that the first communication device supports a data channel independent of audio and video.

[0161] In one embodiment, the multimedia session proposal includes a media description for a data channel and does not include a media description for audio or video.

[0162] In one embodiment, sending a first response message to a first communication device according to a first request message includes: sending a first type response message to the first communication device; wherein the multimedia session response in the first type response message includes at least one of the following: a valid media description for the requested data channel; an invalid media description for the requested data channel.

[0163] In one embodiment, sending a first response message to the first communication device according to the first request message includes: sending a second type response message to the first communication device; wherein the second type response message is used to indicate that the requested multimedia session proposal is unacceptable.

[0164] In one embodiment, sending a first response message to the first communication device according to the first request message includes: sending a third type response message to the first communication device; wherein the third type response message carries a feature tag indicating that the second communication device supports a data channel independent of audio and video.

[0165] In one embodiment, the data channel includes at least one of the following: a boot data channel; and an application data channel.

[0166] It should be noted that for the explanation of parameters such as the first request message, the first response message, the multimedia session proposal, the first type response message, the second type response message and the third type response message in the communication method applied to the second communication device, please refer to the description of the corresponding parameters in the above-mentioned communication method applied to the first communication device, and will not be repeated here.

[0167] In one embodiment, FIG6 is a schematic diagram of a flow chart of establishing a guide data channel described by a non-audio and video media according to an embodiment of the present application. The process shown in FIG6 is similar to that in FIG2 , but has the following differences:

[0168] Step 1: UE#1 sends a SIP INVITE request (including an SDP proposal for a data channel not associated with the audio or video media description) to the IMS AS.

[0169] A SIP INVITE request with an SDP offer is sent to the IMS AS through the P-CSCF and S-CSCF in the originating network.

[0170] The SDP offer includes a media description for the guided data channel, which includes the guided DC flow ID. In this example, the SDP offer includes media descriptions for the guided data channel for both the originating and terminating sides.

[0171] In this embodiment, the SDP proposal in the SIP INVITE does not include the audio / video media description, that is, the media description that guides the data channel. There is no dependency (association) between the media description and the audio / video media description. This also means that the establishment of the data channel is independent of the establishment of the audio / video channel. That is, in this embodiment, the request to establish a data channel independent of the audio and video is.

[0172] Step 2: The IMS AS verifies the user subscription data to determine whether the call request of the data channel should be notified to the DCSF.

[0173] Step 3: The IMS AS sends a session event notification to the DCSF.

[0174] Step 4: DCSF determines a processing strategy for the bootstrap data channel establishment request.

[0175] Step 5: DCSF creates DC media information between the originating side and the terminating side.

[0176] Step 6: DCSF calls the Nimsas_Media Control_Media Instruction operation based on its policy.

[0177] Step 7: The IMS AS discovers and selects DCMF or enMRF.

[0178] Step 8: The IMS AS calls the Nmf_MRM_Create service operation to instruct the MF to allocate the required data channel media resources.

[0179] Step 9: The IMS AS sends a Nimsas_Media Control_Media Instruction response to the DCSF.

[0180] Step 10: DCSF sends a Nimsas session event notification response to the IMS AS.

[0181] Step 2-10 in this embodiment is similar to step 2-10 shown in Figure 2 and will not be described in detail here. Step 2-10 is equivalent to the interaction process between the IMS AS, DCSF and MF / MRF shown in Figure 6.

[0182] Step 11: The IMS AS sends a SIP INVITE to the I / S-CSCF.

[0183] Step 12: The originating S-CSCF sends a SIP INVITE to the terminating network and UE#2.

[0184] In steps 11-12, the IMS AS sends a SIP INVITE to the terminating network side and UE#2 via the originating S-CSCF, wherein the SIP INVITE includes an updated SDP proposal (ie, SDP Offer), in which media information of the MF or MRF is added.

[0185] The SIP INVITE includes an SDP proposal for the guided data channel of UE#2. That is, the SDP proposal includes a media description of the guided data channel of UE#2.

[0186] According to the description of step 1, in steps 11-12, there is no audio / video media description in the SDP proposal.

[0187] In step 13, the terminating network and UE#2 negotiate whether to accept the SDP proposal.

[0188] Upon receiving the SDP offer, UE#2 and the terminating network decide whether to accept the SDP offer and generate an SDP answer accordingly.

[0189] The SDP response returned by UE#2 and the terminating network depends on whether UE#2 and the terminating network support the "DC without Audio / Video" capability:

[0190] First, if UE#2 supports "DC without Audio / Video", this means that UE#2 can correctly process the SDP offer for guiding the data channel (but without the associated audio / video media description). Therefore, UE#2 will allocate the resources required to guide the data channel (e.g., SCTP ports, etc.) and fill in the corresponding parameters for guiding the data channel in the SDP answer. In this case, an 18x response will be returned (e.g., a "183 Session Progress" response with an SDP answer);

[0191] Secondly, if UE#2 does not support "DC without Audio / Video", this means that UE#2 cannot correctly process the SDP proposal used to guide the data channel (but without the associated audio / video media description). One method is that UE#2 determines that the SDP proposal is an invalid SDP proposal, generates an invalid SDP response (for example, setting the SCTP port to 0 in the corresponding m line), and carries the invalid SDP response in the 18x response to be returned (for example, "183 Session Progress") or 200 OK response. Another method is that UE#2 determines that the SDP proposal is an invalid SDP proposal, so that the SIP INVITE cannot be accepted, and therefore returns a 4xx response (for example, "488 Not Acceptable Here");

[0192] Third, if the terminating network does not support "DC without Audio / Video", even if UE#2 supports "DC without Audio / Video", the terminating network can still change the SDP answer generated by UE#2 to an invalid SDP answer (for example, changing the corresponding SCTP port in the SDP Answer to 0);

[0193] Fourth, if the terminating network supports "DC without Audio / Video", it will not modify the SDP answer generated by UE#2.

[0194] In all the above cases, there is no audio / video media description in the SDP answer.

[0195] Step 14: UE#2 and the terminating network return an 18X, 200, or 4xx response to the originating network.

[0196] According to the decision in step 13, UE#2 and the terminating network return an 18x / 200 / 4xx response containing an SDP answer for directing the data channel to the originating network.

[0197] For a successful response (eg, "183 Session Progress" with a valid SDP answer), the IMS AS may instruct the MF or MRF to update the data channel media resource information for UE#2.

[0198] For a failure response (eg, a "183 Session Progress" / "200 OK" / 4xx response containing an invalid SDP answer), the IMS AS performs an error handling procedure.

[0199] Upon receiving the 18x / 200 / 4xx response in step 14, UE#1 may determine whether UE#2 supports "DC without Audio / Video" based on the SDP answer returned by UE#2 and the terminating network.

[0200] One method is that if UE#1 receives a response message with a valid SDP answer from UE#2 and the terminating network, it is considered that UE#2 and the terminating network support the "DC without Audio / Video" feature.

[0201] Another approach is that if UE#1 receives a response message from UE#2 and the terminating network without the feature tag "DC without Audio / Video" or with an invalid SDP answer (for example, the SCTP port is set to 0), it is considered that UE#2 and / or the terminating network do not support the "DC without Audio / Video" feature.

[0202] Step 15: UE#2 returns a 200 OK response to the I / S-CSCF.

[0203] Step 16: The I / S-CSCF returns a 200 OK response to the IMS AS.

[0204] Step 17: The IMS AS sends a Nimsas session event notification to the DCSF.

[0205] In step 18, DCSF responds to the Nimsas notification request.

[0206] Steps 17-18 in this embodiment are similar to steps 17-18 in FIG. 2 and are not described again here.

[0207] Step 19: The IMS AS sends a 200 OK to UE#1.

[0208] The IMS AS forwards a 200 OK to UE#1, which indicates the result of the bootstrapped data channel establishment.

[0209] Similar to the determination in step 14, UE#1 may determine whether UE#2 and the terminating network support the "DC without Audio / Video" feature.

[0210] In one embodiment, Figure 7 is a schematic diagram of the process of establishing another guided data channel described by audio / video media without another embodiment of the present application. Figure 7 describes the process of negotiating the "DC without Audio / Video" capability based on the exchange of explicit feature tags "DC without Audio / Video" between the originating UE and the terminating UE.

[0211] The implementation process shown in Figure 7 is similar to that in Figure 2, but with the following differences:

[0212] Step 1: UE#1 sends a SIP INVITE request (including an SDP proposal to support a data channel independent of audio and video media) to the IMS AS.

[0213] UE#1 sends a SIP INVITE request with an SDP offer to the IMS AS through the P-CSCF and S-CSCF in the originating network.

[0214] The SDP offer includes a media description of the guided data channel, which includes the guided DC flow ID. In this example, the SDP offer includes media descriptions of the guided data channel for both the originating and terminating sides.

[0215] Furthermore, the SDP offer in the SIP INVITE in this embodiment includes a feature tag of a data channel independent of audio and video (DC without Audio / Video) to indicate that the originating UE (UE#1) supports the feature of establishing a data channel without audio / video.

[0216] In SIP INVITE, the SDP proposal does not contain audio / video media description, that is, the media description of the data channel has no dependency (association) with the audio / video media description, which also means that the establishment of the data channel is independent of the establishment of the audio / video channel.

[0217] Step 2: The IMS AS verifies the user subscription data to determine whether the call request of the data channel should be notified to the DCSF.

[0218] Step 3: The IMS AS sends a session event notification to the DCSF.

[0219] Step 4: DCSF determines a processing strategy for the bootstrap data channel establishment request.

[0220] Step 5: DCSF creates DC media information between the originating side and the terminating side.

[0221] Step 6: DCSF calls the Nimsas_Media Control_Media Instruction operation based on its policy.

[0222] Step 7: The IMS AS discovers and selects DCMF or enMRF.

[0223] Step 8: The IMS AS calls the Nmf_MRM_Create service operation to instruct the MF to allocate the required data channel media resources.

[0224] Step 9: The IMS AS sends a Nimsas_Media Control_Media Instruction response to the DCSF.

[0225] Step 10: DCSF sends a Nimsas session event notification response to the IMS AS.

[0226] Step 2-10 in this embodiment is similar to step 2-10 shown in FIG2 , and will not be described again here.

[0227] Step 11: The IMS AS sends a SIP INVITE to the originating S-CSCF.

[0228] Step 12: The originating S-CSCF sends a SIP INVITE to the terminating network and UE#2.

[0229] In steps 11-12, the IMS AS sends a SIP INVITE to the terminating network side and UE#2 via the originating S-CSCF, and adds the media information of the MF or MRF in the updated SDP Offer.

[0230] In the SIP INVITE, an SDP offer for the bootstrapped data channel to UE#2 is included, that is, the SDP offer contains a media description for the bootstrapped data channel to UE#2.

[0231] In SIP INVITE, a feature tag for a data channel independent of audio and video (DC without Audio / Video) is included.

[0232] In a SIP INVITE, there is no media description of audio / video in the SDP offer.

[0233] In step 13, the terminating network and UE#2 negotiate whether to accept the SDP proposal.

[0234] After receiving the SIP INVITE, UE#2 and the terminating network decide whether to accept the SDP proposal based on the included feature tag "DC without Audio / Video" and the SDP proposal containing the guided data channel, and generate an SDP response accordingly.

[0235] The SDP response returned by UE#2 and the terminating network depends on whether UE#2 and the terminating network support the "DC without Audio / Video" feature:

[0236] First, if UE#2 supports "DC without Audio / Video", this means that UE#2 is able to recognize the feature tag "DC without Audio / Video" in the SIP INVITE and is able to correctly process the SDP proposal that only contains the guided data channel (but no associated audio / video media description). Therefore, UE#2 will allocate the resources required to guide the data channel (for example, SCTP ports, etc.) and fill in the corresponding parameters of the guided data channel in the SDP response. At this time, UE#2 returns an 18x response (for example, a "183 Session Progress" response with a valid SDP response). In the 18x response, UE#2 includes the feature tag "DC without Audio / Video" to indicate its own (UE#2's) ability to establish a data channel without audio / video;

[0237] Secondly, if UE#2 does not support "DC without Audio / Video", this means that UE#2 is unable to recognize the feature tag "DC without Audio / Video" in the SIP INVITE, and is unable to correctly process the SDP proposal that only contains the guided data channel (but no associated audio / video media description). One method is that UE#2 determines that the SDP proposal is an invalid SDP proposal, thereby generating an invalid SDP response (for example, setting the SCTP port to 0 in the corresponding m line), and carrying the invalid SDP response in the returned 18x response (for example, "183 Session Progress") or 200 OK response. Another method is that UE#2 determines that the SDP proposal is an invalid SDP proposal, and thus the SIP INVITE cannot be accepted, and therefore returns a 4xx response (for example, "488 Not Acceptable Here");

[0238] Third, if the terminating network does not support "DC without Audio / Video", even if UE#2 supports "DC without Audio / Video", the terminating network can still change the SDP answer generated by UE#2 to an invalid SDP answer (for example, changing the SCTP port in the SDP Answer to 0), or remove the feature tag "DC without Audio / Video" from the SIP response (18x / 200 / 4xx response);

[0239] If the terminating network supports "DC without Audio / Video", it does not modify the SDP answer generated by UE#2, nor does it remove the feature tag "DC without Audio / Video" from the SIP response (18x / 200 / 4xx response) generated by UE#2.

[0240] In all the above cases, no audio / video media description is present in the SDP answer.

[0241] Step 14: UE#2 and the terminating network return an 18X, 200, or 4xx response to the originating network.

[0242] Following the decision in step 13, UE#2 and the terminating network return an 18x / 200 / 4xx response with an SDP answer to the bootstrapped data channel to the originating network.

[0243] For a successful response (eg, "183 Session Progress" with feature tag "DC without Audio / Video" and containing a valid SDP answer), the IMS AS may instruct the MF or MRF to update the data channel media resource information for UE#2.

[0244] For a failure response (eg, "183 Session Progress" / "200 OK" without the feature tag "DC without Audio / Video" or "183 Session Progress" / "200 OK" / 4xx response containing an invalid SDP answer), the IMS AS performs an error handling procedure.

[0245] Upon receiving the 18x / 200 / 4xx response in step 14 , UE#1 may determine whether UE#2 supports “DC without Audio / Video” based on the feature tag “DC without Audio / Video” and / or the returned SDP answer.

[0246] One method is that if UE#1 receives a response message with a feature tag "DC without Audio / Video" from UE#2 and the terminating network, it is considered that UE#2 and the terminating network support the "DC without Audio / Video" feature.

[0247] Another approach is that if UE#1 receives a response message from UE#2 and the terminating network that does not have the feature tag "DC without Audio / Video" or contains an invalid SDP answer, it is considered that UE#2 and / or the terminating network do not support the "DC without Audio / Video" feature.

[0248] Step 15: UE#2 returns a 200OK response to the I / S-CSCF.

[0249] Step 16: The I / S-CSCF returns a 200 OK response to the IMS AS.

[0250] Similar to step 14, steps 15-16 can be used for the same purpose. That is, in steps 15-16, the feature tag "DC without Audio / Video" is included in the SIP response to indicate that UE#2 and the terminating network support the "DC without Audio / Video" feature.

[0251] Step 17: The IMS AS sends a Nimsas session event notification to the DCSF.

[0252] In step 18, DCSF responds to the Nimsas notification request.

[0253] Step 19: The IMS AS sends a 200 OK to UE#1.

[0254] The IMS AS forwards a 200 OK to UE#1, which indicates the result of the bootstrapped data channel establishment.

[0255] Similar to the determination in step 14, UE#1 may determine whether UE#2 and the terminating network support the "DC without Audio / Video" feature.

[0256] In the processes described in Figures 6 and 7, the "DC without Audio / Video" capability negotiation occurs during the bootstrap data channel establishment process. Similarly, this negotiation mechanism can also be applied to the application data channel establishment process with similar enhancements.

[0257] Using the process described in Figures 6 and 7, during the IMS session establishment process, the originating UE can negotiate with the terminating UE for support for establishing a data channel without audio / video (i.e., "DC without Audio / Video"), thereby initiating an IMS session with a pure data channel without involving an audio / video call.

[0258] It should be noted that the process described in Figure 7, i.e., negotiating whether to support the "DC without Audio / Video" method through explicit feature tags, can also occur in other processes for establishing non-IMS sessions (such as the SIP message sending process). A typical way is that UE#1 sends a SIP Message to UE#2, carrying its own "DC without Audio / Video" capability tag in the SIP Message, and UE#2 also returns its own capability tag accordingly, thereby negotiating their respective capabilities.

[0259] In one embodiment, FIG8 is a block diagram of a communication device provided in an embodiment of the present application. This embodiment is applied to a first communication device. As shown in FIG8 , the communication device in this embodiment includes: a transmitter 310, a receiver 320, and a determination module 330.

[0260] The transmitter 310 is configured to send a first request message to the second communication device.

[0261] The receiver 320 is configured to receive a first response message from the second communication device according to the first request message.

[0262] The determination module 330 is configured to determine whether the second communication device has the capability of supporting a data channel independent of audio and video based on the first response message.

[0263] In one embodiment, the first request message carries at least one of the following: a multimedia session proposal for a data channel unrelated to the audio and video media description; a feature tag indicating that the first communication device supports a data channel independent of audio and video.

[0264] In one embodiment, the multimedia session proposal includes a media description for a data channel and does not include a media description for audio or video.

[0265] In one embodiment, the receiver 320 is further configured to receive a first type response message from the second communication device; wherein the multimedia session response in the first type response message includes at least one of the following: a valid media description for the requested data channel; an invalid media description for the requested data channel.

[0266] In one embodiment, the receiver 320 is further configured to receive a second type response message from the second communication device; wherein the second type response message is used to indicate that the requested multimedia session proposal is unacceptable.

[0267] In one embodiment, the determination module 330 is further configured to determine whether the second communication device has the capability of supporting a data channel independent of audio and video based on the multimedia session response in the first response message.

[0268] In one embodiment, the determination module 330 is further configured to:

[0269] In a case where the first response message includes a multimedia session response, and the multimedia session response includes a valid media description for the requested data channel, determining that the second communication device has a capability of supporting a data channel independent of audio and video; or

[0270] In a case where the first response message includes a multimedia session answer, and the multimedia session answer includes an invalid media description for the requested data channel, it is determined that the second communication device does not have a capability of supporting a data channel independent of audio and video.

[0271] In one embodiment, the determination module 330 is further configured to determine that the second communication device does not have the capability to support a data channel independent of audio and video when the first response message indicates that the request is unacceptable.

[0272] In one embodiment, the receiver 320 is further configured to receive a third type of response message from the second communication device; wherein the third type of response message carries a feature tag indicating that the second communication device supports a data channel independent of audio and video.

[0273] In one embodiment, the determination module 330 is further configured to determine that the second communication device has the capability of supporting a data channel independent of audio and video when the first response message includes a feature tag indicating that the second communication device supports a data channel independent of audio and video.

[0274] In one embodiment, the data channel includes at least one of the following: a boot data channel; and an application data channel.

[0275] The communication apparatus provided in this embodiment is configured to implement the communication method applied to the first communication device in the embodiment shown in FIG4 . The implementation principle and technical effects of the communication apparatus provided in this embodiment are similar and will not be described in detail here.

[0276] In one embodiment, FIG9 is a block diagram of another communication device provided in an embodiment of the present application. This embodiment is applied to a second communication device. As shown in FIG9 , the communication device in this embodiment includes: a receiver 410 and a transmitter 420.

[0277] The receiver 410 is configured to receive a first request message sent by a first communication device.

[0278] The transmitter 420 is configured to send a first response message to the first communication device according to the first request message, so that the first communication device determines whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message.

[0279] In one embodiment, the first request message carries at least one of the following: a multimedia session proposal for a data channel unrelated to the audio and video media description; a feature tag indicating that the first communication device supports a data channel independent of audio and video.

[0280] In one embodiment, the multimedia session proposal includes a media description for a data channel and does not include a media description for audio or video.

[0281] In one embodiment, sending a first response message to a first communication device according to a first request message includes: sending a first type response message to the first communication device; wherein the multimedia session response in the first type response message includes at least one of the following: a valid media description for the requested data channel; an invalid media description for the requested data channel.

[0282] In one embodiment, sending a first response message to the first communication device according to the first request message includes: sending a second type response message to the first communication device; wherein the second type response message is used to indicate that the requested multimedia session proposal is unacceptable.

[0283] In one embodiment, the first request message further carries a feature tag indicating that the first communication device supports a data channel independent of audio and video.

[0284] In one embodiment, sending a first response message to the first communication device according to the first request message includes: sending a third type response message to the first communication device; wherein the third type response message carries a feature tag indicating that the second communication device supports a data channel independent of audio and video.

[0285] In one embodiment, the data channel includes at least one of the following: a boot data channel; and an application data channel.

[0286] The communication apparatus provided in this embodiment is configured to implement the communication method applied to the second communication device in the embodiment shown in FIG5 . The implementation principle and technical effects of the communication apparatus provided in this embodiment are similar and will not be described in detail here.

[0287] In one embodiment, Figure 10 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application. As shown in Figure 10, the device provided in the present application includes: a processor 510, a memory 520, and a communication module 530. The number of processors 510 in the device can be one or more, and Figure 10 uses one processor 510 as an example. The number of memories 520 in the device can be one or more, and Figure 10 uses one memory 520 as an example. The processor 510, memory 520, and communication module 530 of the device can be connected via a bus or other means, and Figure 10 uses a bus connection as an example. In this embodiment, the device can be a first communication device or a second communication device.

[0288] The memory 520, as a computer-readable storage medium, can be configured to store software programs, computer executable programs, and modules, such as program instructions / modules corresponding to the device of any embodiment of the present application (for example, the transmitter 310, the receiver 320, and the determination module 330 in the communication device). The memory 520 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the device, etc. In addition, the memory 520 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 520 may further include a memory remotely located relative to the processor 510, and these remote memories may be connected to the device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0289] In the case where the communication device is a first communication device, the device provided above can be configured to execute the communication method applied to the first communication device provided in any of the above embodiments, and have corresponding functions and effects.

[0290] In the case where the communication device is a second communication device, the device provided above can be configured to execute the communication method applied to the second communication device provided in any of the above embodiments, and have corresponding functions and effects.

[0291] An embodiment of the present application also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute a communication method applied to a first communication device, the method comprising: sending a first request message to a second communication device; receiving a first response message from the second communication device based on the first request message; and determining whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message.

[0292] An embodiment of the present application also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute a communication method applied to a second communication device, the method comprising: receiving a first request message sent by a first communication device; and sending a first response message to the first communication device based on the first request message, so that the first communication device determines whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message.

[0293] It will be appreciated by those skilled in the art that the term user equipment encompasses any suitable type of wireless user equipment, such as a mobile phone, a portable data processing device, a portable web browser or a car-mounted mobile station.

[0294] In general, various embodiments of the present application may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, although the present application is not limited thereto.

[0295] Embodiments of the present application may be implemented by executing computer program instructions by a data processor of a mobile device, for example, in a processor entity, or by hardware, or by a combination of software and hardware. The computer program instructions may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages.

[0296] The block diagram of any logical flow in the drawings of the present application may represent program steps, or may represent interconnected logical circuits, modules and functions, or may represent a combination of program steps and logical circuits, modules and functions. A computer program may be stored on a memory. The memory may be of any type suitable for the local technical environment and may be implemented using any suitable data storage technology, such as, but not limited to, a read-only memory (ROM), a random access memory (RAM), an optical storage device and system (a digital versatile disc (DVD) or a compact disk (CD)). Computer-readable media may include non-transient storage media. A data processor may be of any type suitable for the local technical environment, such as, but not limited to, a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and a processor based on a multi-core processor architecture.

Claims

1. A communication method, applied to a first communication device, includes: Sending a first request message to a second communication device; Receiving a first response message from the second communication device according to the first request message; Determining whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message.

2. The method according to claim 1, wherein, The first request message carries at least one of the following: a multimedia session offer for a data channel not associated with an audio-video media description; a feature tag indicating that the first communication device supports a data channel independent of audio and video.

3. The method according to claim 2, wherein, The multimedia session offer includes a media description for the data channel and does not include a media description for audio and video.

4. The method according to claim 2, wherein The receiving a first response message from the second communication device according to the first request message includes: Receiving a first type of response message from the second communication device; wherein, the multimedia session answer in the first type of response message includes at least one of the following: a valid media description for the requested data channel; an invalid media description for the requested data channel.

5. The method according to claim 2, wherein The receiving a first response message from the second communication device according to the first request message includes: Receiving a second type of response message from the second communication device; wherein, the second type of response message is used to indicate that the requested multimedia session offer is unacceptable.

6. The method according to claim 2, wherein, The determining whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message includes: Determining whether the second communication device has the ability to support a data channel independent of audio and video based on the multimedia session answer in the first response message.

7. The method according to claim 2, wherein, The determining whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message includes: In the case where the first response message includes a multimedia session answer and the multimedia session answer includes a valid media description for the requested data channel, determining that the second communication device has the ability to support a data channel independent of audio and video; or, In the case where the first response message includes a multimedia session answer and the multimedia session answer includes an invalid media description for the requested data channel, determining that the second communication device does not have the ability to support a data channel independent of audio and video.

8. The method according to claim 2, wherein The determining whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message includes: In the case where the first response message indicates that the request is unacceptable, determining that the second communication device does not have the ability to support a data channel independent of audio and video.

9. The method according to claim 2, wherein The receiving a first response message from the second communication device according to the first request message includes: Receiving a third type of response message from the second communication device; wherein, the third type of response message carries a feature tag indicating that the second communication device supports a data channel independent of audio and video.

10. The method according to claim 2 or 9, wherein, The determining whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message includes: In the case that the first response message includes a feature tag indicating that the second communication device supports a data channel independent of audio and video, determine that the second communication device has the ability to support a data channel independent of audio and video.

11. The method according to any one of claims 1-9, wherein, The data channel includes at least one of the following: a bootstrap data channel; an application data channel.

12. A communication method, applied to a second communication device, includes: Receiving a first request message sent by a first communication device; Sending a first response message to the first communication device according to the first request message, so that the first communication device determines whether the second communication device has the ability to support a data channel independent of audio and video based on the first response message.

13. The method according to claim 12, wherein, The first request message carries at least one of the following: a multimedia session proposal for a data channel not associated with an audio-video media description; a feature tag indicating that the first communication device supports a data channel independent of audio and video.

14. The method according to claim 13, wherein, The multimedia session proposal includes a media description for the data channel and does not include a media description for audio and video.

15. According to the method of claim 12, the sending the first response message to the first communication device according to the first request message includes: Sending a first type of response message to the first communication device; wherein, the multimedia session answer in the first type of response message includes at least one of the following: a valid media description for the requested data channel; an invalid media description for the requested data channel.

16. The method according to claim 12, wherein, The sending the first response message to the first communication device according to the first request message includes: Sending a second type of response message to the first communication device; wherein, the second type of response message is used to indicate that the requested multimedia session proposal is unacceptable.

17. The method according to claim 13, wherein, The sending the first response message to the first communication device according to the first request message includes: Sending a third type of response message to the first communication device; wherein, the third type of response message carries a feature tag indicating that the second communication device supports a data channel independent of audio and video.

18. The method according to any one of claims 12-17, wherein, The data channel includes at least one of the following: a bootstrap data channel; an application data channel.

19. A communication device, comprising: A memory, and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1-11 or 12-18 above.

20. A storage medium, the storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1-11 or 12-18 above is implemented.

Images