janus本身部署在公网时，其内部使用的libnice库已经实现了stun的功能，在配置文件janus.jcfg里面，nat_1_1_mapping配置成公网地址，其位于NAT后面的局域网客户端之间可以实现媒体流之间的分享，发布者将媒体流推到公网，而janus服务端将媒体流推给订阅者。

如下图所示：

这种情况下，根本不需要coturn，现在引入coturn，coturn是stun和turn的结合体，其中stun用于发现地址发现，turn用于流转发。
关于coturn，看到的博客都是用于地址发现，如下图这样一个场景，收集candidate。

而对于流转发，尚未找到合适的博客。
本篇博客，主要说明coturn的流转发功能。

首先，本人在公网上部署了coturn，关于部署的过程，本人参考了博客
coturn服务配置
其中在turnserver.conf的最后，本人添加了如下内容：

listening-port=19302
listening-ip=0.0.0.0
external-ip=xxx.xxx.251.92
min-port=20000
max-port=40000
user=li:li123
realm=stun.XX.cn
cli-password=qwerty
cert=/usr/local/turnserver/etc/turn_server_cert.pem
pkey=/usr/local/turnserver/etc/turn_server_pkey.pem

其中external-ip是公网地址，为了隐私，本人将ip段的前面部分用xxx.xxx代替。

然后用下面命令启动coturn服务

./bin/turnserver -v -r xxx.xxx.251.92 -a -o -c ./etc/turnserver.conf

启动服务后，发现19302既是tcp端口，又是udp端口。

下面我们将NAT内的客户端的流经过coturn转发，推给janus服务端，下面分别给出地址信息：
coturn：公网地址为xxx.xxx.251.92(中国 天津市)，本地地址为10.0.0.143
janus：公网地址为xxx.xxx.251.90(中国 天津市)，本地地址为10.0.0.122

客户端地址：本地地址10.0.0.2，所在NAT：60.12.13.106(中国 浙江省 杭州市 滨江区)

注意，客户端的本地地址和上面的coturn以及janus的本地地址不能互通。

此时媒体发布者的流走向如下：

媒体订阅端走向为：

下面我们讲解下媒体发布情况下，终端将流推经过coturn转发推给janus的过程。

首先，janus的配置文件中，nat_1_1_mapping注释掉，关于turn的配置开启，如下图所示：

其中公网地址的前部分做了马赛克处理，turn_user和turn_pwd按照配置coturn时设置的信息来，不要配错。

同时webrtc客户端也需要将coturn的地址加入进来，代码如下：

关于客户端为何需要将coturn的地址添加进去，后面再做解释。

然后启动客户端，加入会议，接着在客户端所在机器，coturn所在机器，janus所在机器，开启抓包，然后打开摄像头，向服务端推流，结果发现，流直接推给了janus，没有经过coturn。

我查看了在sdp交互时，janus回给客户端的answer sdp，如下所示：

o=- 2743266240368598531 2 IN IP4 10.0.0.122
s=VideoRoom 38584232
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS janus
m=video 9 UDP/TLS/RTP/SAVPF 127 120
c=IN IP4 10.0.0.122
b=AS:4096
a=recvonly
a=mid:video
a=rtcp-mux
a=ice-ufrag:/6At
a=ice-pwd:V0LKmCsUWBaXjcAFKkHmqK
a=ice-options:trickle
a=fingerprint:sha-256 D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38
a=setup:active
a=rtpmap:127 H264/90000
a=fmtp:127 profile-level-id=42e01f;packetization-mode=1
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=extmap:3 urn:3gpp:video-orientation
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=127
a=ssrc-group:FID 3739256708 2784241827
a=candidate:1 1 udp 2015363327 10.0.0.122 32893 typ host
a=candidate:2 1 udp 1679819007 xxx.xxx.251.90 32893 typ srflx raddr 10.0.0.122 rport 32893
a=candidate:3 1 udp 505413887 xxx.xxx.251.92 27192 typ relay raddr 10.0.0.122 rport 32893
a=end-of-candidates

注意，公网地址处，本人用了xxx代替。

可见answer sdp的最后部分是3个candidate，其中第一个是janus的本地地址，第二个是janus的公网地址(srflx反射地址)，第三个是janus的relay地址(coturn地址)。
而本人其实在janus上并没有配置janus的公网ip，janus通过函数nice_agent_set_relay_info设置了coturn信息，其通过与coturn的交互得知了自己的公网ip，如下图所示，janus在向coturn进行relay端口请求时，得到了自己的公网ip。

而candidate是有优先级的，srflx的优先级要高于relay，故此次推流，发现没有经过coturn，直接发给了janus。

由于answer sdp中的candidate是janus组装的，故可以修改janus的代码，将srflx的地址去掉，在ice.c的函数janus_ice_candidates_to_sdp里面，添加红色部分的代码，将srflx的candidate屏蔽掉。

重新编译并启动janus，启动客户端并发布媒体，janus回复的answer sdp如下：

o=- 2892261328926992312 2 IN IP4 10.0.0.122
s=VideoRoom 95364800
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS janus
m=video 9 UDP/TLS/RTP/SAVPF 127 120
c=IN IP4 10.0.0.122
b=AS:4096
a=recvonly
a=mid:video
a=rtcp-mux
a=ice-ufrag:3GO5
a=ice-pwd:mjai24kvf9SI1+fE3IXIg4
a=ice-options:trickle
a=fingerprint:sha-256 D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38
a=setup:active
a=rtpmap:127 H264/90000
a=fmtp:127 profile-level-id=42e01f;packetization-mode=1
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=extmap:3 urn:3gpp:video-orientation
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=127
a=ssrc-group:FID 2148634348 4202343640
a=candidate:1 1 udp 2015363327 10.0.0.122 22349 typ host
a=candidate:3 1 udp 505413887 xxx.xxx.251.92 24104 typ relay raddr 10.0.0.122 rport 22349
a=end-of-candidates

看sdp最后部分的candidate，只剩下了两个，这次经过抓包分析，流确实由客户端推给coturn，然后由coturn推给janus。

下面我根据三个抓包分析下过程，先分析下客户端的流如何发给coturn，首先从sdp中看到xxx.xxx.251.92 24104，这个是coturn用于接收客户端流的地址端口，这个24104端口是由janus向coturn申请转发端口时，coturn主机上分配的。

客户端将流发给coturn时，在NAT上进行了打洞，打出的地址为(60.12.13.106:21003)，下面是抓包的过程，本人直接用文本写出来，避免贴图模糊。

10.0.0.2(61888)--------Binding Request user:3G05:y04Z--------------> xxx.xxx.251.92(24104)
10.0.0.2(61888)<-Binding Success Response XOR-MAPPED-ADDRESS: 60.12.13.106:21003 user: 3GO5:yO4Z--xxx.xxx.251.92(24104)

下面抓包下janus向coturn申请转发端口(端口号：24104)的过程

10.0.0.122(22349)--------Allocate Request UDP----------->xxx.xxx.251.92(19302)
10.0.0.122(22349)<--------Allocate Error Response error-code: 401 (Unauthenticated) Unauthorized with nonce realm: xxx.xxx.251.92-----------xxx.xxx.251.92(19302)	
10.0.0.122(22349)--------Allocate Request UDP realm: xxx.xxx.251.92 with nonce user: li----------->xxx.xxx.251.92(19302)
10.0.0.122(22349)<--------Allocate Success Response XOR-RELAYED-ADDRESS: xxx.xxx.251.92:24104 XOR-MAPPED-ADDRESS: xxx.xxx.251.90:22349 lifetime: 600-----------xxx.xxx.251.92(19302)

交互中，可以发现，向 coturn申请转发端口，需要用户名和密码，由交互过程中的第四步发现，coturn分配了24104的转发端口，在coturn的24104端口接收到了客户端的媒体流后，其用19302端口将媒体流发给了janus的22349端口（不是24104端口）。

10.0.0.143(19302)--------UDP媒体流----------->xxx.xxx.251.90(22349)

janus在申请转发端口时，就已经给出了其本身接收转发流的端口22349。

下面说下webrtc客户端为何需要将coturn的地址加入进来，若不将coturn的地址加入进来，发现，客户端在向coturn转发端口24104 打洞(Binding Request)的时候，此端口一直未能给以回复，导致打洞失败，具体原因未知。

经过抓包发现，客户端 打洞(Binding Request)的时候，必须先向coturn的配置端口19302进行Binding请求，然后才能向此转发端口(24104)进行Binding，交互如下：

10.0.0.2(61888)--------Binding Request--------------> xxx.xxx.251.92(19302)
10.0.0.2(61888)<-Binding Success Response XOR-MAPPED-ADDRESS: 60.12.13.106:21002 MAPPED-ADDRESS: 60.12.13.106:21002 RESPONSE-ORIGIN: xxx.xxx.251.92:19302--xxx.xxx.251.92(19302)
10.0.0.2(61888)--------Binding Request user:3G05:y04Z--------------> xxx.xxx.251.92(24104)
10.0.0.2(61888)<-Binding Success Response XOR-MAPPED-ADDRESS: 60.12.13.106:21003 user: 3GO5:yO4Z--xxx.xxx.251.92(24104)

客户端代码将coturn的地址加入进来，会触发向coturn的配置端口19302进行Binding请求，使得最后打洞成功。