一种跨网域的RTSP流媒体传输方法与流程

一种跨网域的rtsp流媒体传输方法
技术领域
1.本发明属于流媒体传输技术领域，尤其涉及一种跨网域的rtsp流媒体传输方法。


背景技术：

2.随着社会的发展，工业智能化的进一步提高，对各种流媒体数据的智能分析、挖掘越来越重视，这些流媒体数据大多来源于摄像头、麦克风等物理设备。为了更高效、更及时地传输流媒体数据以用于后期的智能分析工作，通常采用实时流协议实现流媒体数据的传输。
3.实时流协议(real time streaming protocol，rtsp)是tcp/ip协议体系中的一个应用层协议，该协议定义了一对多应用程序如何有效地通过ip网络传送多媒体数据。rtsp在体系结构上位于rtp和rtcp之上，使用udp或tcp完成数据传输。
4.然而，在工业企业的多网域环境下存在弊端，由于工业企业的媒体源与客户端大多处于不同的网域，不同网域的服务器之间无法直接基于rtsp协议实现流媒体信息的传输。因此现有的rtsp流媒体转发方式大多无法实现跨网域转发，或者在需要跨网域转发时需要设置多级代理，而多级代理的转发会占用较多的带宽，并且多级代理的部署难度较大，不方便扩展。


技术实现要素：

5.为了解决现有技术中存在的缺点和不足，本发明提出了一种跨网域的rtsp流媒体传输方法，包括：
6.获取客户端的rtsp请求，经命令转接服务端转发给媒体源代理；
7.确定媒体源代理的端口与客户端的端口的第一映射关系，基于第一映射关系将rtsp协议中客户端的端口替换为媒体源代理的端口，通过替换后的rtsp协议将rtsp请求发送至媒体源；
8.获取媒体源对rtsp请求的响应，当响应发送至媒体源代理时，获取此时rtsp协议中的流媒体信息；
9.确定媒体源的端口与客户端代理的端口的第二映射关系，基于第二映射关系将rtsp协议中媒体源的端口替换为客户端代理的端口，基于第一映射关系将rtsp协议中媒体源代理的端口还原为客户端的端口；
10.通过替换后的rtsp协议，将流媒体信息经客户端代理发送至客户端。
11.可选的，所述确定媒体源代理的端口与客户端的端口的第一映射关系，包括：
12.当媒体源代理接收到rtsp请求时，确定当前rtsp协议中客户端开放的rtp/rtcp端口对，开放媒体源代理的第一本地udp端口对，建立所述rtp/rtcp端口对和第一本地udp端口对的第一映射关系。
13.可选的，在确定媒体源代理的端口与客户端的端口的第一映射关系时，所述媒体源代理开启ice的p2p会话，将p2p会话的地址信息经命令转接服务端转发到客户端代理。
14.可选的，所述基于第一映射关系将rtsp协议中客户端的端口替换为媒体源代理的端口，通过替换后的rtsp协议将rtsp请求发送至媒体源，包括：
15.基于第一映射关系，将rtsp协议中客户端开放的rtp/rtcp端口对替换为用于传输流媒体数据的第一本地udp端口对；
16.基于预先保存在媒体源代理的地址列表对rtsp请求进行解析；
17.基于替换后的rtsp协议，将rtsp请求的解析结果发送至媒体源。
18.可选的，所述地址列表的生成过程包括：
19.媒体源代理获取本地网域中媒体源的rtsp地址列表，所述rtsp地址列表中包含媒体源的rtsp url；
20.对每个媒体源进行编码生成本地唯一标识；
21.将同一媒体源的本地唯一标识与rtsp url之间的对应关系保存到地址列表中，通过媒体源代理与命令转接服务端之间的tcp协议将地址列表上传至命令转接服务端。
22.可选的，所述基于预先保存在媒体源代理的地址列表对rtsp请求进行解析，包括：
23.媒体源代理在rtsp请求的原url中解析出本地唯一标识，在预先保存的地址列表中找到与本地唯一标识对应的rtsp url，将所述rtsp url作为解析结果。
24.可选的，所述确定媒体源的端口与客户端代理的端口的第二映射关系，包括：
25.当客户端代理收到rtsp请求的返回时，确定当前rtsp协议中媒体源开放的rtp/rtcp端口对，开放客户端代理的第二本地udp端口对，建立所述rtp/rtcp端口对和第二本地udp端口对的第二映射关系。
26.可选的，在确定媒体源的端口与客户端代理的端口的第二映射关系时，所述客户端代理开启ice的p2p会话，将p2p会话的地址信息经命令转接服务端转发到媒体源代理。
27.可选的，所述基于第二映射关系将rtsp协议中媒体源的端口替换为客户端代理的端口，包括：
28.基于第二映射关系，将rtsp协议中媒体源开放的rtp/rtcp端口对替换为用于传输流媒体数据的第二本地udp端口对。
29.可选的，所述基于第一映射关系将rtsp协议中媒体源代理的端口还原为客户端的端口，包括：
30.基于第一映射关系，将rtsp协议中第一本地udp端口对还原为客户端开放的rtp/rtcp端口对。
31.本发明提供的技术方案带来的有益效果是：
32.(1)本发明为rtsp协议中的媒体源、客户端提供了的跨网域直接访问的方法，使媒体源和客户端之间的rtsp传输无需做任何流媒体协议的转换工作，仅需分别进行客户端与媒体源代理之间的端口替换，以及媒体源与客户端代理之间的端口替换，即可达到与本地直流等同的传输效果，只要符合标准rtsp协议的媒体源和客户端都可按本发明所提出的方法接入，极大地提高了访问的便利性。
33.(2)将客户端代理和媒体源代理作为中间节点，即使流媒体的媒体源分散在多个不同私网中，也可通过客户端代理、媒体源代理以及命令转接服务端进行统一管理，而无需设置多级代理服务而占用过多的带宽，降低了代理服务器的部署难度。
附图说明
34.为了更清楚地说明本发明的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
35.图1为本发明一实施例提出的一种跨网域的rtsp流媒体传输方法的流程示意图；
36.图2为实施例一种提出的跨网域rtsp传输系统的架构图；
37.图3为rtsp请求的url替换示意图。
具体实施方式
38.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
39.本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。
40.应当理解，在本发明的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
41.应当理解，在本发明中，“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
42.应当理解，在本发明中，“多个”是指两个或两个以上。“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。“包含a、b和c”、“包含a、b、c”是指a、b、c三者都包含，“包含a、b或c”是指包含a、b、c三者之一，“包含a、b和/或c”是指包含a、b、c三者中任1个或任2个或3个。
43.应当理解，在本发明中，“与a对应的b”、“与a相对应的b”、“a与b相对应”或者“b与a相对应”，表示b与a相关联，根据a可以确定b。根据a确定b并不意味着仅仅根据a确定b，还可以根据a和/或其他信息确定b。a与b的匹配，是a与b的相似度大于或等于预设的阈值。
44.取决于语境，如在此所使用的“若”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”或“响应于检测”。
45.下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。
46.实施例一
47.如图1所示，本实施例提出了一种跨网域的rtsp流媒体传输方法，所述rtsp流媒体传输方法涉及处于第一网域的客户端、客户端代理，以及处于第二网域的媒体源、媒体源代
理，包括：
48.s1：获取客户端的rtsp请求，经命令转接服务端转发给媒体源代理；
49.s2：确定媒体源代理的端口与客户端的端口的第一映射关系，基于第一映射关系将rtsp协议中客户端的端口替换为媒体源代理的端口，通过替换后的rtsp协议将rtsp请求发送至媒体源；
50.s3：获取媒体源对rtsp请求的响应，当响应发送至媒体源代理时，获取此时rtsp协议中的流媒体信息；
51.s4：确定媒体源的端口与客户端代理的端口的第二映射关系，基于第二映射关系将rtsp协议中媒体源的端口替换为客户端代理的端口，基于第一映射关系将rtsp协议中媒体源代理的端口还原为客户端的端口；
52.s5：通过替换后的rtsp协议，将流媒体信息经客户端代理发送至客户端。
53.本实施例为rtsp协议中的媒体源、客户端提供了的跨网域直接访问的方法，使媒体源和客户端之间的rtsp传输无需做任何流媒体协议的转换工作，达到与本地直流等同的传输效果，只要符合标准rtsp协议的媒体源和客户端都可按本发明所提出的方法接入，极大地提高了访问的便利性。
54.在本实施例中，客户端和媒体源分别处于不同的网域中，具体的跨网域rtsp传输系统如图2所示，包括以下模块：
55.a.客户端(rtsp client，rc)，本实施例中为自行开发或来自第三方的支持rtsp协议的客户端，处于一个独立的网域network c中；
56.b.媒体源(rtsp server，rs)，可提供rtsp协议访问的任何硬件设备或服务器，在与rc不同的另一个独立的网域network b中；
57.c.客户端代理(rtsp client agent，rca)，部署在rc所在的网域network c中，模拟rtsp媒体源服务器功能，rc通过rtsp协议可直接访问rca，即通过各自的本地udp端口实现rtp/rtcp协议的传输；
58.d.媒体源代理(rtsp server agent，rsa)，部署在rs所在的网域network b中，模拟rtsp客户端功能，rsa通过rtsp协议可直接访问rs的rtsp服务，即通过各自的本地udp端口实现rtp/rtcp协议的传输；
59.e.命令转接服务(command transfer service，cts)，可部署在任意与rc和rs不同的网域，本实施例中部署在network a中，但须保证rca和rsa能够连接到cts的tcp服务，rca和rsa之间通过cts进行命令数据传输。
60.以上仅是对功能模块的描述，不涉及具体的实现方式，如rsa与rs可为同一进程中的不同子模块，或同一物理设备内的不同进程，或运行于不同的物理设备。
61.在本实施例中，rca和rsa分别与cts建立tcp长连接的命令通道，命令协议可使用任意协议，如http协议或protobuf私有协议等。cts对每个连上的rca和rsa进行唯一标识，即对rca生成rcaid，对rsas生成rsaid。rca和rsa与cts需定时发送心跳命令，以维持整个登录周期。同时，rca和rsa之间通过ice框架建立p2p通讯，实现流媒体信息的传输。rc按照标准rtsp协议开启播放流程，请求地址是rca的本地服务地址。所有rtsp协议包由rca命令协议封装后转发到cts，再由cts转发至rsa，最后rsa解析命令协议得到真正的rtsp协议，并向真正的媒体源发起rtsp请求。媒体源返回的rtsp协议，也按同样方式反向传输rsa-》cts-》
rca-》rc。
62.在rca和rsa与cts维持登录周期的过程中，rsa通过onvif搜索或手动配置的方式获取本地网络中媒体源的rtsp地址，即媒体源的rtsp url。再对每个rs进行编码，生成唯一标识的本地唯一标识(local stream id，lsid)。rsa将rs的本地唯一标识与rtsp url之间的对应关系保存到地址列表中，一方面地址列表存储在rsa中，rsa中预先存储的地址列表如下：
63.{
[0064]“lsid1”:”rtsp://192.168.1.1:554/stream1”,
[0065]“lsid1”:”rtsp://192.168.1.1:554/stream2”,
[0066]“lsid1”:”rtsp://192.168.1.1:554/stream3”,
[0067]
……
[0068]
}；
[0069]
另一方面通过rsa与cts之间的tcp协议将地址列表同步上传至命令转接服务端，将来rc可通过cts查询全局所有的媒体源，cts保存的全局媒体源地址列表如下：
[0070][0071][0072]
其中，“rsaid1”、“rsaid2”、“rsaid3”分别表示不同rsa的id，其后列出了每个rsa下管理的媒体源的lsid。
[0073]
当rc需要获取某个媒体源的流媒体信息时，rc按照标准rtsp协议开启播放流程，由此生成rtsp请求，本实施例中rtsp请求的url的格式为“rtsp://[rcaip]:[rca本地端口]/[rsaid]/[lsid]”，rcaip对应的rca通过url解析出rsaid和lsid,并为该路会话创建上下文。
[0074]
在本实施例中，rs返回redirect消息，rsa需要分析新的url为其自动创建新的lsid并上传cts，同时更新redirect消息url中的路径为[rsaid]/[lsid]。当rca收到该redirect消息时，需替换消息中的url的ip和port为本地地址，最终由rc结束旧的会话teardown并连接新的url。
[0075]
在本实施例中，获取客户端的rtsp请求，经命令转接服务端将rtsp请求转发给媒体源代理，具体为：rtsp请求由rc发出，通过本地网络发送到rca，再通过tcp协议经cts发送到rsaid对应的rsa。
[0076]
此时，确定媒体源代理的端口与客户端的端口的第一映射关系，确定当前rtsp协议中客户端开放的rtp/rtcp端口对，开放媒体源代理的第一本地udp端口对，建立所述rtp/rtcp端口对和第一本地udp端口对的第一映射关系。确定第一映射关系的目的在于使处于network b中的rs能够将来与network c中的rc的rtp/rtcp端口对通讯并传输媒体数据，最后在媒体源代理上对第一映射关系进行本地保存。
[0077]
在本实施例中，在确定媒体源代理的端口与客户端的端口的第一映射关系时，媒体源代理开启ice的p2p会话，将p2p会话的地址信息经命令转接服务端转发到客户端代理。ice协议的描述格式通常采用标准的会话描述协议(session description protocol，sdp)，是一种信息格式的描述标准。客户端代理和媒体源代理双方需要把自己的本地地址,外部地址等信息告知对端.本地地址通过网卡信息获取，外部地址需要通过stun服务器或turn服务器获取，本领域技术人员应当知道如何基于ice协议实现p2p通讯，此处不再赘述。
[0078]
本实施例利用第一映射关系用第一本地udp端口对替换rtsp协议中涉及到的客户端开放的rtp/rtcp端口对，从而使rc的rtsp请求能够被不同网域的rs接收，具体为：
[0079]
基于第一映射关系，将rtsp协议中客户端开放的rtp/rtcp端口对替换为第一本地udp端口对，在rtsp协议中需要通过setup请求指明流媒体以什么方式传输，每个流媒体播放之前必须执行setup操作，发送setup请求时，客户端会指定两个端口，一个端口用于传输rtp数据，一个端口用于传输rtcp数据。本实施例中，rtsp请求的setup请求到达rsa后，rsa解析rtsp协议header中transport的client_port＝port1-port2，port1-port2表示客户端的一对rtp-rtcp端口，以client_port表示rc在发起setup请求前开放的将来用于接收流媒体数据的端口对。此时rsa另开放两个本地udp端口，即第一本地udp端口来替换port1和port2。因为同处于network b的rs就可以识别到rsa的udp端口，所以rs可以识别替换后的rtsp协议，进而将替换后的rtsp请求基于替换后的rtsp协议转发至rtsp url对应的媒体源。
[0080]
基于预先保存在媒体源代理的地址列表对rtsp请求进行解析，基于替换后的rtsp协议，将rtsp请求的解析结果发送至媒体源。例如，rsa基于本地保存的地址列表找到rs的rtsp url，用所述rtsp url替换rtsp请求的原url，例如如图3所示，rca发来的rtsp请求的原url为“rtsp://172.16.1.0:554/rsaid/lsid1”，其中“172.16.1.0”为rca的本地ip，“554”为rca的本地端口，rsaid为cts为rsa分配的id，lsid1为rsa为本地网络中的rs分配的id。通过查找地址列表可知rsaid对应有图3所示的若干个lsid，将rtsp请求的原url整体替换为lsid1的具体url，可知替换后的rtsp请求的url为“rtsp://192.168.1.1:554/channels/101？transportmode＝unicast”。
[0081]
随后，基于替换后的rtsp协议，将rtsp请求的解析结果经本地网络发送至媒体源，将rtsp请求发送给“rtsp://192.168.1.1:554/channels/101？transportmode＝unicast”对应的rs，并获取该rs的流媒体信息。由于rs与rsa同处于network b，因此可直接经本地网络将流媒体信息发送至rsa，此时进入setup返回流程。
[0082]
在setup返回时首先确定媒体源与客户端代理之间端口的第二映射关系，与第一映射关系的确定同理，具体为：当客户端代理收到rtsp请求的返回时，即setup返回，确定当前rtsp协议中媒体源开放的rtp/rtcp端口对，开放客户端代理的第二本地udp端口对，建立所述rtp/rtcp端口对和第二本地udp端口对的第二映射关系；在客户端代理上对第二映射关系进行本地保存。
[0083]
与setup请求时同理，在确定媒体源的端口与客户端代理的端口的第二映射关系时，所述客户端代理开启ice的p2p会话，将p2p会话的地址信息经命令转接服务端转发到媒体源代理。至此建立起rsa和rca之间的p2p会话，用于传输流媒体信息。
[0084]
由于在setup请求阶段，为了rs将来与rsa传输媒体数据，已将rtsp协议中rc的
rtp/rtcp端口对client_port替换为第一本地udp端口对，因此在setup返回时需要将替换的client_port复原，即基于第一映射关系，将rtsp协议中第一本地udp端口对还原为客户端开放的rtp/rtcp端口对，使此时rtsp协议中的第一本地udp端口对还原为client_port，才能使rc接收到。随后，为了rca将来与rc传输媒体数据，基于第二映射关系，将rtsp协议中媒体源开放的rtp/rtcp端口对替换为第二本地udp端口对，例如，rtsp请求的setup返回时，rca解析rtsp协议header中transport的server_port＝port3-port4，port3-port4表示一对表示媒体源的一对rtp-rtcp端口，以server_port表示rs开放的将来用于传输流媒体数据的端口对。此时rca另开放两个本地udp端口，即第二本地udp端口来替换port3和port4。因为同处于network c的rc就可以识别到rca的udp端口，所以rc可以识别替换后的rtsp协议，进而基于替换后的rtsp协议，将媒体源对rtsp请求响应的流媒体信息依次经媒体源代理和客户端代理发送至客户端。
[0085]
由此可见，本实施例一方面通过预先建立的地址列表统一多个媒体源的地址，即生成唯一标识的lsid，从而使rc能够跨网域的获取不同媒体源的流媒体信息。另一方面，通过第一映射关系和第二映射关系对rtsp协议进行处理，从而使多个不同网域之间的rc与rs能够基于rtsp协议进行流媒体传输。
[0086]
在本实施例中，为了rtsp传输的安全性，所述客户端代理获取客户端的rtsp请求时，还需要根据rtsp请求的header中的authorization头信息对rtsp请求进行认证，当authorization头信息定义认证方式为basic认证时，通过对rtsp请求中的用户名字段与密码字段进行base64编码完成认证，当authorization头信息定义认证方式为digest认证时，根据rtsp的预设认证规则重置用户名字段和响应头字段完成认证。
[0087]
同时，rtsp协议每次返回时，需要记录header中的cseq和session，供后续会话使用，如在rca异常断线时，rsa可附带cseq和session，执行发送teardown关闭会话。
[0088]
上述实施例中的各个序号仅仅为了描述，不代表各部件的组装或使用过程中的先后顺序。
[0089]
以上所述仅为本发明的实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。