help me , why allocation timeout ?

[371816210]

 

first   i use     rfc5766-turn-server  server script is below : turnserver -v --syslog -a -L  10.142.40.62  -E 10.142.40.62 -p 443 --max-bps=3000000 -f -m 3 --min-port=3235 5 --max-port=65535 -r  218.17.160.137  --no-dtls --no-tls  --mysql-userdb="host=localhost dbname=turn user=root password=123456 connect_timeout=30" client : turnutils_uclient 203.195.238.168 -u myitm  -w 123456 -p 443   my public ip is   203.195.238.168   client log： 　 yh@yh-System-Product-Name:~$ turnutils_uclient 203.195.238.168 -u myitm  -w 123456 -p 443 0: Total connect time is 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=5, tot_recv_msgs=0, tot_send_bytes ~ 500, tot_recv_bytes ~ 0 5: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, 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 8: start_mclient: msz=1, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0 9: start_mclient: tot_send_msgs=10, tot_recv_msgs=0 9: start_mclient: tot_send_bytes ~ 1000, tot_recv_bytes ~ 0 9: Total transmit time is 9 9: Total lost packets 10 (100.000000%), total send dropped 0 (0.000000%) 9: Average round trip delay 0.000000 ms; min = 4294967295 ms, max = 0 ms 9: Average jitter -nan ms; min = 4294967295 ms, max = 0 ms server log : root@VM-40-62-ubuntu:/usr/share/rfc5766-turn-server/examples/scripts/longtermsecuredb# ./secure_relay_with_db_mysql.sh   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.3.94 '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 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: 10.142.40.62 0: Relay address to use: 10.142.40.62 0: 3000000 bytes per second allowed per session 0: Config file found: /etc/turnserver.conf 0: MySQL DB connection success: host=localhost dbname=turn user=root password=123456 connect_timeout=30 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 10.142.40.62 initialization... 0:   relay 10.142.40.62 initialization done 0: Relay ports initialization done 0: IO method (udp listener/relay thread): epoll (with changelist) 0: IO method (general relay thread): epoll (with changelist) 0: turn server id=0 created 0: IO method (general relay thread): epoll (with changelist) 0: turn server id=1 created 0: IO method (general relay thread): epoll (with changelist) 0: turn server id=2 created 0: turn server id=128 created 0: IPv4. UDP listener opened on: 10.142.40.62:443 0: IPv4. TCP listener opened on : 10.142.40.62:443 0: IO method (cli thread): epoll (with changelist) 0: IPv4. CLI listener opened on : 127.0.0.1:5766 0: IO method (auth thread): epoll (with changelist) 33: handle_udp_packet: New UDP endpoint: local addr 10.142.40.62:443, remote addr 218.17.160.137:44133 33: session 128000000000000001: user <>: incoming packet message processed, error 401: Unauthorised 33: IPv4. Local relay addr: 10.142.40.62:65104 33: IPv4. Local reserved relay addr: 10.142.40.62:65105 33: session 128000000000000001: new, username=<myitm>, lifetime=800 33: session 128000000000000001: user <myitm>: incoming packet ALLOCATE processed, success 33: session 128000000000000001: refreshed, username=<myitm>, lifetime=600 33: session 128000000000000001: user <myitm>: incoming packet REFRESH processed, success 33: handle_udp_packet: New UDP endpoint: local addr 10.142.40.62:443, remote addr 218.17.160.137:53433 33: session 128000000000000002: user <>: incoming packet message processed, error 401: Unauthorised 33: IPv4. Local relay addr (RTCP): 10.142.40.62:65105 33: session 128000000000000002: new, username=<myitm>, lifetime=800 33: session 128000000000000002: user <myitm>: incoming packet ALLOCATE processed, success 33: session 128000000000000002: refreshed, username=<myitm>, lifetime=600 33: session 128000000000000002: user <myitm>: incoming packet REFRESH processed, success 33: handle_udp_packet: New UDP endpoint: local addr 10.142.40.62:443, remote addr 218.17.160.137:56752 33: session 128000000000000003: user <>: incoming packet message processed, error 401: Unauthorised 33: IPv4. Local relay addr: 10.142.40.62:52354 33: IPv4. Local reserved relay addr: 10.142.40.62:52355 33: session 128000000000000003: new, username=<myitm>, lifetime=800 33: session 128000000000000003: user <myitm>: incoming packet ALLOCATE processed, success 33: session 128000000000000003: refreshed, username=<myitm>, lifetime=600 33: session 128000000000000003: user <myitm>: incoming packet REFRESH processed, success 33: session 128000000000000002: user <myitm>: incoming packet CHANNEL_BIND processed, success 33: session 128000000000000002: user <myitm>: incoming packet CHANNEL_BIND processed, success 33: session 128000000000000002: user <myitm>: incoming packet CHANNEL_BIND processed, success 33: session 128000000000000002: user <myitm>: incoming packet CHANNEL_BIND processed, success 33: session 128000000000000003: user <myitm>: incoming packet CHANNEL_BIND processed, success 33: session 128000000000000002: refreshed, username=<myitm>, lifetime=600 33: session 128000000000000002: user <myitm>: incoming packet REFRESH processed, success 33: session 128000000000000002: user <myitm>: incoming packet CREATE_PERMISSION processed, success 33: session 128000000000000002: user <myitm>: incoming packet CHANNEL_BIND processed, success 33: session 128000000000000003: refreshed, username=<myitm>, lifetime=600 33: session 128000000000000003: user <myitm>: incoming packet REFRESH processed, success 33: session 128000000000000003: user <myitm>: incoming packet CREATE_PERMISSION processed, success 33: session 128000000000000003: user <myitm>: incoming packet CHANNEL_BIND processed, success 42: session 128000000000000002: refreshed, username=<myitm>, lifetime=0 42: session 128000000000000002: user <myitm>: incoming packet REFRESH processed, success 42: session 128000000000000003: refreshed, username=<myitm>, lifetime=0 42: session 128000000000000003: user <myitm>: incoming packet REFRESH processed, success 43: session 128000000000000002: closed (2nd stage), user <myitm>, local 10.142.40.62:443, remote 218.17.160.137:53433, reason: allocation timeout 44: session 128000000000000003: closed (2nd stage), user <myitm>, local 10.142.40.62:443, remote 218.17.160.137:56752, reason: allocation timeout why is always allocation timeout ?   help me ,thank you .

[Oleg Moskalenko]

Look at the messages at second 42. The client sends the refresh requests with lifetime zero (0). That means that the clients wants to end the session. The server treats that condition as a timeout - the log message is probably somewhat misleading. But as far as i see everything works correctly - except that you network topology is probably off.

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

[371816210]

dear Oleg ,how to check network ?

i want to use rfc5766-turn-server  as turn server for imsdroid  (https://code.google.com/p/imsdroid/) ,

i found stun  in  rfc5766-turn-server   work  very well 

but turn in   rfc5766-turn-server is did't work

server log  is as same as above  

hope your  answer ,thank you  

在 2014年7月5日星期六UTC+8上午10时49分41秒，371816210写道：

[Oleg Moskalenko]

That's just too general a question. For your particular purpose, you have to check that there is a good connectivity path between your relay endpoints and your peers. The absence of that connectivity is a common problem in complex topology scenarios.