Why my relay is not working? I switched off Turnserver but still connection is alive.

[Sprogrammer]

To verify the relay is working exactly like below i have tested and rebooted the server when A and B was connected. but when i did crash turnserver and closed the server why client A and B was still connected? Does it mean the relay did not worked? How can i make it work like Step 0?

Step 0: Plan to achieve

Client A
  connects to the TURN server at port 80
  and the TURN server allocates a relay endpoint on the relay IP and port,
  say, 34567 (RA).

Client B
  connects to the TURN server at port 80
  and the TURN server allocates a relay endpoint on the relay IP and port,
  say, 45678 (RB).

The packets between A and B must follow the path:

  A <==> TURN <==> RA <==> RB <==> TURN <==> B

See the TurnNetworks.pdf document.

Step 1: i have set turnserver configured as:

user=root:root
realm=212.67.221.110
no-tls
no-dtls
syslog
#verbose
aux-server=212.67.221.110:80
aux-server=212.67.221.110:443

Step 2:

[root@100957 tmp]# turnserver -v
0:
RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server
Version Citrix-3.2.2.6 'Marshal West'
0:
Max number of open files/sockets allowed for this process: 4096
0:
Due to the open files/sockets limitation,
max supported number of TURN Sessions possible is: 2000 (approximately)
0:


==== Show him the instruments, Practical Frost: ====


0: TLS supported
0: DTLS supported
0: Redis supported
0: PostgreSQL supported
0: MySQL supported
0: OpenSSL version: fresh enough
0: Default Net Engine version: 3 (UDP thread per CPU core)


=====================================================


0: Config file found: /etc/turnserver/turnserver.conf
0: Aux server: 212.67.221.110:80
0: Aux server: 212.67.221.110:443
0: Config file found: /etc/turnserver/turnserver.conf
0: Config file found: /etc/turnserver/turnuserdb.conf
0:
CONFIGURATION ALERT: you specified long-term user accounts, (-u option)
 but you did not specify the long-term credentials option
 (-a or --lt-cred-mech option).
  I am turning --lt-cred-mech ON for you, but double-check your configuration.
0: ===========Discovering listener addresses: =========
0: Listener address to use: 127.0.0.1
0: Listener address to use: 212.67.221.110
0: Listener address to use: ::1
0: =====================================================
0: ===========Discovering relay addresses: =============
0: Relay address to use: 212.67.221.110
0: Relay address to use: ::1
0: =====================================================
0: pid file created: /var/run/turnserver.pid
0: IO method (main listener thread): epoll (with changelist)
0: IO method (general relay thread): epoll (with changelist)
0: IPv4. UDP listener opened on: 212.67.221.110:80
0: IPv4. UDP listener opened on: 212.67.221.110:443
0: IPv4. UDP listener opened on: 127.0.0.1:3478
0: IPv4. UDP listener opened on: 127.0.0.1:3479
0: IPv4. UDP listener opened on: 212.67.221.110:3478
0: IPv4. UDP listener opened on: 212.67.221.110:3479
0: IPv6. UDP listener opened on: ::1:3478
0: IPv6. UDP listener opened on: ::1:3479
0: IO method (auth thread): epoll (with changelist)
0: turn server id=0 created
0: IPv4. TCP listener opened on : 212.67.221.110:80
0: IPv4. TCP listener opened on : 212.67.221.110:443
0: Cannot create TLS listener
0: Cannot create TLS listener
0: Cannot create TLS listener
0: Cannot create TLS listener
0: Cannot create TLS listener
0: Cannot create TLS listener
0: IO method (cli thread): epoll (with changelist)
0: ERROR: Cannot create CLI listener
31: IPv4. tcp or tls connected to: 213.224.54.254:48588
31: user <>: incoming packet message processed, error 401
31: IPv4. tcp or tls connected to: 213.224.54.254:48589
31: user <>: incoming packet message processed, error 401
31: IPv4. Server relay addr: 212.67.221.110:80
31: IPv4. Local relay addr: 212.67.221.110:52975
31: new: session id=000000000000000001, username=<root>, lifetime=600
31: user <root>: incoming packet ALLOCATE processed, success
31: IPv4. Server relay addr: 212.67.221.110:80
31: IPv4. Local relay addr: 212.67.221.110:56792
31: new: session id=000000000000000002, username=<root>, lifetime=600
31: user <root>: incoming packet ALLOCATE processed, success
31: IPv4. tcp or tls connected to: 213.224.54.254:48612
31: user <>: incoming packet message processed, error 401
31: IPv4. tcp or tls connected to: 213.224.54.254:48613
31: user <>: incoming packet message processed, error 401
31: IPv4. Server relay addr: 212.67.221.110:80
31: IPv4. Local relay addr: 212.67.221.110:54606
31: new: session id=000000000000000003, username=<root>, lifetime=600
31: user <root>: incoming packet ALLOCATE processed, success
31: IPv4. Server relay addr: 212.67.221.110:80
31: IPv4. Local relay addr: 212.67.221.110:64227
31: new: session id=000000000000000004, username=<root>, lifetime=600
31: user <root>: incoming packet ALLOCATE processed, success
32: user <root>: incoming packet CREATE_PERMISSION processed, success
32: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
33: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
34: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
35: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
36: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
37: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
38: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
39: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
40: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
41: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
42: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
43: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
44: user <root>: incoming packet CREATE_PERMISSION processed, success
61: TURN connection closed (non-mobile pattern), user <root>
61: delete: session id=000000000000000001, username=<root>
61: TURN connection closed (non-mobile pattern), user <root>
61: delete: session id=000000000000000002, username=<root>
61: TURN connection closed (non-mobile pattern), user <root>
61: delete: session id=000000000000000003, username=<root>
61: TURN connection closed (non-mobile pattern), user <root>
61: delete: session id=000000000000000004, username=<root>
^C

Step 3: Shutdown or crash the turnserver to switch off Client A and B connection (cause we are testing server relay here)

[root@100957 tmp]# ps aux | grep turnserver

497       9948  0.0  0.1 317740  1952 ?        Ssl  10:50   0:00 /usr/bin/turnserver -o -c /etc/turnserver/turnserver.conf

root      9995  0.0  0.0 103252   800 pts/1    S+   10:56   0:00 grep turnserver

[root@100957 tmp]# service turnserver stop

Stopping turnserver:                                       [  OK  ]

[root@100957 tmp]# ps aux | grep turnserver

root     10012  0.0  0.0 103252   800 pts/1    S+   10:56   0:00 grep turnserver

[root@100957 tmp]# ps aux | grep turnserver

