CN107846567B - 一种srtp能力协商方法及会议终端 - Google Patents

一种srtp能力协商方法及会议终端 Download PDF

Info

Publication number
CN107846567B
CN107846567B CN201711065229.3A CN201711065229A CN107846567B CN 107846567 B CN107846567 B CN 107846567B CN 201711065229 A CN201711065229 A CN 201711065229A CN 107846567 B CN107846567 B CN 107846567B
Authority
CN
China
Prior art keywords
conference terminal
srtp
capability
negotiation
supported
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.)
Active
Application number
CN201711065229.3A
Other languages
English (en)
Other versions
CN107846567A (zh
Inventor
张国锋
韦国华
胡小鹏
陈冬根
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Suzhou Keda Technology Co Ltd
Original Assignee
Suzhou Keda Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Suzhou Keda Technology Co Ltd filed Critical Suzhou Keda Technology Co Ltd
Priority to CN201711065229.3A priority Critical patent/CN107846567B/zh
Publication of CN107846567A publication Critical patent/CN107846567A/zh
Application granted granted Critical
Publication of CN107846567B publication Critical patent/CN107846567B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明公开了一种SRTP能力协商方法及会议终端，其中，方法包括：第二会议终端接收第一会议终端发送的第一呼叫请求；第二会议终端基于第一呼叫请求中的第一属性参数查询本地是否支持第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商；当查询出不支持时，第二会议终端向第一会议终端发送二次SRTP能力协商请求，二次SRTP能力协商请求用于请求与第一会议终端进行二次SRTP能力协商。通过请求/应答模型进行相关SRTP能力的协商；如果协商失败，能够通过二次协商机制进行再次协商，保证了最终SRTP能力的有效性，降低SRTP能力协商的失败率，避免在一次SRTP能力协商过程中由于SRTP能力更新或者未能全部进行协商导致的协商失败的情况。

Description

一种SRTP能力协商方法及会议终端
技术领域
本发明涉及信息安全技术领域，具体涉及一种SRTP能力协商方法及会议终端。
背景技术
在视频会议系统中，需要对音频以及视频数据进行实时传输。现有技术中，音、视频数据通常基于实时传输协议(Real-time Transport Protocol，简称为RTP)进行实时传输的，其详细规定了每一帧数据的打包格式，能够满足大部分的应用需求。
但是，随着网络信息安全问题的日趋重要，对视频会议系统中的音频以及视频数据进行加密的应用需求已经不可避免。此时，安全实时传输协议(Secure Real-timeTransport Protocol，简称为SRTP)作为媒体加密协议，就应运而生。SRTP提供了一套用于RTP流进行加密和认证的框架，提供了加密算法和认证算法。SRTP对RTP流进行加密、认证以及报文重传保护，有效的避免了音、视频数据流窃听问题。
在不同的视频会议终端，往往携带了不同的多个加密认证算法，同时各个加密认证算法所对应的密钥也不相同，即不同的视频会议终端的SRTP能力可能不同，因此需要进行协商。
公开号为CN103685181A的中国专利文献公开了一种基于SRTP的密钥协商方法，其公开了对AES加密算法和密钥的协商方式。然而，发明人发现，一次协商通常容易导致协商失败的概率大大增加，例如，初次协商时未能将所有支持的SRTP能力发送给对方终端，或者，及时更新了本地的SRTP能力未能告知对方终端等。
发明内容
有鉴于此，本发明实施例提供了一种SRTP能力协商方法，解决现有技术中SRTP能力协商失败的概率高的问题。
本发明第一方面提供了一种SRTP能力协商方法，包括以下步骤：
第二会议终端接收第一会议终端发送的第一呼叫请求，所述第一呼叫请求携带有用于表示所述第一会议终端当前所支持的SRTP能力的第一属性参数；
所述第二会议终端基于所述第一属性参数查询本地是否支持所述第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商；
当查询出不支持时，所述第二会议终端向所述第一会议终端发送二次SRTP能力协商请求，其中，所述二次SRTP能力协商请求携带有用于表示所述第二会议终端当前所支持的SRTP能力的第二属性参数，用于请求与所述第一会议终端进行二次SRTP能力协商。
可选地，所述第一属性参数包括：用于表示加密算法的参数、用于表示认证算法的参数以及密钥。
可选地，所述第二会议终端基于所述第一属性参数查询本地是否支持所述第一会议终端当前所支持的SRTP能力包括：
所述第二会议终端解析所述第一属性参数，得到用于表示所述第一会议终端当前所支持的加密算法的参数和认证算法的参数以及密钥；
所述第二会议终端基于所述用于表示所述第一会议终端当前所支持的加密算法的参数和认证算法的参数查询本地所支持的加密算法和认证算法；
如果查询到，则所述第二会议终端确定支持所述第一会议终端当前所支持的SRTP能力。
可选地，在SRTP能力协商之后，还包括：
所述第二会议终端向所述第一会议终端发送应答消息；
其中，当协商成功时，所述应答消息携带有所述第一会议终端和所述第二会议终端均支持的一项SRTP能力的属性参数；当协商不成功时，所述应答消息中不包含任何SRTP能力的属性参数。
本发明第二方面提供了一种SRTP能力协商方法，包括以下步骤：
第一会议终端向第二会议终端发送的第一呼叫请求，所述第一呼叫请求携带有用于表示所述第一会议终端当前所支持的SRTP能力的第一属性参数，所述第一呼叫请求用于请求与所述第二会议终端进行初次SRTP能力协商；
所述第一会议终端接收二次SRTP能力协商请求，其中，所述二次SRTP能力协商请求为所述第二会议终端在初次协商失败的情况下发送的，其携带有用于表示所述第二会议终端当前所支持的SRTP能力的第二属性参数；
所述第一会议终端基于所述第二属性参数查询本地是否支持所述第二会议终端所支持的SRTP能力，以进行二次SRTP能力协商。
本发明第三方面提供了一种会议终端，包括：
第一接收模块，接收第一会议终端发送的第一呼叫请求，所述第一呼叫请求携带有用于表示所述第一会议终端当前所支持的SRTP能力的第一属性参数；
第一协商模块，用于基于所述第一属性参数查询本地是否支持所述第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商；
第一发送模块，用于当查询出不支持时，向所述第一会议终端发送二次SRTP能力协商请求，其中，所述二次SRTP能力协商请求携带有用于表示本地当前所支持的SRTP能力的第二属性参数，用于请求与所述第一会议终端进行二次SRTP能力协商。
可选地，所述第一属性参数包括：用于表示加密算法的参数、用于表示认证算法的参数和密钥。
可选地，所述第一协商模块包括：
第一解析模块，用于解析所述第一属性参数，得到用于表示所述第一会议终端当前所支持的加密算法的参数和认证算法的参数以及密钥；
第一查询模块，用于基于所述用于表示所述第一会议终端当前所支持的加密算法的参数和认证算法的参数查询本地所支持的加密算法和认证算法；
第三确定模块，用于确定支持所述第一会议终端当前所支持的SRTP能力。
可选地，还包括：
第三发送模块，用于向所述第一会议终端发送应答消息；
其中，当协商成功时，所述应答消息携带有所述第一会议终端和本端均支持的一项SRTP能力的属性参数；当协商不成功时，所述应答消息中不包含任何SRTP能力的属性参数。
本发明第四方面提供了一种会议终端，包括：
第二发送模块，用于向第二会议终端发送的第一呼叫请求，所述第一呼叫请求携带有用于表示本地当前所支持的SRTP能力的第一属性参数，所述第一呼叫请求用于请求与所述第二会议终端进行初次SRTP能力协商；
第二接收模块，用于接收二次SRTP能力协商请求，其中，所述二次SRTP能力协商请求为所述第二会议终端在初次协商失败的情况下发送的，其携带有用于表示所述第二会议终端当前所支持的SRTP能力的第二属性参数；
第二协商模块，用于基于所述第二属性参数查询本地是否支持所述第二会议终端所支持的SRTP能力，以进行二次SRTP能力协商。
本发明提供的技术方案，具有如下优点：
1.本发明实施例提供的SRTP能力协商方法，包括：第二会议终端接收第一会议终端发送的第一呼叫请求；第二会议终端基于第一呼叫请求中的第一属性参数查询本地是否支持第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商；当查询出不支持时，第二会议终端向第一会议终端发送二次SRTP能力协商请求，二次SRTP能力协商请求携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数，用于请求与第一会议终端进行二次SRTP能力协商。通过请求/应答模型进行相关SRTP能力的协商；如果协商失败，能够通过二次协商机制进行再次协商，保证了最终SRTP能力的有效性，降低SRTP能力协商的失败率，避免在一次SRTP能力协商过程中由于SRTP能力更新或者未能全部进行协商导致的协商失败的情况。
2.本发明实施例提供的SRTP能力协商方法，其中，第一属性参数包括用于表示加密算法的参数，用于表示认证算法的参数，以及密钥。通过对会议系统中传输音、视频数据所涉及的加密算法、认证算法进行协商，协商出一个会议系统中传输数据的双方都支持的加密算法和认证算法，从而保证数据传输过程的安全，可靠。
3.本发明实施例提供的SRTP能力协商方法，其中，第二会议终端在接收第一会议终端发送的第一呼叫请求之后，解析第一呼叫请求中所携带的对应于第一终端SRTP能力的认证算法和加密算法；然后基于第一属性参数查询本地所支持的加密算法和认证算法；查询到之后，第二会议终端就能够确认所支持的第一会议终端当前所支持的SRTP能力。通过依据对端的认证算法和加密算法，在本地查询所匹配的认证算法和加密算法，能够提高协商的效率，进而提高数据传输的效率。
4.本发明实施例提供的SRTP能力协商方法，其中，在SRTP能力协商之后，还包括：第二会议终端向第一会议终端发送应答消息；当协商成功时，所述应答消息携带有第一会议终端和第二会议终端均支持的一项SRTP能力的属性参数；当协商不成功时，应答消息中不包含任何SRTP能力的属性参数。在不管协商成功与否，第二会议终端都需要向第一会议终端发送应答消息，表示第二会议终端已经成功接收第一终端发送的第一呼叫请求；同时，根据不同的协商结果，在应答消息中所携带的内容不同。通过在应答消息中加载对应于不同协商结果的内容，使得第一终端在获知第二终端的接收状态的同时能够知晓协商结果，可挺高数据传输的效率以及可靠性。
5.本发明实施例提供的SRTP能力协商方法，其中，在初次协商失败的情况下，第一会议终端接收第二会议终端发送的第二次呼叫请求，并在本地中查询是否存在与第二此呼叫请求中的第二属性参数匹配的参数，并将查询结果发送给第二会议终端。通过二次协商机制进行再次协商，降低SRTP能力协商的失败率，保证了最终SRTP加密认证算法的有效性。
附图说明
通过参考附图会更加清楚的理解本发明的特征和优点，附图是示意性的而不应理解为对本发明进行任何限制，在附图中：
图1示出了本发明实施例的应用场景；
图2示出了本发明实施例1的SRTP能力协商方法的一个具体示意的流程图；
图3示出了本发明实施例2的SRTP能力协商方法的一个具体示意的流程图；
图4示出了本发明实施例3的SRTP能力协商方法的一个具体示意的流程图；
图5示出了本发明实施例4的SRTP能力协商方法的一个具体示意的流程图；
图6示出了本发明实施例5的SRTP能力协商方法的一个具体示意的流程图；
图7示出了本发明实施例6的SRTP能力协商方法的一个具体示意的流程图；
图8示出了本发明实施例9的会议终端的一个具体示意的结构图；
图9示出了本发明实施例9的会议终端的另一个具体示意的结构图；
图10示出了本发明实施例10的会议终端的一个具体示意的结构图；
图11示出了本发明实施例10的会议终端的另一个具体示意的结构图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1所示，是本发明实施例的应用场景。第一会议终端和第二会议终端为具有音、视频数据传输功能的电子产品，例如可以是个人电脑，手机，平板电脑等。第一会议终端和第二会议终端所支持的SRTP能力属性可能不同，因此在数据传输之前，需要进行SRTP能力的协商，以保证能够协商出一个双方都支持的SRTP能力，从而保证数据传输的安全性。此外，本发明实施例的数据传输双方并不限于一对一的模式，也可以是一对多，即一个第一会议终端与多个第二会议终端；或，多个第一会议终端与多个第二会议终端。
实施例1
本施例提供一种SRTP能力协商方法，用于会议终端中。如图2所示，该SRTP能力协商方法包括以下步骤：
步骤S11，第二会议终端接收第一会议终端发送的第一呼叫请求，第一呼叫请求携带有用于表示第一会议终端当前所支持的SRTP能力的第一属性参数。
本实施例中，会议系统中的会议终端以两个会议终端为例，进行描述。即第一会议终端与第二会议终端进行视频会议，在第一会议终端与第二会议终端之间进行视频会议的音、视频数据的传输。
第二会议终端接收第一会议终端发送的第一呼叫请求，即第一会议终端发起初次SRTP能力协商。在第一呼叫请求中携带有用于表示第一终端当前所支持的SRTP能力的第一属性参数；其中，第一属性参数包括多种参数类别；而第一呼叫请求中包括多个第一属性参数。即可以通过一个属性值表示一组第一属性参数，而第一呼叫请求中包括有一个或多个属性值。
第一属性参数用于保证音、视频数据的准确传输，即通过协商出一个第一会议终端和第二会议终端全都支持的属性参数。通过在第一呼叫请求中携带第一属性参数，可以提高协商效率，节约通信资源。
步骤S12，第二会议终端基于第一属性参数查询本地是否支持第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商。若查询出不支持，则执行步骤S13；否则，执行其他操作。
第二会议终端接收第一会议终端发送的第一呼叫请求之后，基于第一呼叫请求所携带的第一属性参数，查询本地(即第二会议终端)是否支持第一会议终端当前所支持的SRTP能力；即查询本地是否存在至少一个与第一属性参数相同的参数。具体地，可以是以第一属性参数为索引，查询第二会议终端本地的SRTP能力列表是否具有相同的SRTP能力。
通过基于第一属性参数在本地进行匹配查询，就能够较快地确认查询结果；在第二会议终端本地中，如果匹配查询不成功，则表示第二会议终端不支持第一会议终端当前所支持的SRTP能力；如果匹配查询成功，表示第二会议终端支持第一会议终端当前所支持的SRTP能力，则可以进行后续的通信。
本实施例中，在匹配查询成功时，第二会议终端所执行的其他操作，可以是第二会议终端确定支持第一会议终端当前所支持的SRTP能力；也可以是，第二会议终端将查询出的匹配的SRTP能力再次发送给第一会议终端，第一会议终端进行确认后，确定双方所支持的SRTP能力。
步骤S13，第二会议终端向第一会议终端发送二次SRTP能力协商请求，其中，二次SRTP能力协商请求携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数，用于请求与第一会议终端进行二次SRTP能力协商。
本实施例中，当第二会议终端基于第一属性参数查询出本地不支持第一会议终端当前所支持的SRTP能力时，表示由第一会议终端发起的初次SRTP能力协商失败。此时，第二会议终端向第一会议终端发送二次SRTP能力协商请求，在二次SRTP能力协商请求中携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数。
由于第一会议终端所支持的SRTP能力会进行更新(包括新增或替换SRTP能力)或者未能全部发送给第二会议终端，因此，当协商不成功时，有第二会议终端发起二次协商，具体为向第一会议中的发送携带有第二属性参数的二次SRTP能力协商请求。
第二属性参数中所包括的参数类别同第一属性参数，即通过一个属性值表示一组第二属性参数，同时二次SRTP能力协商请求中包括一个或多个属性值。优选地，第二属性参数中所包含的SRTP能力为第二会议终端所支持的并且与第一属性参数中所包含的SRTP能力不同的SRTP能力，从而减少二次协商时查询匹配的数据量，提高协商效率。当然，第二属性参数可以包含有第二会议终端所支持的所有的SRTP能力。
本实施例通过二次协商机制进行再次协商，保证了最终SRTP能力的有效性，降低SRTP能力协商的失败率，避免在一次SRTP能力协商过程中由于SRTP能力更新或者未能全部进行协商导致的协商失败的情况。
实施例2
本施例提供一种SRTP能力协商方法，用于会议终端中。如图3所示，该SRTP能力协商方法包括以下步骤：
步骤S21，第二会议终端接收第一会议终端发送的第一呼叫请求，第一呼叫请求携带有用于表示第一会议终端当前所支持的SRTP能力的第一属性参数。
本实施例中的视频会议的音、视频数据的传输中，借助于会话初始化协议(Session Initiation Protocol，简称为SIP)进行会话过程中的交互信息的描述；此外，结合会话描述协议(Session Description Protocol，简称为SDP)进行媒体能力的描述。
其中，基于SRTP的音、视频数据的交互，需要SIP进行信令交互时协商SRTP的加密算法、认证算法和密钥；其中，加密算法、认证算法为SRTP能力。SIP通过在消息的SDP部分中增加“crypto”属性来完成上述功能；其中，“crypto”属性包括加密算法、认证算法，以及加密或认证算法所需的密钥。
本实施例中，第一属性参数包括：用于表示加密算法的参数、用于表示认证算法的参数以及密钥。其中，加密算法采用国密算法实现，国密即国家密码局认定的国产密码算法，主要有SM1，SM2，SM3，SM4；密钥长度和分组长度均为128位。
例如，当前第一会议终端支持如下三个国密能力(采用crypto属性表示)：SM1_CM_HMAC_SM3_80、SM4_CM、SM4_CM_HMAC_SM3_80。其中包含的加密算法分别为SM1、SM4、SM4，认证算法分别对应为HMAC_SM3、无认证算法、HMAC_SM3。第一终端采用SDP数据包，通过SIP的国密传输层安全协议(GM Transport Layer Security，简称为GM TLS)进行传输。
其余，与实施例1步骤S11相同，在此不再赘述。
步骤S22，第二会议终端基于第一属性参数查询本地是否支持第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商。若查询出不支持，则执行步骤S23；否则，执行步骤S24。
第二会议终端在收到第一会议终端的第一呼叫请求后，根据第一呼叫请求中所携带的第一属性参数进行SRTP能力匹配的查询，具体包括以下步骤：
步骤S221，解析第一属性参数，即第一会议终端当前所支持的加密算法的参数和认证算法的参数以及密钥，并保存第一属性参数。
第二会议终端在收到第一会议终端发送的第一呼叫请求之后，解析SDP数据包里面的SRTP属性值，并采用Base64对其解码；即解析出SDP数据包用以表示SRTP属性值的crypto属性；并保存第一会议终端的crypto属性，即第一会议终端当前所支持的加密算法、认证算法以及密钥。
步骤S222，第二会议终端基于用于表示第一会议终端当前所支持的加密算法的参数和认证算法的参数查询本地所支持的加密算法和认证算法。若查询出不支持，则执行步骤S23；否则，执行步骤S24。
第二会议终端基于解析出的对应于第一会议终端的crypto属性，检索本地所支持的SRTP加密算法以及认证算法，依次进行匹配查询。
例如，首先，对应于crypto属性“SM1_CM_HMAC_SM3_80”，第二会议终端在本地进行匹配查询，查询是否有匹配的SRTP能力；如果没有，则进行crypto属性“SM4_CM”的匹配查询；依次类推，直至查询到匹配的SRTP能力，或者对应于第一会议终端的所有crypto属性全都匹配查询完成。
通过依次匹配查询的方法，能够准确地查询到第一会议终端和第二会议终端所支持的SRTP能力，能够提高视频会议系统中音、视频数据传输的可靠性。
作为本实施例的一种可选实施方式，第二会议终端根据第一会议终端所有的crypto属性，同时进行SRTP能力的匹配查询。具体地，在第二会议终端中，开启多个与第一会议终端的crypto属性一一对应的线程，进行SRTP能力的并行匹配查询。
步骤S23，第二会议终端向第一会议终端发送二次SRTP能力协商请求，其中，二次SRTP能力协商请求携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数，用于请求与第一会议终端进行二次SRTP能力协商。
本实施例中，当查询出不支持时，第二会议终端将其当前所支持的SRTP能力(加密算法、认证算法以及密钥)封装成SDP数据包，发送给第一会议终端。具体地，第二会议终端查询自身所支持的加密算法以及认证算法，并利用密钥生成函数Gkey生成随机串，再利用Base64对该随机串进行编码，以保证密钥在网络传输中的有效性。其中，本实施例中随机串的生成函数，以及编码方法并不限于此，所有加密算法中的随机串生成函数以及编码方法均属于本发明的保护范围。
第二会议终端将一个或多个加密算法以及认证算法，以及密钥借助于crypto属性表示；封装成SDP数据包，在发送第二次呼叫请求时，将该SDP数据包发送给第一会议终端，进行第二次SRTP能力协商。
步骤S24，第二会议终端确定支持第一会议终端当前所支持的SRTP能力。
当查询出支持时，即第一会议终端发起的初次协商成功，第二会议终端确定查询到的SRTP能力为双方都支持的SRTP能力。其中，采用依次匹配查询的方法进行，只要查询出一个匹配的SRTP能力，则查询结束，即最终匹配出一个SRTP能力，该SRTP能力双方全都支持。
作为本实施例的一种可选实施方式，采用并行匹配查询的方法进行，可能会查询出多个匹配的SRTP能力，即第二会议终端中存在多个与第一会议终端匹配的SRTP能力。第二会议终端从多个匹配的SRTP能力中选出一个SRTP能力，作为最终匹配的SRTP能力。
步骤S25，第二会议终端向第一会议终端发送应答消息。
第二会议终端在匹配查询之后，不论是否查询到匹配的SRTP能力，都向第一会议终端发送应答消息。其中，当协商成功时，应答消息携带有第一会议终端和所述第二会议终端均支持的一项SRTP能力的属性参数；当协商不成功时，应答消息中不包含任何SRTP能力的属性参数。
通过在应答消息中加载对应于不同协商结果的内容，使得第一终端在获知第二终端的接收状态的同时能够知晓协商结果，可挺高数据传输的效率以及可靠性。
实施例3
本施例提供一种SRTP能力协商方法，用于会议终端中。如图4所示，该SRTP能力协商方法包括以下步骤：
步骤S31，第一会议终端向第二会议终端发送第一呼叫请求，第一呼叫请求携带有用于表示第一会议终端当前所支持的SRTP能力的第一属性参数，第一呼叫请求用于请求与第二会议终端进行初次SRTP能力协商。
第一会议终端查询本地所支持的SRTP能力，将其中的一项或多项SRTP能力以第一属性参数的形式发送给第二会议终端，以进行初次SRTP能力协商。
其中，关于第一属性参数的相关细节，请参照实施例1的步骤S11，在此不再赘述。
步骤S32，第一会议终端接收二次SRTP能力协商请求，其中，二次SRTP能力协商请求为第二会议终端在初次协商失败的情况下发送的，其携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数。
在第一会议终端发起的初次协商失败的情况下，第一会议终端会接收第二会议终端发送的二次SRTP能力协商请求，即第二会议终端会发起二次SRTP能力协商。
关于第二属性参数的相关细节，请参照实施例1的步骤S13，在此不再赘述。
步骤S33，第一会议终端基于第二属性参数查询本地是否支持第二会议终端所支持的SRTP能力。若支持，则执行步骤S34；否则，执行其他操作。
本实施例中，第一会议终端在进行匹配查询之前，可以先进行本地所支持的SRTP能力的更新，增加或替换与初次协商的SRTP能力不同的SRTP能力。
其中，第一会议终端的查询过程与实施例1的步骤S12类似，在此不再赘述。
本实施例中，其他操作可以为第一会议终端再次发起三次SRTP能力协商请求，直至双方协商出统一的SRTP能力为止；也可以为第一会议终端确定第二会议终端发起的二次SRTP能力协商失败，不能进行音、视频数据传输。
步骤S34，第一会议终端确定支持第二会议终端当前所支持的SRTP能力。
当查询出支持时，即第二会议终端发起的二次协商成功，第一会议终端确定查询到的SRTP能力为双方都支持的SRTP能力。
本实施例通过二次协商机制进行再次协商，保证了最终SRTP能力的有效性，能够实现会议系统中音、视频数据传输的安全有效，从而大大提高了SRTP的实用性。
实施例4
本施例提供一种SRTP能力协商方法，用于会议终端中。如图5所示，该SRTP能力协商方法包括以下步骤：
步骤S41，第一会议终端向第二会议终端发送第一呼叫请求，第一呼叫请求携带有用于表示第一会议终端当前所支持的SRTP能力的第一属性参数，第一呼叫请求用于请求与第二会议终端进行初次SRTP能力协商。
其中，关于第一属性参数的相关细节，请参照实施例2步骤S21。
其余，与实施例3步骤S31相同，在此不再赘述。
步骤S42，第一会议终端接收二次SRTP能力协商请求，其中，二次SRTP能力协商请求为第二会议终端在初次协商失败的情况下发送的，其携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数。
其中，第二属性参数与第一属性参数类似，具体请参照实施例2步骤S21。
其余，与实施例3步骤S32相同，在此不再赘述。
步骤S43，第一会议终端基于第二属性参数查询本地是否支持第二会议终端所支持的SRTP能力。若支持，则执行步骤S44；否则，执行步骤S45。
本实施例中，第一会议终端的查询过程与实施例2的步骤S22类似，在此不再赘述。
步骤S44，第一会议终端确定支持第二会议终端当前所支持的SRTP能力。
与实施例2步骤S24类似，在此不再赘述。
步骤S45，第一会议终端确定第二会议终端发起的二次SRTP能力协商失败。
本实施例中，第一会议终端确定二次SRTP能力协商失败，表示双方不能进行音、视频数据的传输。
步骤S46，第一会议终端向第二会议终端发送应答消息。
第一会议终端在匹配查询之后，不论是否查询到匹配的SRTP能力，都向第二会议终端发送应答消息。其中，当协商成功时，应答消息携带有第一会议终端和所述第二会议终端均支持的一项SRTP能力的属性参数；当协商不成功时，应答消息中不包含任何SRTP能力的属性参数。
实施例5
本施例提供一种SRTP能力协商方法，用于会议终端中。如图6所示，该SRTP能力协商方法包括以下步骤：
步骤S51，第一会议终端向第二会议终端发送第一呼叫请求，第一呼叫请求携带有用于表示第一会议终端当前所支持的SRTP能力的第一属性参数，第一呼叫请求用于请求与第二会议终端进行初次SRTP能力协商。
与实施例3步骤S31相同，在此不再赘述。
步骤S52，第二会议终端接收第一会议终端发送的第一呼叫请求，第一呼叫请求携带有用于表示第一会议终端当前所支持的SRTP能力的第一属性参数。
与实施例1步骤S11相同，在此不再赘述。
步骤S53，第二会议终端基于第一属性参数查询本地是否支持第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商。若查询出不支持，则执行步骤S54；否则，执行其他操作。
与实施例1步骤S12相同，在此不再赘述。
步骤S54，第二会议终端向第一会议终端发送二次SRTP能力协商请求，其中，二次SRTP能力协商请求携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数，用于请求与第一会议终端进行二次SRTP能力协商。
与实施例1步骤S13相同，在此不再赘述。
步骤S55，第一会议终端接收二次SRTP能力协商请求，其中，二次SRTP能力协商请求为第二会议终端在初次协商失败的情况下发送的，其携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数。
与实施例3步骤S32相同，在此不再赘述。
步骤S56，第一会议终端基于第二属性参数查询本地是否支持第二会议终端所支持的SRTP能力，以进行二次SRTP能力协商。若查询出支持，则执行步骤S57，否则执行其他操作。
与实施例3步骤S33相同，在此不再赘述。
步骤S57，第一会议终端确定支持第二会议终端当前所支持的SRTP能力。
与实施例3步骤S34相同，在此不再赘述。
实施例6
本施例提供一种SRTP能力协商方法，用于会议终端中。如图7所示，该SRTP能力协商方法包括以下步骤：
步骤S61，第一会议终端向第二会议终端发送第一呼叫请求，第一呼叫请求携带有用于表示第一会议终端当前所支持的SRTP能力的第一属性参数，第一呼叫请求用于请求与第二会议终端进行初次SRTP能力协商。
与实施例4步骤S41相同，在此不再赘述。
步骤S62，第二会议终端接收第一会议终端发送的第一呼叫请求，第一呼叫请求携带有用于表示第一会议终端当前所支持的SRTP能力的第一属性参数。
与实施例2步骤S21相同，在此不再赘述。
步骤S63，第二会议终端基于第一属性参数查询本地是否支持第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商。若查询出不支持，则执行步骤S64；否则，执行步骤S65。
与实施例2步骤S22相同，在此不再赘述。
步骤S65，第二会议终端确定支持第一会议终端当前所支持的SRTP能力。
与实施例2步骤S24相同，在此不再赘述。跳转执行步骤S66。
步骤S64，第二会议终端向第一会议终端发送二次SRTP能力协商请求，其中，二次SRTP能力协商请求携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数，用于请求与第一会议终端进行二次SRTP能力协商。
与实施例2步骤S23相同，在此不再赘述。
步骤S66，第二会议终端向第一会议终端发送应答消息。
当协商成功时，应答消息携带有第一会议终端和所述第二会议终端均支持的一项SRTP能力的属性参数；此时，结束SRTP能力协商方法。
当协商不成功时，应答消息中不包含任何SRTP能力的属性参数。接着执行步骤S67。
其余，与实施例2步骤S25相同，在此不再赘述。
步骤S67，第一会议终端接收二次SRTP能力协商请求，其中，二次SRTP能力协商请求为第二会议终端在初次协商失败的情况下发送的，其携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数。
与实施例4步骤S42相同，在此不再赘述。
步骤S68，第一会议终端基于第二属性参数查询本地是否支持第二会议终端所支持的SRTP能力，以进行二次SRTP能力协商。若查询出支持，则执行步骤S69，否则执行步骤S70。
与实施例4步骤S43相同，在此不再赘述。
步骤S69，第一会议终端确定支持第二会议终端当前所支持的SRTP能力。
与实施例4步骤S44相同，在此不再赘述。跳转执行步骤S71。
步骤S70，第一会议终端确定第二会议终端发起的二次SRTP能力协商失败。
与实施例4步骤S45相同，在此不再赘述。
步骤S71，第一会议终端向第二会议终端发送应答消息。
与实施例4步骤S46相同，在此不再赘述。
实施例7
本施例提供一种实施例1至实施例6中SRTP能力协商的具体实施方式，用于会议终端中。
第1步，第一会议终端通过邀请Invite信令来携带其自身所支持的SRTP能力，加密算法类型可以包括国密1(SM1)、国密4(SM4)等，根据不同的加密算法对应的SRTP的密码Crypto属性为SM1_CM_HMAC_SM3_80、SM4_CM_HMAC_SM3_80。
第2步，为了加密音、视频数据，因此需要把第1步中的加密认证算法填充到SDP的音、视频属性里。在Invite的SDP里构造SRTP的媒体属性时，还需要有一个密钥去进行设置，这个密钥可以由一个随机函数生成。这个随机函数可以为行业公知算法。
第3步，在完成第1、2步后，为了保证传输的密钥安全，这里使用基于国密算法的SIP的安全传输协议TLS来传输SDP。
第4步，通过国密TLS发出一个Invite请求，其SDP的音、视频媒体行里包含了第1，2，3步所生成的SRTP能力。
第5步，第二会议终端在收到一个Invite请求后，首先解析SDP包里面的SRTP属性，保存对端所支持的加密算法和认证算法以及密钥。
第6步，第二会议终端检索自身所支持的SRTP加密认证算法，按照顺序查找的算法来和第一会议终端进行匹配，最终匹配出一个加密认证算法。
第7步，第二会议终端根据随机函数来生成一个随机串来充当SRTP能力的密钥。
第8步，第二会议终端将协商出的加密认证算法和密钥来构造SDP里音、视频的SRTP媒体属性。
第9步，第二会议终端将构造好的SDP包通过SIP信令最终应答200Ok回复给第一会议终端，此时走的还是TLS链路。
第10步，第一会议终端收到第二会议终端的200Ok应答后，解析SDP包。如果有SRTP能力，则协商成功，同时保存第二会议终端的密钥，否则协商失败。第一会议终端确认协商成功后，给第二会议终端回确认应答ACK。
第11步，如果协商失败，则第二会议终端在协商失败后，就进行二次协商Re-invite，将其支持的SRTP能力进行SDP打包发送给第一会议终端。
第12步，第一会议终端重复第二会议终端协商的过程，直至协商成功后发送200Ok给第一会议终端。
实施例8
本实施例提供一种SRTP能力协商方法，用于会议终端中。该SRTP能力协商方法，包括：在实施例1至实施例7任一项所述的SRTP能力协商方法之前进行的握手阶段的协商。
实施例1至实施例7中的SDP数据包的传输可以基于国密TLS传输，而在进行TLS握手阶段所需要的证书分为两个：加密证书和签名证书。加密证书和签名证书里分别使用SM2算法进行签名认证以及其它相关认证信息，具体可包含证书有效期、数字签名、签发者等。其中数字签名是使用摘要算法SM3结合现有的一些用户信息用CA私钥生成的。因此一个完整的国密证书应该包含加密证书、签名证书以及对应的CA证书，其中国密TLS协商步骤如下：
步骤81，第一会议终端加载SIP终端A所生成的加密证书和签名证书，其中加密证书的密钥由CA生成。加密证书的私钥如果是硬终端的加解密，则需要设置到相应的安全硬件Ukey里。
步骤82，第二会议终端按照步骤81加载第二会议终端所生成的加密证书和签名证书。
步骤83，第一会议终端和第二会议终端进行国密TLS传输前的协商，协商成功后，通过数字签名的方式来保证消息来源的真实性，使用加密证书的密钥对数据的加解密进行处理。由于密钥是保存在Ukey里，因此可以通过专门的Ukey芯片来进行加解密处理，这样大大提高效率。
实施例9
本实施例提供一种会议终端，该会议终端可以是上述实施例中的第二会议终端，用于执行实施例1、实施例2、实施例5以及实施例6中任一项的SRTP能力协商方法。如图8所示，该会议终端包括：
第一接收模块81，接收第一会议终端发送的第一呼叫请求，第一呼叫请求携带有用于表示第一会议终端当前所支持的SRTP能力的第一属性参数。
第一协商模块82，用于基于第一属性参数查询本地是否支持第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商。
第一发送模块83，用于向第一会议终端发送二次SRTP能力协商请求，其中，二次SRTP能力协商请求携带有用于表示本地当前所支持的SRTP能力的第二属性参数，用于请求与第一会议终端进行二次SRTP能力协商。
作为本实施例的一种可选实施方式，如图9所示，第一协商模块82包括：
第一解析模块821，用于解析所述第一属性参数，得到用于表示第一会议终端当前所支持的加密算法的参数和认证算法的参数以及密钥。
第一查询模块822，用于基于用于表示第一会议终端当前所支持的加密算法的参数和认证算法的参数查询本地所支持的加密算法和认证算法。
第三确定模块823，用于确定支持第一会议终端当前所支持的SRTP能力。
作为本实施例的另一种可选实施方式，如图9所示，该会议终端还包括：
第三发送模块84，用于向第一会议终端发送应答消息。
其中，当协商成功时，应答消息携带有第一会议终端和本端均支持的一项SRTP能力的属性参数；当协商不成功时，应答消息中不包含任何SRTP能力的属性参数。
实施例10
本实施例提供一种会议终端，该会议终端可以是上述实施例中的第一会议终端，用于执行实施例3、实施例4、实施例5以及实施例6中任一项的SRTP能力协商方法。如图10所示，该会议终端包括：
第二发送模块91，用于向第二会议终端发送的第一呼叫请求，第一呼叫请求携带有用于表示本地当前所支持的SRTP能力的第一属性参数，第一呼叫请求用于请求与第二会议终端进行初次SRTP能力协商。
第二接收模块92，用于接收二次SRTP能力协商请求，其中，二次SRTP能力协商请求为第二会议终端在初次协商失败的情况下发送的，其携带有用于表示第二会议终端当前所支持的SRTP能力的第二属性参数。
第二协商模块93，用于基于第二属性参数查询本地是否支持第二会议终端所支持的SRTP能力，以进行二次SRTP能力协商。
第二确定模块94，用于确定支持当前所支持的SRTP能力。
作为本实施例的一种可选实施方式，如图11所示，第二协商模块93包括：
第二解析模块931，用于解析所述第二属性参数，得到用于表示第二会议终端当前所支持的加密算法的参数和认证算法的参数以及密钥。
第二查询模块932，用于基于用于表示第二会议终端当前所支持的加密算法的参数和认证算法的参数查询本地所支持的加密算法和认证算法。
第四确定模块933，用于确定支持第二会议终端当前所支持的SRTP能力。
作为本实施例的另一种可选实施方式，如图11所示，该会议终端还包括：
第四发送模块95，用于向第二会议终端发送应答消息。
其中，当协商成功时，应答消息携带有第一会议终端和本端均支持的一项SRTP能力的属性参数；当协商不成功时，应答消息中不包含任何SRTP能力的属性参数。
本领域技术人员可以理解，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(ROM)或随机存储记忆体(RAM)等。
虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (8)

1.一种SRTP能力协商方法，其特征在于，包括以下步骤：
第二会议终端接收第一会议终端发送的第一呼叫请求，所述第一呼叫请求携带有用于表示所述第一会议终端当前所支持的SRTP能力的第一属性参数；
所述第二会议终端基于所述第一属性参数查询本地是否支持所述第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商；
当查询出不支持时，所述第二会议终端向所述第一会议终端发送二次SRTP能力协商请求，其中，所述二次SRTP能力协商请求携带有用于表示所述第二会议终端当前所支持的SRTP能力的第二属性参数，用于请求与所述第一会议终端进行二次SRTP能力协商。
2.根据权利要求1所述的方法，其特征在于，所述第一属性参数包括：用于表示加密算法的参数、用于表示认证算法的参数以及密钥。
3.根据权利要求2所述的方法，其特征在于，所述第二会议终端基于所述第一属性参数查询本地是否支持所述第一会议终端当前所支持的SRTP能力包括：
所述第二会议终端解析所述第一属性参数，得到用于表示所述第一会议终端当前所支持的加密算法的参数和认证算法的参数以及密钥；
所述第二会议终端基于所述用于表示所述第一会议终端当前所支持的加密算法的参数和认证算法的参数查询本地所支持的加密算法和认证算法；
如果查询到，则所述第二会议终端确定支持所述第一会议终端当前所支持的SRTP能力；
其中，在SRTP能力协商之后，还包括：
所述第二会议终端向所述第一会议终端发送应答消息；
其中，当协商成功时，所述应答消息携带有所述第一会议终端和所述第二会议终端均支持的一项SRTP能力的属性参数；当协商不成功时，所述应答消息中不包含任何SRTP能力的属性参数。
4.一种SRTP能力协商方法，其特征在于，包括以下步骤：
第一会议终端向第二会议终端发送第一呼叫请求，所述第一呼叫请求携带有用于表示所述第一会议终端当前所支持的SRTP能力的第一属性参数，所述第一呼叫请求用于请求与所述第二会议终端进行初次SRTP能力协商；
所述第一会议终端接收二次SRTP能力协商请求，其中，所述二次SRTP能力协商请求为所述第二会议终端在初次协商失败的情况下发送的，其携带有用于表示所述第二会议终端当前所支持的SRTP能力的第二属性参数；
所述第一会议终端基于所述第二属性参数查询本地是否支持所述第二会议终端所支持的SRTP能力，以进行二次SRTP能力协商；其中，当查询出支持时，所述第一会议终端确定支持所述第二会议终端当前所支持的SRTP能力；
当查询出不支持时，所述第一会议终端再次发起三次SRTP能力协商请求，直至双发协商出统一的SRTP能力为止；或者，所述第一会议终端确定所述第二会议终端发起的二次SRTP能力协商失败。
5.一种会议终端，其特征在于，包括：
第一接收模块，用于接收第一会议终端发送的第一呼叫请求，所述第一呼叫请求携带有用于表示所述第一会议终端当前所支持的SRTP能力的第一属性参数；
第一协商模块，用于基于所述第一属性参数查询本地是否支持所述第一会议终端当前所支持的SRTP能力，以进行初次SRTP能力协商；
第一发送模块，用于当查询出不支持时，向所述第一会议终端发送二次SRTP能力协商请求，其中，所述二次SRTP能力协商请求携带有用于表示本地当前所支持的SRTP能力的第二属性参数，用于请求与所述第一会议终端进行二次SRTP能力协商。
6.根据权利要求5所述的会议终端，其特征在于，所述第一属性参数包括：用于表示加密算法的参数、用于表示认证算法的参数和密钥。
7.根据权利要求5所述的会议终端，其特征在于，所述第一协商模块包括：
第一解析模块，用于解析所述第一属性参数，得到用于表示所述第一会议终端当前所支持的加密算法的参数和认证算法的参数以及密钥；
第一查询模块，用于基于所述用于表示所述第一会议终端当前所支持的加密算法的参数和认证算法的参数查询本地所支持的加密算法和认证算法；
第三确定模块，用于确定支持所述第一会议终端当前所支持的SRTP能力；
第三发送模块，用于向所述第一会议终端发送应答消息；
其中，当协商成功时，所述应答消息携带有所述第一会议终端和本端均支持的一项SRTP能力的属性参数；当协商不成功时，所述应答消息中不包含任何SRTP能力的属性参数。
8.一种会议终端，其特征在于，包括：
第二发送模块，用于向第二会议终端发送的第一呼叫请求，所述第一呼叫请求携带有用于表示本地当前所支持的SRTP能力的第一属性参数，所述第一呼叫请求用于请求与所述第二会议终端进行初次SRTP能力协商；
第二接收模块，用于接收二次SRTP能力协商请求，其中，所述二次SRTP能力协商请求为所述第二会议终端在初次协商失败的情况下发送的，其携带有用于表示所述第二会议终端当前所支持的SRTP能力的第二属性参数；
第二协商模块，用于基于所述第二属性参数查询本地是否支持所述第二会议终端所支持的SRTP能力，以进行二次SRTP能力协商；其中，当查询出支持时，所述会议终端确定支持所述第二会议终端当前所支持的SRTP能力；
当查询出不支持时，所述会议终端再次发起三次SRTP能力协商请求，直至双发协商出统一的SRTP能力为止；或者，所述会议终端确定所述第二会议终端发起的二次SRTP能力协商失败。
CN201711065229.3A 2017-11-02 2017-11-02 一种srtp能力协商方法及会议终端 Active CN107846567B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711065229.3A CN107846567B (zh) 2017-11-02 2017-11-02 一种srtp能力协商方法及会议终端

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711065229.3A CN107846567B (zh) 2017-11-02 2017-11-02 一种srtp能力协商方法及会议终端

Publications (2)

Publication Number Publication Date
CN107846567A CN107846567A (zh) 2018-03-27
CN107846567B true CN107846567B (zh) 2020-12-29

Family

ID=61681660

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711065229.3A Active CN107846567B (zh) 2017-11-02 2017-11-02 一种srtp能力协商方法及会议终端

Country Status (1)

Country Link
CN (1) CN107846567B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108833943B (zh) * 2018-04-24 2020-12-08 苏州科达科技股份有限公司 码流的加密协商方法、装置及会议终端
CN108696512B (zh) * 2018-04-24 2021-02-02 苏州科达科技股份有限公司 跨协议的码流加密协商方法、装置及会议设备
CN110012260B (zh) * 2019-03-18 2021-01-19 苏州科达科技股份有限公司 一种视频会议内容保护方法、装置、设备及系统

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1751304A (zh) * 2003-02-13 2006-03-22 诺基亚有限公司 在多媒体流中用于信号指示流质量匹配和控制机制的方法
CN101183935A (zh) * 2007-12-17 2008-05-21 华为技术有限公司 Rtp报文的密钥协商方法、装置及系统
CN102594794A (zh) * 2011-12-24 2012-07-18 华为技术有限公司 一种媒体加密会议的接入方法及装置
CN103139737A (zh) * 2011-11-30 2013-06-05 中国移动通信集团公司 密钥协商方法及装置、短信二次确认方法、系统及设备
CN103475639A (zh) * 2013-08-09 2013-12-25 杭州华三通信技术有限公司 一种rtp回退处理方法及装置
CN103685181A (zh) * 2012-09-13 2014-03-26 北京大唐高鸿软件技术有限公司 一种基于srtp的密钥协商方法
CN105554029A (zh) * 2016-01-27 2016-05-04 北京邮电大学 WebRTC与SIP终端媒体互通的方法和媒体网关
US9722976B1 (en) * 2015-02-26 2017-08-01 Sonus Networks, Inc. Methods and apparatus for synchronizing decryption state with remote encryption state

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101106449B (zh) * 2006-07-13 2010-05-12 华为技术有限公司 实现多方通信安全的系统和方法
US8332639B2 (en) * 2006-12-11 2012-12-11 Verizon Patent And Licensing Inc. Data encryption over a plurality of MPLS networks
JP5316423B2 (ja) * 2007-12-19 2013-10-16 富士通株式会社 暗号化実施制御システム
US9154460B1 (en) * 2014-02-12 2015-10-06 Sonus Networks, Inc. Methods and apparatus for denial of service resistant policing of packets
CN104486077B (zh) * 2014-11-20 2017-09-15 中国科学院信息工程研究所 一种VoIP实时数据安全传输的端到端密钥协商方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1751304A (zh) * 2003-02-13 2006-03-22 诺基亚有限公司 在多媒体流中用于信号指示流质量匹配和控制机制的方法
CN101183935A (zh) * 2007-12-17 2008-05-21 华为技术有限公司 Rtp报文的密钥协商方法、装置及系统
CN103139737A (zh) * 2011-11-30 2013-06-05 中国移动通信集团公司 密钥协商方法及装置、短信二次确认方法、系统及设备
CN102594794A (zh) * 2011-12-24 2012-07-18 华为技术有限公司 一种媒体加密会议的接入方法及装置
CN103685181A (zh) * 2012-09-13 2014-03-26 北京大唐高鸿软件技术有限公司 一种基于srtp的密钥协商方法
CN103475639A (zh) * 2013-08-09 2013-12-25 杭州华三通信技术有限公司 一种rtp回退处理方法及装置
US9722976B1 (en) * 2015-02-26 2017-08-01 Sonus Networks, Inc. Methods and apparatus for synchronizing decryption state with remote encryption state
CN105554029A (zh) * 2016-01-27 2016-05-04 北京邮电大学 WebRTC与SIP终端媒体互通的方法和媒体网关

Also Published As

Publication number Publication date
CN107846567A (zh) 2018-03-27

Similar Documents

Publication Publication Date Title
US20200344063A1 (en) Authentication method, authentication apparatus, and authentication system
CN102833253B (zh) 建立客户端与服务器安全连接的方法及服务器
US8639929B2 (en) Method, device and system for authenticating gateway, node and server
CN106470104B (zh) 用于生成共享密钥的方法、装置、终端设备及系统
EP3151597B1 (en) Method and apparatus for achieving secret communications
CN109450852B (zh) 网络通信加密解密方法及电子设备
WO2017045552A1 (zh) 一种在ssl或tls通信中加载数字证书的方法和装置
CN102100031B (zh) 用于在用户接口中提供安全服务的设备及方法
WO2019178942A1 (zh) 一种进行ssl握手的方法和系统
CN107846567B (zh) 一种srtp能力协商方法及会议终端
CN102868665A (zh) 数据传输的方法及装置
WO2015180589A1 (zh) 终端设备的登录方法、终端设备和云端服务器
KR20080090534A (ko) 모바일 네트워크에서 재귀 인증을 위한 방법 및 시스템
CN107579826A (zh) 一种网络认证方法、中转节点及相关系统
CN108833943B (zh) 码流的加密协商方法、装置及会议终端
CN108599926B (zh) 一种基于对称密钥池的HTTP-Digest改进型AKA身份认证系统和方法
CN101449510B (zh) 加密和解密媒体数据的方法、装置
CN108040071B (zh) 一种VoIP音视频加密密钥动态切换方法
CN108616350B (zh) 一种基于对称密钥池的HTTP-Digest类AKA身份认证系统和方法
CN113472792B (zh) 一种长连接网络通信加密方法及系统
US20180183584A1 (en) IKE Negotiation Control Method, Device and System
WO2017197968A1 (zh) 一种数据传输方法及装置
CN112235320B (zh) 一种基于密码的视联网组播通信方法及装置
CN106464603B (zh) 一种传输请求的方法及客户端
US11362812B2 (en) Method of end to end securing of a communication

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant