Connect to relay addr always timeout.

[cain]

Turnserver generate a relay addr 118.194.166.124:56906 for remote addr 61.148.243.193:30072 which is a 3G device.

Here is the turn server log.

52: handle_udp_packet: New UDP endpoint: local addr 118.194.166.124:9030, remote addr 61.148.243.193:30072

52: session 128000000000000001: user <>: incoming packet message processed, error 401: Unauthorised

52: IPv4. Local relay addr: 118.194.166.124:56906

52: session 128000000000000001: new, username=<348630376>, lifetime=600

52: session 128000000000000001: user <348630376>: incoming packet ALLOCATE processed, success

54: session 128000000000000001: user <348630376>: incoming packet CREATE_PERMISSION processed, success

652: session 128000000000000001: closed (2nd stage), user <348630376>, local 118.194.166.124:9030, remote 61.148.243.193:30072, reason: allocation timeout

652: session 128000000000000001: delete: username=<348630376>

There is a device which run a WebRTC app, wants to connect device A by the relay addr: 118.194.166.124:56906. But it's always timeout.

Here is the WebRTC connect log.

Jingle:Conn[audio:aQQfpZ6d:1:0:local:udp:192.168.1.105:63352->:1:0.01:relay:udp:118.194.166.124: 56906|C--I|179896594927861246|-]: Timed out after 15010 ms without a response, rtt=3000

Jingle:Conn[audio:aQQfpZ6d:1:0:local:udp:192.168.1.105:63352->:1:0.01:relay:udp:118.194.166.124: 56906|C-xI|179896594927861246|-]: Connection deleted

The relay address and port are opened, why is the connection always timeout?

[Oleg Moskalenko]

That's a simple question. Look at the log file timestamps. The allocation was created at 52 seconds, and it timed out at 652 - exactly 600 seconds after. That is the default timeout of the session. Before the timeout expires, the TURN client must refresh the allocation (send a refresh command, and also the permissions have to be refreshed, with a separate command). Your client does not do that - so the allocation is getting terminated. I cannot tell you how to configure the client; but I can tell you what the server is expecting.

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/d/optout.

[cain]

But the reason why allocation timed out was that client "Timed out after 15010 ms without a response, rtt=3000".

I use tcpdump to dump the data at relay addr, there was only data sent to relay addr from "192.168.1.105:63352", but no data sent back.

在 2014年5月5日星期一UTC+8上午2时07分11秒，Oleg Moskalenko写道：

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.

[Oleg Moskalenko]

I have no idea what is happening at the client side. I can only tell you how the server views the situation and why the server times out. That's what I wrote in my first response. What the client is doing and why is beyond my competence.

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.

[cain]

Thank you for your help :)

在 2014年5月5日星期一UTC+8上午11时30分45秒，Oleg Moskalenko写道：

To post to this group, send email to turn-server-project-rfc5766-turn-s...@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/d/optout.

[cain]

I don't know whether this will help, the localhost.58076 is the device addr, and the localhost.57877 is the relay addr.

device had sent data to relay, but relay had no response.

localhost:rfc5766-turn-server cain$ sudo tcpdump -X 'port 57877'

tcpdump: data link type PKTAP

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on pktap, link-type PKTAP (Packet Tap), capture size 65535 bytes

11:58:01.463893 IP localhost.58076 > localhost.57877: UDP, length 112

0x0000:  5426 96d2 16f1 3848 4ce5 d24d 0800 4500  T&....8HL..M..E.

0x0010:  008c 8163 0000 4011 e36e 0a09 00bb 0a09  ...c..@..n......

0x0020:  00c3 e2dc e215 0078 fe59 0001 005c 2112  .......x.Y...\!.

0x0030:  a442 4c6a 3675 696e 7a47 4867 5530 0006  .BLj6uinzGHgU0..

0x0040:  0021 7977 364f 6d7a 5845 4130 726a 6452  .!yw6OmzXEA0rjdR

0x0050:  7361 3a4c 756f 3571 3864 7972 7772 686f  sa:Luo5q8dyrwrho

