coturn

turnserver

turnserver应用程序是一个TURN中继服务的实现。

使用:

 $ turnserver [flags] [-n | -c <configfile>] [ --db=<sqlite-db-file> | --userdb=<sqlite-db-file> | --psql-userdb=<db-conn-string> | --mysql-userdb=<db-conn-string> | --mongo-userdb=<db-conn-string>  | --redis-userdb=<db-conn-string> ] [options]
$ turnserver -h

Flags:

  • -v,--verbose 中等的详细模式
  • -V,--Verbose 额外的详细模式,非常烦人,不推荐
  • -o,--daemon 以后守护进程的形式运行
  • -f,--fingerprint 在TURN消息中使用指纹。如果收到的请求包含指纹,则TURN服务器将始终向此次会话中的消息添加指纹,不会考虑每台服务器的设置。
  • -a,--lt-cred-mech 使用长期证书机制。(这个在WebRTC中需要使用)
  • -z,--no-auth 不适用任何的证书机制,允许匿名访问。与-a和-A选项冲突。
  • --use-auth-secret TURN REST API标志。该标识设置一个特殊的基于认证秘钥的WebRTC认证选项。这个功能的目的是用来支持TURNServerRESTAPI.pdf文档中描述的'TURN Server REST API'。此选项和长期证书机制一起使用(即-a,--lt-cred-mech选项)。
  • --oauth 支持RFC 7635中的oAuth认证。这个认证密钥必须存放在数据库中,并且由一个额外的程序来处理。TURN服务器要求密钥存放在数据库中,并且TURN服务器不会自己去处理这些密钥。在规范文档的4.1节中,提出了几个密钥管理方案,并且由额外的密钥管理程序来实现。
  • --syslog 将所有消息都输出到系统日志 syslog
  • --secure-stun 需要验证STUN绑定请求。默认情况下,允许客户端匿名使用STUN绑定功能。
  • -S,--stun-only 仅作为STUN服务器运行,所有的TURN请求都会被忽略。该选项会关闭TURN功能,只有STUN请求会被处理。
  • --no-stun 仅作为TURN服务器运行,所有的STUN请求都会被忽略。该选项会关闭STUN功能,只有TURN请求会被处理。
  • --mobility 移动与ICE(MICE)规范支持
  • --no-cli 关闭CLI(命令行界面)支持。默认情况下,它总是打开的,并且TURN服务器进程接收telnet客户端链接127.0.0.1:5766。另外参考--cli-ip --cli-port --cli-password
  • --server-relay 服务中继。这是一个非标准以及危险的选项。仅适合用来充当一个中继点的情况。此选项不会对传入中继点的数据包的IP权限进行检查。这使得系统容器收到DOS攻击。该选项的使用规则是:如果你不清楚这个选项是干什么用的以及你为什么要使用它,那么绝对不要使用它。
  • --check-origin-consistency 该标志设置来源一致性检查。在这整个会话中,所有的请求都必须具备相同的主ORIGIN属性值(如果这个会话一开始就使用了ORIGIN的话)(此选项在WebRTC用是用来,用来确定该请求是否来自realm旗下的页面,避免第三方使用我们的TURN服务器)
  • -h 查看帮助

配置文件设置

  • -n 不使用配置文件,仅使用命令行参数
  • -c
  • current directory
  • current directory etc/ subdirectory
  • upper directory level etc/
  • /etc/
  • /usr/local/etc/

用户数据库设置

  • -b,--db,--userdb
  • -e,--psql-userdb,--sql-userdb

连接字符串的格式如下

"host=<host> dbname=<dbname> user=<db-user> password=<db-user-password> connect_timeout=<seconds>"
  • -M,--mysql-userdb
"host=<host> dbname=<dbname> user=<db-user> password=<db-user-password> connect_timeout=<seconds>".
  • -N,--redis-userdb

连接字符串的格式如下

"ip=<ip-addr> dbname=<number> password=<db-password> connect_timeout=<seconds>"
  • -J, --mongo-userdb
"mongodb://username:password@host:port/database?options".

当我们在配置文件中进行配置了之后,就会启用该数据库。

Options

  • -d,--listening-device
  • -L,--listening-ip
  • -p,--listening-port
  • --aux-server
  • -E,--relay-ip
  • -u,--user
  • -r,--realm
  • --static-auth-secret
  • -C, --rest-api-separator

WebRTC使用

这是一些给WebRTC用户的使用事项:

