一种基于背靠背鉴权模式的端到端流媒体路由方法与流程

1.本发明涉及流媒体通讯领域，多用于通讯场景，尤其涉及一种基于背靠背鉴权模式的端到端流媒体路由方法。


背景技术：

2.目前行业中通常通过通讯双方的ip鉴权来解决通讯中的安全问题，或通过采购一些通讯支撑系统来进行上下游ip信任管理。常用通讯管理工具例如vos，rts等，系统集成成本高，且服务支持规模仍非常有限。
3.使用外呼终端建立实时通讯会话，通讯双方需要进行ip鉴权来保证通讯的安全。单台服务器支持的流媒体通道为500左右，意味着单台服务器能支撑最多500通会话同时进行。在通讯服务场景中，通讯服务商通常需要支持数以万计的会话，这将需要同时有数百上千台服务器同时提供服务。如果为了保证通讯的安全性，那么通讯双方需要鉴权信任的ip将会成百上千，这种鉴权信任的方式十分繁琐，且添加或减少服务器时，服务需要中断才能进行修改。目前行业通用做法中，采用信令和媒体分流的方式来解决，但单台信令服务器容纳上线仍不超过5000，不足以满足高并发的业务场景。


技术实现要素：

4.本发明的目的在于提供一种基于背靠背鉴权模式的端到端流媒体路由方法，以解决上述技术背景中提出的问题。
5.为实现上述目的，本发明采用以下技术方案：
6.一种基于背靠背鉴权模式的端到端流媒体路由方法，包括：
7.在外呼终端和外呼系统之间增设外呼网关，所述外呼网关为包括至少两个网关节点的网关集群，每个网关节点对应一个独立的信令服务器；
8.外呼终端建立实时通讯会话请求；
9.外呼网关收集各个外呼终端的sdp消息，进行鉴权处理，基于预设的负载策略调整各网关节点的负载，并对内网进行nat穿透，将外呼终端的会话请求通过外呼系统转发给外呼目标终端，以及将外呼目标终端的音频数据流通过外呼系统转发给外呼终端，实现内网音频服务器和外网终端设备之间端到端的音频互通。
10.优选地，所述外呼终端包括、但不限于h5页面、移动终端、物联网络端。
11.优选地，所述鉴权处理包括：
12.在使用外呼终端前，手工从外呼网关注册终端号，并在外呼终端生成密钥；
13.外呼终端接入外呼网关时需要根据分配的终端号进行登录操作，即在后端调用登录接口并获取此次交互的临时token；
14.外呼终端进行外呼时，向外呼网关发起一个长链接请求，该长链接请求中携带有登录时的临时token，外呼网关根据所述临时token进行校验，若验证成功，则判断该外呼终端为合法终端，建立外呼终端与外呼系统之间的交互；
15.其中，外呼终端与外呼网关进行交互过程中，数据传输采用预先设置的加密算法进行加密操作。
16.更优选地，所述加密算法采用aes rsa加密。
17.优选地，所述负载策略包括：
18.(1)获取不同网关节点的机器配置信息；
19.(2)配置高的机器，被分配较高的权重，使其能处理更多的会话请求；
20.(3)配置低的机器，被分配较低的权重；
21.(4)根据加权轮询算法对每个网关节点中的负载信息进行计算，确定每个网关节点的负载权重，以达到(2)(3)的效果；
22.(5)当系统压力大于预设阈值后，动态地添加机器数量，并将新增的机器添加至轮询列表；
23.(6)当系统压力峰值过后，根据需要减少机器数量。
24.优选地，所述方法包括鉴权场景、建立会话场景和结束会话场景；
25.所述鉴权场景包括如下步骤：
26.a1，外呼终端发起登录请求，外呼网关返回此次交互的临时token；
27.a2，外呼终端发起长链接请求，长链接请求携带所述临时token，外呼网关根据所述临时token进行校验，若校验通过，则外呼终端获得交互权限；
28.所述建立会话包括如下步骤：
29.b1，外呼终端与外呼网关之间进行nat穿透协商；
30.b2，外呼网关与外呼系统之间进行nat穿透协商；
31.b3，外呼终端发起呼叫请求，请求外呼网关开始sip信令协商；
32.b4，外呼网关与外呼系统之间透传sip信令，并进行信令数据转换传递，外呼系统依据呼叫请求的目标对象信息解析，并通过外呼网关向外呼目标终端发起新的呼叫；
33.b5，外呼网关与外呼目标终端之间进行sip信令协商，并将外呼目标终端返回的信令数据传递回外呼网关，最终由外呼网关转换信令数据并传递至外呼终端；
34.b6，外呼终端与外呼网关之间进行媒体协商，协商信息包含音频编码及目标地址等传输媒体依赖信息；
35.b7，外呼终端向外呼网关发送语音，经编码加密后传输至外呼网关；
36.b8，外呼网关与外呼系统之间透传媒体流数据，外呼系统接收媒体流数据，如果通话两方编码一致，则直接转发媒体数据，若不一致，则进行编码转换操作后转发媒体数据；
37.b9，外呼网关与外呼目标终端之间透传媒体流数据，外呼目标终端接收到媒体流数据进行解码操作；
38.b10，外呼目标终端向外呼网关发送语音，同外呼终端向外呼网关发送语音过程一致；
39.b11，外呼系统与外呼网关之间透传流媒体数据；
40.b12，外呼系统与外呼终端之间透传流媒体数据；
41.所述结束会话场景包括如下步骤：
42.c1，外呼终端发起结束sip信令协商；
43.c2，外呼网关与外呼系统之间透传sip信令，外呼网关将外呼终端的挂断信令转发
至外呼系统；
44.c3，外呼系统接收到挂断信令，立即回复外呼终端已收到挂断请求，同时释放与外呼终端一侧建立的呼叫通道，另外，外呼系统根据与外呼目标终端一侧已经建立的呼叫通道，重新向外呼终端发起挂断请求，请求首先到外呼网关，并从外呼网关发往外呼目标终端；
45.c4，外呼网关与外呼终端目标终端之间进行sip信令协商；
46.c5，外呼目标终端收到挂断信令，进行资源释放并回复外呼网关已收到请求；
47.c6，外呼网关将外呼目标终端回复的信息转发至外呼系统；
48.c7，外呼系统收到消息，释放通话资源，通话结束；
49.其中，sip信令，用于交互对端信息并建立会话连接。
50.更优选地，所述方法还包括：外呼终端注册场景，所述外呼终端注册场景包括：外呼终端在使用前，先向外呼网关注册终端号，并在外呼终端上生成密钥。
51.优选地，所述外呼终端与所述外呼目标终端之间的音频传输采用流式编解码方式实现。
52.优选地，所述nat穿透采用udp协议实现媒体流的传输，具体包括如下步骤：
53.外呼终端通过对外呼网关的请求，将外呼终端的通信地址告知外呼网关，同时外呼网关将请求经过处理后转发至外呼系统；
54.外呼系统收到请求经处理回复并告知自身的通信地址；
55.当外呼终端发送媒体流数据时，则由外呼网关按照已知的通信地址转发至外呼系统。
56.与现有技术相比，本发明的技术方案具有以下有益效果：
57.本技术通过容器化的部署方式，实现了外呼网关的集群使用，防止单一外呼网关节点承压过大导致服务不可用的现象；同时，通过容器化构建信令服务器的思想，将多台信令服务器容器化进行构建，理论上可无限扩展信令服务器的数量，支撑海量实时通讯。本技术对外服务中仅暴露容器ip，通讯双方的ip信任维护管理工作变得简单且顺畅。
附图说明
58.构成本技术的一部分附图用来提供对本技术的进一步理解，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
59.图1是本发明的物理架构图；
60.图2是本发明中外呼终端与外呼目标终端之间进行交互的交互流程图。
具体实施方式
61.为使本发明的目的、技术方案及效果更加清楚、明确，以下参照附图并举实例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
62.需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序，应该理解这样使用的数据在适当情况下可以互换。此外，术语“包括”和“具有”以及它们的任何变形，意图在于
覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
63.本技术公开了一种基于背靠背鉴权模式的端到端流媒体路由方法，包括：在外呼终端和外呼系统之间增设外呼网关，所述外呼网关为包括至少两个网关节点的网关集群，每个网关节点对应一个独立的信令服务器；外呼终端建立实时通讯会话请求；外呼网关收集各个外呼终端的sdp消息，进行鉴权处理，基于预设的负载策略调整各网关节点的负载，并对内网进行nat穿透，将外呼终端的会话请求通过外呼系统转发给外呼目标终端，以及将外呼目标终端的音频数据流通过外呼系统转发给外呼终端，实现内网音频服务器和外网终端设备之间端到端的音频互通。其中，信令服务器作为外呼网关的重要组成部分，承担了于内部呼叫系统和外部呼叫终端的信令交互工作；外呼网关采用容器化的部署方式实现了集群使用，防止单一外呼网关节点承压过大导致服务不可用。
64.外呼终端可以是h5页面、移动终端，甚至可以是物联网终端。这些外呼终端实现外呼时必须联网，这就涉及到网络安全的问题。本技术在外呼终端外呼时进行了鉴权处理，同时为了满足大批量外呼终端同时在线使用，在网关层对访问的外呼终端做了负载策略，可以分布式地横向扩容网关节点。具体参阅图1所示。
65.上述内容中，所述鉴权处理包括：
66.在使用外呼终端前，手工从外呼网关注册终端号，并在外呼终端生成密钥；
67.外呼终端接入外呼网关时需要根据分配的终端号进行登录操作，即在后端调用登录接口并获取此次交互的临时token；
68.外呼终端进行外呼时，向外呼网关发起一个长链接请求，该长链接请求中携带有登录时的临时token，外呼网关根据所述临时token进行校验，若验证成功，则判断该外呼终端为合法终端，建立外呼终端与外呼系统之间的交互；
69.其中，外呼终端与外呼网关进行交互过程中，数据传输采用预先设置的加密算法进行加密操作，所述加密算法优选为aes rsa加密算法。
70.上述内容中，所述负载策略包括：
71.(1)由于不同网关节点的机器，其配置和当前系统的负载并不相同，因此它们的抗压能力也不一样；
72.(2)配置高的机器，被分配较高的权重，使其能处理更多的会话请求；
73.(3)配置低的机器，被分配较低的权重；
74.(4)根据加权轮询算法对每个网关节点中的负载信息进行计算，确定每个网关节点的负载权重，以达到(2)(3)的效果；
75.(5)当系统压力大于预设阈值后，动态地添加机器数量，并将新增的机器添加至轮询列表；
76.(6)当系统压力峰值过后，可以根据需要减少机器的数量，减少浪费。
77.鉴于外呼网关中每台机器的配置等不同，其处理能力会不一样。所以，本技术采用了加权轮询算法(weightedround-robin)。加权轮询算法的原理是：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。采用加权轮询算法对每个网关节点中的负载信息进行计算，确定每个网关节点的负载权重，动态调整机
器的数量，可以分布式地横向扩容网关节点，可支持海量实时通讯。
78.为了保证访问的安全性，本技术的技术方案中，对内网采用nat穿透技术，实现了外呼终端和外呼目标终端之间、即端到端的互联互通。nat(network address translation，网络地址转换)是将ip数据报文头中的ip地址转换为另一个ip地址的过程。本技术中主要是通过udp方式来实现，外呼终端通过对外呼网关的请求，将外呼终端的通信地址告知外呼网关，同时外呼网关将请求经过处理后转发至外呼系统，外呼系统收到请求经处理回复并告知自身的通信地址，当外呼终端发送媒体流数据，则由外呼网关转发至外呼系统。
79.图2给出了外呼终端与外呼目标终端之间进行交互的交互流程图。参阅图2所示，整个交互过程具体包括如下步骤：
80.步骤s1，外呼终端发起登录请求，外呼网关返回此次交互的临时token；
81.步骤s2，外呼终端发起长链接请求，长链接请求携带所述临时token，外呼网关根据所述临时token进行校验，若校验通过，则外呼终端获得交互权限；
82.步骤s3，外呼终端与外呼网关之间进行nat穿透协商；
83.步骤s4，外呼网关与外呼系统之间进行nat穿透协商；
84.步骤s5，外呼终端发起呼叫请求，请求外呼网关开始sip信令协商；
85.步骤s6，外呼网关与外呼系统之间透传sip信令，并进行信令数据转换传递，外呼系统依据呼叫请求的目标对象信息解析，并通过外呼网关向外呼目标终端发起新的呼叫；
86.步骤s7，外呼网关与外呼目标终端之间进行sip信令协商，并将外呼目标终端返回的信令数据传递回外呼网关，最终由外呼网关转换信令数据并传递至外呼终端；
87.步骤s8，外呼终端与外呼网关之间进行媒体协商，协商信息包含音频编码及目标地址等传输媒体依赖信息；
88.步骤s9，外呼终端向外呼网关发送语音，经编码加密后传输至外呼网关；
89.步骤s10，外呼网关与外呼系统之间透传媒体流数据，外呼系统接收媒体流数据，如果通话两方编码一致，则直接转发媒体数据，若不一致，则进行编码转换操作后转发媒体数据；
90.步骤s11，外呼网关与外呼目标终端之间透传媒体流数据，外呼目标终端接收到媒体流数据进行解码操作；
91.步骤s12，外呼目标终端向外呼网关发送语音，同外呼终端向外呼网关发送语音过程一致；
92.步骤s13，外呼系统与外呼网关之间透传流媒体数据；
93.步骤s14，外呼系统与外呼终端之间透传流媒体数据；
94.步骤s15，外呼终端发起结束sip信令协商；
95.步骤s16，外呼网关与外呼系统之间透传sip信令，外呼网关将外呼终端的挂断信令转发至外呼系统；
96.步骤s17，外呼系统接收到挂断信令，立即回复外呼终端已收到挂断请求，同时释放与外呼终端一侧建立的呼叫通道，另外，外呼系统根据与外呼目标终端一侧已经建立的呼叫通道，重新向外呼终端发起挂断请求，请求首先到外呼网关，并从外呼网关发往外呼目标终端；
97.步骤s18，外呼网关与外呼终端目标终端之间进行sip信令协商；
98.步骤s19，外呼目标终端收到挂断信令，进行资源释放并回复外呼网关已收到请求；
99.步骤s20，外呼网关将外呼目标终端回复的信息转发至外呼系统；
100.步骤s21，外呼系统收到消息，释放通话资源，通话结束。
101.上述内容中，步骤s1～s2实现了外呼时的鉴权，保证了通讯的安全性；步骤s3～s14实现了外呼终端和外呼目标终端之间的互联互通；步骤s15～s21实现了会话场景的结束。
102.上述内容中，sip信令，用于交互对端信息并建立会话连接；所述外呼终端与所述外呼目标终端之间的音频传输采用流式编解码方式实现，确保了信息的安全性。
103.其中，sip是由ietf(internet engineering task force)组织提出的ip电话信令协议。sip是一种基于文本格式的客户机/服务器模式的通讯协议，sip消息包括了请求消息和响应消息。二者都具有相同的消息格式，这两种消息类型都由一个起始行，一个或者多个头部域，一个可选的消息体组成：
104.在请求消息的起始行(又称请求行)中，sip定义了请求执行的操作。sip提供了给用户扩充的功能集，到目前为止的版本共定义了：邀请(invite)、回应(ack)、选择(options)、结束(bye)、取消(cancel)、注册(register)、信息(info)、分配(ailocate)和更新(update)。
105.在响应消息的起始行(又称状态行)中共定义了6类响应来表示指示请求执行的结果，每个响应代码均用3位数表示，第1位数字指示响应的类别，后2位数字表示具体的响应。
106.sip消息体采用sdp定义，sdp会话描述由文本行组成，每个文本行的格式均为《类型》＝《值》，包含了参与现存会话相关的必要信息：
107.会话信息：会话名和目的；会话激活的时间区段；构成会话的媒体；接收媒体所需地址、端口、格式等；会话所用的带宽信息(任选)；会话负责人的联系信息(任选)；
108.媒体信息：媒体类型(视频/音频等)；传送协议(rtp/udp/ip、h.323等)；媒体格式(h.261视频/mpeg视频等)；媒体地址和端口；
109.时间信息：会话的开始和结束时间；
110.加密信息：可选。
111.上述交互过程中，本技术技术方案可以穿透指定内网，避免了外呼系统直接对外暴露，提高了系统的安全性。应用本技术技术方案，可以实现随时给电话网络中的手机号拨打电话进行外呼。
112.综上所述，本技术通过容器化的部署方式，实现了外呼网关的集群使用，防止单一外呼网关节点承压过大导致服务不可用的现象；同时，通过容器化构建信令服务器的思想，将多台信令服务器容器化进行构建，理论上可无限扩展信令服务器的数量，支撑海量实时通讯。本技术对外服务中仅暴露容器ip，通讯双方的ip信任维护管理工作变得简单且顺畅。
113.以上对本发明的具体实施例进行了详细描述，但其只是作为范例，本发明并不限制于以上描述的具体实施例。对于本领域技术人员而言，任何对本发明进行的等同修改和替代也都在本发明的范畴之中。因此，在不脱离本发明的精神和范围下所作的均等变换和修改，都应涵盖在本发明的范围内。