root     10014  0.0  0.0 103252   800 pts/1    S+   10:56   0:00 grep turnserver

[root@100957 tmp]# sudo reboot

Broadcast message from ro...@100957.vps-10.com

(/dev/pts/1) at 10:56 ...

The system is going down for reboot NOW!

[root@100957 tmp]# Connection to 212.67.221.110 closed by remote host.

But still Peer A and B is connected even the server is down. Why? and how to fix it? So that relay only happens via server.

[Oleg Moskalenko]

I am not sure that your TURN sessions were established successfully. As you can see yourself, two ALLOCATE sessions were established, but then for some reason your client was re-sending multiple CREATE_PERMISSION commands. I do not know what is happening on your client.

Regards,
Oleg

...

[Sprogrammer]

YES - you are 100% right. WebRTC/HAS has BUG for TURN Relay which causing the 99% call failure

Follow up:

https://groups.google.com/forum/#!topic/discuss-webrtc/l1_TRxk-qkA

https://groups.google.com/forum/#!topic/discuss-webrtc/LKChBGTmA3c

https://code.google.com/p/webrtc/issues/detail?id=1179

Reg

/sham

[Sprogrammer]

I think i am finally able to make it webRTC turn client working with turn-server. 

I would like to share the logs can you confirm please kindly if this is hitting the turnserver correctly now?

i have used 80 port instead of 3478 for the signaling

root@sun-Alienware-X51-R2:/var/tmp# turnserver -v
turnserver: /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18: no version information available (required by turnserver)

0:
RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server

Version Citrix-3.2.2.8 'Marshal West'

0:
Max number of open files/sockets allowed for this process: 4096
0:
Due to the open files/sockets limitation,
max supported number of TURN Sessions possible is: 2000 (approximately)
0:


==== Show him the instruments, Practical Frost: ====


0: TLS supported
0: DTLS supported
0: Redis supported
0: PostgreSQL supported
0: MySQL supported
0: OpenSSL version: fresh enough

0: Default Net Engine version: 2 (UDP thread per network endpoint)


=====================================================


0: Config file found: /etc/turnserver.conf
0: Aux server: 82.x.x.1:80
0: Aux server: 82.x.x.1:443
0: Config file found: /etc/turnserver.conf
0: Config file found: /etc/turnuserdb.conf

0:
CONFIGURATION ALERT: you specified long-term user accounts, (-u option)
 but you did not specify the long-term credentials option
 (-a or --lt-cred-mech option).
  I am turning --lt-cred-mech ON for you, but double-check your configuration.

0: NO EXPLICIT LISTENER ADDRESS(ES) ARE CONFIGURED

0: ===========Discovering listener addresses: =========
0: Listener address to use: 127.0.0.1

0: Listener address to use: 82.x.x.1

0: Listener address to use: ::1
0: =====================================================

0: Total: 1 'real' addresses discovered
0: =====================================================
0: NO EXPLICIT RELAY ADDRESS(ES) ARE CONFIGURED

0: ===========Discovering relay addresses: =============

0: Relay address to use: 82.x.x.1

0: Relay address to use: ::1
0: =====================================================

0: Total: 2 relay addresses discovered

0: =====================================================
0: pid file created: /var/run/turnserver.pid
0: IO method (main listener thread): epoll (with changelist)

0: Wait for relay ports initialization...
0:   relay 82.x.x.1 initialization...
0:   relay 82.x.x.1 initialization done
0:   relay ::1 initialization...
0:   relay ::1 initialization done
0: Relay ports initialization done

0: IO method (general relay thread): epoll (with changelist)
0: IO method (general relay thread): epoll (with changelist)
0: IO method (general relay thread): epoll (with changelist)
0: IO method (general relay thread): epoll (with changelist)

0: turn server id=1 created

0: turn server id=0 created

0: IO method (general relay thread): epoll (with changelist)

0: turn server id=3 created

0: IO method (general relay thread): epoll (with changelist)
0: IO method (general relay thread): epoll (with changelist)

0: turn server id=2 created
0: IO method (udp listener/relay thread): epoll (with changelist)
0: turn server id=4 created

0: IO method (general relay thread): epoll (with changelist)

0: turn server id=6 created
0: turn server id=5 created
0: turn server id=128 created
0: IO method (udp listener/relay thread): epoll (with changelist)
0: turn server id=7 created
0: turn server id=129 created
0: IO method (udp listener/relay thread): epoll (with changelist)
0: turn server id=130 created
0: IO method (udp listener/relay thread): epoll (with changelist)
0: turn server id=131 created
0: IO method (udp listener/relay thread): epoll (with changelist)
0: turn server id=132 created
0: IO method (udp listener/relay thread): epoll (with changelist)
0: turn server id=133 created
0: IO method (udp listener/relay thread): epoll (with changelist)
0: turn server id=134 created
0: IO method (udp listener/relay thread): epoll (with changelist)
0: turn server id=135 created
0: IPv4. UDP listener opened on: 82.x.x.1:80
0: IPv4. UDP listener opened on: 82.x.x.1:443

0: IPv4. UDP listener opened on: 127.0.0.1:3478
0: IPv4. UDP listener opened on: 127.0.0.1:3479

0: IPv4. UDP listener opened on: 82.x.x.1:3478
0: IPv4. UDP listener opened on: 82.x.x.1:3479

0: IPv6. UDP listener opened on: ::1:3478
0: IPv6. UDP listener opened on: ::1:3479

0: IPv4. TCP listener opened on : 82.x.x.1:80
0: IPv4. TCP listener opened on : 82.x.x.1:443
0: IPv4. TCP listener opened on : 127.0.0.1:3478
0: IPv4. TCP listener opened on : 127.0.0.1:3479
0: IPv4. TCP listener opened on : 82.x.x.1:3478
0: IPv4. TCP listener opened on : 82.x.x.1:3479
0: IPv6. TCP listener opened on : ::1:3478
0: IPv6. TCP listener opened on : ::1:3479

0: IO method (auth thread): epoll (with changelist)

0: IO method (cli thread): epoll (with changelist)

0: IPv4. CLI listener opened on : 127.0.0.1:5766
















12: handle_udp_packet: New UDP endpoint: local addr 82.x.x.1:80, remote addr 82.143.92.17:53390
12: user <>: incoming packet BINDING processed, success
12: IPv4. tcp or tls connected to: 82.143.92.17:37248
12: user <>: incoming packet message processed, error 401
12: IPv4. Server relay addr: 82.x.x.1:80
12: IPv4. Local relay addr: 82.x.x.1:64104
12: new: session id=000000000000000001, username=<root>, lifetime=600
12: user <root>: incoming packet ALLOCATE processed, success
13: handle_udp_packet: New UDP endpoint: local addr 82.x.x.1:80, remote addr 82.143.92.17:60607
13: user <>: incoming packet BINDING processed, success
13: IPv4. tcp or tls connected to: 82.143.92.17:37257
13: user <>: incoming packet message processed, error 401
13: IPv4. Server relay addr: 82.x.x.1:80
13: IPv4. Local relay addr: 82.x.x.1:50851
13: new: session id=001000000000000001, username=<root>, lifetime=600
13: user <root>: incoming packet ALLOCATE processed, success
13: user <root>: incoming packet CREATE_PERMISSION processed, success
13: user <root>: incoming packet CREATE_PERMISSION processed, success
13: user <root>: incoming packet CHANNEL_BIND processed, success
13: user <root>: incoming packet CHANNEL_BIND processed, success
22: user <>: incoming packet BINDING processed, success
23: usage: session id=001000000000000001, username=<root>, rp=1021, rb=452386, sp=1027, sb=476484
23: usage: session id=000000000000000001, username=<root>, rp=1027, rb=474960, sp=1021, sb=453936
23: user <>: incoming packet BINDING processed, success
31: usage: session id=001000000000000001, username=<root>, rp=1014, rb=588166, sp=1034, sb=597856
31: usage: session id=000000000000000001, username=<root>, rp=1034, rb=596306, sp=1014, sb=589680
32: user <>: incoming packet BINDING processed, success
33: user <>: incoming packet BINDING processed, success
37: usage: session id=001000000000000001, username=<root>, rp=1008, rb=672441, sp=1040, sb=697644
37: usage: session id=000000000000000001, username=<root>, rp=1041, rb=697136, sp=1007, sb=673812
43: usage: session id=001000000000000001, username=<root>, rp=1018, rb=752725, sp=1030, sb=773052
43: usage: session id=000000000000000001, username=<root>, rp=1030, rb=770518, sp=1018, sb=754168
47: usage: session id=001000000000000001, username=<root>, rp=1014, rb=810498, sp=1034, sb=839968
47: usage: session id=000000000000000001, username=<root>, rp=1033, rb=838311, sp=1015, sb=813068
51: usage: session id=001000000000000001, username=<root>, rp=1006, rb=856046, sp=1042, sb=897984
51: usage: session id=000000000000000001, username=<root>, rp=1042, rb=896472, sp=1006, sb=857636
55: usage: session id=000000000000000001, username=<root>, rp=1025, rb=906287, sp=1023, sb=909540
55: usage: session id=001000000000000001, username=<root>, rp=1024, rb=909011, sp=1024, sb=906656
58: usage: session id=001000000000000001, username=<root>, rp=1024, rb=905441, sp=1024, sb=913316
58: usage: session id=000000000000000001, username=<root>, rp=1024, rb=910701, sp=1024, sb=906936
^C
root@sun-Alienware-X51-R2:/var/tmp#

reg

/sham

[Oleg Moskalenko]

I see all signs of correct TURN sessions:

1) allocations happening;
2) permissions created;
3) channels bound;
4) real data traffic is flowing ("usage:..." lines);

so I guess everything is right.

Regards,
Oleg

37: usage: session id=000000000000000001, username=<root<span style="color: #660;"

...

[Sprogrammer]

YES - it seems like for webRTC and trun relay to make work we have to hack a lot in the JavaScript After that it works. So after making it work with our turnserver i have done following tests:

1) Peer 1 connected with Peer 2 via Turn server relay

    now while they are connected, i switched off turn server 

    Peer 1 and Peer 2 was frozen

    it proves the turn client was doing correctly relay via turn server

2) now Peer1 and Peer 2 was 1 hour frozen and the status of webRTC signalling says "connected" which is still bug of webRTC and Chrome

TurnServer works 100% perfectly like it should, the whole community confusion starts when they use webRTC and turnserver to do relay, by default webRTC/Chrome do not work, someone need to do some hack like "Alex" mentioned in my earlier post,

there is no issue with our turnServer, it is 100% stable for the relay. 

now tested with Bria, PjSIP, WebRTC for the turn relay and it all worked correctly with the latest version available.

Best regards

/Sham

[Sprogrammer]

Why is it happening?

- Peer 1: Chrome 33

- Peer 2: Chrome 33

- relayed by Turnserver

- P1, P2 Connected for more then 5 minutes

- Suddenly the call automatically disconnected 

- P1 is frozen, P2 is completely disconnected

i had this log at that time

1833: usage: session id=003000000000000002, username=<root>, rp=997, rb=794392, sp=1051, sb=864856
1833: usage: session id=007000000000000001, username=<root>, rp=1047, rb=860674, sp=1001, sb=800356
1837: usage: session id=003000000000000002, username=<root>, rp=1001, rb=846678, sp=1047, sb=910404
1837: usage: session id=007000000000000001, username=<root>, rp=1049, rb=910197, sp=999, sb=846704
1841: usage: session id=003000000000000002, username=<root>, rp=1004, rb=903422, sp=1044, sb=938524
1841: usage: session id=007000000000000001, username=<root>, rp=1045, rb=937486, sp=1003, sb=902744
1844: usage: session id=003000000000000002, username=<root>, rp=1018, rb=925314, sp=1030, sb=930740
1844: usage: session id=007000000000000001, username=<root>, rp=1032, rb=933635, sp=1016, sb=925600
1847: usage: session id=003000000000000002, username=<root>, rp=1005, rb=914277, sp=1043, sb=930436
1847: usage: session id=007000000000000001, username=<root>, rp=1038, rb=921965, sp=1010, sb=920408
1851: usage: session id=003000000000000002, username=<root>, rp=1007, rb=917266, sp=1041, sb=935252
1851: usage: session id=007000000000000001, username=<root>, rp=1039, rb=931473, sp=1009, sb=920944
1854: TURN connection closed (non-mobile pattern), user <root>
1854: delete: session id=003000000000000002, username=<root>
1855: usage: session id=007000000000000001, username=<root>, rp=1192, rb=1059093, sp=856, sb=769936
1857: TURN connection closed (non-mobile pattern), user <>
1858: TURN connection closed (non-mobile pattern), user <>
1894: IPv4. tcp or tls connected to: 50.57.179.66:52883
1894: TURN connection closed (non-mobile pattern), user <>
1898: usage: session id=007000000000000001, username=<root>, rp=2048, rb=1217642, sp=0, sb=0

Again reconnected P1, P2 and now the call is stable for longer duration

Is it a turnserver issue or caused by Chrome 33?

reg

/sham

[Sprogrammer]

FYI - After having 830seconds connection again auto disconnected, here was the captured log at that time: 

(several time its happening like auto disconnected after a while)

Mar  3 00:53:01 sun-Alienware-X51-R2 turnserver: 742: usage: session id=001000000000000001, username=<root>, rp=1054, rb=942744, sp=994, sb=914236
Mar  3 00:53:04 sun-Alienware-X51-R2 turnserver: 745: usage: session id=000000000000000001, username=<root>, rp=986, rb=906783, sp=1062, sb=949384
Mar  3 00:53:04 sun-Alienware-X51-R2 turnserver: 746: usage: session id=001000000000000001, username=<root>, rp=1061, rb=945938, sp=987, sb=907232
Mar  3 00:53:08 sun-Alienware-X51-R2 turnserver: 749: usage: session id=000000000000000001, username=<root>, rp=982, rb=899105, sp=1066, sb=952552
Mar  3 00:53:08 sun-Alienware-X51-R2 turnserver: 749: usage: session id=001000000000000001, username=<root>, rp=1067, rb=953043, sp=981, sb=900544
Mar  3 00:53:11 sun-Alienware-X51-R2 turnserver: 753: usage: session id=000000000000000001, username=<root>, rp=993, rb=918152, sp=1055, sb=940660
Mar  3 00:53:11 sun-Alienware-X51-R2 turnserver: 753: usage: session id=001000000000000001, username=<root>, rp=1054, rb=938135, sp=994, sb=919992
Mar  3 00:53:15 sun-Alienware-X51-R2 turnserver: 756: usage: session id=000000000000000001, username=<root>, rp=1001, rb=920836, sp=1047, sb=944724
Mar  3 00:53:15 sun-Alienware-X51-R2 turnserver: 756: usage: session id=001000000000000001, username=<root>, rp=1033, rb=929300, sp=1015, sb=942368
Mar  3 00:53:18 sun-Alienware-X51-R2 turnserver: 759: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  3 00:53:18 sun-Alienware-X51-R2 turnserver: 759: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  3 00:53:18 sun-Alienware-X51-R2 turnserver: 760: usage: session id=000000000000000001, username=<root>, rp=980, rb=901287, sp=1068, sb=944872
Mar  3 00:53:19 sun-Alienware-X51-R2 turnserver: 760: usage: session id=001000000000000001, username=<root>, rp=1071, rb=946604, sp=977, sb=897460
Mar  3 00:53:22 sun-Alienware-X51-R2 turnserver: 763: usage: session id=000000000000000001, username=<root>, rp=987, rb=905955, sp=1061, sb=940116
Mar  3 00:53:22 sun-Alienware-X51-R2 turnserver: 763: usage: session id=001000000000000001, username=<root>, rp=1073, rb=949674, sp=975, sb=892412
Mar  3 00:53:26 sun-Alienware-X51-R2 turnserver: 767: usage: session id=000000000000000001, username=<root>, rp=975, rb=894359, sp=1073, sb=948304
Mar  3 00:53:26 sun-Alienware-X51-R2 turnserver: 767: usage: session id=001000000000000001, username=<root>, rp=1068, rb=942233, sp=980, sb=903452
Mar  3 00:53:29 sun-Alienware-X51-R2 turnserver: 771: usage: session id=000000000000000001, username=<root>, rp=992, rb=913519, sp=1056, sb=934380
Mar  3 00:53:29 sun-Alienware-X51-R2 turnserver: 771: usage: session id=001000000000000001, username=<root>, rp=1062, rb=939164, sp=986, sb=906880
Mar  3 00:53:33 sun-Alienware-X51-R2 turnserver: 774: usage: session id=000000000000000001, username=<root>, rp=983, rb=903579, sp=1065, sb=944648
Mar  3 00:53:33 sun-Alienware-X51-R2 turnserver: 774: usage: session id=001000000000000001, username=<root>, rp=1059, rb=935524, sp=989, sb=913136
Mar  3 00:53:36 sun-Alienware-X51-R2 turnserver: 778: usage: session id=000000000000000001, username=<root>, rp=990, rb=910649, sp=1058, sb=936464
Mar  3 00:53:36 sun-Alienware-X51-R2 turnserver: 778: usage: session id=001000000000000001, username=<root>, rp=1061, rb=935017, sp=987, sb=904884
Mar  3 00:53:40 sun-Alienware-X51-R2 turnserver: 781: usage: session id=000000000000000001, username=<root>, rp=984, rb=900084, sp=1064, sb=943628
Mar  3 00:53:40 sun-Alienware-X51-R2 turnserver: 781: usage: session id=001000000000000001, username=<root>, rp=1062, rb=944529, sp=986, sb=905892
Mar  3 00:53:44 sun-Alienware-X51-R2 turnserver: 785: usage: session id=000000000000000001, username=<root>, rp=993, rb=915166, sp=1055, sb=938656
Mar  3 00:53:44 sun-Alienware-X51-R2 turnserver: 785: usage: session id=001000000000000001, username=<root>, rp=1047, rb=927985, sp=1001, sb=927964
Mar  3 00:53:47 sun-Alienware-X51-R2 turnserver: 788: usage: session id=000000000000000001, username=<root>, rp=983, rb=906010, sp=1065, sb=936120
Mar  3 00:53:47 sun-Alienware-X51-R2 turnserver: 788: usage: session id=001000000000000001, username=<root>, rp=1076, rb=945356, sp=972, sb=891980
Mar  3 00:53:51 sun-Alienware-X51-R2 turnserver: 792: usage: session id=000000000000000001, username=<root>, rp=993, rb=915232, sp=1055, sb=926632
Mar  3 00:53:51 sun-Alienware-X51-R2 turnserver: 792: usage: session id=001000000000000001, username=<root>, rp=1040, rb=911959, sp=1008, sb=938204
Mar  3 00:53:54 sun-Alienware-X51-R2 turnserver: 796: usage: session id=000000000000000001, username=<root>, rp=985, rb=904364, sp=1063, sb=953872
Mar  3 00:53:54 sun-Alienware-X51-R2 turnserver: 796: usage: session id=001000000000000001, username=<root>, rp=1079, rb=965313, sp=969, sb=884100
Mar  3 00:53:58 sun-Alienware-X51-R2 turnserver: 799: usage: session id=000000000000000001, username=<root>, rp=985, rb=906363, sp=1063, sb=941920
Mar  3 00:53:58 sun-Alienware-X51-R2 turnserver: 799: usage: session id=001000000000000001, username=<root>, rp=1062, rb=938443, sp=986, sb=908236
Mar  3 00:54:01 sun-Alienware-X51-R2 turnserver: 803: usage: session id=000000000000000001, username=<root>, rp=982, rb=905345, sp=1066, sb=926356
Mar  3 00:54:01 sun-Alienware-X51-R2 turnserver: 803: usage: session id=001000000000000001, username=<root>, rp=1051, rb=913646, sp=997, sb=928232
Mar  3 00:54:05 sun-Alienware-X51-R2 turnserver: 806: usage: session id=000000000000000001, username=<root>, rp=983, rb=905312, sp=1065, sb=926364
Mar  3 00:54:05 sun-Alienware-X51-R2 turnserver: 806: usage: session id=001000000000000001, username=<root>, rp=1083, rb=941921, sp=965, sb=884864
Mar  3 00:54:08 sun-Alienware-X51-R2 turnserver: 810: usage: session id=000000000000000001, username=<root>, rp=992, rb=914825, sp=1056, sb=928440
Mar  3 00:54:08 sun-Alienware-X51-R2 turnserver: 810: usage: session id=001000000000000001, username=<root>, rp=1038, rb=909924, sp=1010, sb=938060
Mar  3 00:54:12 sun-Alienware-X51-R2 turnserver: 813: usage: session id=000000000000000001, username=<root>, rp=982, rb=895344, sp=1066, sb=947632
Mar  3 00:54:12 sun-Alienware-X51-R2 turnserver: 813: usage: session id=001000000000000001, username=<root>, rp=1082, rb=958491, sp=966, sb=875572
Mar  3 00:54:15 sun-Alienware-X51-R2 turnserver: 817: usage: session id=000000000000000001, username=<root>, rp=1003, rb=932217, sp=1045, sb=925736
Mar  3 00:54:16 sun-Alienware-X51-R2 turnserver: 817: usage: session id=001000000000000001, username=<root>, rp=1045, rb=925963, sp=1003, sb=933292
Mar  3 00:54:19 sun-Alienware-X51-R2 turnserver: 820: usage: session id=000000000000000001, username=<root>, rp=978, rb=898979, sp=1070, sb=950280
Mar  3 00:54:19 sun-Alienware-X51-R2 turnserver: 820: usage: session id=001000000000000001, username=<root>, rp=1069, rb=947180, sp=979, sb=901668
Mar  3 00:54:23 sun-Alienware-X51-R2 turnserver: 824: usage: session id=000000000000000001, username=<root>, rp=995, rb=917561, sp=1053, sb=933812
Mar  3 00:54:23 sun-Alienware-X51-R2 turnserver: 824: usage: session id=001000000000000001, username=<root>, rp=1046, rb=928205, sp=1002, sb=929272
Mar  3 00:54:27 sun-Alienware-X51-R2 turnserver: 828: TURN connection closed (non-mobile pattern), user <root>
Mar  3 00:54:27 sun-Alienware-X51-R2 turnserver: 828: delete: session id=000000000000000001, username=<root>
Mar  3 00:54:45 sun-Alienware-X51-R2 turnserver: 847: usage: session id=001000000000000001, username=<root>, rp=967, rb=727912, sp=1081, sb=995648

reg

/sham

[Oleg Moskalenko]

It looks like the Chrome does not refresh the TURN connections. I do not see any signs of refresh requests in the TURN server logs provided. After several minutes, the connection is getting destroyed if not refreshed properly by the client.

Oleg

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/groups/opt_out.

[Sprogrammer]

When i run it in Local PC to Local PC, Chrome 33 is sending a the refresh process

When i run it in PC and remotely located another PC Chrome 33 then this refresh process is missing

Chrome 33/Canary is full of bug for Turn relay confirmed. making the whole system confused and unstable.

Mar  3 01:36:01 sun-Alienware-X51-R2 turnserver: 3322: usage: session id=001000000000000003, username=<root>, rp=1017, rb=907795, sp=1031, sb=919316
Mar  3 01:36:01 sun-Alienware-X51-R2 turnserver: 3322: usage: session id=005000000000000001, username=<root>, rp=1028, rb=920028, sp=1020, sb=918100
Mar  3 01:36:04 sun-Alienware-X51-R2 turnserver: 3325: refreshed: session id=001000000000000003, username=<root>, lifetime=600
Mar  3 01:36:04 sun-Alienware-X51-R2 turnserver: 3325: user <root>: incoming packet REFRESH processed, success
Mar  3 01:36:04 sun-Alienware-X51-R2 turnserver: 3325: refreshed: session id=006000000000000002, username=<root>, lifetime=600
Mar  3 01:36:04 sun-Alienware-X51-R2 turnserver: 3325: user <root>: incoming packet REFRESH processed, success
Mar  3 01:36:04 sun-Alienware-X51-R2 turnserver: 3325: refreshed: session id=004000000000000001, username=<root>, lifetime=600
Mar  3 01:36:04 sun-Alienware-X51-R2 turnserver: 3325: refreshed: session id=005000000000000001, username=<root>, lifetime=600
Mar  3 01:36:04 sun-Alienware-X51-R2 turnserver: 3325: user <root>: incoming packet REFRESH processed, success
Mar  3 01:36:04 sun-Alienware-X51-R2 turnserver: 3325: user <root>: incoming packet REFRESH processed, success
Mar  3 01:36:04 sun-Alienware-X51-R2 turnserver: 3325: usage: session id=001000000000000003, username=<root>, rp=1023, rb=906098, sp=1025, sb=907532
Mar  3 01:36:05 sun-Alienware-X51-R2 turnserver: 3326: usage: session id=005000000000000001, username=<root>, rp=1024, rb=909416, sp=1024, sb=912900
Mar  3 01:36:07 sun-Alienware-X51-R2 turnserver: 3329: usage: session id=001000000000000003, username=<root>, rp=1027, rb=905023, sp=1021, sb=906324
Mar  3 01:36:08 sun-Alienware-X51-R2 turnserver: 3329: usage: session id=005000000000000001, username=<root>, rp=1021, rb=904796, sp=1027, sb=907776

[Mallinath Bareddy]

Does AllocateResponse has LIFETIME attribute? That's only check chrome does before scheduling the refresh request. Is it possible to post wireshark logs?

[Sprogrammer]

I will collect the wireshark trace and more details to share with you guys.

Thank you

best reg

/sham

[Oleg Moskalenko]

The TURN server rfc5766-turn-server always, unconditionally, includes the LIFETIME attribute in ALLOCATE response.

Oleg

[Sprogrammer]

Please download the wireshark pcap file. it was started to capture in the Turnserver PC on TCP port 80

1 - http://82.143.92.19:7007/files/dump.pcap

2 - http://82.143.92.19:7007/files/call1.log

3 - P1 was P2 was connected more then 10/15 minutes and suddenly the connection is dropped 

where P1 is still frozen and P2 is like normal disconnect mode, turnserver logs also stopped once the 

connection was dropped automatically

This is in my own lab network getting tested. But when i test it with remote locations, the duration of

auto call disconnect is much more earlier in between 1 to 10 minutes

Hope it helps. 

Please kindly confirm once the logs are collected (then i have to remove it)

reg

/sham

[Oleg Moskalenko]

That's 2 Gb of file, I am not sure that I'll be able to download it. I'll try.

But I looked into the log file:

1) There are actually three sessions, not two. One session is staying "dormant" but all three sessions are getting refreshed.

2) The lifetime is 600 seconds and the sessions are supposed to be refreshed every half-time (300 seconds) but they are refreshed every, about, 550 seconds. That's not right - they must be refreshed every 300 seconds, ideally. But that's not a big deal.

3) Soon after the last refresh, the session id=006000000000000001 got disconnected for some reasons... And according to the log output (second 3188) it is NOT due to a timeout. So, presumably, the timeouts or refreshing does not have anything to do with that. That may be a kind of network problem - it the TURN server receives a network event like "address unreachable" on a packet or something like that.

What protocol you are using - UDP or TCP ?

Are you able to compile the general tarball ? I can prepare a test build with extra log information - and it will tell you why it is getting disconnected. What platform are you using ?

Oleg

[Oleg Moskalenko]

OK, I checked the wireshark capture and the logs.

There is nothing wrong as far as I can see in both the capture file and in the log file. The clients and the server are behaving properly (except that the client is refreshing the allocation a little too late). One strange thing is that we have three allocations; two of them are exchanging data, one allocation "sleeps". Only two allocations of three refresh the channel, but all three are refreshing the allocation. I do not know whether this is a correct behavior. There may be reasons why one of them is not refreshing the channel.

But suddenly, without any signs of problems, the TURN server closes TCP connection with one of the clients (packet 2704683). It sends RST message to the client. As far as I can see in the code, that may happen if the TURN server could not send the packet to the client. There may be some system failures - but I cannot tell it from the log information.

I can add information to the log WHY the server chooses to close the connection. let me know if you can run a special debug build.

Regards,
Oleg

On Monday, March 3, 2014 5:18:37 PM UTC-8, Oleg Moskalenko wrote:

That's 2 Gb of file, I am not sure that I'll be able to download it. I'll try.

But I looked into the log file:

1) There are actually three sessions, not two. One session is staying "dormant" but all three sessions are getting refreshed.

2) The lifetime is 600 seconds and the sessions are supposed to be refreshed every half-time (300 seconds) but they are refreshed every, about, 550 seconds. That's not right - they must be refreshed every 300 seconds, ideally. But that's not a big deal.

3) Soon after the last refresh, the session id=006000000000000001 got disconnected for some reasons... And according to the log output (second 3188) it is NOT due to a timeout. So, presumably, the timeouts or refreshing does not have anything to do with that. That may be a kind of network problem - it the TURN server receives a network event like "address unreachable" on a packet or something like that.

What protocol you are using - UDP or TCP ?

Are you able to compile the general tarball ? I can prepare a test build with extra log information - and it will tell you why it is getting disconnected. What platform are you using ?

Oleg

On Mon, Mar 3, 2014 at 4:37 PM, Sprogrammer <sha...@companysocia.com> wrote:

Please download the wireshark pcap file. it was started to capture in the Turnserver PC on TCP port 80

1 - http://82.143.92.19:7007/files/dump.pcap

2 - http://82.143.92.19:7007/files/call1.log

3 - P1 was P2 was connected more then 10/15 minutes and suddenly the connection is dropped 

where P1 is still frozen and P2 is like normal disconnect mode, turnserver logs also stopped once the 

connection was dropped automatically

This is in my own lab network getting tested. But when i test it with remote locations, the duration of

auto call disconnect is much more earlier in between 1 to 10 minutes

Hope it helps. 

Please kindly confirm once the logs are collected (then i have to remove it)

reg

/sham

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Sprogrammer]

OK - Thank you. 

1) There are actually three sessions, not two. One session is staying "dormant" but all three sessions are getting refreshed.

2) The lifetime is 600 seconds and the sessions are supposed to be refreshed every half-time (300 seconds) but they are refreshed every, about, 550 seconds. That's not right - they must be refreshed every 300 seconds, ideally. But that's not a big deal.

3) Soon after the last refresh, the session id=006000000000000001 got disconnected for some reasons... And according to the log output (second 3188) it is NOT due to a timeout. So, presumably, the timeouts or refreshing does not have anything to do with that. That may be a kind of network problem - it the TURN server receives a network event like "address unreachable" on a packet or something like that.

> You are right, i think this things are breaking the connection for some reason.

> Like i said this auto disconnect is very random but its happening on every interconnect for example if i connect 100 times Peer 1, Peer2 over Turnserver, then 100 times with random duration the call automatically gets disconnected. 

FYI - I had not a single call which was never autodisconnected

What protocol you are using - UDP or TCP ?

> TCP for the turnserver

Are you able to compile the general tarball ? I can prepare a test build with extra log information - and it will tell you why it is getting disconnected. What platform are you using ?

> YES - I am using the latest version that was available from official link of Turnserver

> I am testing in RHEL 7 and Ubuntu 13.10 (64-bit)

There is nothing wrong as far as I can see in both the capture file and in the log file. The clients and the server are behaving properly (except that the client is refreshing the allocation a little too late). One strange thing is that we have three allocations; two of them are exchanging data, one allocation "sleeps". Only two allocations of three refresh the channel, but all three are refreshing the allocation. I do not know whether this is a correct behavior. There may be reasons why one of them is not refreshing the channel.

> This is very strange, in that session we had only Peer 1 (my linux laptop with chrome 33), Peer 2 (windows 7 pc, with chrome 33) and Turnserver (ubuntu 13.10 64-bit with latest turnserver)

But suddenly, without any signs of problems, the TURN server closes TCP connection with one of the clients (packet 2704683). It sends RST message to the client. As far as I can see in the code, that may happen if the TURN server could not send the packet to the client. There may be some system failures - but I cannot tell it from the log information.