1、 WebRTC使用长期认证机制,因此你必须使用-a选项(或者--lt-cred-mech)。WebRTC中继不允许匿名访问。使用-a选项时,不要忘记设置默认域名(-r选项)。你还必须设置用户账号,你可以通过下面的方式来设置:

+ 命令行选项 (-u)
+ 数据库表(如果使用的是SQLite、PostgreSQL或者MySQL)。你必须使用turnadmin工具来设置密钥。你不能在数据库中使用开放的密码。
+ 你还可以使用TURN REST API。你仍然需要通过命令行选项或者通过配置文件或者通过数据库表来设置共享密钥。

2、通常WebRTC使用指纹(-f)
3、-v选项可以方便看到客户端的连接
4、如果你的TURN服务器运行在NAT后面,需要使用-X选项
5、如果你想设置中继断点的端口范围,必须要设置--min-port和--max-port

TURN REST API

在WebRTC中,浏览器从Web服务器获取TURN连接信息。该信息是一个受保护的信息,因为它包含了必要的TURN凭据。由于这些TURN凭据是通过公网来传送的,因此存在一个潜在的安全问题。

如果我们必须通过公网来传送有价值的信息,那么该信息必须具备一个有限时间。这样那些非法获得此信息的人只能对我们造成有限的伤害

这个基于时间限制凭据的想法就是这样出现的。这种安全机制基于长期认证机制。主要想法是Web服务器提供一个凭据给客户端,但是这些凭据只能被那些需要创建TURN连接的应用程序在有限的时间内使用。

在WebRTC客户端和WebRTC管理控制台以及WebRTC web服务器之间使用一套REST API,来处理临时密码和(相对)持久的共享密钥。TURN服务器从TURN端为REST API提供支持。严格地说,TURN服务器不实现REST API,它只是为它提供了支持。

“经典”长期证书机制(LTCM)在这里描述:

对于身份认证,每个用户必须知道两个东西:用户名和密码。除此之外用户还可以提供ORIGIN值,使得服务器能够要给改用户使用的域名。随机数和域名值由服务器提供。但是LTCM不会告诉任何关于用户名和密码的持久性和兴致,并且由REST API使用。

在TURN REST API中,不会给用户持久的密码。一个用户只有用户名,密码始终是临时的,并且是当用户访问WebRTC页面时由Web服务器在后台生成。还有,即时是一个临时的一次性会话,用户名也会提供给用户。

临时用户生成为:

temporary-username="timestamp" + ":" + "username"

其中username是持久用户名,时间戳格式仅由秒(从1970年开始算)组成时间戳是临时密码的过期时间。

临时密码作为HMAC-SHA1函数通过临时用户名获得,和共享密钥作为HMAC密钥一起返回,返回结果被编码

temporary-password = base64_encode(hmac-sha1(input = temporary-username, key = shared-secret))

因此,时间戳用于临时密码计算,并且可以从临时用户名检索此时间戳。此信息是有价值的,但只是临时的,而时间戳未过期。如果没有共享密钥的知识,则无法生成新的临时密码。

这在Justin Uberti TURN REST API草案规范文档中正式描述,可以从这里获得:TURN REST API BEHAVE DRAFT SPECS

一旦临时用户名和密码被客户端(浏览器)应用程序获取,其余的只是“经典”的长期凭证机制。对于开发人员,我们将逐步描述如下:

turnadmin

turnadmin应用程序:一个Turn中继服务管理工具

使用

$ turnadmin [command] [options]
$ turnadmin [ -h | --help]

Commands

  • -P,--generate-encrypted-password 生成一个加密形式的密码(用于Web管理用户或者CL)并输出。然后该密码可用作一个安全的密钥存储在磁盘上或者数据库中。对同一个密码的每次调用都会产生不同的结果。
  • -k,--key 生成密钥用于长期认证机制
  • -A,--add-admin 添加一个管理员
  • -a,--add 添加或者更新一个长期用户
  • -d,--delte 删除一个长期用户
  • -l,--list 显示所有的长期认证用户
  • -s,--set-secret=... 设置数据库中的密钥
  • -S,--show-secret 显示存储在数据库中的密钥
  • -X,--delete-secret
  • --delete-all-secrets 删除所有用于REST API的共享密钥
  • -O,--add-origin 添加origin到realm的关系
  • -R,--del-origin 删除origin到realm的关系
  • -l,--list-origins 显示origin到realm的关系
  • -g,--set-realm-option 设置realm参数:max-bps、total-quota、user-quota
  • -G,--list-realm-options 显示realm参数

Options

  • -b,--db,--userdb
  • -e,--psql-userdb,--sql-userdb
  • -M,--mysql-userdb
  • -N,--redis-userdb
  • -J,--mongo-userdb
  • -u,--user
  • -r,--realm
  • -p,--password
  • -o,--origin 完整形式的来源,例如:https://crinna.org:443.

生成一个加密的密码

$ turnadmin -P -p <password>

生成一个长期认证密钥

$ turnadmin -k -u <username> -r <realm> -p <password>

在数据库中更新或者添加一个用户

$ turnadmin -a [-b <sqlite-db-file> | -e <db-connection-string> | -M <db-connection-string>  | -N <db-connection-string> ] -u <username> -r <realm>  -p  <password>

Demo

# turnadmin -a -M 'host=localhost dbname=turn user=turn password=Turnserver!#14 connect_timeout=30' -u 'kakawater' -r 'apprtc.kakawater.top' -p 'aixocm'
0: log file opened: /var/log/turnserver/turn_21388_2016-12-10.log
0: MySQL DB connection success: host=localhost dbname=turn user=turn password=Turnserver!#14 connect_timeout=30
# 

在数据库中删除一个用户

$ turnadmin -d [-b <sqlite-db-file> | -e <db-connection-string> | -M <db-connection-string>  | -N <db-connection-string> ] -u <username>

显示在MySQL中的所有长期认证用户

$ turnadmin -l --mysql-userdb="<db-connection-string>"

设置密钥

$ turnadmin -s <secret> --mysql-userdb="<db-connection-string>"

显示密钥

$ turnadmin -S --psql-userdb="<db-connection-string>"

Set origin-to-realm relation in MySQL database:

$ turnadmin --mysql-userdb="<db-connection-string>" -r <realm> -o <origin>

登录Turn Admin在线管理TurnServer

https://apprtc.kakawater.top:3478/?service=turn
  • 必须配置cert和key。如果私钥文件有密码,必须通过pkey-pwd选项指定密码
  • 必须配置权限,让turnserver用户能够访问到该文件

我们在登陆TurnServer控制台界面时,一定要先创建管理员账户,否则无法登陆

turnadmin -A -M 'host=localhost dbname=turn user=turn password=Turnserver!#14 connect_timeout=30' -u 'kakawater' -r 'apprtc.kakawater.top' -p 'aixocm'

添加一个共享密钥

turnadmin -S -M 'host=localhost dbname=turn user=turn password=Turnserver!#14 connect_timeout=30' -u 'kakawater' -r 'apprtc.kakawater.top' -p 'aixocm'

TURN Server REST API

Abstract

本文档描述了用于通过短期凭证获取对TURN服务的使用的标准REST API。这些凭证由Web服务器通过HTTP发布,由TURN服务器检查。临时凭证的使用确保在凭证被用户发现(WebRTC中TURN凭证必须在javascript中指定),也可以实现对TURN服务访问的控制。

1、介绍

TURN是一种经常被用来盖上P2P应用程序连接的协议。通过提供基于云的中继服务,TURN确保党一端或者两端都处于不能进行P2P连接的环境中时也能建立"p2p"连接。然而作为一个中继服务,它需要消耗服务提供商的资源,包括宽带资源、CPU资源、内存资源等等。如果允许任何人访问,显示服务提供商是不愿意的,并且也容器遭受DOS攻击。因此需要控制对TURN服务的访问。

TURN提供了一种通过长期认证机制(作为TURN协议的一部分)来控制访问。它希望这些凭证将会秘密地保存,如果凭证被第三方发现,TURN服务可能会被未经授权的用户使用。然而,在Web应用程序中确保凭证不被第三方发现这是不可能的。

为了解决这个问题,本文提出了一套REST API可用于从Web服务器中获取短期TURN凭证。这些短期凭证可以被当作长期凭证使用TURN服务。为了简单起见,这些短期凭证有意地被设计成保持无状态,Web服务和TURN服务之间只需要进行一个交互,即共享密钥。

HTTP 交互

为了获取一组新的凭证,客户端需要发送一个HTTP请求,指定TURN作为为期分配凭据的服务,还可选择指定用户ID参数。用户ID参数的目的是简化TURN服务器上的调试,以及提供控制为特定用户分发凭证的数量(如果需要的话).TURN凭据及其生存期以JSON的形式返回,以及用来连接TURN服务器的URL。