0x0060:  4e4e 3200 0000 8029 0008 0464 32e9 527f  NN2....)...d2.R.

0x0070:  ef41 0024 0004 6e7d 1eff 0008 0014 0f29  .A.$..n}.......)

0x0080:  f733 e260 afd7 2e8e d49c 59fd f525 7c57  .3.`......Y..%|W

0x0090:  8df3 8028 0004 8ecd d8e9                 ...(......

11:58:01.476264 IP localhost.58076 > localhost.57877: UDP, length 112

0x0000:  5426 96d2 16f1 3848 4ce5 d24d 0800 4500  T&....8HL..M..E.

0x0010:  008c 63c5 0000 4011 010d 0a09 00bb 0a09  ..c...@.........

0x0020:  00c3 e2dc e215 0078 f526 0001 005c 2112  .......x.&...\!.

0x0030:  a442 4e4c 5674 5930 3850 4e38 5244 0006  .BNLVtY08PN8RD..

0x0040:  0021 7977 364f 6d7a 5845 4130 726a 6452  .!yw6OmzXEA0rjdR

0x0050:  7361 3a4c 756f 3571 3864 7972 7772 686f  sa:Luo5q8dyrwrho

0x0060:  4e4e 3200 0000 8029 0008 0464 32e9 527f  NN2....)...d2.R.

0x0070:  ef41 0024 0004 6e7d 1eff 0008 0014 26f7  .A.$..n}......&.

0x0080:  04f6 2421 6bad 9e81 029b 6f27 ee78 72fb  ..$!k.....o'.xr.

0x0090:  f5f9 8028 0004 b56e baab                 ...(...n..

11:58:01.520100 IP localhost.58076 > localhost.57877: UDP, length 112

0x0000:  5426 96d2 16f1 3848 4ce5 d24d 0800 4500  T&....8HL..M..E.

0x0010:  008c b6c5 0000 4011 ae0c 0a09 00bb 0a09  ......@.........

0x0020:  00c3 e2dc e215 0078 82a9 0001 005c 2112  .......x.....\!.

0x0030:  a442 356c 7936 3051 724b 4862 7970 0006  .B5ly60QrKHbyp..

0x0040:  0021 7977 364f 6d7a 5845 4130 726a 6452  .!yw6OmzXEA0rjdR

0x0050:  7361 3a4c 756f 3571 3864 7972 7772 686f  sa:Luo5q8dyrwrho

0x0060:  4e4e 3200 0000 8029 0008 0464 32e9 527f  NN2....)...d2.R.

0x0070:  ef41 0024 0004 6e7d 1eff 0008 0014 f836  .A.$..n}.......6

0x0080:  777a 6e25 c379 b3a6 0ddf ce30 abd8 857a  wzn%.y.....0...z

0x0090:  d823 8028 0004 c284 ccae                 .#.(......

11:58:01.579749 IP localhost.58076 > localhost.57877: UDP, length 112

0x0000:  5426 96d2 16f1 3848 4ce5 d24d 0800 4500  T&....8HL..M..E.

0x0010:  008c c106 0000 4011 a3cb 0a09 00bb 0a09  ......@.........

0x0020:  00c3 e2dc e215 0078 414c 0001 005c 2112  .......xAL...\!.

0x0030:  a442 4664 436f 674f 7076 7968 436d 0006  .BFdCogOpvyhCm..

0x0040:  0021 7977 364f 6d7a 5845 4130 726a 6452  .!yw6OmzXEA0rjdR

0x0050:  7361 3a4c 756f 3571 3864 7972 7772 686f  sa:Luo5q8dyrwrho

0x0060:  4e4e 3200 0000 8029 0008 0464 32e9 527f  NN2....)...d2.R.

0x0070:  ef41 0024 0004 6e7d 1eff 0008 0014 90a6  .A.$..n}........

0x0080:  81a9 eff8 435b 2750 10aa 8234 ff70 2201  ....C['P...4.p".

0x0090:  03b5 8028 0004 bf87 1b30                 ...(.....0

11:58:01.617319 IP localhost.58076 > localhost.57877: UDP, length 112

0x0000:  5426 96d2 16f1 3848 4ce5 d24d 0800 4500  T&....8HL..M..E.

0x0010:  008c 6c9f 0000 4011 f832 0a09 00bb 0a09  ..l...@..2......

0x0020:  00c3 e2dc e215 0078 d06b 0001 005c 2112  .......x.k...\!.

0x0030:  a442 3252 6846 7a6f 5541 7a53 762b 0006  .B2RhFzoUAzSv+..

0x0040:  0021 7977 364f 6d7a 5845 4130 726a 6452  .!yw6OmzXEA0rjdR

0x0050:  7361 3a4c 756f 3571 3864 7972 7772 686f  sa:Luo5q8dyrwrho

0x0060:  4e4e 3200 0000 8029 0008 0464 32e9 527f  NN2....)...d2.R.

0x0070:  ef41 0024 0004 6e7d 1eff 0008 0014 89ed  .A.$..n}........

0x0080:  726d 84f9 abf2 889b a2a9 3275 52fd de02  rm........2uR...

0x0090:  11e6 8028 0004 c896 9dba                 ...(......

11:58:01.665196 IP localhost.58076 > localhost.57877: UDP, length 112

0x0000:  5426 96d2 16f1 3848 4ce5 d24d 0800 4500  T&....8HL..M..E.

0x0010:  008c 5733 0000 4011 0d9f 0a09 00bb 0a09  ..W3..@.........

0x0020:  00c3 e2dc e215 0078 3c25 0001 005c 2112  .......x<%...\!.

0x0030:  a442 3130 7a6e 592f 4342 2f37 4241 0006  .B10znY/CB/7BA..

0x0040:  0021 7977 364f 6d7a 5845 4130 726a 6452  .!yw6OmzXEA0rjdR

0x0050:  7361 3a4c 756f 3571 3864 7972 7772 686f  sa:Luo5q8dyrwrho

0x0060:  4e4e 3200 0000 8029 0008 0464 32e9 527f  NN2....)...d2.R.

0x0070:  ef41 0024 0004 6e7d 1eff 0008 0014 18ae  .A.$..n}........

0x0080:  0c5f 112d 02d9 2220 4f47 b0c9 6164 2e22  ._.-..".OG..ad."

0x0090:  2a3c 8028 0004 6627 ee90                 *<.(..f'..

11:58:01.715512 IP localhost.58076 > localhost.57877: UDP, length 112

0x0000:  5426 96d2 16f1 3848 4ce5 d24d 0800 4500  T&....8HL..M..E.

0x0010:  008c 944c 0000 4011 d085 0a09 00bb 0a09  ...L..@.........

0x0020:  00c3 e2dc e215 0078 d158 0001 005c 2112  .......x.X...\!.

0x0030:  a442 5065 6c56 6e4b 6674 7162 6e7a 0006  .BPelVnKftqbnz..

0x0040:  0021 7977 364f 6d7a 5845 4130 726a 6452  .!yw6OmzXEA0rjdR

0x0050:  7361 3a4c 756f 3571 3864 7972 7772 686f  sa:Luo5q8dyrwrho

0x0060:  4e4e 3200 0000 8029 0008 0464 32e9 527f  NN2....)...d2.R.

0x0070:  ef41 0024 0004 6e7d 1eff 0008 0014 f8d6  .A.$..n}........

0x0080:  e99d b8f6 a8c5 b122 0824 d7ac 57cd 997d  .......".$..W..}

0x0090:  a96c 8028 0004 586a 5475                 .l.(..XjTu

在 2014年5月5日星期一UTC+8上午11时30分45秒，Oleg Moskalenko写道：

To post to this group, send email to turn-server-project-rfc5766-turn-s...@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/d/optout.

[Oleg Moskalenko]

The server log is clearly saying that between 54 and 652 seconds the server did not receive any control traffic from the client. That's the problem what you are looking for.

Oleg

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.

[cain]

is the log normal?

9: read_client_connection:3931:start

9: read_client_connection: data.buffer=0x7f2a8c00096c, data.len=100

9: IPv4. Local relay addr: 118.194.166.124:64857

9: session 128000000000000001: new, realm=<xxx.com>, username=<291313369>, lifetime=600

9: session 128000000000000001: realm <xxx.com> user <291313369>: incoming packet ALLOCATE processed, success

9: write_client_connection:3716:start

9: write_client_connection: prepare to write to s 0x7f2a8c010970

9: write_client_connection:3738:end

9: read_client_connection:4029:end

seems there is no binding log like "incoming packet BINDING processed, success"

在 2014年5月5日星期一UTC+8下午12时10分26秒，Oleg Moskalenko写道：

[Oleg Moskalenko]

After ALLOCATE, you need CREATE PERMISSION request and, optionally, BINDING request (if data channels are used).

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.

[cain]

Actually I use WebRTC to handle the candidates received from "stun:xxxxx" and "turn:xxxxx" server, the STUN server works well, but the relay add received from TURN server can not work.

I will continue reading and researching to find out the reason.

在 2014年5月5日星期一UTC+8下午4时38分32秒，Oleg Moskalenko写道：

[cain]

use “turnutils_uclient -u 291313369 -w 111111 -X -p 9030 118.194.166.124” to test turnserver, turnutils_uclient will keep freezing...

Here is the log of turn server.

0: log file opened: /var/log/turn_6885_2014-05-05.log

0: 

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

Version Coturn-4.0.0.0 'Threetrees'

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 compile-time version 0x1000105f: fresh enough

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

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

0: Config file found: /etc/turnserver.conf

0: Listener address to use: 118.194.166.124

0: Relay address to use: 118.194.166.124

0: Config file found: /etc/turnserver.conf

0: Config file found: /deploy/sneaky/sneaky/turnuserdb.conf

0: WARNING: cannot find certificate file: turn_server_cert.pem (1)

0: WARNING: cannot start TLS and DTLS listeners because certificate file is not set properly

0: WARNING: cannot find private key file: turn_server_pkey.pem (1)

0: WARNING: cannot start TLS and DTLS listeners because private key file is not set properly

0: pid file created: /var/run/turnserver.pid

0: IO method (main listener thread): epoll (with changelist)

0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided

0: Wait for relay ports initialization...

0:   relay 118.194.166.124 initialization...

0:   relay 118.194.166.124 initialization done

0: Relay ports initialization done

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

0: turn server id=0 created

0: IO method (udp listener/relay thread): epoll (with changelist)

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

0: turn server id=1 created

0: turn server id=128 created

0: IPv4. UDP listener opened on: 118.194.166.124:9030

0: IPv4. TCP listener opened on : 118.194.166.124:9030

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

2: handle_udp_packet: New UDP endpoint: local addr 118.194.166.124:9030, remote addr 61.148.192.102:63967

2: session 128000000000000001: realm <peiwo.me> user <>: incoming packet message processed, error 401: Unauthorised

2: IPv4. Local relay addr: 118.194.166.124:54914

2: IPv4. Local reserved relay addr: 118.194.166.124:54915

2: session 128000000000000001: new, realm=<peiwo.me>, username=<291313369>, lifetime=800

2: session 128000000000000001: realm <peiwo.me> user <291313369>: incoming packet ALLOCATE processed, success

2: session 128000000000000001: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=600

2: session 128000000000000001: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

2: handle_udp_packet: New UDP endpoint: local addr 118.194.166.124:9030, remote addr 61.148.192.102:57554

2: session 128000000000000002: realm <peiwo.me> user <>: incoming packet message processed, error 401: Unauthorised

2: IPv4. Local relay addr (RTCP): 118.194.166.124:54915

2: session 128000000000000002: new, realm=<peiwo.me>, username=<291313369>, lifetime=800

2: session 128000000000000002: realm <peiwo.me> user <291313369>: incoming packet ALLOCATE processed, success

2: session 128000000000000002: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=600

2: session 128000000000000002: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

在 2014年5月5日星期一UTC+8下午4时38分32秒，Oleg Moskalenko写道：

[cain]

another test

$ turnutils_uclient -u 291313369 -w 111111 -X -p 9030 118.194.166.124

0: Total connect time is 2

0: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0

1: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0

2: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0

3: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0

4: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0

5: start_mclient: msz=2, tot_send_msgs=2, tot_recv_msgs=0, tot_send_bytes ~ 200, tot_recv_bytes ~ 0

6: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0

7: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0

8: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0

9: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0

10: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0

10: start_mclient: tot_send_msgs=10, tot_recv_msgs=0

10: start_mclient: tot_send_bytes ~ 1000, tot_recv_bytes ~ 0

10: Total transmit time is 10

10: Total lost packets 10 (100.000000%), total send dropped 0 (0.000000%)

10: Average round trip delay 0.000000 ms; min = 4294967295 ms, max = 0 ms

10: Average jitter -nan ms; min = 4294967295 ms, max = 0 ms

and the log of turnserver

116: handle_udp_packet: New UDP endpoint: local addr 118.194.166.124:9030, remote addr 173.255.213.94:37874

116: session 128000000000000004: realm <peiwo.me> user <>: incoming packet message processed, error 401: Unauthorised

117: IPv4. Local relay addr: 118.194.166.124:49542

117: IPv4. Local reserved relay addr: 118.194.166.124:49543

117: session 128000000000000004: new, realm=<peiwo.me>, username=<291313369>, lifetime=800

117: session 128000000000000004: realm <peiwo.me> user <291313369>: incoming packet ALLOCATE processed, success

117: session 128000000000000004: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=600

117: session 128000000000000004: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

117: handle_udp_packet: New UDP endpoint: local addr 118.194.166.124:9030, remote addr 173.255.213.94:49770

117: session 128000000000000005: realm <peiwo.me> user <>: incoming packet message processed, error 401: Unauthorised

117: IPv4. Local relay addr (RTCP): 118.194.166.124:49543

117: session 128000000000000005: new, realm=<peiwo.me>, username=<291313369>, lifetime=800

117: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet ALLOCATE processed, success

117: session 128000000000000005: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=600

117: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

117: handle_udp_packet: New UDP endpoint: local addr 118.194.166.124:9030, remote addr 173.255.213.94:54828

117: session 128000000000000006: realm <peiwo.me> user <>: incoming packet message processed, error 401: Unauthorised

118: IPv4. Local relay addr: 118.194.166.124:64798

118: IPv4. Local reserved relay addr: 118.194.166.124:64799

118: session 128000000000000006: new, realm=<peiwo.me>, username=<291313369>, lifetime=800

118: session 128000000000000006: realm <peiwo.me> user <291313369>: incoming packet ALLOCATE processed, success

118: session 128000000000000006: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=600

118: session 128000000000000006: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

118: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet CHANNEL_BIND processed, success

118: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet CHANNEL_BIND processed, success

118: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet CHANNEL_BIND processed, success

118: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet CHANNEL_BIND processed, success

118: session 128000000000000006: realm <peiwo.me> user <291313369>: incoming packet CHANNEL_BIND processed, success

119: session 128000000000000005: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=600

119: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

119: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet CREATE_PERMISSION processed, success

119: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet CHANNEL_BIND processed, success

119: session 128000000000000006: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=600

119: session 128000000000000006: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

119: session 128000000000000006: realm <peiwo.me> user <291313369>: incoming packet CREATE_PERMISSION processed, success

119: session 128000000000000006: realm <peiwo.me> user <291313369>: incoming packet CHANNEL_BIND processed, success

128: session 128000000000000005: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=0

128: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

128: session 128000000000000006: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=0

128: session 128000000000000006: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

129: session 128000000000000005: closed (2nd stage), user <291313369> realm <peiwo.me> origin <>, local 118.194.166.124:9030, remote 173.255.213.94:49770, reason: allocation timeout

129: session 128000000000000006: closed (2nd stage), user <291313369> realm <peiwo.me> origin <>, local 118.194.166.124:9030, remote 173.255.213.94:54828, reason: allocation timeout

在 2014年5月5日星期一UTC+8下午4时38分32秒，Oleg Moskalenko写道：

[Oleg Moskalenko]

The turnutils_uclient was able to connect to the TURN server but it was not able to establish a workable relaying sessions. Why - I do not know, may be something with your topology.

One thing that I see is you are probably not running the peer test program. Then, you have to use option -y.

See this output from the turnserver:

.....................

128: session 128000000000000005: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=0

128: session 128000000000000005: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

128: session 128000000000000006: refreshed, realm=<peiwo.me>, username=<291313369>, lifetime=0

128: session 128000000000000006: realm <peiwo.me> user <291313369>: incoming packet REFRESH processed, success

....................

This output means that the client process closed the sessions (sent REFRESH request with 0 (zero) lifetime.

Run the wireshark over the communication path between them and see where is the problem.

Oleg

[cain]

I captured the udp packages between "caller and turn server" and "callee and turn server".

Sorry I can't capture this two paths at the same time, so I captured them in twice, the 1st time the device act as a caller, and the 2nd time the device act as callee.

Could you help me to check whether there is some wrong? I worked at webrtc and turn server many days, but have no progress.

在 2014年5月6日星期二UTC+8上午12时58分18秒，Oleg Moskalenko写道：

...

[Oleg Moskalenko]

That's not how we can help in the traffic analysis. You have to use the wireshark GUI console and use the STUN traffic option on the packets - then you will see the packets content. Sorry I cannot dedicated my time to find small particular problems in the client configuration - unless I am sure that this is a server bug. This is an open-source project.

Oleg

在 2014年5月6日星期二UTC+8上午12时58分18秒，Oleg Moskalenko写道：

another test

0x0070: &nbs

...

[cain]

I'm sorry to bother you so long, finally we found out that the issue was caused by client side.

Thank you for your patience to answer me, and thank you for bringing us such a great project.

...

[Remya Das]

Hi,

I'm also facing the same issue
I'm able to see the following msgs in the console.

incoming packet ALLOCATE processed, success

CREATE_PERMISSION processed, success

There t no CHANNEL BIND message. And thus the data is not transmitting also.

How to solve this. Please help.

Thanks

[Oleg Moskalenko]

That means that your client program for some reason decided not to allocate a channel. May be ICE relay candidates were not the best candidates.

Sent from my iPhone

> --
> 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.

[Yash Sharma]

Hi

We are also facing the same issue and are not able to solve it. Could you guide me on how did you solve this issue?

-

Yash

www.coffeetable.vc

[Ajay Krishnamurthy]

Hi ,

I am new to WebRTC , when 2 peers connect from the same network(router) we able to make success call .[audio/video].

When the peers are in different network(router) we are unable to make call . We are getting below error in the TURN Log. 

2253: session 000000000000000097: user <username1>: incoming packet REFRESH processed, success
	2253: session 000000000000000112: TCP socket closed remotely 10.99.99.151:59212
	2253: session 000000000000000112: closed (2nd stage), user <username1>, local 93.91.16.33:3478, remote 10.99.99.151:59212, reason: TCP connection closed by client (callback)
	2253: session 000000000000000105: TCP socket closed remotely 10.99.99.151:59205
	2253: session 000000000000000105: closed (2nd stage), user <>, local 93.91.16.36:3478, remote 10.99.99.151:59205, reason: TCP connection closed by client (callback)
	2253: session 000000000000000106: TCP socket closed remotely 10.99.99.151:59206
	2253: session 000000000000000106: closed (2nd stage), user <>, local 93.91.16.33:3478, remote 10.99.99.151:59206, reason: TCP connection closed by client (callback)
	2253: session 000000000000000107: refreshed, username=<username1>, lifetime=0
	2253: session 000000000000000107: user <username1>: incoming packet REFRESH processed, success
	2253: session 000000000000000107: TCP socket closed remotely 10.99.99.151:59207
	2253: session 000000000000000107: closed (2nd stage), user <username1>, local 93.91.16.36:3478, remote 10.99.99.151:59207, reason: TCP connection closed by client (callback)
	2253: session 000000000000000096: refreshed, username=<username1>, lifetime=0 Please help us to resolve this issue. Thanks in Advance Ajay Krishnamurthy

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.