> This must be a Chrome or Turnserver issue 

cause i have tested in random machines too 

(Linux to Linux, Linux to Windows, Windows to Windows PC, and i had same problems)

> FYI - Please note that when i do TURN RELAY then i have this auto disconnects, but if i do not use TURN RELAY then i have stable connection

I can add information to the log WHY the server chooses to close the connection. let me know if you can run a special debug build.

> Sure if you want me to test anything further let me know kindly.

thank you, anything i can do let me know kindly

regards

/sham

[Sprogrammer]

But suddenly, without any signs of problems, the TURN server closes TCP connection with one of the clients (packet 2704683). It sends RST message to the client. As far as I can see in the code, that may happen if the TURN server could not send the packet to the client. There may be some system failures - but I cannot tell it from the log information.

I can add information to the log WHY the server chooses to close the connection. let me know if you can run a special debug build.

> I think this is the exact problem like you have mentioned already, and that is what happening when i am doing the tests

> why the server chooses to close the connection? once server does that,

instantly first Peer 2 is auto disconnected (call initiator) where Peer 1 remain in frozen status (answered the call)

> Is there any way to stop this auto close by force using optional parameter? it always happening while using TURN server RELAY, without TURN server it never happens.

or is there any way via Telnet or via websocket we can controle it ourself? via session ID or so to trigger this close thing?

if possible, would be nice to have an option to force not to disconnect automatically but have at-least some kind of timeout values so that we can test lowering or increasing if that helps the connection to stay longer

Reg

/Sham

[Oleg Moskalenko]

Shamun, I've never heard about this problem before - and this TURN server is used by many. I've never experienced it myself, too - in similar tests (without Chrome, of course), I am able to run TCP connections for days without any disconnections.

The disconnect happens when the socket error is fatal. We have to figure out what is going on in your case. Then we can think what to do.

May be that's a surprise for you, but according to the logs there are indeed three TURN sessions, not two. And they are getting updated in somewhat strange manner. Another possibility is that as your application has an extra connection, may be something is updated not exactly how you want it to be.

Anyway, let's try to find out what is happening. Download, compile and install this tarball:

http://turnserver.open-sys.org/downloads/v3.2.2.9test/turnserver-3.2.2.9test.tar.gz

Run, collect the full log and post it here.

Regards,
Oleg

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.

[Sprogrammer]

OK - Thank you.

Shamun, I've never heard about this problem before - and this TURN server is used by many. I've never experienced it myself, too - in similar tests (without Chrome, of course), I am able to run TCP connections for days without any disconnections.

The disconnect happens when the socket error is fatal. We have to figure out what is going on in your case. Then we can think what to do.

> Its really strange and weird to me. 

That is why we test to find the surprising facts!

> But really something is there causing it, which we are missing all together

May be that's a surprise for you, but according to the logs there are indeed three TURN sessions, not two. And they are getting updated in somewhat strange manner. Another possibility is that as your application has an extra connection, may be something is updated not exactly how you want it to be.

> The strange part is that, when i do not use TURN RELAY at all it works i can leave the connection for day and night, it simply works 

> But as soon as my TURN RELAY started to work since then i have this auto disconnection

Anyway, let's try to find out what is happening. Download, compile and install this tarball:
http://turnserver.open-sys.org/downloads/v3.2.2.9test/turnserver-3.2.2.9test.tar.gz

Run, collect the full log and post it here.

FYI:

> turnserver v3.2.2.9test, Linux sun-Alienware-X51-R2 3.11.0-17-generic #31-Ubuntu SMP Mon Feb 3 21:52:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

> have made a call connection from my Linux laptop Chrome 33 (call answered) to Windows 7 Chrome 33 (initiator)

>>>> the connection was alive till +/_ 1750 seconds

> after that peer 2 (windows 7 pc chrome 33) auto disconnected

> peer 1 (linux pc chrome 33) frozen remote camera image of peer 2

> turnserver logs stopped

Please find the attachment of turnserver log: http://82.143.92.19:7007/files/call2.log

reg
/sham

[Oleg Moskalenko]

I checked the log. It is saying that the remote party (Chrome ?) closed the socket:

1837: session 002000000000000001: socket closed remotely

 Why - I have no idea.

You have to calculate the connections which you have.

These lines clearly show that you have 3 allocations:

................
1680: session 002000000000000001: refreshed, username=<root>, lifetime=600
1680: session 002000000000000001: user <root>: incoming packet REFRESH processed, success
1681: session 001000000000000002: refreshed, username=<root>, lifetime=600
1681: session 001000000000000002: user <root>: incoming packet REFRESH processed, success
1681: session 001000000000000003: refreshed, username=<root>, lifetime=600
1681: session 001000000000000003: user <root>: incoming packet REFRESH processed, success
.................

These lines clearly show that you have 3 channels:
................

302: session 001000000000000002: user <root>: incoming packet CHANNEL_BIND processed, success
302: session 002000000000000001: user <root>: incoming packet CHANNEL_BIND processed, success
302: session 002000000000000001: user <root>: incoming packet CHANNEL_BIND processed, success
302: session 001000000000000003: user <root>: incoming packet CHANNEL_BIND processed, success
........

And the channel in the session 002000000000000001 is now getting updated twice. The same session 

that later closes the connection.

I guess that you have to figure out what is really going on in your system, then we can answer 
the question who and why is closing the connection.

And it does not matter that it works without TURN server. That is a totally different story.

So, please achieve the state so that you know exactly how many TURN sessions you have (and why).

Regards,
Oleg

[Sprogrammer]

Thank you very much. 

1837: session 002000000000000001: socket closed remotely

> It clearly explain that Chrome 33/Canary is causing this. and its a BUG, when-ever TURN RELAY is successfully used,

then Chrome start to do this kind of strange behavior

> i have been facing this problem since more then month constantly

i can now again confirm its a Chrome BUG, without any reason its closing the SOCKET strange!!!!

These lines clearly show that you have 3 allocations:
................
1680: session 002000000000000001: refreshed, username=<root>, lifetime=600
1680: session 002000000000000001: user <root>: incoming packet REFRESH processed, success
1681: session 001000000000000002: refreshed, username=<root>, lifetime=600
1681: session 001000000000000002: user <root>: incoming packet REFRESH processed, success
1681: session 001000000000000003: refreshed, username=<root>, lifetime=600
1681: session 001000000000000003: user <root>: incoming packet REFRESH processed, success
.................

These lines clearly show that you have 3 channels:
................

302: session 001000000000000002: user <root>: incoming packet CHANNEL_BIND processed, success
302: session 002000000000000001: user <root>: incoming packet CHANNEL_BIND processed, success
302: session 002000000000000001: user <root>: incoming packet CHANNEL_BIND processed, success
302: session 001000000000000003: user <root>: incoming packet CHANNEL_BIND processed, success
........

> it is impossible that i have manually made this 3 allocation, 3 channel!!!!

where in reality only 2 peer's only involved (linux chrome 33 , windows 7 crome 33)

and there is no other way i could request to have 3 allocation, 3 channel!!!

> it must be a Chrome BUG, Chrome causing it when the TURN RELAY is successfully getting used, 

i do not created this from my end.

And the channel in the session 002000000000000001 is now getting updated twice. The same session 
that later closes the connection.
I guess that you have to figure out what is really going on in your system, then we can answer 
the question who and why is closing the connection.
And it does not matter that it works without TURN server. That is a totally different story.
So, please achieve the state so that you know exactly how many TURN sessions you have (and why).

> Chrome Bug when its doing TURN RELAY

i have checked my system i am not doing anything wrong only when Chrome has to do this TURN RELAY then its messed up
with 3 allocation, 3 channel.

Thank you, someone needs to report this BUG to Chrome/WebRTC, that when Chrome use successfully the TURN RELAY then it makes the connection unstable by creating a false 3rd allocation and 3rd channel which in a long term cause the connection to auto disconnect. TurnServer is doing perfectly as the log already clearly explains it.

Regards
Shamun

[Sprogrammer]

Reported to Chrome: https://code.google.com/p/chromium/issues/detail?id=348964

(please do the follow up here and there thank you)

[Sprogrammer]

FYI 

> when Google Chrome browser is launched for the first time

and you try first time to connect Peer1 Peer2 then the allocation and channel gets created like below:

2 times (allocation and channel) instead of 3 times in our previous log:

Mar  4 14:29:41 sun-Alienware-X51-R2 turnserver: 8111: session 001000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:29:41 sun-Alienware-X51-R2 turnserver: 8111: session 005000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:33:41 sun-Alienware-X51-R2 turnserver: 8351: session 001000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:33:41 sun-Alienware-X51-R2 turnserver: 8351: session 005000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:37:41 sun-Alienware-X51-R2 turnserver: 8591: session 001000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:37:41 sun-Alienware-X51-R2 turnserver: 8591: session 005000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:41:41 sun-Alienware-X51-R2 turnserver: 8831: session 001000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:41:41 sun-Alienware-X51-R2 turnserver: 8831: session 005000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:45:41 sun-Alienware-X51-R2 turnserver: 9071: session 001000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:45:41 sun-Alienware-X51-R2 turnserver: 9071: session 005000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:49:41 sun-Alienware-X51-R2 turnserver: 9311: session 001000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:49:41 sun-Alienware-X51-R2 turnserver: 9311: session 005000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:53:41 sun-Alienware-X51-R2 turnserver: 9551: session 005000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:53:41 sun-Alienware-X51-R2 turnserver: 9551: session 001000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:57:41 sun-Alienware-X51-R2 turnserver: 9791: session 005000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 14:57:41 sun-Alienware-X51-R2 turnserver: 9791: session 001000000000000005: user <root>: incoming packet CHANNEL_BIND processed, success

But when you have Google Chrome browser launched once (without closing the GUI) and with same instance GUI you disconnect the call and open a new call session then you see more allocation and more channel even greater then 3, 4 i have noticed. But still even with 2 allocation or 2 channel call is still getting auto disconnected by Chrome, that i cant understand yet why.

/sham

[Sprogrammer]

FYI: Did several call tests to mention you the "state":

When the browser is closed and restarted as new session, that first session is properly handled by Chrome (but if the same browser instance get reused then the allocation and channel gets unbalance including lifetime / refresh also). 

But still with correct allocation and channel the call is getting auto disconnect. 2 allocation, 2 channel, 600s lifetime / refresh, channel lifetime/refresh all went fine: 

$ tail -f /var/log/syslog | grep -e lifetime -e CHANNEL_BIND -e 'socket closed remotely'
Mar  4 15:35:29 sun-Alienware-X51-R2 turnserver: 12059: session 002000000000000012: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 15:35:30 sun-Alienware-X51-R2 turnserver: 12060: session 000000000000000007: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 15:36:28 sun-Alienware-X51-R2 turnserver: 12118: session 000000000000000007: refreshed, username=<root>, lifetime=600
Mar  4 15:36:28 sun-Alienware-X51-R2 turnserver: 12118: session 002000000000000012: refreshed, username=<root>, lifetime=600
Mar  4 15:39:29 sun-Alienware-X51-R2 turnserver: 12299: session 002000000000000012: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 15:39:30 sun-Alienware-X51-R2 turnserver: 12300: session 000000000000000007: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 15:43:29 sun-Alienware-X51-R2 turnserver: 12539: session 002000000000000012: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 15:43:30 sun-Alienware-X51-R2 turnserver: 12540: session 000000000000000007: user <root>: incoming packet CHANNEL_BIND processed, success
Mar  4 15:45:28 sun-Alienware-X51-R2 turnserver: 12658: session 000000000000000007: refreshed, username=<root>, lifetime=600
Mar  4 15:45:28 sun-Alienware-X51-R2 turnserver: 12658: session 002000000000000012: refreshed, username=<root>, lifetime=600

But at the end after waiting for a while, again this above call also automatically got disconnected. 

reg

/sham

[Sprogrammer]

Thanks a lot. Problem is solved. Its not Chrome BUG.

it was indeed a timeout from Peer 2 application itself.

reg

/sham

[Oleg Moskalenko]

That's cool.

Oleg

[Alexandre GOUAILLARD]

you should update your bug entry in chromium, and the corresponding thread in discuss-webrtc to let all know that is is not a bug in either chrome, nor the specs. That way, people who have the same problem and end up in your thread when googling it, will also have the solution with it.

cheers.

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/groups/opt_out.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Sprogrammer]

Dear Alex, 

thank you

- i will update

- I have not yet updated the corresponding BUG report cause its not working as WebRTC documentation mentioned 

it works by doing some extra modification such as ignoring the STUN request and replacing some reply host into reply relay

but once that change is applied then it works so in WebRTC still its a BUG it should have worked like the Documentation was written

which is not the case still

I will update the related thread later once the turn relay works after changing 

Point 1  ( https://groups.google.com/forum/#!topic/discuss-webrtc/LKChBGTmA3c ) as you have suggested before.

Best regards

Shamun