CN117938815A - 通信方法、设备及存储介质 - Google Patents
通信方法、设备及存储介质 Download PDFInfo
- Publication number
- CN117938815A CN117938815A CN202410046664.5A CN202410046664A CN117938815A CN 117938815 A CN117938815 A CN 117938815A CN 202410046664 A CN202410046664 A CN 202410046664A CN 117938815 A CN117938815 A CN 117938815A
- Authority
- CN
- China
- Prior art keywords
- data channel
- communication device
- response message
- audio
- video
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000004891 communication Methods 0.000 title claims abstract description 183
- 238000000034 method Methods 0.000 title claims abstract description 79
- 230000004044 response Effects 0.000 claims abstract description 182
- 238000004590 computer program Methods 0.000 claims description 5
- 108091006146 Channels Proteins 0.000 description 220
- XTWQOSYEUVHDIT-CQRHUGCQSA-M sodium 3alpha,7alpha-dihydroxy-5beta-cholane-24-sulfonate Chemical compound [Na+].C([C@H]1C[C@H]2O)[C@H](O)CC[C@]1(C)[C@@H]1[C@@H]2[C@@H]2CC[C@H]([C@@H](CCCS([O-])(=O)=O)C)[C@@]2(C)CC1 XTWQOSYEUVHDIT-CQRHUGCQSA-M 0.000 description 48
- 238000010586 diagram Methods 0.000 description 17
- 230000006870 function Effects 0.000 description 17
- 230000008569 process Effects 0.000 description 13
- 238000012545 processing Methods 0.000 description 6
- 101000581326 Homo sapiens Mediator of DNA damage checkpoint protein 1 Proteins 0.000 description 5
- 102100027643 Mediator of DNA damage checkpoint protein 1 Human genes 0.000 description 5
- 238000013459 approach Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000011664 signaling Effects 0.000 description 3
- 230000003190 augmentative effect Effects 0.000 description 2
- 238000012508 change request Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 241000272808 Anser Species 0.000 description 1
- 101100113576 Arabidopsis thaliana CINV2 gene Proteins 0.000 description 1
- 238000000889 atomisation Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000012092 media component Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提出一种通信方法、设备及存储介质。应用于第一通信设备的通信方法包括：向第二通信设备发送第一请求消息；根据所述第一请求消息从所述第二通信设备接收第一响应消息；基于所述第一响应消息确定所述第二通信设备用于支持无音视频数据通道的能力。
Description
技术领域
本申请涉及通信技术领域，具体涉及一种通信方法、设备及存储介质。
背景技术
IP多媒体子系统(IP Multimedia Subsystem，IMS)是运营商网络中的一个重要组成部分，提供音频/视频服务(Audio/Video Service)。传统的IMS会话只能提供有限的服务，如音频、视频和消息等。
目前，在IMS中引入一种新的应用，比如，数据通道(Data Channel，DC)应用。所谓数据通道应用(Data Channel Application，或DC Application)，是基于脚本的小应用程序(即，HTML+CSS+Javascr ipt+JSON)，这些小应用程序可以在IMS会话(IMS Session)进行期间被动态地下载到用户终端。这种轻量级的小应用程序能够提供交互式的用户体验、高清晰音频/视频内容，甚至在需要时还能提供增强现实(Augmented Reality，AR)内容。基于数据通道服务，可以在IMS呼叫中提供交互式的和智能的客户服务，而通信服务提供商(Communications Service Provider，CSP)也能够在IMS呼叫期间提供朋友间的社交游戏，等等。
按照现有的数据通道相关流程，数据通道包括引导数据通道(bootstrap datachannel)和应用数据通道(application data channel)。无论是引导数据通道，还是应用数据通道的建立，均要求同时建立音频/视频(audio/video)媒体。即在SDP提议(SDPOffer)/SDP应答(SDP Anser)中，音频/视频的媒体描述(media component)需要出现在数据通道的媒体描述之前。相应的，音频/视频的媒体描述应出现在SDP提议/SDP应答中的首个m行中。虽然这样的限制条件可以满足SDP协议的兼容性，但降低了数据通道服务的灵活性，尤其是对于那些与音频/视频会话没有紧密关联的数据通道应用。
发明内容
有鉴于此，本申请实施例提供一种通信方法、设备及存储介质，增加了数据通道应用的灵活性。
本申请实施例提供一种通信方法，应用于第一通信设备，包括：
向第二通信设备发送第一请求消息；
根据所述第一请求消息从所述第二通信设备接收第一响应消息；
基于所述第一响应消息确定所述第二通信设备用于支持无音视频数据通道的能力。
本申请实施例提供一种通信方法，应用于第二通信设备，包括：
接收第一通信设备发送的第一请求消息；
根据所述第一请求消息向所述第一通信设备发送第一响应消息，以使所述第一通信设备基于所述第一响应消息确定所述第二通信设备用于支持无音视频数据通道的能力。
本申请实施例提供一种通信设备，包括：存储器，以及一个或多个处理器；
所述存储器，配置为存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一实施例所述的方法。
本申请实施例提供一种存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述任一实施例所述的方法。
附图说明
图1是现有技术提供的一种支持数据通道服务的IMS架构示意图；
图2是现有技术提供的一种引导数据通道的建立流程示意图；
图3是现有技术提供的一种P2P应用数据通道的建立流程示意图；
图4是本申请实施例提供的一种通信方法的流程图；
图5是本申请实施例提供的另一种通信方法的流程图；
图6是本申请实施例提供的一种无音视频媒体描述的引导数据通道的建立流程示意图；
图7是本申请实施例提供的另一种无音视频媒体描述的引导数据通道的建立流程示意图；
图8是本申请实施例提供的一种通信装置的结构框图；
图9是本申请实施例提供的另一种通信装置的结构框图；
图10是本申请实施例提供的一种通信设备的结构示意图。
具体实施方式
下文中将结合附图对本申请的实施例进行说明。以下结合实施例附图对本申请进行描述，所举实例仅用于解释本申请，并非用于限定本申请的范围。
图1是现有技术提供的一种支持数据通道服务的IMS架构示意图。在如图1所示的上述架构中，包括以下网络功能：
用户设备(User Equipment，UE)
呼叫会话控制功(Call Session Control Function，CSCF)：IMS核心网内的通用术语，用于指代可以充当代理CSCF(Proxy CSCF，P-CSCF)、服务CSCF(Serving CSCF，S-CSCF)或查询CSCF(Interrogating，I-CSCF)的功能实体。
代理代理CSCF(Proxy CSCF，P-CSCF)：用户设备(UE)在IMS核心网内的首个接触点。
服务CSCF(Serving CSCF，S-CSCF)：IMS核心网中处理呼叫会话状态的实体。
归属签约服务(Home Subscriber Server，HSS)：HSS是支持IMS网络实体的主数据库。它是包含用户签约相关信息的实体，以支持网络实体并执行对用户的认证和授权，并且能够提供关于签约用户的位置信息和IP信息。
策略控制功能(Policy Control Function，PCF)：PCF提供针对IMS呼叫会话的QoS策略规则。
IMS应用服务器(IMS Application Server，IMS AS)：IMS AS是基于SIP的应用服务器，其提供了IMS服务逻辑。
IMS应用层网(IMS Application Layer Gateway，IMS ALG)：IMS ALG控制IMS AGW以在UE与IMS核心网之间建立媒体安全性。
IMS接入媒体网(IMS Access Media Gateway，IMS AGW)：IMS AGW提供了UE与IMS核心网之间的媒体安全性。
媒体功能/媒体资源功能(Multimedia Function/Multimedia ResourceFunction，MF/MRF)：MF和MRF提供媒体资源管理和对数据通道媒体流量的转发。在支持数据通道服务时，MF和MRF也提供数据通道媒体控制功能。
数据通道信令功(Data Channel Singalling Function，DCSF)：DCSF是提供数据通道控制逻辑的信令控制功能。DCSF在SIP信令中不被涉及。
数据通道应用服务器(Data Channel Application Server，DC AS)：DC AS为特定的数据通道应用提供应用逻辑。
与音频/视频服务相比，数据通道服务(Data Channel Service)是一种特殊的媒体服务，它为运行在此特殊媒体通道之上的数据应用建立特殊的媒体通道。数据通道包括引导数据通道(Bootstrap Data Channel)和应用数据通道(Application Data Channel)。引导数据通道是专供引导应用(Bootstrap Application)在其上运行的媒体通道。引导应用(也可称为“引导程序”)是一个入口级应用，用于加载各种具体的数据通道应用(DataChannel Application)，其中每个数据通道应用运行在为它建立的应用数据通道之上。
图2是现有技术提供的一种引导数据通道的建立流程示意图。如图2所示，描述了人对人(Person-to-Person，P2P)用例中建立引导数据通道(bootstrap data channel)的流程。其中，引导数据通道锚定在MF/MRF上，并且始呼网络也将引导数据通道提供给终呼UE，以遍终呼UE下载引导应用。其中，始呼UE为UE#1，终呼UE为UE#2。
如图2所示，引导数据通道的建立过程包括以下步骤：
步骤1，UE#1通过始呼网络中的P-CSCF和S-CSCF向IMS AS发送包含初始SDP提议(即SDP Offer)的SIP INVITE请求。
在初始SDP提议中，包含要被建立具有引导DC流ID的引导数据通道的媒体描述。在本示例过程中，SDP Offer中包含用于始呼侧和终呼侧的引导数据通道的媒体描述信息。
按照现有流程的限制，SDP提议中应当包含音频/视频的媒体描述作为SDP Offer中的第一媒体描述，即音频/视频的媒体描述出现在SDP提议的首个m行中。任何用于数据通道的媒体描述都应出现在音频/视频的媒体描述之后。
该SIP INVITE也可以是在建立初始IMS视频会话之后执行的SIP Re-INVITE。
步骤2，IMS AS进行DC路由决策和DCSF发现。
IMS AS验证用户订阅数据，以确定数据通道的呼叫请求是否应该被通知给DCSF。
如果IMS AS基于用户配置文件(user profile)确定数据通道的呼叫请求需要被通知给DCSF，则IMS AS基于本地配置或经由NRF的DCSF实例的发现和选择为该用户选择DCSF。
如果IMS AS基于用户配置文件确定数据通道的呼叫请求不需要被通知给DCSF，或者DCSF决定不允许DC请求，则IMS AS通过删除DC相关媒体信息并将更新后的SIP INVITE发送到始呼S-CSCF，继续正常的IMS过程以在不建立引导数据通道的情况下建立MMTel会话。
步骤3，IMS AS向DCSF发送Nimsas会话事件控制通知。
Nimsas会话事件控制通知(Nimsas_Session Event Control_Notify)也可以称为会话建立请求事件(Session Establishment RequestEvent)，IMS AS向DCSF发送会话事件通知的过程包括下述参数：Session ID(会话ID)、Calling ID(主叫ID)、Called ID(被叫ID)、会话情况、事件发起者、媒体信息列表、DC流ID，即向DCSF通知DC呼叫事件。
步骤4，DCSF确定引导数据通道建立请求的处理策略。
在DCSF接收到DC控制请求之后，基于数据通道控制请求中的相关参数(例如主叫ID、被叫ID、DC流ID)和/或DCSF的特定策略，DCSF确定关于如何处理引导数据通道建立请求的策略。
步骤5，DCSF创建始呼侧和终呼侧之间的DC媒体信息。
由于Session Establishment Request Event指示了为被服务用户提供本地引导媒体通道，DCSF基于其策略保留始呼侧MDC1媒体信息，以及终呼侧MDC1远程的引导媒体通道(目标为远程UE)，其用于接收UE从MF或MRF下载应用的请求。
步骤6，DCSF调用Nimsas媒体控制媒体指令。
DCSF基于其策略调用Nimsas媒体控制媒体指令(即Nimsas_Media Control_MediaInstruction)操作。
通过Nimsas_Media Control_Media Instruction指示IMS AS如何为始呼侧和终呼侧通过MF建立引导数据通道。由DSCF提供的MediaInstructionSet(媒体指令集)包括步骤5中创建的其MDC1媒体端点地址、DC流ID、以及表示经由MDC1接口提供的应用列表的替换HTTP URL。
在这种场景中，DCSF指示IMS AS终止始呼MF上的引导数据通道建立请求，并且发起远程引导数据通道建立请求(目标为远程UE)以及向终呼网络转发被服务用户的远程引导数据通道建立请求(目标为远程DCSF)。
步骤7，IMS AS发现并选择DCMF或enMRF。
IMS AS基于本地配置选择MF，或者经由NRF发现并选择支持DC媒体功能的MF实例或MRF。
步骤8，IMS AS调用Nmf_MRM_Create服务操作以指示MF分配所需的数据通道媒体资源。
IMS AS请求创建两个不同的媒体端点(Media Termination)，一个为本地引导媒体端点，另一个为提供给远程UE的远程引导媒体端点。每个媒体端点信息包括在Mb和MDC1接口中分配资源所需的信息。MF用协商后的数据通道媒体资源信息对IMS AS作出响应。如果使用MRF，则IMS AS使用Mr'/Cr到MRF以保留数据通道媒体资源。
步骤9，IMS AS向DCSF发送Nimsas媒体控制媒体指令响应。
IMS AS对步骤6中接收到的媒体指令请求作出响应。该响应可以包括操作的原子化成功结果，并且还包括用于MDC1的协商后的数据通道媒体资源信息。
步骤10，DCSF向IMS AS发送Nimsas会话事件控制通知响应。
DCSF存储媒体资源信息，并且对在步骤3中接收到的通知请求返回通知响应。
步骤11，IMS AS向I/S-CSCF发送SIP INVITE。
步骤12，IMS AS向终呼网络侧和UE#2发送SIP INVITE。
在步骤11-12中，SIP INVITE包含更新后的SDP Offer，在更新的SDP Offer中添加了MF或MRF的媒体信息。在该步骤中，包括用于UE#2的引导数据通道的SDP提议，即，该SDP提议中包含用于UE#2的引导数据通道的媒体描述。
步骤13，终呼网络侧和UE#2协商是否接受SDP提议。
在接收到SDP提议时，终呼网络UE#2决定是否能够接受SDP提议。
步骤14，终呼网络侧和UE#2向始呼网络返回18X、PRACK或200OK响应。
其中，18X响应包含对引导数据通道的SDP应答(SDP Answer)。根据接收到的SDP应答，IMS AS可以指示MF或MRF更新用于UE#2的数据通道媒体资源信息。
步骤15，终呼网络侧和UE#2向I/S-CSCF返回200OK响应。
步骤16，I/S-CSCF向IMS AS返回200OK响应。
步骤17，IMS AS向DCSF发送Nimsas会话事件控制通知。
其中，IMS AS向DCSF通知成功会话建立事件Nimsas_Session Event ControlNotify(SessionEstablishmentSuccessEvent、会话ID、媒体信息列表)。
步骤18，DCSF反馈Nimsas会话事件控制通知响应。
步骤19，I/S-CSCF将200OK转发到UE#1。
将200OK转发到UE#1，表示引导数据通道已经被建立。
步骤20-1，建立始呼侧MF/MRF与UE#1之间的引导数据通道。
步骤20-2，下载DC应用列表。
步骤20-3，从始呼侧DCSF请求和下载专用DC应用。
步骤21-1，建立始呼侧MF/MRF与UE#2之间的引导数据通道。
步骤21-2，下载DC应用列表。
步骤21-3，从始呼侧DCSF请求和下载专用DC应用。
步骤22-1，建立终呼侧MF/MRF与UE#1之间的引导数据通道。
步骤22-2，下载DC应用列表。
步骤22-3，从终呼侧DCSF请求和下载专用DC应用。
步骤23，终呼网络侧和UE#2建立终呼侧MF/MRF与UE#2之间的引导数据通道，下载DC应用列表，以及下载专用DC应用。
在步骤20-23中，引导数据通道已经在始呼侧MF或MRF和UE#1/UE#2之间被建立。UE经由具有其数据通道能力的已建立的引导数据通道向MF或MRF发送应用请求消息(如果有多个DC应用的话)以请求数据通道应用或应用列表。MF或MRF用在步骤8中接收到的替换URL代替根URL，并将该消息转发到DCSF的接收媒体点。DCSF基于UE#1和UE#2的数据通道能力以及它们通过MF或MRF的选择，进一步向UE#1和UE#2提供应用列表和适当的数据通道应用。
引导数据通道已在终端侧MF或MRF和UE#1/UE#2之间建立。数据通道应用从终呼DCSF被请求并下载到UE#1和UE#2。
如果对PRACK和UPDATE消息的200OK中的SDP应答包含建立引导数据通道所需的消息，则步骤20-23可以在步骤14之后执行。
步骤24，继续后续过程。
在上述图2过程中，在发送SIP INVITE/reINVITE(即，步骤1/11/12)的情况下，针对音频/视频媒体描述的SDP提议应当被呈现在首个m行中。在发送对SIP INVITE/reINVITE的响应(即，步骤14/15/16/19)的情况下，针对音频/视频媒体描述的SDP应答应被呈现在首个m行中。
使用如图2中描述的过程，始呼UE发起与终呼UE的引导数据通道建立，并且随后始呼UE和终呼UE两者都能够从已建立的引导数据通道下载DC应用。稍后，始呼UE可以发起与终呼UE的应用数据通道建立，以便运行两方之间的特定的数据通道应用。
图3是现有技术提供的一种P2P应用数据通道的建立流程示意图，如图3所示，描述了人对人(P2P)用例中建立应用数据通道的流程。在这种情景中，MF不被用于锚定应用数据通道。
在呼叫流程中，UE已经建立了IMS音频会话，并且始呼UE正在将IMS音频/视频会话更新为IMS数据通道会话。
如图3所示，P2P应用数据通道的建立过程包括以下步骤：
步骤0，IMS会话和引导数据通道已经被建立。
(一个或多个)所选的数据通道应用已经被下载到UE#1以及UE#2。
步骤1，UE#1通过始呼网络P-CSCF和S-CSCF向IMS AS发送具有更新后的SDP提议的SIP reINVITE请求。
更新后的SDP提议包含引导数据通道信息，以及所请求的应用数据通道和相关联的DC应用绑定信息。
按照现有流程的限制，更新后的SDP提议中应当包含音频/视频的媒体描述作为SDP Offer中的第一媒体描述，即，音频/视频的媒体描述出现在SDP提议的首个m行中。任何用于数据通道的媒体描述都应出现在音频/视频的媒体描述之后。
步骤2，IMS AS进行DC路由决策。
IMS AS验证用户订阅数据，以确定媒体改变请求事件是否应该被通知给DCSF。
步骤3，IMS AS向DSCF发送Nimsas会话事件控制通知。
IMS AS向DSCF发送会话事件通知，即发送Nimsas_SessionEventControl_Notify(SessionEstablishmentRequestEvent、Session ID、事件方向、事件发起者、媒体信息列表)，向DCSF通知媒体改变请求事件。
步骤4，DCSF确定引导数据通道建立请求的处理策略。
在接收到会话事件通知之后，基于通知中的相关参数(即，相关联的DC应用绑定信息)和/或DCSF服务特定策略，DCSF确定关于如何处理应用数据通道建立请求的策略。
步骤5，DSCF允许DC e2e应用流发送至远程方。
DCSF确定SDP提议的新添加的应用数据通道媒体描述信息将UE#2作为目标端点，并且不需要锚定在本地MF或MRF上。如果MF或MRF需要锚定应用数据通道，DCSF将使用Nimsas_MediaControl服务操作来指示IMS AS分配MF或MRF的数据通道媒体资源。
步骤6，DCSF向IMS AS发送Nimsas会话事件控制通知响应。
DCSF响应在步骤3中接收到的通知。
步骤7，IMS AS将re-INVITE发送给I/S-CSCF。
步骤8，I/S-CSCF将re-INVITE发送至终呼网络侧/UE#2。
在步骤7和8中，IMS AS将re-INVITE发送给始呼S-CSCF，然后发送到终呼网络侧和UE#2。在该步骤中，包含用于UE#2的应用数据通道的SDP提议。
步骤9，终呼网络侧和UE#2协商是否接受SDP提议。
步骤10，终呼网络侧和UE#2向I/S-CSCF发送200OK。
步骤11，I/S-CSCF向IMS AS发送200OK。
在步骤9-11中，UE#2和终呼网络向始呼网络返回200OK，其中包含应用数据通道的SDP应答。基于从re-INVITE的SDP提议中的接收到的DC应用绑定信息，UE#2可能需要下载SDP提议中的对应的DC应用(如果尚未下载的话)，并且将其与所请求的应用DC相关联。
步骤12，IMS AS向DCSF发送Nimsas会话事件控制通知。
可以理解为，IMS AS向DCSF通知数据通道修改成功。
步骤13，DCSF反馈Nimsas会话事件控制通知响应。
步骤14,IMS AS向I/S-CSCF发送200OK响应。
步骤15，I/S-CSCF向P-CSCF发送200OK响应。
步骤16，I/S-CSCF和始呼网络执行QoS过程。
始呼网络和P-CSCF基于来自200OK响应的SDP应答信息执行针对应用数据通道媒体的QoS过程。
步骤17，P-CSCF将200OK响应返回到UE#1。
步骤18，UE#1向终呼网络发送ACK。
步骤19，UE#1和UE#2之间的应用数据通道被建立。在本示例中，它没有被锚定在MF/MRF中。
在上述图3过程中，当发送SIP reINVITE/Update(即步骤1/7/8)，针对音频/视频媒体描述的SDP提议应被呈现在第一个媒体行(m line)中。当发送对SIP reINVITE/Update的响应(即，步骤10/11/14/15)时，针对音频/视频媒体描述的SDP应答应被呈现在第一个媒体行中。
如上面的过程(即图2和图3过程)中描述的，数据通道(即，无论是引导数据通道还是应用数据通道)的建立要求同时伴随音频/视频媒体的建立，即，在SDP Offer/SDPAnswer中，音频/视频媒体描述作为首个媒体行(m line)应出现在数据通道媒体描述之前出现。这样的限制降低了数据通道服务的灵活性，尤其是对于那些与音频/视频呼叫会话没有紧密关联的数据通道应用。为了增加数据通道应用的灵活性，数据通道媒体描述与音频/视频媒体描述之间的紧密关联应从SDP提议/应答中移除。
为了支持移除这种紧密关联，需要始呼UE和终呼UE支持无音频/视频的数据通道建立的新功能(即“没有音频/视频的dc”特征)。
本申请实施例提供了一种通信方法，用于在始呼UE与终呼UE之间协商“无音频/视频的数据通道”(即“DC without Audio/Video”)能力。
在一实施例中，图4是本申请实施例提供的一种通信方法的流程图。本实施例应用于支持无音视频的数据通道的能力的情况。本实施例可以由第一通信设备执行。其中，第一通信设备也可以称为第一通信节点。示例性地，第一通信设备可以为始呼UE，第二通信设备可以为终呼UE。如图4所示，本实施例包括：S110-S130。
S110、向第二通信设备发送第一请求消息。
在一示例中，第一请求消息可以为SIP请求消息；SIP请求消息可以为SIP INVITE，也可以为SIP reINVITE。
S120、根据第一请求消息从第二通信设备接收第一响应消息。
在一示例中，在第一请求消息为SIP请求消息的情况下，对应的第一响应消息为SIP响应消息。
S130、基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力。
在一实施例中，第一请求消息携带下述至少之一：与音视频媒体描述非关联的数据通道的多媒体会话提议；指示第一通信设备支持无音视频的数据通道的特征标签。
在一实施例中，多媒体会话提议包括用于数据通道的媒体描述，并且不包括用于音视频的媒体描述。
在一实施例中，根据第一请求消息从第二通信设备接收第一响应消息，包括：从第二通信设备接收第一类型响应消息；其中，第一类型响应消息中的多媒体会话应答至少包括下述之一：用于请求的数据通道的有效媒体描述；用于请求的数据通道的无效媒体描述。在一示例中，在第一请求消息为SIP请求消息的情况下，对应的第一响应消息可以为SIP响应消息，第一类型响应消息可以为SIP 183会话进度响应消息，或者，SIP 200OK响应消息。
在一实施例中，根据第一请求消息从第二通信设备接收第一响应消息，包括：从第二通信设备接收第二类型响应消息；其中，第二类型响应消息用于指示所请求的多媒体会话提议是无法接受的。在一示例中，在第一请求消息为SIP请求消息的情况下，对应的第一响应消息可以为SIP响应消息，第二类型响应消息可以为SIP 4xx响应，比如，SIP 4xx响应可以为SIP 488响应，并且，488响应用于指示SDP提议是无法接受的。
在一实施例中，基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力，包括：基于第一响应消息中的多媒体会话应答确定第二通信设备用于支持无音视频数据通道的能力。
在一实施例中，基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力，包括：
在第一响应消息包括多媒体会话应答，且多媒体会话应答包括用于请求的数据通道的有效媒体描述的情况下，确定第二通信设备具有无音视频数据通道的能力；或者，
在第一响应消息包括多媒体会话应答，且多媒体会话应答包括用于请求的数据通道的无效媒体描述的情况下，确定第二通信设备不具有无音视频数据通道的能力。
在一实施例中，基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力，包括：在第一响应消息指示请求是无法接受的情况下，确定第二通信设备不具有无音视频数据通道的能力。
在一实施例中，根据第一请求消息从第二通信设备接收第一响应消息，包括：从第二通信设备接收第三类型响应消息；其中，第三类型响应消息携带指示第二通信设备支持无音视频的数据通道的特征标签。在一示例中，在第一请求消息为SIP请求消息的情况下，对应的第一响应消息可以为SIP响应消息，第三类型响应消息可以为SIP 183会话进度响应消息，或者，SIP 200OK响应消息。并且，在SIP 183会话进度响应消息，或者，SIP 200OK响应消息携带指示指示终呼UE支持无音频/视频的数据通道的特征标签。
在一实施例中，基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力，包括：在第一响应消息包括第二通信设备支持无音视频的数据通道的特征标签的情况下，确定第二通信设备具有无音视频数据通道的能力。
在一实施例中，数据通道至少包括下述之一：引导数据通道；应用数据通道。
在一实施例中，图5是本申请实施例提供的另一种通信方法的流程图。本实施例应用于支持无音视频的数据通道的能力的情况。本实施例可以由第二通信设备执行。其中，第二通信设备也可以称为第二通信节点。示例性地，第二通信设备可以为终呼UE。如图5所示，本实施例包括：S210-S220。
S210、接收第一通信设备发送的第一请求消息。
S220、根据第一请求消息向第一通信设备发送第一响应消息，以使第一通信设备基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力。
在一实施例中，第一请求消息携带下述至少之一：与音视频媒体描述非关联的数据通道的多媒体会话提议；指示所述第一通信设备支持无音视频的数据通道的特征标签。
在一实施例中，多媒体会话提议包括用于数据通道的媒体描述，并且不包括用于音视频的媒体描述。
在一实施例中，根据第一请求消息向第一通信设备发送第一响应消息，包括：向第一通信设备发送第一类型响应消息；其中，第一类型响应消息中的多媒体会话应答至少包括下述之一：用于请求的数据通道的有效媒体描述；用于请求的数据通道的无效媒体描述。
在一实施例中，根据第一请求消息向第一通信设备发送第一响应消息，包括：向第一通信设备发送第二类型响应消息；其中，第二类型响应消息用于指示所请求的多媒体会话提议是无法接受的。
在一实施例中，根据第一请求消息向第一通信设备发送第一响应消息，包括：向第一通信设备发送第三类型响应消息；其中，第三类型响应消息携带指示第二通信设备支持无音视频的数据通道的特征标签。
在一实施例中，数据通道至少包括下述之一：引导数据通道；应用数据通道。
需要说明的是，应用于第二通信设备的通信方法中的第一请求消息、第一响应消息、多媒体会话提议、第一类型响应消息、第二类型响应消息和第三类型响应消息等参数的解释，参见上述应用于第一通信设备的通信方法中对应参数的描述，在此不再赘述。
在一实施例中，图6是本申请实施例提供的一种无音视频媒体描述的引导数据通道的建立流程示意图，图6所示的过程与图2相似，但有以下不同之处：
步骤1，UE#1向IMS AS发送SIP INVITE请求(包含与音视频媒体描述非关联的数据通道的SDP提议)。
通过始呼网络中的P-CSCF和S-CSCF向IMS AS发送具有SDP提议的SIP INVITE请求。
SDP提议中包含引导数据通道的媒体描述，该引导数据通道的媒体描述包含引导DC流ID。在本示例过程中，SDP Offer中同时包含用于始呼侧和用于终呼侧的引导数据通道的媒体描述。
在本实施例中的SIP INVITE中的SDP提议中不包含音频/视频的媒体描述，即引导数据通道的媒体描述，与音频/视频的媒体描述之间无依赖关系(关联关系)，也意味着数据通道的建立独立于音频/视频通道的建立。
步骤2，IMS AS验证用户订阅数据，以确定数据通道的呼叫请求是否应该被通知给DCSF。
步骤3，IMS AS向DCSF发送会话事件通知。
步骤4，DCSF确定引导数据通道建立请求的处理策略。
步骤5，DCSF创建始呼侧和终呼侧之间的DC媒体信息。
步骤6，DCSF基于其策略调用Nimsas_Media Control_Media Instruction操作。
步骤7，IMS AS发现并选择DCMF或enMRF。
步骤8，IMS AS调用Nmf_MRM_Create服务操作以指示MF分配所需的数据通道媒体资源。
步骤9，IMS AS向DCSF发送Nimsas_Media Control_Media Instruction响应。
步骤10，DCSF向IMS AS发送Nimsas会话事件控制通知响应。
本实施例中的步骤2-10与图2所示的步骤2-10相似，在此不再赘述。步骤2-10的步骤等同于图6所示的在IMS AS,DCSF and MF/MRF之间交互的过程。
步骤11，IMS AS向I/S-CSCF发送SIP INVITE。
步骤12，始呼S-CSCF向终呼网络侧和UE#2发送SIP INVITE。
在步骤11-12中，IMS AS经由始呼S-CSCF向终呼网络侧和UE#2发送SIP INVITE，其中，SIP INVITE包括更新后的SDP提议(即SDP Offer)，在SDP Offer中添加了MF或MRF的媒体信息。
在SIP INVITE中，包括用于UE#2的引导数据通道的SDP提议，即，该SDP提议包含用于UE#2的引导数据通道的的媒体描述。
按照步骤1的描述，在该步骤11-12中，SDP提议中不存在音频/视频的媒体描述。
步骤13，终呼网络侧和UE#2协商是否接受SDP提议。
在接收到SDP提议的情况下，UE#2和终呼网络决定是否能够接受SDP提议，并且相应地产生SDP应答。
由UE#2和终呼网络返回的SDP应答取决于UE#2和终呼网络是否支持“DC withoutAudio/Video”能力：
其一，如果UE#2支持“DC without Audio/Video”，则这意味着UE#2能够正确地处理用于引导数据通道(但无关联的音频/视频媒体描述)的SDP提议。因此，UE#2将分配引导数据通道所需的资源(例如，SCTP端口等)，并且在SDP应答中填写引导数据通道的对应参数。在这种情况下，将返回18x响应(例如，具有SDP应答的“183Session Progress”响应)；
其二，如果UE#2不支持“DC without Audio/Video”，这意味着UE#2不能够正确地处理用于引导数据通道(但无关联的音频/视频媒体描述)的SDP提议。一种方法是，UE#2确定该SDP提议是无效的SDP提议，产生无效的SDP应答(例如，在对应的m行中将SCTP端口设置为0)，并将无效的SDP应答携带在要返回的18x响应(例如，“183Session Progress”)、或200OK响应。另一种方法是，UE#2确定该SDP提议是无效的SDP提议，从而该SIP INVITE不能被接受，因此返回4xx响应(例如，“488Not Acceptable Here”)；
其三，如果终呼网络不支持“DC without Audio/Video”，即使UE#2支持“DCwithout Audio/Video”，终呼网络仍然可以将UE#2产生的SDP应答更改为无效的SDP应答(例如，将SDP Answer中对应的SCTP端口改变为0)；
其四，如果终呼网络支持“DC without Audio/Video”，则它不会对UE#2产生的SDP应答进行更改。
在上述所有情况下，SDP应答中不存在音频/视频的媒体描述。
步骤14，UE#2和终呼网络向始呼网络返回18X、200或4xx响应。
按照步骤13中的决策，UE#2和终呼网络将包含有引导数据通道的SDP应答的18x/200/4xx响应返回到始呼网络。
对于成功响应(例如，具有有效SDP应答的“183Session Progress”)，IMS AS可以指示MF或MRF更新用于UE#2的数据通道媒体资源信息。
对于失败响应(例如，包含无效SDP应答的“183Session Progress”/“200OK”/4xx响应)，IMS AS执行错误处理过程。
在步骤14中接收到18x/200/4xx响应时，UE#1可以基于UE#2和终呼网络返回的SDP应答来确定UE#2是否支持“DC without Audio/Video”。
一种方法是，如果UE#1从UE#2和终呼网络接收到具有有效SDP应答的响应消息，则认为UE#2和终呼网络支持“DC without Audio/Video”特征。
另一种方法是，如果UE#1从UE#2和终呼网络接收到没有特征标签“DC withoutAudio/Video”或者具有无效SDP应答(例如，SCTP端口被设置为0)的响应消息，则认为UE#2和/或终呼网络不支持“DC without Audio/Video”特征。
步骤15，UE#2向I/S-CSCF返回200OK响应。
步骤16，I/S-CSCF向IMS AS返回200OK响应。
步骤17，IMS AS向DCSF发送Nimsas会话事件控制通知。
步骤18，DCSF对Nimsas通知请求作出响应。
本实施例中的步骤17-18与图2的步骤17-18相似，在此不再赘述。
步骤19，IMS AS向UE#1发送200OK。
IMS AS转发到UE#1的200OK，其指示引导数据通道建立的结果。
与步骤14中的确定相似，UE#1可以确定UE#2和终呼网络是否支持“DC withoutAudio/Video”特征。
在一实施例中，图7是本申请实施例提供的另一种无音视频媒体描述的引导数据通道的建立流程示意图，图7描述了基于在始呼UE和终呼UE之间显式的特征标签“DCwithout Audio/Video”的交换，来协商“DC without Audio/Video”能力的流程。
图7所示的实现过程与图2的过程相似，但有以下不同之处：
步骤1，UE#1向IMS AS发送SIP INVITE请求(包含支持无音视频媒体的数据通道的SDP提议)。
UE#1通过始呼网络中的P-CSCF和S-CSCF向IMS AS发送具有SDP提议的SIP INVITE请求。
SDP提议中包含引导数据通道的媒体描述，该引导数据通道媒体描述包含引导DC流ID。在本示例过程中，SDP Offer中同时包含用于始呼侧和用于终呼侧的引导数据通道的媒体描述。
进一步地，在本实施例中的SIP INVITE中的SDP offer包含无音视频的数据通道(DC without Audio/Video)的特征标签，以指示始呼UE(UE#1)支持无音频/视频的数据通道建立的特征。
在SIP INVITE中，SDP提议中不包含音频/视频媒体描述，即引导数据通道的媒体描述，和音频/视频的媒体描述无依赖关系(关联关系)，也意味着数据通道的建立独立于音频/视频通道的建立。
步骤2，IMS AS验证用户订阅数据，以确定数据通道的呼叫请求是否应该被通知给DCSF。
步骤3，IMS AS向DCSF发送会话事件通知。
步骤4，DCSF确定引导数据通道建立请求的处理策略。
步骤5，DCSF创建始呼侧和终呼侧之间的DC媒体信息。
步骤6，DCSF基于其策略调用Nimsas_Media Control_Media Instruction操作。
步骤7，IMS AS发现并选择DCMF或enMRF。
步骤8，IMS AS调用Nmf_MRM_Create服务操作以指示MF分配所需的数据通道媒体资源。
步骤9，IMS AS向DCSF发送Nimsas_Media Control_Media Instruction响应。
步骤10，DCSF向IMS AS发送Nimsas会话事件控制通知响应。
本实施例中的步骤2-10与图2所示的步骤2-10相似，在此不再赘述。
步骤11，IMS AS向始呼S-CSCF发送SIP INVITE。
步骤12，始呼S-CSCF向终呼网络侧和UE#2发送SIP INVITE。
在步骤11-12中，IMS AS经由始呼S-CSCF向终呼网络侧和UE#2发送SIP INVITE，在更新的SDP Offer中添加了MF或MRF的媒体信息。
在SIP INVITE中，包括用于到UE#2的引导数据通道的SDP提议，即，该SDP提议包含用于到UE#2的引导数据通道的媒体描述。
在SIP INVITE中，包含无音视频的数据通道(DC without Audio/Video)的特征标签。
在SIP INVITE中，SDP提议中不存在音频/视频的媒体描述。
步骤13，终呼网络侧和UE#2协商是否接受SDP提议。
在接收到SIP INVITE后，根据包含的特征标签“DC without Audio/Video”、包含引导数据通道的SDP提议，UE#2和终呼网络决定是否能够接受SDP提议，并且相应地产生SDP应答。
由UE#2和终呼网络返回的SDP应答取决于UE#2和终呼网络是否支持“DC withoutAudio/Video”特征：
其一，如果UE#2支持“DC without Audio/Video”，则这意味着UE#2能够识别SIPINVI TE中的特征标签“DC without Audio/Video”，并且能够正确地处理仅包含引导数据通道的(但无关联的音频/视频媒体描述)的SDP提议。因此，UE#2将分配引导数据通道所需的资源(例如，SCTP端口等)，并且在SDP应答中填写引导数据通道的对应参数。此时，UE#2返回18x响应(例如，具有有效SDP应答的“183 Session Progress”响应)，在18x响应中，UE#2包括特征标签“DC without Audio/Video”，以指示其自身(UE#2)的无音频/视频数据通道建立的能力；
其二，如果UE#2不支持“DC without Audio/Video”，则这意味着UE#2不能够识别SIP INVITE中的特征标签“DC without Audio/Video”，也不能够正确地处理仅包含引导数据通道的(但无关联的音频/视频媒体描述)SDP提议。一种方法是，UE#2确定该SDP提议是无效的SDP提议，从而产生无效的SDP应答(例如，在对应的m行中将SCTP端口设置为0)，并且将无效的SDP应答携带在返回的18x响应(例如，“183 Session Progress”)、或200OK响应。另一种方法是，UE#2确定该SDP提议是无效的SDP提议，从而SIP INVITE不能被接受，因此返回4xx响应(例如，“488 Not Acceptable Here”)；
其三，如果终呼网络不支持“DC without Audio/Video”，即使UE#2支持“DCwithout Audio/Video”，终呼网络仍然可以将UE#2产生的SDP应答更改为无效的SDP应答(如，将SDP Answer中的SCTP端口改变为0)，或者，从SIP响应(18x/200/4xx响应)中移除特征标签“DC without Audio/Video”；
如果终呼网络支持“DC without Audio/Video”，则它不会对UE#2产生的SDP应答进行更改，也不会从UE#2产生的SIP响应(18x/200/4xx响应)中移除特征标签“DC withoutAudio/Video”。
在上述所有情况下，SDP应答中不存在音频/视频媒体描述。
步骤14，UE#2和终呼网络向始呼网络返回18X、200或4xx响应。
按照步骤13中的决策，UE#2和终呼网络将具有对引导数据通道的SDP应答的18x/200/4xx响应返回到始呼网络。
对于成功响应(例如，具有特征标签“DC without Audio/Video”且包含有效SDP应答的“183Session Progress”)，IMS AS可以指示MF或MRF更新用于UE#2的数据通道媒体资源信息。
对于失败响应(例如，不具有特征标签“DC without Audio/Video”的“183SessionProgress”/“200OK”，或者包含无效SDP应答的“183Session Progress”/“200OK”/4xx响应)，IMS AS执行错误处理过程。
在步骤14中接收到18x/200/4xx响应时，UE#1可以基于特征标签“DC withoutAudio/Video”和/或返回的SDP应答来确定UE#2是否支持“DC without Audio/Video”。
一种方法是，如果UE#1从UE#2和终呼网络接收到具有特征标签“DC withoutAudio/Video”的响应消息，则认为UE#2和终呼网络支持“DC without Audio/Video”特征。
另一种方法是，如果UE#1从UE#2和终呼网络接收到没有特征标签“DC withoutAudio/Video”或包含无效的SDP应答的响应消息，则认为UE#2和/或终呼网络不支持“DCwithout Audio/Video”特征。
步骤15，UE#2向I/S-CSCF返回200OK响应.
步骤16，I/S-CSCF向IMS AS返回200OK响应。
类似步骤14，步骤15-16可用于相同目的。即在15-16步骤中，在SIP响应中包含特征标签“DC without Audio/Video”，以指示UE#2和终呼网络对“DC without Audio/Video”特征的支持。
步骤17，IMS AS向DCSF发送Nimsas会话事件控制通知。
步骤18，DCSF对Nimsas通知请求作出响应。
步骤19，IMS AS向UE#1发送200OK。
IMS AS转发到UE#1的200OK，其指示引导数据通道建立的结果。
与步骤14中的确定相似，UE#1可以确定UE#2和终呼网络是否支持“DC withoutAudio/Video”特征。
在图6和图7中描述的过程中，“DC without Audio/Video”的能力协商发生引导数据通道的建立过程中。类似地，这种协商机制也可以适用于应用数据通道建立过程，其中具有相似的增强。
使用图6和图7中描述的过程，在IMS会话建立的流程中，始呼UE能够与终呼UE协商对无音频/视频的数据通道建立的支持(即“DC without Audio/Video”)，从而能够在不涉及音频/视频呼叫的情况下发起纯数据通道的IMS会话。
需要指出的是，图7所描述的过程，即通过显式的特征标签来协商是否支持“DCwithout Audio/Video”方法，也可以发生在非IMS会话建立的其他流程(如SIP消息发送流程)中，一种典型的方式是，UE#1向UE#2发送SIP Message，在SIP Message中携带自身的“DCwithout Audio/Video”能力标签，而UE#2也相应地返回自身的能力标签，从而协商各自的能力。
在一实施例中，图8是本申请实施例提供的一种通信装置的结构框图。本实施例应用于第一通信设备。如图8所示，本实施例中的通信装置包括：发送器310、接收器320和确定模块330。
发送器310，配置为向第二通信设备发送第一请求消息。
接收器320，配置为根据第一请求消息从第二通信设备接收第一响应消息。
确定模块330，配置为基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力。
在一实施例中，第一请求消息携带下述至少之一：与音视频媒体描述非关联的数据通道的多媒体会话提议；指示所述第一通信设备支持无音视频的数据通道的特征标签。
在一实施例中，多媒体会话提议包括用于数据通道的媒体描述，并且不包括用于音视频的媒体描述。
在一实施例中，接收器320，还配置为从第二通信设备接收第一类型响应消息；其中，第一类型响应消息中的多媒体会话应答至少包括下述之一：用于请求的数据通道的有效媒体描述；用于请求的数据通道的无效媒体描述。
在一实施例中，接收器320，还配置为从第二通信设备接收第二类型响应消息；其中，第二类型响应消息用于指示所请求的多媒体会话提议是无法接受的。
在一实施例中，确定模块330，还配置为基于第一响应消息中的多媒体会话应答确定第二通信设备用于支持无音视频数据通道的能力。
在一实施例中，确定模块330，还配置为：
在第一响应消息包括多媒体会话应答，且多媒体会话应答包括用于请求的数据通道的有效媒体描述的情况下，确定第二通信设备具有无音视频数据通道的能力；或者，
在第一响应消息包括多媒体会话应答，且多媒体会话应答包括用于请求的数据通道的无效媒体描述的情况下，确定第二通信设备不具有无音视频数据通道的能力。
在一实施例中，确定模块330，还配置为在第一响应消息指示请求是无法接受的情况下，确定第二通信设备不具有无音视频数据通道的能力。
在一实施例中，接收器320，还配置为从第二通信设备接收第三类型响应消息；其中，第三类型响应消息均携带指示第二通信设备支持无音视频的数据通道的特征标签。
在一实施例中，确定模块330，还配置为在第一响应消息包括第二通信设备支持无音视频的数据通道的特征标签的情况下，确定第二通信设备具有无音视频数据通道的能力。
在一实施例中，数据通道至少包括下述之一：引导数据通道；应用数据通道。
本实施例提供的通信装置设置为实现图4所示实施例的应用于第一通信设备的通信方法，本实施例提供的通信装置实现原理和技术效果类似，此处不再赘述。
在一实施例中，图9是本申请实施例提供的另一种通信装置的结构框图。本实施例应用于第二通信设备。如图9所示，本实施例中的通信装置包括：接收器410和发送器420。
接收器410，配置为接收第一通信设备发送的第一请求消息。
发送器420，配置为根据第一请求消息向第一通信设备发送第一响应消息，以使第一通信设备基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力。
在一实施例中，第一请求消息携带下述至少之一：与音视频媒体描述非关联的数据通道的多媒体会话提议；指示所述第一通信设备支持无音视频的数据通道的特征标签。
在一实施例中，多媒体会话提议包括用于数据通道的媒体描述，并且不包括用于音视频的媒体描述。
在一实施例中，根据第一请求消息向第一通信设备发送第一响应消息，包括：向第一通信设备发送第一类型响应消息；其中，第一类型响应消息中的多媒体会话应答至少包括下述之一：用于请求的数据通道的有效媒体描述；用于请求的数据通道的无效媒体描述。
在一实施例中，根据第一请求消息向第一通信设备发送第一响应消息，包括：向第一通信设备发送第二类型响应消息；其中，第二类型响应消息用于指示所请求的多媒体会话提议是无法接受的。
在一实施例中，第一请求消息还携带指示第一通信设备支持无音视频的数据通道的特征标签。
在一实施例中，根据第一请求消息向第一通信设备发送第一响应消息，包括：向第一通信设备发送第三类型响应消息；其中，第三类型响应消息携带指示第二通信设备支持无音视频的数据通道的特征标签。
在一实施例中，数据通道至少包括下述之一：引导数据通道；应用数据通道。
本实施例提供的通信装置设置为实现图5所示实施例的应用于第二通信设备的通信方法，本实施例提供的通信装置实现原理和技术效果类似，此处不再赘述。
在一实施例中，图10是本申请实施例提供的一种通信设备的结构示意图。如图10所示，本申请提供的设备，包括：处理器510、存储器520和通信模块530。该设备中处理器510的数量可以是一个或者多个，图10中以一个处理器510为例。该设备中存储器520的数量可以是一个或者多个，图10中以一个存储器520为例。该设备的处理器510、存储器520和通信模块530可以通过总线或者其他方式连接，图10中以通过总线连接为例。在该实施例中，该设备为可以为第一通信设备和第二通信设备。
存储器520作为一种计算机可读存储介质，可设置为存储软件程序、计算机可执行程序以及模块，如本申请任意实施例的设备对应的程序指令/模块(例如，通信装置中的发送器310、接收器320和确定模块330)。存储器520可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据设备的使用所创建的数据等。此外，存储器520可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器520可进一步包括相对于处理器510远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
在通信设备为第一通信设备的情况下，上述提供的设备可设置为执行上述任意实施例提供的应用于第一通信设备的通信方法，具备相应的功能和效果。
在通信设备为第二通信设备的情况下，上述提供的设备可设置为执行上述任意实施例提供的应用于第二通信设备的通信方法，具备相应的功能和效果。
本申请实施例还提供一种包含计算机可执行指令的存储介质，计算机可执行指令在由计算机处理器执行时用于执行一种应用于第一通信设备的通信方法，该方法包括：向第二通信设备发送第一请求消息；根据第一请求消息从第二通信设备接收第一响应消息；基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力。
本申请实施例还提供一种包含计算机可执行指令的存储介质，计算机可执行指令在由计算机处理器执行时用于执行一种应用于第二通信设备的通信方法，该方法包括：接收第一通信设备发送的第一请求消息；根据第一请求消息向第一通信设备发送第一响应消息，以使第一通信设备基于第一响应消息确定第二通信设备用于支持无音视频数据通道的能力。
本领域内的技术人员应明白，术语用户设备涵盖任何适合类型的无线用户设备，例如移动电话、便携数据处理装置、便携网络浏览器或车载移动台。
一般来说，本申请的多种实施例可以在硬件或专用电路、软件、逻辑或其任何组合中实现。例如，一些方面可以被实现在硬件中，而其它方面可以被实现在可以被控制器、微处理器或其它计算装置执行的固件或软件中，尽管本申请不限于此。
本申请的实施例可以通过移动装置的数据处理器执行计算机程序指令来实现，例如在处理器实体中，或者通过硬件，或者通过软件和硬件的组合。计算机程序指令可以是汇编指令、指令集架构(Instruction Set Architecture，ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码。
本申请附图中的任何逻辑流程的框图可以表示程序步骤，或者可以表示相互连接的逻辑电路、模块和功能，或者可以表示程序步骤与逻辑电路、模块和功能的组合。计算机程序可以存储在存储器上。存储器可以具有任何适合于本地技术环境的类型并且可以使用任何适合的数据存储技术实现，例如但不限于只读存储器(Read-Only Memory，ROM)、随机访问存储器(Random Access Memory，RAM)、光存储器装置和系统(数码多功能光碟(Digital Video Disc，DVD)或光盘(Compact Disk，CD))等。计算机可读介质可以包括非瞬时性存储介质。数据处理器可以是任何适合于本地技术环境的类型，例如但不限于通用计算机、专用计算机、微处理器、数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑器件(Field-Programmable Gate Array，FGPA)以及基于多核处理器架构的处理器。
以上仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
Claims (20)
1.一种通信方法，其特征在于，应用于第一通信设备，包括：
向第二通信设备发送第一请求消息；
根据所述第一请求消息从所述第二通信设备接收第一响应消息；
基于所述第一响应消息确定所述第二通信设备用于支持无音视频数据通道的能力。
2.根据权利要求1所述的方法，其特征在于，所述第一请求消息携带下述至少之一：与音视频媒体描述非关联的数据通道的多媒体会话提议；指示所述第一通信设备支持无音视频的数据通道的特征标签。
3.根据权利要求2所述的方法，其特征在于，所述多媒体会话提议包括用于数据通道的媒体描述，并且不包括用于音视频的媒体描述。
4.根据权利要求2所述的方法，其特征在于，所述根据所述第一请求消息从所述第二通信设备接收第一响应消息，包括：
从所述第二通信设备接收第一类型响应消息；其中，所述第一类型响应消息中的多媒体会话应答至少包括下述之一：用于请求的数据通道的有效媒体描述；用于请求的数据通道的无效媒体描述。
5.根据权利要求2所述的方法，其特征在于，所述根据所述第一请求消息从所述第二通信设备接收第一响应消息，包括：
从所述第二通信设备接收第二类型响应消息；其中，所述第二类型响应消息用于指示所请求的多媒体会话提议是无法接受的。
6.根据权利要求2所述的方法，其特征在于，所述基于所述第一响应消息确定所述第二通信设备用于支持无音视频数据通道的能力，包括：
基于所述第一响应消息中的多媒体会话应答确定所述第二通信设备用于支持无音视频数据通道的能力。
7.根据权利要求2所述的方法，其特征在于，所述基于所述第一响应消息确定所述第二通信设备用于支持无音视频数据通道的能力，包括：
在所述第一响应消息包括多媒体会话应答，且所述多媒体会话应答包括用于请求的数据通道的有效媒体描述的情况下，确定所述第二通信设备具有无音视频数据通道的能力；或者，
在所述第一响应消息包括多媒体会话应答，且所述多媒体会话应答包括用于请求的数据通道的无效媒体描述的情况下，确定所述第二通信设备不具有无音视频数据通道的能力。
8.根据权利要求2所述的方法，其特征在于，所述基于所述第一响应消息确定所述第二通信设备用于支持无音视频数据通道的能力，包括：
在所述第一响应消息指示请求是无法接受的情况下，确定所述第二通信设备不具有无音视频数据通道的能力。
9.根据权利要求2所述的方法，其特征在于，所述根据所述第一请求消息从所述第二通信设备接收第一响应消息，包括：
从所述第二通信设备接收第三类型响应消息；其中，所述第三类型响应消息携带指示所述第二通信设备支持无音视频的数据通道的特征标签。
10.根据权利要求2或9所述的方法，其特征在于，所述基于所述第一响应消息确定所述第二通信设备用于支持无音视频数据通道的能力，包括：
在所述第一响应消息包括第二通信设备支持无音视频的数据通道的特征标签的情况下，确定所述第二通信设备具有无音视频数据通道的能力。
11.根据权利要求1-9任一项所述的方法，其特征在于，所述数据通道至少包括下述之一：引导数据通道；应用数据通道。
12.一种通信方法，其特征在于，应用于第二通信设备，包括：
接收第一通信设备发送的第一请求消息；
根据所述第一请求消息向所述第一通信设备发送第一响应消息，以使所述第一通信设备基于所述第一响应消息确定所述第二通信设备用于支持无音视频数据通道的能力。
13.根据权利要求12所述的方法，其特征在于，所述第一请求消息携带下述至少之一：与音视频媒体描述非关联的数据通道的多媒体会话提议；指示所述第一通信设备支持无音视频的数据通道的特征标签。
14.根据权利要求13所述的方法，其特征在于，所述多媒体会话提议包括用于数据通道的媒体描述，并且不包括用于音视频的媒体描述。
15.根据权利要求12所述的方法，其特征在于，所述根据所述第一请求消息向所述第一通信设备发送第一响应消息，包括：
向所述第一通信设备发送第一类型响应消息；其中，所述第一类型响应消息中的多媒体会话应答至少包括下述之一：用于请求的数据通道的有效媒体描述；用于请求的数据通道的无效媒体描述。
16.根据权利要求12所述的方法，其特征在于，所述根据所述第一请求消息向所述第一通信设备发送第一响应消息，包括：
向所述第一通信设备发送第二类型响应消息；其中，所述第二类型响应消息用于指示所请求的多媒体会话提议是无法接受的。
17.根据权利要求13所述的方法，其特征在于，所述根据所述第一请求消息向所述第一通信设备发送第一响应消息，包括：
向所述第一通信设备发送第三类型响应消息；其中，所述第三类型响应消息携带指示所述第二通信设备支持无音视频的数据通道的特征标签。
18.根据权利要求12-17任一项所述的方法，其特征在于，所述数据通道至少包括下述之一：引导数据通道；应用数据通道。
19.一种通信设备，其特征在于，包括：存储器，以及一个或多个处理器；
所述存储器，配置为存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上述权利要求1-11或12-18任一项所述的方法。
20.一种存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述权利要求1-11或12-18中任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410046664.5A CN117938815A (zh) | 2024-01-11 | 2024-01-11 | 通信方法、设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410046664.5A CN117938815A (zh) | 2024-01-11 | 2024-01-11 | 通信方法、设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117938815A true CN117938815A (zh) | 2024-04-26 |
Family
ID=90768036
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410046664.5A Pending CN117938815A (zh) | 2024-01-11 | 2024-01-11 | 通信方法、设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117938815A (zh) |
-
2024
- 2024-01-11 CN CN202410046664.5A patent/CN117938815A/zh active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8717876B2 (en) | Providing packet-based multimedia services via a circuit bearer | |
| EP2112798B1 (en) | Service controlling in a service provisioning system | |
| US8774178B2 (en) | Call transfer with multiple application servers in session initiation protocol-based network | |
| US8325707B2 (en) | Session initiation from application servers in an IP multimedia subsystem | |
| CN101563903B (zh) | 用于向用户提供ip多媒体子系统通信服务的方法和设备 | |
| US20090185557A1 (en) | Method and Device for Selecting Service Domain | |
| EP2587777B1 (en) | Method and system for implementing color ring back tone and multimedia ring alert tone service. | |
| US9071690B2 (en) | Call transfer processing in SIP mode | |
| US10313400B2 (en) | Method of selecting a network resource | |
| US9648050B2 (en) | Routing of a service request aimed at an IMS subscriber | |
| US11418635B2 (en) | Method of dynamic selection, by a caller, from a plurality of terminals of a callee | |
| CN117938815A (zh) | 通信方法、设备及存储介质 | |
| EP2249541A1 (en) | Distribution of communication flows between two nodes linked by different network paths | |
| US11277451B2 (en) | Method and entity for managing a multimedia session between a calling terminal and at least one called terminal, corresponding terminal and computer programs | |
| CN111492633B (zh) | 用于ims基础设施中的媒体传递会话的方法、系统和实体 | |
| US11283842B2 (en) | Method for controlling a communication comprising multiple transactions | |
| CN110089097B (zh) | 通信网络中的呼叫碰撞解决 | |
| EP2059001A1 (en) | Multitype SIP processing element | |
| KR20220018761A (ko) | 얼리 세션 모델 기반 비디오 cat을 제공하기 위한 통신 프로토콜 | |
| US10608898B2 (en) | Dynamic method for determining a list of services in an SIP network | |
| CN102195926B (zh) | 一种媒体处理方法及相关设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication |