CN115460322A

CN115460322A - 通信协商的方法及装置、电子设备、计算机可读存储介质

Info

Publication number: CN115460322A
Application number: CN202110641455.1A
Authority: CN
Inventors: 李贺
Original assignee: Beijing Xiaomi Mobile Software Co Ltd
Current assignee: Beijing Xiaomi Mobile Software Co Ltd
Priority date: 2021-06-09
Filing date: 2021-06-09
Publication date: 2022-12-09

Abstract

本公开是关于通信协商的方法及装置、电子设备、计算机可读存储介质。方法包括：向被叫设备发送建立通话的邀请报文，接收其返回的响应报文；响应于被叫设备要求网络放音，根据响应报文中的链路消息与主叫侧服务器建立链路；响应于建立的链路不符合响应报文中目标早期媒体字段对应的链路要求，确定主叫设备运营商是否属于预设运营商；响应于主叫设备运营商属于预设运营商，确定二者协商成功，继续进行通话。本公开针对主叫与被叫的运营商采用的早期媒体模式不兼容的问题，在主叫确定其建立的链路不能满足被叫的链路要求时，对主叫运营商是否为预设的运营商进行确定，并在是的情况下确定二者针对早期媒体协商成功，保障二者间的通话能够正常进行。

Description

通信协商的方法及装置、电子设备、计算机可读存储介质

技术领域

本公开涉及通信技术领域，尤其涉及通信协商的方法及装置、电子设备、计算机可读存储介质。

背景技术

彩铃业务一直是运营商的主要增值业务之一。在实际的通信过程中，为了对主叫与被叫之间的通话数据和彩铃数据加以区分，将所述通话数据定义为常规媒体，而将所述彩铃数据定义为早期媒体。

早期媒体存在多种模式，包括本地放音的模式和网络放音的模式，网络放音的模式则还可再分为双向网络放音模式以及单向网络放音模式。不同运营商采用的早期媒体模式可能并不相同，在主叫与被叫的运营商所采用的早期媒体模式互不兼容的情况下，主叫与被叫针对早期媒体的协商将会失败，产生主叫与被叫无法正常通话的问题。

发明内容

本公开提供通信协商的方法及装置、电子设备、计算机可读存储介质，以解决相关技术中的不足。

根据本公开实施例的第一方面，提出一种通信协商的方法，所述方法应用于主叫设备，包括：

向被叫设备发送建立通话的邀请报文，接收所述被叫设备返回的响应报文；

响应于所述被叫设备要求网络放音，根据所述响应报文中的链路消息与主叫侧服务器建立用于传输网络放音数据的链路；

响应于建立的链路不符合所述响应报文中目标早期媒体字段对应的链路要求，确定所述主叫设备的运营商是否属于预设的运营商；

响应于所述主叫设备的运营商属于所述预设的运营商，确定与所述被叫设备针对早期媒体协商成功，执行网络放音后继续执行与所述被叫设备之间的通话。

根据本公开实施例的第二方面，提出一种通信协商的装置，所述装置应用主叫设备，包括报文收发模块、链路建立模块、运营商确定模块和通话执行模块：

所述报文收发模块，用于向被叫设备发送建立通话的邀请报文，接收所述被叫设备返回的响应报文；

所述链路建立模块，用于响应于所述被叫设备要求网络放音，根据所述响应报文中的链路消息与主叫侧服务器建立用于传输网络放音数据的链路；

所述运营商确定模块，用于响应于建立的链路不符合所述响应报文中目标早期媒体字段对应的链路要求，确定所述主叫设备的运营商是否属于预设的运营商；

所述通话执行模块，用于响应于所述主叫设备的运营商属于所述预设的运营商，确定与所述被叫设备针对早期媒体协商成功，执行网络放音后继续执行与所述被叫设备之间的通话。

根据本公开实施例的第三方面，提出一种电子设备，包括处理器和用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令实现如上述第一方面所述方法中的步骤。

根据本公开实施例的第四方面，提出一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述第一方面所述方法中的步骤。

本公开实施例提供的技术方案可以包括以下有益效果：

针对主叫与被叫的运营商所采用的早期媒体模式不兼容的问题，在主叫检测出其建立的链路不能满足被叫响应报文中目标早期媒体字段对应的链路要求时，检测主叫设备的运营商是否为预设的运营商，并在是的情况下，确定二者针对早期媒体协商成功，主叫执行网络放音后，继续与被叫执行通话流程而不会取消通话，保障二者间的通信正常进行。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种通信协商的方法流程图。

图2是根据另一示例性实施例示出的一种通信协商的方法流程图。

图3是根据另一示例性实施例示出的一种通信协商的方法流程图。

图4是根据一示例性实施例示出的一种通信协商的装置的框图。

图5是根据一示例性实施例示出的一种通信协商的装置所在电子设备的示意框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在通信领域中，主动发起通话的一方为主叫方，被动接收通话的一方为被叫方。在进行跨运营商通话的场景下，主叫方使用的主叫设备将通过主叫侧服务器与被叫设备通信，所述主叫侧服务器由主叫设备的运营商提供；而被叫方使用的被叫设备将通过被叫侧服务器与主叫设备通信，所述被叫侧服务器则由被叫设备的运营商提供。可以理解的是，除了所述主叫侧服务器和被叫侧服务器，主叫设备和被叫设备的交互数据也可以经过交换机、网关等网络设备，此处不再赘述。

在实际通话前，主叫设备与被叫设备之间可以交互彩铃、彩振等多媒体数据，区别于双方实际的通话数据，这种在实际通话前进行的数据传输被定义为早期媒体。

早期媒体模式包括本地放音模式和网络放音模式。在早期媒体模式为本地放音模式下，通话设备可以播放缓存在本地的音频而无需与所在侧服务器建立链路；而在早期媒体模式为网路放音模式下，通话设备将与所在侧服务器建立链路，从而向对方发送己方指定的早期媒体数据或接收对方发送的其指定的早期媒体数据，即所述通话设备将播放其所在侧服务器转达的音频。

所述网络放音的模式，还进一步包括双向网络放音模式和单向网络放音模式。二者的区别在于，当通话设备的运营商所支持的早期媒体模式为双向网络放音模式时，通话设备可以与其所在侧服务器同时建立上行链路和下行链路，因而既可以向对方发送己方指定的早期媒体数据，又可以接收对方发送的其指定的早期媒体数据；当通话设备的运营商所支持的早期媒体模式为单向网络放音模式时，则通话设备只可以与其所在侧服务器建立下行链路而不可以与所在侧服务器建立上行链路，因而只能够接收对方发送的其指定的早期媒体数据而不会向对方发送己方指定的早期媒体数据。

不同运营商所采用的早期媒体模式不尽相同，在进行跨运营商通话的场景下，经常发生由于主叫与被叫的运营商采用互不兼容的早期媒体模式，导致主叫与被叫针对早期媒体协商失败而无法继续进行通话的问题。

举例来说，当主叫设备的运营商采用的早期媒体模式为单向网络放音模式时，如果被叫设备的运营商采用的早期媒体模式为双向网络放音模式，基于3GPP(3rdGeneration Partnership Project，第三代合作伙伴计划)的协议规范，主叫设备将在检测到自身不能与主叫侧服务器建立所述双向网络放音模式所要求的上行链路后，确定其与被叫设备针对早期媒体协商失败，主动取消与被叫设备之间的通话。然而，事实上，主叫设备缺少与主叫侧服务器之间的上行链路并不会对早期媒体数据的传输产生影响，主叫设备与主叫侧服务器之间的下行链路已然能够实现将被叫设备的彩铃等音频数据传输至主叫设备，因而主叫设备没有必要取消与被叫设备之间的通话。

有鉴于此，本说明书提供一种通信协商的方法，在不需要供应商服务器更改配置、维持原有协议规范的情况下，通过对主叫设备的运营商加以检测，规避上述因早期媒体协商失败而无法通话的问题。

所述通信协商的方法应用于电子设备，所述电子设备在本次通信协商的过程中为主叫设备。所述通信协商的方法包括以下步骤：

步骤102，主叫设备向被叫设备发送建立通话的邀请报文，接收所述被叫设备返回的响应报文。

在主叫设备与被叫设备建立通话的过程中，首先，主叫设备将主动向所欲联系的被叫设备发送建立通话的邀请报文，所述邀请报文可以经由主叫侧服务器、主叫方与被叫方之间的交换机、网关等网络设备、以及被叫侧服务器的转发，最终到达所述被叫设备。可以理解的是，在一些实现方式中，主叫设备在发送邀请报文前，还需要向主叫侧服务器、交换机、漫游服务器等查询被叫设备的通信地址或号码，具体内容可以参见相关技术，此处不再赘述。

被叫设备在接收到主叫设备发来的邀请报文后，将根据自身状态向主叫设备返回响应报文。通常，所述响应报文为用于协商早期媒体的信令报文，它的报文头域中存在着目标早期媒体字段，所述目标早期媒体字段可以表征被叫设备的运营商所采用的早期媒体模式。主叫设备将在接收到所述响应报文后对其中的目标早期媒体字段进行提取，检测所述目标早期媒体字段是否对应网络放音的模式，以确定被叫设备是否要求网络放音。

举例来说，当响应报文头域中的目标早期媒体字段P-Early-Media(缩写为PEM字段)的字段值为sendrecv或sendonly时表征被叫设备的运营商采用的早期媒体模式为网络放音的模式，其中，PEM字段值为sendrecv时对应双向网络放音模式，PEM字段值为sendonly时对应单向网络放音模式。若主叫设备提取得到响应报文头域中P-Early-Media字段的字段值为sendrecv或sendonly，则可以确定被叫设备要求主叫设备执行网络放音。

步骤104，响应于所述被叫设备要求网络放音，所述主叫设备根据所述响应报文中的链路消息与主叫侧服务器建立用于传输网络放音数据的链路。

在被叫设备要求网络放音的情况下，被叫设备向主叫设备返回的响应报文中携带着链路消息，所述链路消息用于指示主叫设备如何与主叫侧服务器建立传输网络放音数据的链路，其中包括诸如流量限制的链路要求等；所述链路消息包括上行链路消息和/或下行链路消息，具体所包括的链路消息的数量和类型与被叫设备的运营商所采用的早期媒体模式相对应。

主叫设备在确定被叫设备要求网络放音后，将根据所述响应报文中的链路消息与主叫侧服务器建立链路，具体地，主叫设备可以根据响应报文中的上行链路消息与主叫侧服务器建立相应的上行链路，根据响应报文中的下行链路消息与主叫侧服务器建立相应的下行链路。

步骤106，响应于建立的链路不符合所述响应报文中目标早期媒体字段对应的链路要求，所述主叫设备确定其运营商是否属于预设的运营商。

在确定请求与主叫侧服务器建立的上行链路和/或下行链路建立成功后，主叫设备将确定已建立成功的链路是否符合响应报文中目标早期媒体字段对应的链路要求。

响应报文中的目标早期媒体字段	链路要求
		PEM＝sendrecv	上行链路和下行链路均建立成功
PEM＝sendonly	下行链路建立成功

表1

如表1所示，当响应报文中的目标早期媒体字段为sendrecv时，被叫设备的运营商采用双向网络放音模式，其对应的链路要求为：上行链路和下行链路均建立成功；当响应报文中的目标早期媒体字段为sendonly时，被叫设备的运营商采用单向网络放音模式，其对应的链路要求：下行链路建立成功。根据表1，主叫设备可以检测其与主叫侧服务器建立的链路是否符合响应报文中目标早期媒体字段对应的链路要求。

以响应报文中目标早期媒体字段P-Early-Media的字段值为sendrecv为例，其对应的的链路要求是：上行链路和下行链路均建立成功，主叫设备在检测到建立成功的链路中既包括上行链路又包括下行链路时，说明二者均采用双向网络放音模式，可以正常执行网络放音。

主叫设备在检测到建立的链路不符合所述目标早期媒体字段对应的链路要求时，为避免前文所述因主叫与被叫的早期媒体模式不兼容而导致主叫取消通话的问题，主叫设备将检测其运营商是否为预设的运营商。

当响应报文中的目标早期媒体字段对应的链路要求中要求建立上行链路，而主叫设备检测到建立成功的链路不包括上行链路后，主叫设备可以检测其运营商是否属于预设的运营商。主叫设备上预设的若干运营商采用的早期媒体模式为单向网络放音模式，预设的具体为何运营商以及具体为几个运营商可以由技术人员视商业合作以及应用场景等进行配置。

步骤108，响应于所述主叫设备的运营商属于所述预设的运营商，确定所述主叫设备与所述被叫设备针对早期媒体协商成功，继续执行与所述被叫设备之间的通话。

在确定主叫设备的运营商属于预设的运营商后，主叫设备可以确定其与被叫设备针对早期媒体协商成功，正常执行网络放音，包括向被叫设备反馈早期媒体协商成功，接收并播放后续传达的音频数据等；网络放音结束后，主叫设备可以继续执行与被叫设备之间的通话，有关主叫设备在网络放音后继续与被叫设备进行通话的具体流程，可以参见相关技术，此处不再赘述。

在确定主叫设备的运营商不属于预设的运营商后，主叫设备可以确定其与被叫设备针对早期媒体协商失败，向被叫设备取消本次通话。

以被叫设备的运营商采用双向网络放音模式为例，所述响应报文中将携带上行链路消息和下行链路消息，以使主叫设备与主叫侧服务器建立相应的上行链路和下行链路，然而，若主叫设备的运营商采用的早期媒体模式是与之不兼容单向网络放音模式，则基于3GPP协议规范，主叫侧服务器将在转发所述响应报文至主叫设备时删除所述响应报文中的上行链路消息，主叫设备只能与主叫侧服务器建立下行链路，建立成功的链路因而不能包括目标早期媒体字段sendrecv所要求的上行链路。但通过将所述主叫设备的运营商设置为预设的运营商，在检测到建立成功的链路不满足链路要求后，主叫设备仍可以通过运营商识别确定早期媒体协商成功，正常执行网络放音，并继续执行与被叫设备之间的通话。

综上，采用图1所示实施例提出的通信协商的方法，针对主叫与被叫的运营商所采用的早期媒体模式不兼容的问题，在主叫检测出其建立成功的链路不能满足被叫响应报文中目标早期媒体字段对应的链路要求时，检测主叫设备的运营商是否为预设的运营商，并在是的情况下，确定二者针对早期媒体协商成功，主叫执行网络放音后，继续与被叫执行通话流程而不会取消通话，保障二者间的通信正常进行。

针对步骤106中所述的确定主叫设备的运营商是否属于预设的运营商，存在多种可选择的实现方式。

在一种可选择的实现方式下，可以在主叫设备上预设若干运营商标识，通过匹配主叫设备的运营商标识和预设的运营商标识，确定主叫设备与被叫设备针对早期媒体的协商成功与否；包括：

获取所述主叫设备的运营商标识，所述主叫设备检测所述运营商标识是否与所述预设的运营商标识匹配。

具体地，主叫设备可以获取自身的MCC(Mobile Country Code，移动通信国家码)和MNC(Mobile Network Code，移动通信网络码)，与预设的运营商的MCC和MNC进行匹配，以结合MCC和MNC确定具体的运营商。

响应于所述主叫设备的运营商标识与任一预设的运营商标识匹配，确定所述主叫设备的运营商属于预设的运营商，所述主叫设备确定与被叫设备针对早期媒体协商成功，执行网络放音后继续执行与被叫设备之间的通话；响应于所述主叫设备的运营商标识与所有预设的运营商标识均不匹配，确定所述主叫设备的运营商不属于预设的运营商，所述主叫设备确定与被叫设备针对早期媒体协商失败，取消与被叫设备之间的通话。

该实现方式能够提高主叫设备确认其运营商是否为预设运营商的准确性。

图2是根据一示例性实施例示出的另一种通信协商的方法流程图，对实际用于传输被叫方的网络放音数据的下行链路进行确认，进一步保障主叫设备与被叫设备之间的通话顺利进行，所述通信协商的方法包括以下步骤：

步骤202，主叫设备向被叫设备发送建立通话的邀请报文，接收所述被叫设备返回的响应报文。

步骤204，响应于所述被叫设备要求网络放音，所述主叫设备根据所述响应报文中的链路消息与主叫侧服务器建立用于传输网络放音数据的链路。

步骤202至步骤204的具体实现方式，可以参考前文所述的图1所示实施例的步骤102至步骤104，此处不再赘述。

步骤206，响应于建立的链路不符合所述目标早期媒体字段对应的链路要求，所述主叫设备确定所述响应报文的链路消息中是否包括下行链路消息。

步骤208，响应于所述响应报文的链路消息中不包括下行链路消息，所述主叫设备确定其与所述被叫设备针对早期媒体协商失败，取消与所述被叫设备之间的通话。

在基于所述响应报文中的链路消息与主叫侧服务器建立链路且均建立成功的情况下，检测到建立成功的链路不符合目标早期媒体字段对应的链路要求，所述主叫设备进一步检测所述链路消息中是否包括下行链路消息，以确定实际用于传输被叫方的音频数据的下行链路是否建立成功。

若所述链路消息中不包括下行链路消息，说明主叫设备与主叫侧服务器之间的下行链路未建立成功，实际无法传输早期媒体数据，主叫设备确定早期媒体协商失败，将向被叫设备取消本次通话。

步骤210，响应于所述响应报文的链路消息中包括下行链路消息，所述主叫设备确定其运营商是否属于预设的运营商。

步骤212，响应于所述主叫设备的运营商属于预设的运营商，所述主叫设备确定其与所述被叫设备针对早期媒体协商成功，执行网络放音后继续执行与所述被叫设备之间的通话。

步骤210至步骤212的具体实现方式，可以参考前文所述的图1所示实施例的步骤106至步骤108，此处不再赘述。

图2示出的实施例对实际用于向主叫设备传输网络放音数据的下行链路是否成功建立加以确认，能够进一步保障主叫设备与被叫设备之间的通话顺利进行。

图3是根据一示例性实施例示出的另一种通信协商的方法流程图，进一步包括了执行本地放音和因被叫设备拒绝而取消通话的情况。所述通信协商的方法包括：

步骤302，主叫设备向被叫设备发送建立通话的邀请报文，接收所述被叫设备返回的响应报文。

步骤304，所述主叫设备确定所述响应报文是否为同意建立通话的响应报文。

步骤306，响应于所述响应报文不是同意建立通话的响应报文，所述主叫设备取消与所述被叫设备之间的通话。

在一些特定场景下，被叫设备返回的响应报文并非用于协商早期媒体的信令报文，而是其他表征不同意建立通话的响应报文，包括表征对方拒绝通话或持续占线的信令报文等，因而主叫设备在接收到所述响应报文，可以先对报文性质进行检测，在检测出所述响应报文不是同意建立通话的报文后可以向被叫设备取消本次通话，而无需再针对早期媒体进行协商。

步骤308，响应于所述响应报文是同意建立通话的响应报文，所述主叫设备根据所述响应报文中的目标早期媒体字段确定所述被叫设备是否要求网络放音。

参考前文所述的图1所示实施例的步骤102，主叫设备将在接收到被叫设备返回的响应报文后对其中的目标早期媒体字段进行提取，根据所述响应报文中目标早期媒体字段确定被叫设备是否要求网络放音。

步骤310，响应于所述被叫设备不要求网络放音，所述主叫设备执行本地放音。

当主叫设备确定所述响应报文中目标早期媒体字段对应的并非网络放音的模式，即被叫设备不要求网络放音，说明被叫设备未开通彩铃业务，主叫设备可以直接读取缓存在主叫设备的本地音频执行本地放音，无需再与主叫侧服务器进行链路建立，主叫设备在执行本地放音后可继续执行与被叫设备之间的通话。

步骤312，响应于所述被叫设备要求网络放音，所述主叫设备根据所述响应报文中的链路消息与主叫侧服务器建立用于传输网络放音数据的链路。

步骤314，响应于建立的链路不符合所述目标早期媒体字段对应的链路要求，所述主叫设备确定其运营商是否属于预设的运营商。

步骤316，响应于所述主叫设备的运营商属于预设的运营商，所述主叫设备确定其与所述被叫设备针对早期媒体协商成功，继续执行与所述被叫设备之间的通话。

步骤312至步骤316的具体实现方式，可以参考前文所述的图1所示实施例的步骤104至步骤108，此处不再赘述。

图3示出的实施例进一步包括了对本地放音和被叫方拒绝通话等情况的处理。

为了使本领域技术人员更好地理解本公开所提出的通信协商的方法，接下来作进一步的详细说明，后续描述的实施例仅是本公开的一部分实施例，而不是全部的实施例。

跨运营商通话场景下，主叫设备的运营商采用的早期媒体模式为单向网络放音模式，被叫设备的运营商采用的早期媒体模式为双向网络放音模式，二者均支持网络放音。

某一时刻，主叫设备向被叫设备发送建立通话的邀请报文，由主叫侧服务器、交换机、被叫侧服务器等转至被叫设备。

被叫设备开通有彩铃业务，它向主叫设备返回用于协商早期媒体的信令报文作为响应报文，响应报文中包括上行链路消息和下行链路消息。

主叫侧服务器基于3GPP协议规范，基于主叫设备的运营商所采用的单向网络放音模式，删除了响应报文中的上行链路消息，保留了响应报文中的下行链路消息。

主叫设备在接收到被叫设备的响应报文后，确认了所述响应报文为同意建立通话的报文，获取了所述响应报文中的目标早期媒体字段PEM＝sendrecv，确认了被叫设备要求网络放音。

主叫设备根据响应报文中的下行链路消息与主叫侧服务器成功建立下行链路，并检测建立成功的下行链路是否符合所述目标早期媒体字段PEM＝sendrecv对应的链路要求：上行链路和下行链路均建立成功。

建立成功的下行链路并未满足所述目标早期媒体字段PEM＝sendrecv对应的包括成功建立上行链路的链路要求，主叫设备检测响应报文的链路消息中是否包括下行链路消息。

在确认响应报文中包括下行链路消息后，主叫设备检测其MCC和MNC是否属于预设的MCC和MNC，确认所述主叫设备的MCC和MNC属于预设的MCC和MNC后，向被叫设备反馈早期媒体协商成功，等待被叫方的音频数据，并在网络放音结束后继续执行与被叫设备之间的通话。

与前述通信协商的方法实施例相对应，本公开还提供了通信协商的装置实施例。

所述装置应用于主叫设备，包括报文收发模块410、链路建立模块420、运营商确定模块430和通话执行模块440：

其中，报文收发模块410，用于向被叫设备发送建立通话的邀请报文，接收所述被叫设备返回的响应报文；

链路建立模块420，用于响应于所述被叫设备要求网络放音，根据所述响应报文中的链路消息与主叫侧服务器建立用于传输网络放音数据的链路；

运营商确定模块430，用于响应于建立的链路不符合所述响应报文中目标早期媒体字段对应的链路要求，确定所述主叫设备的运营商是否属于预设的运营商；

通话执行模块440，用于响应于所述主叫设备的运营商属于所述预设的运营商，确定与所述被叫设备针对早期媒体协商成功，执行网络放音后继续执行与所述被叫设备之间的通话。

进一步地，所述运营商确定模块430，还用于：

在确定所述主叫设备的运营商是否属于预设的运营商之前，确定所述链路消息中是否包括下行链路消息；

响应于所述链路消息中包括下行链路消息，确定所述主叫设备的运营商是否属于所述预设的运营商；

响应于所述链路消息中不包括下行链路消息，确定与所述被叫设备针对早期媒体协商失败，取消与所述被叫设备之间的通话。

进一步地，所述运营商确定模块430，还用于：

响应于所述主叫设备的运营商不属于所述预设的运营商，确定与所述被叫设备针对早期媒体协商失败，取消与所述被叫设备之间的通话。

可选择地，所述主叫设备上预设有若干运营商标识；所述运营商确定模块430，在确定所述主叫设备的运营商是否属于预设的运营商时，具体用于：

获取所述主叫设备的运营商标识，确定获取的运营商标识是否与所述预设的运营商标识匹配；

响应于所述获取的运营商标识与任一所述预设的运营商标识匹配，确定所述主叫设备的运营商属于所述预设的运营商；

响应于所述获取的运营商标识与所有所述预设的运营商标识均不匹配，确定所述主叫设备的运营商不属于所述预设的运营商。

进一步地，所述链路建立模块420，还用于：

在接收到所述响应报文后，根据所述响应报文中的目标早期媒体字段确定所述被叫设备是否要求网络放音；

响应于所述被叫设备不要求网络放音，执行本地放音后继续执行与所述被叫设备之间的通话。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在相关方法的实施例中进行了详细描述，此处将不做详细阐述说明。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本公开的实施例还提出一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令实现如上述任一实施例所述方法中的步骤。

图5是根据本公开的实施例示出的一种通信协商的装置所在电子设备500的示意框图。例如，电子设备500可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图5，电子设备500可以包括以下一个或多个组件：处理组件502，存储器504，电源组件506，多媒体组件508，音频组件510，输入/输出(I/O)的接口512，传感器组件514，以及通信组件516。

处理组件502通常控制设备500的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件502可以包括一个或多个处理器520来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件502可以包括一个或多个模块，便于处理组件502和其他组件之间的交互。例如，处理组件502可以包括多媒体模块，以方便多媒体组件508和处理组件502之间的交互。

存储器504被配置为存储各种类型的数据以支持在设备500的操作。这些数据的示例包括用于在设备500上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器504可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件506为设备500的各种组件提供电力。电源组件506可以包括电源管理系统，一个或多个电源，及其他与为设备500生成、管理和分配电力相关联的组件。

多媒体组件508包括在所述设备500和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件508包括一个前置摄像头和/或后置摄像头。当设备500处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件510被配置为输出和/或输入音频信号。例如，音频组件510包括一个麦克风(MIC)，当设备500处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器504或经由通信组件516发送。在一些实施例中，音频组件510还包括一个扬声器，用于输出音频信号。

I/O接口512为处理组件502和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件514包括一个或多个传感器，用于为设备500提供各个方面的状态评估。例如，传感器组件514可以检测到设备500的打开/关闭状态，组件的相对定位，例如所述组件为设备500的显示器和小键盘，传感器组件514还可以检测设备500或设备500一个组件的位置改变，用户与设备500接触的存在或不存在，设备500方位或加速/减速和设备500的温度变化。传感器组件514可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件514还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件514还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件516被配置为便于设备500和其他设备之间有线或无线方式的通信。设备500可以接入基于通信标准的无线网络，如WiFi，2G或3G，4G LTE、5G NR或它们的组合。在一个示例性实施例中，通信组件516经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件516还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，电子设备500可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述任一实施例所述的方法。

在本公开的示例性实施例中，还提供了一种非临时性计算机可读存储介质，其上存储有计算机程序，例如包括指令的存储器504，上述指令可由设备500的处理器520执行以完成上述任一实施例所述方法中的步骤。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims

1.一种通信协商的方法，其特征在于，所述方法应用于主叫设备，包括：

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

4.根据权利要求1所述的方法，其特征在于，所述主叫设备上预设有若干运营商标识；

所述确定所述主叫设备的运营商是否属于预设的运营商，包括：

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

6.一种通信协商的装置，其特征在于，所述装置应用于主叫设备，包括报文收发模块、链路建立模块、运营商确定模块和通话执行模块：

7.根据权利要求6所述的装置，其特征在于，所述运营商确定模块，还用于：

8.根据权利要求6所述的装置，其特征在于，所述运营商确定模块，还用于：

9.根据权利要求6所述的装置，其特征在于，所述主叫设备上预设有若干运营商标识；

所述运营商确定模块在确定所述主叫设备的运营商是否属于预设的运营商时，具体用于：

10.根据权利要求6所述的装置，其特征在于，所述链路建立模块，还用于：

11.一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令实现如权利要求1至5任一项所述方法中的步骤。

12.一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行实现如权利要求1至5任一项所述方法中的步骤。