一种跨安全边界的视频通话方法及系统与流程

1.本发明涉及视频通话技术领域，特别涉及一种跨安全边界的视频通话方法及系统。


背景技术：

2.随着目前数字信息联网技术的快速发展，各行业专用通信网络的建立，形成包括公安专网、铁路专网、教育专网、石化专网等信息网络分层的多元化广域网络。各个行业对信息联网应用建设日趋成熟。而某些特殊的网络应用，需要在不同的网络之间交互数据。比如公安系统一线部门需要实时与公安数据中心交换信息，传统模式是采用开放端口的方式，实现数据的交换。但在某些特殊的网络环境下或者对安全方面的需要，是无法开放所有的网络端口的。在这种情况下很多网络应用就无法部署了。
3.webrtc是近年流行的实时通讯技术，它使得视频通话技术门槛被大幅降低，更多的人愿意参与到这项功能的开发。但基于上述背景，在某些对数据安全要求较高的网络环境中，都会部署安全边界及防火墙等安全设备，这就会导致在很多跨网环境中无法应用基于webrtc技术实现的通讯功能。针对上述缺陷，本发明作出了改进。


技术实现要素：

4.为了克服背景技术的不足，本发明提供一种跨安全边界的视频通话方法及系统，通过改进视频通话方法流程和系统架构设计，能使安全边界两边的webrtc实现双向互通，以传统rtsp协议为媒介打通网络安全边界，来实现跨网webrtc视频通话，从而可以很好地满足实际需求。
5.本发明提供一种跨安全边界的视频通话方法，网络a与网络b之间布置有安全边界，网络a的第一用户与网络b的第二用户跨安全边界视频通话的方法包括以下步骤：
6.第一用户发布本地媒体到网络b，发布时会形成webrtc流且将webrtc流转成rtsp流，然后通过安全边界将网络a中的rtsp流转发至网络b；
7.第一用户订阅网络b的远端媒体，订阅时会将从网络b转发至网络a的rtsp流转成webrtc流；
8.第二用户发布本地媒体到网络a，发布时会形成webrtc流且将webrtc流转成rtsp流，然后通过安全边界将网络b中的rtsp流转发至网络a；
9.第二用户订阅网络a的远端媒体，订阅时会将从网络a转发至网络b的rtsp流转成webrtc流；
10.当第一用户成功发布本地媒体到网络b和成功订阅网络b的远端媒体且第二用户成功发布本地媒体到网络a和成功订阅网络a的远端媒体时，第一用户和第二用户就能实现跨安全边界的视频通话。
11.优选的，网络a的第一用户发布本地媒体到网络b包括以下步骤：
12.网络a的第一用户向网络a的webrtc服务器请求发布本地媒体；
13.鉴权通过，第一用户和网络a的webrtc服务器进行ice媒体协商；
14.协商成功，第一用户发布本地媒体到网络a的webrtc服务器；
15.网络a的mediaproxy服务器获取到本地媒体成功发布到webrtc服务器的通知；
16.网络a的mediaproxy服务器从webrtc服务器获取媒体流；
17.网络a的mediaproxy服务器将获取到的媒体流通过rtsp协议转发；
18.网络a的rtsp服务器接收到mediaproxy服务器推送的媒体流；
19.安全边界将网络a的rtsp服务器中的媒体流转发至网络b，至此网络a的第一用户成功发布本地媒体到网络b。
20.优选的，网络a的第一用户订阅网络b的远端媒体包括以下步骤：
21.网络a的第一用户向网络a的webrtc服务器请求订阅远端媒体；
22.鉴权通过，第一用户和网络a的webrtc服务器进行ice媒体协商；
23.网络a的mediaproxy服务器获取到第一用户请求订阅远端媒体的通知；
24.网络a的mediaproxy服务器向网络a的rtsp服务器拉取媒体流；
25.拉流成功且ice媒体协商成功，此时网络a的第一用户成功订阅网络b的远端媒体。
26.优选的，网络a的第一用户向网络a的webrtc服务器请求发布本地媒体或请求订阅远端媒体时会向webrtc服务器发出加入通话房间请求，加入通话房间请求包括鉴权信息，所述鉴权信息包括房间号、用户名和密码。
27.优选的，将webrtc流转成rtsp流包括以下步骤：
28.mediaproxy服务器接收到同一网络中webrtc服务器的通知消息；
29.mediaproxy服务器判断接收到的通知消息是否是用户发布本地媒体的通知类型；
30.判断为是，mediaproxy服务器获取与发布本地媒体的用户对应的用户id和媒体id；
31.mediaproxy服务器创建用于接收来自webrtc服务器转发的媒体流的网络端口；
32.mediaproxy服务器发送http请求至webrtc服务器并等待接收媒体流；
33.接收成功，mediaproxy服务器通过rtsp协议和同一网络中的rtsp服务器建立会话；
34.mediaproxy服务器发送rstp流至rtsp服务器。
35.优选的，将rtsp流转成webrtc流包括以下步骤：
36.mediaproxy服务器接收到同一网络中webrtc服务器的通知消息；
37.mediaproxy服务器判断接收到的通知消息是否是用户订阅远端媒体的通知类型；
38.判断为是，mediaproxy服务器获取与订阅远端媒体中被订阅用户对应的用户id；
39.mediaproxy服务器和同一网络中的rtsp服务器建立会话；
40.mediaproxy服务器从rtsp服务器拉取rtsp流；
41.拉取成功，mediaproxy服务器发送http请求至webrtc服务器，通知其创建用于接收媒体流的网络端口；
42.网络端口创建成功，mediaproxy服务器发送媒体流至webrtc服务器。
43.优选的，mediaproxy服务器接收到同一网络中webrtc服务器的通知消息，所述通知消息包括webrtc服务器地址和用户id。
44.本发明还提供一种跨安全边界的视频通话系统，包括网络a和网络b，所述网络a与
网络b之间布置有安全边界，所述网络a布置有webrtc服务器、mediaproxy服务器和rtsp服务器，所述网络b布置有webrtc服务器、mediaproxy服务器和rtsp服务器；
45.所述webrtc服务器用于实现webrtc协议服务，包括面向同一网络中用户的通话房间管理功能、媒体分发功能以及ice功能，还包括向同一网络中的mediaproxy服务器发送通知消息；
46.所述mediaproxy服务器用于监听同一网络中webrtc服务器的消息及管理同一网络中的rtsp服务器，管理同一网络中的rtsp服务器包括向rtsp服务器发出媒体推送请求和拉取请求；
47.所述rtsp服务器用于媒体流在不同网络之间的摆渡功能及用于接收来自同一网络中mediaproxy服务器的媒体推送和拉取请求。
48.优选的，所述mediaproxy服务器包括sessionmanager媒体会话模块、webrtcadapter模块和rtspadapter模块；
49.所述sessionmanager媒体会话模块用于监听来自同一网络中webrtc服务器的通知消息，通知消息包括同一网络中用户是否加入通话房间、是否发布本地媒体及是否订阅远端媒体，同时用于创建或删除本地接收媒体的网络端口，还用于通过http接口订阅同一网络中webrtc服务器通话房间内的媒体流；
50.所述webrtcadapter模块用于接收从同一网络中webrtc服务器通话房间内订阅到的媒体流并转换成rtp的封装格式，然后转发给所述rtspadapter模块，或用于接收来自所述rtspadapter模块的rtp流并通过webrtc协议将其发布到同一网络中的webrtc服务器中；
51.所述rtspadapter模块用于接收来自所述webrtcadapter模块的rtp流并通过rtsp协议将其推送至同一网络中的rtsp服务器中，同时也用于从同一网络中的rtsp服务器拉取rtsp流转换成rtp后转发至所述webrtcadapter模块。
52.优选的，所述mediaproxy服务器还用于管理同一网络中的其他媒体处理服务器，包括媒体存储服务器、视频分发服务器以及视频算法服务器。
53.综上所述，本发明有益效果为：
54.本发明在方法流程和系统架构方面提供了综合的解决方案，当网络a的第一用户发起通话请求的时候，第一用户发布的本地媒体首先通过ice协商，发布至webrtc服务器当中，mediaproxy服务器会监测到该媒体流，并通过发送消息拉取该媒体流，并转码成rtsp协议推送至网络a的rtsp服务器，此时安全边界会以rtsp服务器为媒体转发服务，将媒体数据转发到网络b的rtsp服务器当中，同时网络a的第一用户会不断尝试订阅网络b中第二用户发布的本地媒体，网络a的mediaproxy服务器从网络a的rtsp服务器拉取网络b摆渡过来的第二用户的媒体流，并发布到webrtc服务器，本发明能使安全边界两边的webrtc实现双向互通，以传统rtsp协议为媒介打通网络安全边界，来实现跨网webrtc视频通话，从而可以很好地满足实际需求。
55.下面结合附图对本发明作进一步说明。
附图说明
56.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本
发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
57.图1是本发明实施例提供的一种跨安全边界的视频通话系统的网络拓扑图；
58.图2是本实施例提供的一种跨安全边界的视频通话系统的结构框图；
59.图3是本发明实施例提供的跨安全边界的视频通话系统中发布本地媒体的一种流程图；
60.图4是本发明实施例提供的跨安全边界的视频通话系统中订阅远端媒体的一种流程图；
61.图5是本发明实施例提供的跨安全边界的视频通话系统中webrtc转rtsp的一种流程图；
62.图6是本发明实施例提供的跨安全边界的视频通话系统中rtsp转webrtc的一种流程图。
具体实施方式
63.下面将结合本发明实施例中的图1至图6，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
64.为使本发明实施的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行更加详细的描述。
65.如图1至图6所示，本实施例公开一种跨安全边界的视频通话方法，网络a与网络b之间布置有安全边界，网络a的第一用户与网络b的第二用户跨安全边界视频通话的方法包括以下步骤：
66.第一用户发布本地媒体到网络b，发布时会形成webrtc流且将webrtc流转成rtsp流，然后通过安全边界将网络a中的rtsp流转发至网络b；
67.第一用户订阅网络b的远端媒体，订阅时会将从网络b转发至网络a的rtsp流转成webrtc流；
68.第二用户发布本地媒体到网络a，发布时会形成webrtc流且将webrtc流转成rtsp流，然后通过安全边界将网络b中的rtsp流转发至网络a；
69.第二用户订阅网络a的远端媒体，订阅时会将从网络a转发至网络b的rtsp流转成webrtc流；
70.当第一用户成功发布本地媒体到网络b和成功订阅网络b的远端媒体且第二用户成功发布本地媒体到网络a和成功订阅网络a的远端媒体时，第一用户和第二用户就能实现跨安全边界的视频通话。
71.上述步骤给出了跨安全边界视频通话的基本方法，视频通话，包含发布本地媒体和订阅远端媒体，其中，发布本地媒体就是本地视频采集发布(即发布自己的图像)，订阅远端媒体就是远端视频的订阅(即订阅对方的图像)，视频通话过程中，发布本地媒体和订阅远端媒体的两种流程是可以独立存在的。跨安全边界视频通话可以是网络a的第一用户向网络b的第二用户发起视频通话请求，网络b的第二用户接受网络a的第一用户发起的视频
通话请求，第一用户向第二用户发起视频通话请求时会发布本地媒体到网络b并同时订阅网络b的远端媒体，第二用户接受第一用户发起的视频通话请求时会发布本地媒体到网络a并同时订阅网络a的远端媒体，跨安全边界视频通话也可以是网络b的第二用户向网络a的第一用户发起视频通话请求，网络a的第一用户接受网络b的第二用户发起的视频通话请求，原理同上。当第一用户成功发布本地媒体到网络b和成功订阅网络b的远端媒体且第二用户成功发布本地媒体到网络a和成功订阅网络a的远端媒体时，第一用户和第二用户就能实现跨安全边界的视频通话。上述技术方案使安全边界两边的webrtc实现双向互通，以传统rtsp协议为媒介打通网络安全边界，来实现跨网webrtc视频通话，从而可以很好地满足实际需求。上述技术方案中的第一用户和第二用户均可理解为终端。
72.作为优选的一种技术方案，网络a的第一用户发布本地媒体到网络b包括以下步骤：
73.步骤301，网络a的第一用户向网络a的webrtc服务器请求发布本地媒体；
74.在本步骤中，网络a的第一用户向网络a的webrtc服务器请求发布本地媒体时会向webrtc服务器发出加入通话房间请求，加入通话房间请求包括鉴权信息，所述鉴权信息包括但不限于房间号、用户名和密码等。
75.步骤302，鉴权通过，第一用户和网络a的webrtc服务器进行ice媒体协商；
76.在本步骤中，鉴权通过后第一用户就加入通话房间，第一用户开始同webrtc服务器进行ice媒体协商。
77.步骤303，协商成功，第一用户发布本地媒体到网络a的webrtc服务器；
78.在本步骤中，如果协商成功，会创建第一用户与webrtc服务器之间的媒体传输通道，建立媒体通道后，调用浏览器的getusermedia接口采集第一用户的本地视频流，一般会是摄像头的画面，而后传入媒体通道，第一用户成功发布本地媒体到网络a的webrtc服务器，然后进入步骤305。如果协商失败，则进入步骤304。
79.步骤304，协商失败，ice协商失败导致发布本地媒体的流程失败，即流程结束；
80.步骤305，网络a的mediaproxy服务器获取到本地媒体成功发布到webrtc服务器的通知；
81.在本步骤中，webrtc服务器接收的用户加入通话房间或本地媒体成功发布到webrtc服务器，会发送http通知消息给mediaproxy服务器，mediaproxy服务器获取到通知消息后，会解析出用户id和创建本地用于接收媒体的网络端口，并发送http请求至webrtc服务器，携带已经创建的网络端口号。
82.步骤306，网络a的mediaproxy服务器从webrtc服务器获取媒体流；
83.在本步骤中，mediaproxy服务器通过创建的本地网络接收端口接收来自webrtc服务器发送的媒体流。
84.步骤307，网络a的mediaproxy服务器将获取到的媒体流通过rtsp协议转发；
85.在本步骤中，mediaproxy服务器构建推流地址与rtsp服务器建立会话，并将接收到的媒体流发送到rtsp服务器。
86.步骤308，网络a的rtsp服务器接收到mediaproxy服务器推送的媒体流；
87.步骤309，安全边界将网络a的rtsp服务器中的媒体流转发至网络b，至此网络a的第一用户成功发布本地媒体到网络b。
88.上述流程通过将webrtc流转换成rtsp流，并以rtsp协议将数据流摆渡至对端网络，从而实现了媒体的跨网发布。
89.作为优选的一种技术方案，网络a的第一用户订阅网络b的远端媒体包括以下步骤：
90.步骤401，网络a的第一用户向网络a的webrtc服务器请求订阅远端媒体；
91.在本步骤中，网络a的第一用户向网络a的webrtc服务器请求订阅远端媒体时会向webrtc服务器发出加入通话房间请求，加入通话房间请求包括鉴权信息，所述鉴权信息包括但不限于房间号、用户名和密码。
92.步骤402，鉴权通过，第一用户和网络a的webrtc服务器进行ice媒体协商；
93.在本步骤中，鉴权通过后第一用户就加入通话房间，第一用户开始同webrtc服务器进行ice媒体协商，协商成功就创建第一用户与webrtc服务器之间的媒体传输通道，用于接收远端媒体流，协商失败就不断尝试协商直至成功。
94.步骤403，网络a的mediaproxy服务器获取到第一用户请求订阅远端媒体的通知；
95.在本步骤中，webrtc服务器接收的用户加入通话房间并请求订阅远端媒体时，会发送http通知消息给mediaproxy服务器，mediaproxy服务器会获取到该http消息订阅请求。
96.步骤404，网络a的mediaproxy服务器向网络a的rtsp服务器拉取媒体流；
97.在本步骤中，mediaproxy服务器获取到http消息订阅请求时会向网络a的rtsp服务器拉取媒体流。
98.步骤405，拉流成功且ice媒体协商成功，此时网络a的第一用户成功订阅网络b的远端媒体。
99.在本步骤中，ice媒体协商成功会成功创建用于接收远端媒体流的媒体传输通道并将消息反馈给第一用户，拉流成功且ice媒体协商成功时网络a的第一用户就成功订阅网络b的远端媒体。拉流失败或ice协商失败会将消息反馈给第一用户，第一用户会收到拉流失败或协商失败的消息，提示订阅远端媒体失败。
100.上述流程通过将对端网络摆渡过来的rtsp流转换成webrtc流，从而实现了远端媒体的订阅。
101.作为优选的一种技术方案，将webrtc流转成rtsp流包括以下步骤：
102.步骤501，mediaproxy服务器接收到同一网络中webrtc服务器的通知消息；
103.在本步骤中，mediaproxy服务器接收到同一网络中webrtc服务器的通知消息，通知消息包括webrtc服务器地址和用户id，webrtc服务器地址能表明是哪台webrtc服务器的通话房间有用户加入，用户id作为指示该用户的标识。
104.步骤502，mediaproxy服务器判断接收到的通知消息是否是用户发布本地媒体的通知类型；
105.在本步骤中，具体实施时接收到的通知消息除了用户发布本地媒体的通知类型外还存在其他通知类型，不同通知类型会对应不同的处理流程，故通过本步骤来判断接收到的通知消息是否是用户发布本地媒体的通知类型。
106.步骤503，判断为是，mediaproxy服务器获取与发布本地媒体的用户对应的用户id和媒体id；
107.在本步骤中，判断接收到的通知消息是用户发布本地媒体的通知类型，即有通话房间内发布本地媒体了，则mediaproxy服务器就会获取与发布本地媒体的用户对应的用户id和媒体id，然后进入步骤505，媒体id对应该用户发布的本地媒体。判断为否，则进入步骤504。
108.步骤504，其它处理流程，包括但不限于录像存储、媒体流转发第三方模块等。
109.步骤505，mediaproxy服务器创建用于接收来自webrtc服务器转发的媒体流的网络端口；
110.步骤506，mediaproxy服务器发送http请求至webrtc服务器并等待接收媒体流；
111.在本步骤中，mediaproxy服务器发送http请求至webrtc服务器时会携带媒体id和已经创建的网络端口，此处已经创建的网络端口指步骤505中创建好的网络端口。
112.步骤507，接收成功，mediaproxy服务器通过rtsp协议和同一网络中的rtsp服务器建立会话；
113.在本步骤中，mediaproxy服务器的本地网络端口成功接收到webrtc服务器发送的媒体流后，mediaproxy服务器会以用户id来构建url地址，并和同一网络中的rtsp服务器建立会话。mediaproxy服务器接收媒体流失败时则转发失败。
114.步骤508，mediaproxy服务器发送rstp流至rtsp服务器。
115.在本步骤中，mediaproxy服务器和rtsp服务器建立会话后mediaproxy服务器就能发送rstp流至rtsp服务器，至此mediaproxy服务器的webrtc流转rtsp流的流程完成。
116.作为优选的一种技术方案，将rtsp流转成webrtc流包括以下步骤：
117.步骤601，mediaproxy服务器接收到同一网络中webrtc服务器的通知消息；
118.在本步骤中，mediaproxy服务器接收到同一网络中webrtc服务器的通知消息，通知消息包括webrtc服务器地址和用户id，webrtc服务器地址能表明是哪台webrtc服务器的通话房间有用户加入，用户id作为指示该用户的标识。
119.步骤602，mediaproxy服务器判断接收到的通知消息是否是用户订阅远端媒体的通知类型；
120.在本步骤中，具体实施时接收到的通知消息除了用户订阅远端媒体的通知类型外还存在其他通知类型，不同通知类型会对应不同的处理流程，故通过本步骤来判断接收到的通知消息是否是用户订阅远端媒体的通知类型。
121.步骤603，判断为是，mediaproxy服务器获取与订阅远端媒体中被订阅用户对应的用户id；
122.在本步骤中，判断接收到的通知消息是用户订阅远端媒体的通知类型，即有通话房间内订阅远端媒体了，则mediaproxy服务器就会获取用户id，该用户id对应订阅远端媒体中被订阅的用户，然后进入步骤605。判断为否，则进入步骤604。
123.步骤604，其它处理流程，包括但不限于录像存储、媒体流转发第三方模块等。
124.步骤605，mediaproxy服务器和同一网络中的rtsp服务器建立会话；
125.在本步骤中，mediaproxy服务器通过rtsp协议和同一网络中的rtsp服务器建立会话。
126.步骤606，mediaproxy服务器从rtsp服务器拉取rtsp流；
127.在本步骤中，mediaproxy服务器和rtsp服务器建立会话后mediaproxy服务器就会
从rtsp服务器拉取rtsp流。
128.步骤607，拉取成功，mediaproxy服务器发送http请求至webrtc服务器，通知其创建用于接收媒体流的网络端口；
129.在本步骤中，mediaproxy服务器从rtsp服务器成功拉取rtsp流后mediaproxy服务器会发送http请求至webrtc服务器，通知其创建用于接收媒体流的网络端口。
130.步骤608，网络端口创建成功，mediaproxy服务器发送媒体流至webrtc服务器。
131.在本步骤中，webrtc服务器成功创建网络端口后mediaproxy服务器就会转发媒体流至webrtc服务器，至此mediaproxy服务器的rtsp流转webrtc流的流程完成。当webrtc服务器未成功创建网络端口时则转发失败。
132.本实施例还公开一种跨安全边界的视频通话系统，包括网络a和网络b，所述网络a与网络b之间布置有安全边界，所述网络a布置有webrtc服务器、mediaproxy服务器和rtsp服务器，所述网络b布置有webrtc服务器、mediaproxy服务器和rtsp服务器；如图1所示，是本发明实施例提供的一种跨安全边界视频通话系统的网络拓扑图，具体实施时rtsp服务器可以包含多台服务器，图1中都以单台服务器、单次双向通话请求为例进行说明，所述系统通过http/json-rpc消息和终端用户通信。
133.所述webrtc服务器用于实现webrtc协议服务，包括面向同一网络中用户的通话房间管理功能、媒体分发功能以及ice功能，还包括向同一网络中的mediaproxy服务器发送通知消息；webrtc服务器用于通话房间管理和媒体分发，以及包含底层的webrtc协议实现，具体可以为收到来自终端用户的加入通话房间请求，用户加入通话房间后，即可以发布直接的媒体流，同时会获取到房间内其它用户的用户信息和媒体信息，用户可以选择订阅或不订阅其它用户的媒体，至此简单的通话房间管理和媒体分发流程完成。用户发布完本地媒体或订阅远端媒体之后，webrtc服务器会立即通知mediaproxy服务器，同时也会提供http接口方便第三方服务订阅房间内的媒体流，可参考现有技术，在此不做具体说明。对于ice功能，主要是终端用户和同一网络的webrtc服务器进行ice媒体协商，协商成功就创建终端用户与webrtc服务器之间的媒体通道，可便于媒体流的传送。
134.所述mediaproxy服务器用于监听同一网络中webrtc服务器的消息及管理同一网络中的rtsp服务器，管理同一网络中的rtsp服务器包括向rtsp服务器发出媒体推送请求和拉取请求；mediaproxy服务器专门用于监听webrtc服务器的消息，包括但不限于用户的加入、本地媒体的发布和远端媒体的订阅以及用户的离开、本地媒体的发布取消和远端媒体的订阅取消等，同时用于将媒体或信令通知转发给第三方服务器，它会管理多台服务器，从中选取合适的转发，比如rtsp服务器，进而便于实现分发功能(拉取和推送)，即通过mediaproxy服务器向rtsp服务器发出媒体推送请求和拉取请求。作为优选的一种技术方案，mediaproxy服务器管理多台服务器时还用于管理同一网络中的其他媒体处理服务器，包括媒体存储服务器、视频分发服务器以及视频算法服务器，可有利于更好地满足实际使用需求。
135.所述rtsp服务器用于媒体流在不同网络之间的摆渡功能及用于接收来自同一网络中mediaproxy服务器的媒体推送和拉取请求。rtsp服务器，用于rtsp服务的实现，可以从mediaproxy服务器接收到通话的媒体流并将其转换成rtsp格式播放地址，提供媒体摆渡媒介，为网络安全边界实施媒体转发提供服务，还可以在mediaproxy服务器发出拉取媒体请
求时将从对端网络转发过来的rtsp流发送给mediaproxy服务器。
136.由此可知采用上述视频通话系统实施前述视频通话方法就能很好地进行跨安全边界的视频通话，可有利于更好地满足实际需求。
137.作为优选的一种技术方案，所述mediaproxy服务器包括sessionmanager媒体会话模块、webrtcadapter模块和rtspadapter模块；
138.所述sessionmanager媒体会话模块用于监听来自同一网络中webrtc服务器的通知消息，通知消息包括同一网络中用户是否加入通话房间、是否发布本地媒体及是否订阅远端媒体，同时用于创建或删除本地接收媒体的网络端口，还用于通过http接口订阅同一网络中webrtc服务器通话房间内的媒体流；sessionmanager媒体会话模块主要用于实现媒体监听功能和分发功能(拉取和推送)，进而便于实现双向视频通话功能。
139.所述webrtcadapter模块用于接收从同一网络中webrtc服务器通话房间内订阅到的媒体流并转换成rtp的封装格式，然后转发给所述rtspadapter模块，或用于接收来自所述rtspadapter模块的rtp流并通过webrtc协议将其发布到同一网络中的webrtc服务器中；webrtcadapter模块可以理解为面向webrtc服务器的适配端口。
140.所述rtspadapter模块用于接收来自所述webrtcadapter模块的rtp流并通过rtsp协议将其推送至同一网络中的rtsp服务器中，同时也用于从同一网络中的rtsp服务器拉取rtsp流转换成rtp后转发至所述webrtcadapter模块。rtspadapter模块可以理解为面向rtsp服务器的适配端口。
141.本实施例中未涉及部分均与现有技术相同或可采用现有技术加以实现，在此不做进一步说明。
142.各位技术人员须知：虽然本发明已按照上述具体实施方式做了描述，但是本发明的发明思想并不仅限于此发明，任何运用本发明思想的改装，都将纳入本专利权保护范围内。