为了避免需要在Web服务和TURN服务之间传递状态,返回的凭证包括username(包含了必要的状态,到期时间和用户ID),和使用共享密钥签名的TURN密码(该密码是这些状态的摘要)。

由于返回的凭证是短期的,它们最终都会过期。这并不影响现有的TURN分配,因为它们会被绑定到特殊的5元祖,但是使用这些短期凭证请求分配一个新的TURN端口会在过期时间之后失效。这在ICE重启的情况下非常重要,因为客户端可能需要请求分配一组新的候选项包括TURN候选项。为了获得一组新的临时凭证,客户端可以简单地重新发送具有想听参数的原始HTTP请求,新的凭证会以JSON返回。

为了组织未经授权使用TURN服务,HTTP请求可以通过各种方式来进行访问控制,例如IP地址,Origin头、User-Agent头、登陆Cookie、API密钥等等。

请求

请求包括以下参数,在URL中指定:

  • service : 指定需要的服务 (turn)
  • username : 可选用户标识,用来和凭据关联的
  • key : 如果使用API密钥进行身份验证的话

示例:

GET /?service=turn&username=mbzrxpgjys

响应

返回响应时,指定"content-type"字段为"application/json",并且响应内容为具有以下参数的JSON对象:

  • username:要使用的TURN用户名,它是由请求到期时间和来自请求的username(如果有的话)以:分割组合而成。时间戳旨在让Web应用程序无法理解,因此其格式是任意的,但是为了简单起见,推荐使用UNIX时间戳。
  • password:要使用的TURN密码。这个值由与TURN服务器共享的密钥和返回的用户名username进行base64(hmac(secret key,returned username))计算出来。HMAC-SHA1是一种可以使用HMAC算法,但是任何合并一个共享密钥的算法都是可接受的,只要Web服务器和TURN服务器使用相同的算法和密钥。
  • ttl:用户名和密码有效的持续时间(以秒为单位)。建议使用一天(86400秒)的值
  • uris:一组TURN URLS。用于指定可以用来连接TURN 服务器的不同地址或者协议。这些URLS应该为TURN服务器指定一个主机名、IPV4或者IPV6地址、以及要使用到的端口

示例:

{
     "username" : "12334939:mbzrxpgjys",
     "password" : "adfsaflsjfldssia",
     "ttl" : 86400,
     "uris" : [
       "turn:1.2.3.4:9991?transport=udp",
       "turn:1.2.3.4:9992?transport=tcp",
       "turns:1.2.3.4:443?transport=tcp"
     ]
}

WebRTC 交互

返回的JSON被解析成一个RTCIceServer对象,并作为创建RTCPeercONNECTION时使用的RTCConfiguration对象的一部分。

示例:

var iceServer = {
     "username": response.username,
     "credential": response.password,
     "uris": response.uris
   };
   var config = {"iceServers": [iceServer]};
   var pc = new RTCPeerConnection(config);

当凭证更新的时候(例如它们即将到期),可以通过uodateice方法将具有更新的凭证的新的RTCConfiguration提供给存在的RTCPeerConnection.此更新不得影响现有TURN分配,因为TURN要求用户名对于分配保持不变,但新凭据将用于任何新分配

TURN交互

客户端

WebRTC客户端将使用长期凭证机制,即通过返回的username和password进行标准的TURN 分配操纵。

服务端

TURN服务器将使用长期凭证机制处理请求。请注意,服务器提供的REALM在这个上下文中没有任何含义,可以被设置成任何有效值。当处理ALLOCATE请求时,TURN服务器必须将username拆分为时间戳和用户ID,并且验证时间戳来查看凭证何时过期。如果验证失败,他应该拒绝该请求,并指示401(未认证)错误。

如果需要,TURN服务器可选择验证解析出来的用户ID值是否对应当前外部服务的有效用户。这需要在每个ALLOCATE请求时TURN服务器和外部服务之间的专有通信,并且对于典型应用程序不是必需的。如果此外部验证失败,它应拒绝401(未授权)错误的请求。

安装Turn

下载

$wget http://turnserver.open-sys.org/downloads/v4.5.0.5/turnserver-4.5.0.5-CentOS6.8-x86_64.tar.gz

解压

$tar -xf turnserver-4.5.0.5-CentOS6.8-x86_64.tar.gz

重命名

$mv turnserver-4.5.0.5/ turnserver

安装

$cd turnserver/
turnserver]$./install.sh

MySQL配置

schema.sql

# Table for long-term credentials mechanism authorization:
#
CREATE TABLE turnusers_lt (
    realm varchar(127) default '',
    name varchar(512),
    hmackey char(128),
    PRIMARY KEY (realm,name)
);

The field hmackey contains HEX string representation of the key.
We do not store the user open passwords for long-term credentials, for security reasons.
Storing only the HMAC key has its own implications - if you change the realm,
you will have to update the HMAC keys of all users, because the realm is 
used for the HMAC key generation.

The key must be 32 characters (HEX representation of 16 bytes) for SHA1.

# Table holding shared secrets for secret-based authorization
# (REST API). It can only be used together with the long-term 
# mechanism:
#
CREATE TABLE turn_secret (
    realm varchar(127) default '',
        value varchar(128),
    primary key (realm,value)
);

# Table holding "white" allowed peer IP ranges.
#
CREATE TABLE allowed_peer_ip (
    realm varchar(127) default '',
    ip_range varchar(256),
    primary key (realm,ip_range)
);

# Table holding "black" denied peer IP ranges.
#
CREATE TABLE denied_peer_ip (
    realm varchar(127) default '',
    ip_range varchar(256),
    primary key (realm,ip_range)
);

# Table to match origin to realm.
# Multiple origins may have the same realm.
# If no realm is found or the origin is absent
# then the default realm is used.
#
CREATE TABLE turn_origin_to_realm (
    origin varchar(127),
    realm varchar(127),
    primary key (origin,realm)
);

# Realm options.
# Valid options are 'max-bps',
# 'total-quota' and 'user-quota'.
# Values for them are integers (in text form).
#
CREATE TABLE turn_realm_option (
    realm varchar(127) default '',
    opt varchar(32),
    value varchar(128),
    primary key (realm,opt)
);

# oAuth key storage table.
#
CREATE TABLE oauth_key (
    kid varchar(128), 
    ikm_key varchar(256),
    timestamp bigint default 0,
    lifetime integer default 0,
    as_rs_alg varchar(64) default '',
    primary key (kid)
);

#The oauth_key table fields meanings are:
#  kid: the kid of the key;
#  ikm_key - base64-encoded key ("input keying material");
#  timestamp - (optional) the timestamp (in seconds) when the key lifetime started; 
#  lifetime - (optional) the key lifetime in seconds; the default value is 0 - unlimited lifetime.
#  as_rs_alg - oAuth token encryption algorithm; the valid values are "A256GCM", "A128GCM" (see http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.1). The default value is "A256GCM";
#

# Https access admin users.
# Leave this table empty if you do not want 
# remote https access to the admin functions.
# 
# The password may be stored in encrypted form
# $5$<...salt...>$<...sha256(salt+password)...>
# The encrypted form can be generated with turnadmin utility.
#
CREATE TABLE admin_user (
    name varchar(32),
    realm varchar(127),
    password varchar(127),
    primary key (name)
);

创建账户

GRANT ALL ON turn.* TO 'turn'@'localhost' IDENTIFIED BY 'Turnserver!#14';

以该账户登录并创建数据库

CREATE DATABASE turn;

创建表

cd turnserver-4.5.0.3/turndb
mysql -u turn -p -D turn < schema.sql 

启动TURN

turnserver -v --syslog -a -L '127.0.0.1' -L '::1' -E '127.0.0.1' -E '::1' --max-bps=3000000 -f -m 3 --min-port=32355 --max-port=65535 --use-auth-secret --realm='www.kakawater.top' --mysql-userdb='host=localhost dbname=turn user=turn password=Turnserver!#14 connect_timeout=30' --cert=1_www.kakawater.top_bundle.crt --pkey=2_www.kakawater.top.key --log-file=stdout --cipher-list=ALL --static-auth-secret='4080218913' -o

添加测试用户

turnadmin -a  --mysql-userdb='host=localhost dbname=turn user=turn password=Turnserver!#14 connect_timeout=30' -u test -r test.kakawater.top -p test520

最终配置

账号

turnadmin -a -u hutlifeapprtc -r apprtc.kakawater.top -p apprtcaixocm

管理员

turnadmin -A -u kakawater -p lingyu520 -r apprtc.kakawater.top

turnserver配置文件

[root@host-163-44-168-146 ~]# cat /etc/turnserver/turnserver.conf | egrep -v '^$|^#'
listening-device=eth0
listening-port=3478
                             
    
relay-device=eth0
min-port=59000
max-port=65535
    
    
Verbose
fingerprint
lt-cred-mech
realm=apprtc.kakawater.top
stale-nonce
cert=/root/WebRTCWorkPlace/apprtcKakawaterTopSizeSSL/1_apprtc.kakawater.top_bundle.crt
pkey=/root/WebRTCWorkPlace/apprtcKakawaterTopSizeSSL/2_apprtc.kakawater.top.key
no-stdout-log
syslog
            
no-loopback-peers
no-multicast-peers
mobility
no-cli
user=hutlifeapprtc:apprtcaixocm
[root@host-163-44-168-146 ~]# 

测试

[root@host-163-44-168-146 ~]# turnutils_stunclient 163.44.168.146

========================================
RFC 5780 response 1
0: IPv4. Response origin: : 163.44.168.146:3478
0: IPv4. Other addr: : 163.44.168.146:3479
0: IPv4. UDP reflexive addr: 163.44.168.146:52244

========================================
RFC 5780 response 2
0: IPv4. Response origin: : 163.44.168.146:3479
0: IPv4. Other addr: : 163.44.168.146:3479
0: IPv4. UDP reflexive addr: 163.44.168.146:52244

========================================
RFC 5780 response 3
0: IPv4. Response origin: : 163.44.168.146:3479
0: IPv4. Other addr: : 163.44.168.146:3479
0: IPv4. UDP reflexive addr: 163.44.168.146:52245
[root@host-163-44-168-146 ~]# turnutils_uclient -u hutlifeapprtc -w apprtcaixocm  163.44.168.146 -y -v
0: IPv4. Connected from: 163.44.168.146:39031
0: IPv4. Connected to: 163.44.168.146:3478
0: allocate sent
0: allocate response received: 
0: allocate sent
0: allocate response received: 
0: success
0: IPv4. Received relay addr: 163.44.168.146:60620
0: clnet_allocate: rtv=968274461052430979
0: refresh sent
0: refresh response received: 
0: success
0: IPv4. Connected from: 163.44.168.146:35769
0: IPv4. Connected to: 163.44.168.146:3478
0: IPv4. Connected from: 163.44.168.146:58209
0: IPv4. Connected to: 163.44.168.146:3478
0: IPv4. Connected from: 163.44.168.146:60510
0: IPv4. Connected to: 163.44.168.146:3478
0: IPv4. Connected from: 163.44.168.146:45605
0: IPv4. Connected to: 163.44.168.146:3478
0: allocate sent
0: allocate response received: 
0: allocate sent
0: allocate response received: 
0: success
0: IPv4. Received relay addr: 163.44.168.146:60621
0: clnet_allocate: rtv=0
0: refresh sent
0: refresh response received: 
0: success
0: allocate sent
0: allocate response received: 
0: allocate sent
0: allocate response received: 
0: success
0: IPv4. Received relay addr: 163.44.168.146:63338
0: clnet_allocate: rtv=2831687778094409979
0: refresh sent
0: refresh response received: 
0: success
0: allocate sent
0: allocate response received: 
0: allocate sent
0: allocate response received: 
0: success
0: IPv4. Received relay addr: 163.44.168.146:63339
0: clnet_allocate: rtv=0
0: refresh sent
0: refresh response received: 
0: success
0: allocate sent
0: allocate response received: 
0: allocate sent
0: allocate response received: 
0: success
0: IPv4. Received relay addr: 163.44.168.146:62778
0: clnet_allocate: rtv=2909317117241387930
0: refresh sent
0: refresh response received: 
0: success
0: channel bind sent
0: cb response received: 
0: success: 0x5a28
0: channel bind sent
0: cb response received: 
0: success: 0x65a5
0: channel bind sent
0: cb response received: 
0: success: 0x6334
0: channel bind sent
0: cb response received: 
0: success: 0x7ca4
1: Total connect time is 1
1: start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
2: start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
3: start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
4: start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
5: start_mclient: msz=4, tot_send_msgs=5, tot_recv_msgs=5, tot_send_bytes ~ 500, tot_recv_bytes ~ 500
5: done, connection 0x7ff0369e0010 closed.
5: done, connection 0x7ff0369bf010 closed.
5: done, connection 0x7ff03699e010 closed.
5: done, connection 0xfcb600 closed.
5: start_mclient: tot_send_msgs=20, tot_recv_msgs=20
5: start_mclient: tot_send_bytes ~ 2000, tot_recv_bytes ~ 2000
5: Total transmit time is 4
5: Total lost packets 0 (0.000000%), total send dropped 0 (0.000000%)
5: Average round trip delay 0.000000 ms; min = 0 ms, max = 0 ms
5: Average jitter 0.000000 ms; min = 0 ms, max = 0 ms
[root@host-163-44-168-146 ~]#

webrtc-turnserver配置文件

[root@host-163-44-168-146 apprtc]# cat /etc/turnserver/turnserver.conf | egrep -v '^$|^#'
listening-device=eth0
listening-port=3478
                             
    
relay-device=eth0
min-port=59000
max-port=65535
    
    
Verbose
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=4080218913
realm=apprtc.kakawater.top
stale-nonce
cert=/root/WebRTCWorkPlace/apprtcKakawaterTopSizeSSL/1_apprtc.kakawater.top_bundle.crt
pkey=/root/WebRTCWorkPlace/apprtcKakawaterTopSizeSSL/2_apprtc.kakawater.top.key
no-stdout-log
syslog
            
no-loopback-peers
no-multicast-peers
mobility
no-cli
user=hutlifeapprtc:apprtcaixocm
[root@host-163-44-168-146 apprtc]# 

测试

[root@host-163-44-168-146 apprtc]# turnutils_stunclient 163.44.168.146

========================================
RFC 5780 response 1
0: IPv4. Response origin: : 163.44.168.146:3478
0: IPv4. Other addr: : 163.44.168.146:3479
0: IPv4. UDP reflexive addr: 163.44.168.146:34760

========================================
RFC 5780 response 2
0: IPv4. Response origin: : 163.44.168.146:3479
0: IPv4. Other addr: : 163.44.168.146:3479
0: IPv4. UDP reflexive addr: 163.44.168.146:34760

========================================
RFC 5780 response 3
0: IPv4. Response origin: : 163.44.168.146:3479
0: IPv4. Other addr: : 163.44.168.146:3479
0: IPv4. UDP reflexive addr: 163.44.168.146:34761
[root@host-163-44-168-146 apprtc]# 

下面的密码通过TURNRestServer给出

[root@host-163-44-168-146 apprtc]# turnutils_uclient -u '1479528077:hutlifeapprtc' -w 'xBwC7y8uEgpX1siQTKiyEsdhkhA='  163.44.168.146 -y 
0: Total connect time is 0
1: start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
2: start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
3: start_mclient: msz=4, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
4: start_mclient: msz=4, tot_send_msgs=5, tot_recv_msgs=5, tot_send_bytes ~ 500, tot_recv_bytes ~ 500
5: start_mclient: msz=4, tot_send_msgs=10, tot_recv_msgs=10, tot_send_bytes ~ 1000, tot_recv_bytes ~ 1000
6: start_mclient: msz=4, tot_send_msgs=10, tot_recv_msgs=10, tot_send_bytes ~ 1000, tot_recv_bytes ~ 1000
6: start_mclient: tot_send_msgs=20, tot_recv_msgs=20
6: start_mclient: tot_send_bytes ~ 2000, tot_recv_bytes ~ 2000
6: Total transmit time is 6
6: Total lost packets 0 (0.000000%), total send dropped 0 (0.000000%)
6: Average round trip delay 0.000000 ms; min = 0 ms, max = 0 ms
6: Average jitter 0.050000 ms; min = 0 ms, max = 1 ms
[root@host-163-44-168-146 apprtc]# 
尝试使用一个错误的密码
[root@host-163-44-168-146 apprtc]# turnutils_uclient -u '1479528077:hutlifeapprtc' -w 'xBwsC7y8uEgpX1siQTKiyEsdhkhA='  163.44.168.146 -y 
0: Cannot complete Allocation
0: ERROR: Cannot complete Allocation
[root@host-163-44-168-146 apprtc]# 

事实上,我们我们使用了WebRTC的方式就不支持长期认证方式了,所有的密码必须通过TRUN REST API服务器来获取。

此外,realm一定要为我们域名的区域,如果完整主机名不在区域的管辖范围内,则WebRTC配置下的TRUN服务器不会处理任何请求。

posted @ 2017-07-03 20:31 kakawater 阅读(...) 评论(...) 编辑 收藏