alexdruzhilov / rfc5766-turn-server Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/rfc5766-turn-server
Automatically exported from code.google.com/p/rfc5766-turn-server
Currently it works only with long-term or short-term credentials. Allow
anonymous operations.
Original issue reported on code.google.com by [email protected]
on 23 Jul 2013 at 6:25
It cannot be compiled in RedHat/CentOS with FIPS version of OpenSSL, 0.9.8.
Original issue reported on code.google.com by [email protected]
on 14 Apr 2013 at 7:17
Currently when the debian package is installed, it always sets the turnserver
as the system service. It may not be what some users need.
Original issue reported on code.google.com by [email protected]
on 2 May 2013 at 9:49
The problem and the solution is described here:
http://archives.seul.org/libevent/users/Jul-2013/msg00017.html
Original issue reported on code.google.com by [email protected]
on 20 Jul 2013 at 6:18
Current implementation requires that a single IP address being used when the
TURN server is behind a NAT (-X option). There are two problems with that:
1) RFC 5780 STUN NAT discovery requires at least two IP addresses.
2) Some setups could you multiple relay addresses.
The turnserver must allow multiple -X options of format:
$ turnserver ... -X IPpublic1/IPprivate1 -X IPpublic2/IPprivate2 ...
to establish multiple IP-to-IP mappings.
For backward compatibility, the old form also must be supported:
$ turnserver -X IPpublic
- to establish a single "global" IP mapping.
Original issue reported on code.google.com by [email protected]
on 14 May 2013 at 3:57
What steps will reproduce the problem?
1.I use pjnath library, and pjsua client(UAS,UAC)
2.Client fast speed duplicate connect and disconnect, and then sometimes(upon
4) later will reproduce the problem. I find
client_ss_allocation_timeout_handler(refresh_client_ss_allocation_timeout_handle
r) the callback will run loss sometimes. why? This libevent library is a issue?
What version of the product are you using? On what operating system?
The new version also has this problem.
Please provide any additional information below.
Sorry, I know little English, I hope you can understand what express meaning .
Thank you!
Original issue reported on code.google.com by [email protected]
on 18 Jul 2013 at 6:01
> What steps will reproduce the problem?
1. compile via "make" or "build.sh"
> What is the expected output? What do you see instead?
src/apps/relay/turnmutex.c: In function ‘turn_mutex_init_recursive’:
src/apps/relay/turnmutex.c:104: warning: implicit declaration of function
‘pthread_mutexattr_settype’
src/apps/relay/turnmutex.c:104: warning: nested extern declaration of
‘pthread_mutexattr_settype’
src/apps/relay/turnmutex.c:104: error: ‘PTHREAD_MUTEX_RECURSIVE’ undeclared
(first use in this function)
src/apps/relay/turnmutex.c:104: error: (Each undeclared identifier is reported
only once
src/apps/relay/turnmutex.c:104: error: for each function it appears in.)
make: *** [bin/turnserver] Error 1
> What version of the product are you using? On what operating system?
I'm compiling from release 1.3.0.1, on and up-to-date Debian squeeze (libevent2
from squeeze-backports).
> Please provide any additional information below.
I am not familiar with the topic, but I think that the problem resides in the
usage of pthread.h from the GNU C Library. Both the warning on
"pthread_mutexattr_settype" and the missing PTHREAD_MUTEX_RECURSIVE (pthread.h
from GNU defines only PTHREAD_MUTEX_RECURSIVE_NP by default) suggests that it
is an extension which is not enabled given the defined macros.
An option may be to modify your build system in build.sh by adding a
conditional like the one you used for Solaris. I tried adding "-D_GNU_SOURCE"
to "OSCFLAGS", and it resolves the issue (patch attached). It may not be,
however, the most fit solution as it enables lots of other definitions.
Original issue reported on code.google.com by [email protected]
on 27 Dec 2012 at 2:08
Attachments:
There is a bug in the current version of chrome that does not allow a ":" to be
used as part of a TURN url. Therefore, I think it is a good idea to allow this
so be configured (eg use a "+") and use ":" as the default.
I am happy to supply a patch if you are interested.
Original issue reported on code.google.com by [email protected]
on 25 Apr 2013 at 1:24
It is not possible to configure "Per-session packet interval" less than 10
milliseconds.
We need 5 milliseconds to simulate some audio+video clients.
Find patch attached just reducing the libevent timeout from 10 msecs to 1 msec.
PD. Feel free to close this issue without solving if this is a very specific
use case. Anyway I thought it could be useful for reference in case somebody
needs to do the same in the future.
Original issue reported on code.google.com by [email protected]
on 29 Mar 2013 at 3:55
Attachments:
This is not an error or bug but a capability being added to other TURN server
implementations so that they can be hosted on cloud services such as AWS which
only offer NAT and not public IPs.
This can be achieved by creating a config parameter for external_IP which is
the set to the outside address of the NAT. This address must have port
forwarding to a valid listening address:port for the rfc5766turnserver.
Responses to STUN and TURN requests are then formulated using the external_IP
override rather than the native address of the listening interface.
Would you consider this enhancement to your very good TURN solution.
Thanks,
Warren
Original issue reported on code.google.com by [email protected]
on 28 Jan 2013 at 3:33
This TURN server implements the original TURN REST API proposal when the
combination user name was constructed as "username:timestamp". In the latest
specs it is "timestamp:username". It has to be updated to support both ways.
Original issue reported on code.google.com by [email protected]
on 8 Jul 2013 at 7:20
According to RFC 5766, the channel messages for TCP and TLS must be padded to
the nearest 4 bytes boundary. This functionality is missed.
Original issue reported on code.google.com by [email protected]
on 4 Jun 2013 at 8:13
Red Hat Enterprise Linux 6.4 / 64- bit i installed the server package.
Install:
$ cd /var/tmp;
wget
https://github.com/downloads/libevent/libevent/libevent-2.0.21-stable.tar.gz;
tar xvfz libevent-2.0.21-stable.tar.gz; cd libevent-2.0.21-stable; ./configure;
make; make install;
wget http://rfc5766-turn-server.googlecode.com/files/turnserver-1.8.6.3.tar.gz
; tar xvfz turnserver-1.8.6.3.tar.gz; cd turnserver-1.8.6.3; ./configure; make;
make install;
/var/tmp/turnserver-1.8.6.3/bin/turnserver;
Run:
[root@ip-10-59-143-73 stund]# export
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib/;
PATH="bin:../bin:../../bin:${PATH}" turnserver -L 176.34.x.x -a -b
/usr/local/etc/turnuserdb.conf -f -r 176.34.x.x
1371111272: RFC 5389/5766/5780/6062/6156 STUN/TURN Server, version
Citrix-1.8.6.3 'Black Dow'
1371111272: Config file found: /usr/local/etc/turnserver.conf
1371111272: Listener address to use: 176.34.x.x
1371111272: Config file found: /usr/local/etc/turnserver.conf
1371111272: WARNING: cannot find certificate file: turn_server_cert.pem (1)
1371111272: WARNING: cannot start TLS and DTLS listeners because certificate
file is not set properly
1371111272: WARNING: cannot find private key file: turn_server_pkey.pem (1)
1371111272: WARNING: cannot start TLS and DTLS listeners because private key
file is not set properly
1371111272: Relay address to use: 176.34.x.x
1371111272: IO method (listener thread): epoll
1371111272: WARNING: I cannot start alternative services of RFC 5780 because
only one IP address is provided
1371111272: IO method: epoll
1371111272: IPv4. UDP listener opened on : 0.0.0.0:0
1371111272: IPv4. TCP listener opened on : 0.0.0.0:39227
1371111272: IO method (auth thread): epoll
1371111272: IO method (relay thread): epoll
But when TURN/STUN client is trying to connect it does not show any kind of log
what is happening weather its working or not.
Is there any turn/stun client script with (python/perl/bash) just to test
remotely if the stun/turn server is working correctly?
Original issue reported on code.google.com by [email protected]
on 13 Jun 2013 at 8:43
If an error is returned from the server in "classic" STUN operation, it is
formatted as if the modern RFC 5389 was used.
Original issue reported on code.google.com by [email protected]
on 3 Aug 2013 at 6:19
We support UDP, TCP, TLS, DTLS protocols on client-to-TURN side (as in RFC
5766) but on the relay side only UDP is supported (again, as required by RFC
5766). But our goal, eventually, is no support TCP on the relay side, too, as
dscribed in RFC 6062.
Original issue reported on code.google.com by [email protected]
on 3 Mar 2013 at 7:46
What steps will reproduce the problem?
1. install turn server 1.8.4.0
2. edit /etc/turnserver.conf with followins:-
no-stdout-log
log-file=/var/tmp/turn.log
#syslog
3. start server with command:
$ turnserver
What is the expected output?
no output in the console
messages logs in the log file
What do you see instead?
the log printed in the console
log file created under /var/tmp with empty.
What version of the product are you using? On what operating system?
turnserver 1.8.4.0, ubuntu 12.04-64
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 16 May 2013 at 8:43
If symbol {"} is involved, then the value is not getting parsed properly.
Original issue reported on code.google.com by [email protected]
on 26 May 2013 at 6:16
We use libnice to test with rfc5766-turn-server, libnice failed to parse the
classic-stun bin response.
After capture the packets, we found the id of bind response is different from
bind request.
What steps will reproduce the problem?
1. setup rfc5766-turn-server
2. run simple-example from libnice package
3. failed to get the srvflx address
What is the expected output? What do you see instead?
Got srvflx
What version of the product are you using? On what operating system?
rfc5766-turn-server --> 2.5.1.2
libnice --> 0.1.4
Please provide any additional information below.
See the attached wireshark packets.
Original issue reported on code.google.com by [email protected]
on 2 Aug 2013 at 7:58
Attachments:
Currently the timestamp in the ephemeral username is the time at which that
username was created. This means that both the web service creating the
username and the TURN server have to be independently configured with the same
TTL for everything to work as expected.
I think it would make more sense to put the expiry timestamp in the username,
so the TURN server just needs to check whether it is in the past. The web
service is the only component that needs to be configured with the TTL, so
you're less likely to see unexpected behaviour due to misconfiguration.
Original issue reported on code.google.com by [email protected]
on 4 Jun 2013 at 3:45
John Selbie reported:
=====================================
I am contributing a patch to the 1.8.3.4 source tree that will allow the client
program from the Stuntman source to make STUN binding requests to your server.
Here's the gist of the change. Stuntman comes with a STUN client library and
client program. The client program displays the mapped IP address and port if
it gets back a successful binding response. It also interops with JSTUN, a
Java implementation of STUN. However, the JSTUN server refuses to respond to
any binding request that doesn't have a CHANGE-REQUEST attribute in it. I had
previous contacted the developer of that code base about the issue, but he
didn't respond back. So the only workaround is for the client to make a
request with an empty CHANGE-REQUEST attribute (neither the ip or port bit are
set).
I can see in the code you don't explicitly support the CHANGE-REQUEST attribute
unless RFC 5780 mode is turned on. Otherwise, an error response is sent back.
And it doesn't appear that is an option for the user to enable this yet. So
the patch I'm providing allows the code to reasonably accept an EMPTY
CHANGE-REQUEST attributes, while rejecting anything else.
======================================================
Original issue reported on code.google.com by [email protected]
on 1 May 2013 at 5:39
Attachments:
Stale Nonce functionality code has typo and has to be fixed
Original issue reported on code.google.com by [email protected]
on 25 Apr 2013 at 8:46
Currently the TURN server requires that TCP and TLS listeners are having
different ports, with the default values as in RFC5766. But the WebRTC may
require that both are running on the same port.
Original issue reported on code.google.com by [email protected]
on 2 May 2013 at 9:47
Microsoft Lync includes a Microsoft TURN server promoted under the name "Edge"
server.
Some clients (e.g. Polycom phones with new firmware) claim to be limited to
work only with the Microsoft permutation of ICE/STUN/TURN rather than the IETF
official version.
Are you aware of how Microsoft's variation of the protocol differs? E.g. does
it use Microsoft authentication hashes rather than md5(A1) style hashes or are
there more obscure differences?
Does this project make any effort to support such clients and potentially relay
calls from a WebRTC client to a Microsoft-style client?
Original issue reported on code.google.com by [email protected]
on 6 Jun 2013 at 2:24
Need to add ability to set TCP connection timeout
Now it's 30 seconds and after that client will be disconnected from server
looks like it's #define TURN_MAX_TO_ALLOCATE_TIMEOUT (30) param in
ns_turn_server.c
Original issue reported on code.google.com by [email protected]
on 11 May 2013 at 10:53
What steps will reproduce the problem?
I deployed turnserver in one of my machine(192.168.11.53). When I tried with
the buildin tool
turnutils_stunclient 192.168.11.53
I can get the response successfully. (see the No.3 message in the attached file)
I setup a softphone(xlite) in another machine(192.168.11.188) with stun
configuration.
When the turnserve received the request, no response will be send back. (See
the No.13 message in the attached file)
Is that means turnserver doesn't support the classic stun message.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 17 May 2013 at 3:28
Attachments:
why delete my issue????
Original issue reported on code.google.com by [email protected]
on 17 Jul 2013 at 12:33
The timestamp never expires.
Original issue reported on code.google.com by [email protected]
on 5 Apr 2013 at 9:16
If you do not set permissions to any peer, you will still be receiving packets
from the peer. Those packets must be rejected. Found by Roman Lisagor.
Original issue reported on code.google.com by [email protected]
on 5 Jun 2013 at 11:53
With thousands live UDP connections, the common UDP stack implementation (like
one in vanilla Linux kernel) may handle the UDP packets inefficiently. The
existing model is very scalable for the TCP, but UDP requires a different
approach.
Original issue reported on code.google.com by [email protected]
on 13 Jul 2013 at 1:08
I want to support STUN CHANGE_REQUEST,how should i do?
must hava a server which has two net cards,
and set different public ip to them?
thanks
Original issue reported on code.google.com by [email protected]
on 16 Jul 2013 at 11:29
What steps will reproduce the problem?
1. Launch turnserver with the parameters below (on Ubuntu 12.10, running on
Azure)
2. Try to establish a WebRTC connection between two browsers ith Chrome 25.
What is the expected output? What do you see instead?
As soon as the browsers try to connect, the turnserver process exits with a
"segmentation fault".
What version of the product are you using? On what operating system?
Version Citrix-1.6.1.2, newly built from the svn repo.
Please provide any additional information below.
Here's the log file:
Administrator@alantaux1:/usr/local/bin$ turnserver -r alanta.com -X
168.61.73.72 --no-tls --no-dtls -a -b turnuserdb.co
nf -f -u [email protected]:password -v
RFC 5389/5766/6062/6156 STUN/TURN Server, version Citrix-1.6.1.2 'Whirrun'
File found: ../etc/turnserver.conf
File found: ../etc/turnserver.conf
File found: ../etc/turnuserdb.conf
===========Discovering listener addresses: =========
Listener address to use: 127.0.0.1
Listener address to use: 100.68.58.111
Listener address to use: ::1
=====================================================
===========Discovering relay addresses: =============
Relay address to use: 100.68.58.111
=====================================================
IO method (listener thread): epoll
create_server_socket:209:start
IPv4. UDP listener opened on : 127.0.0.1:3478
create_server_socket:243:end
create_server_socket:209:start
IPv4. UDP listener opened on : 127.0.0.1:3479
create_server_socket:243:end
create_server_listener:130:start
IPv4. TCP listener opened on : 127.0.0.1:3478
create_server_listener:168:end
create_server_listener:130:start
IPv4. TCP listener opened on : 127.0.0.1:3479
create_server_listener:168:end
create_server_socket:209:start
IPv4. UDP listener opened on : 100.68.58.111:3478
create_server_socket:243:end
create_server_socket:209:start
IPv4. UDP listener opened on : 100.68.58.111:3479
create_server_socket:243:end
create_server_listener:130:start
IPv4. TCP listener opened on : 100.68.58.111:3478
create_server_listener:168:end
create_server_listener:130:start
IPv4. TCP listener opened on : 100.68.58.111:3479
create_server_listener:168:end
create_server_socket:209:start
IPv6. UDP listener opened on : ::1:3478
create_server_socket:243:end
create_server_socket:209:start
IPv6. UDP listener opened on : ::1:3479
create_server_socket:243:end
create_server_listener:130:start
IPv6. TCP listener opened on : ::1:3478
create_server_listener:168:end
create_server_listener:130:start
IPv6. TCP listener opened on : ::1:3479
create_server_listener:168:end
IO method (auth thread): epoll
run_listener_server: cycle=1, stats=0
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
server_input_handler:76:start
open_client_connection_socket:161:start
open_client_connection_socket: AF: 2:2
Binding socket 24 to addr
IPv4. Bind to: 100.68.58.111:3478
IPv4. UDP connected to: 98.247.37.95:59370
open_client_connection_socket:202:end
Segmentation fault (core dumped)
Please let me know if I can do anything to provide troubleshooting help.
Original issue reported on code.google.com by [email protected]
on 22 Mar 2013 at 3:43
Wor security reasons, the user must be able to disallow multicast and/or
loopback peer addresses,
Original issue reported on code.google.com by [email protected]
on 8 May 2013 at 1:38
Current implementation handles UDP in multuthreaded way and TCP in single
thread. It has to be improved.
Original issue reported on code.google.com by [email protected]
on 8 Jul 2013 at 7:21
Cygwin is not supported
Original issue reported on code.google.com by [email protected]
on 14 Apr 2013 at 7:15
Lots of things are missed in general installation procedure. In FreeBSD port,
somethings are missed, too.
Original issue reported on code.google.com by [email protected]
on 28 Apr 2013 at 7:21
What steps will reproduce the problem?
1.Set log to verbose
2.
3.
What is the expected output? What do you see instead?
I would like to see time stamps on each log line
I would like a log level between verbose and normal, perhaps without the
regular "timer_event_handler: timeout"
What version of the product are you using? On what operating system?
1.8.1 Ubuntu 12.04
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 9 Apr 2013 at 3:03
The server that just returns 300 ALTERNATE-SERVER response, requires
authentication in pretty much the same way as the "real" server. This is
allowed by the RFC 5389, but this is unnecessary and it may complicate the
setup.
Original issue reported on code.google.com by [email protected]
on 6 Aug 2013 at 5:55
What steps will reproduce the problem?
1. Open Cygwin terminal
2. cd \
3. tar xvfz turnserver-1.8.7.0.tar.gz, works fine
4. ./configure, works fine
5. make, got an error
What is the expected output? What do you see instead?
It should install successfully. Instead, I am getting error -
src/client/ns_turn_ioaddr.c:169:13:error 'struct_sockaddr_in' has no member
named 'sin_len'
What version of the product are you using? On what operating system?
Turn server 1.8.7.0
Windows 7, 64 bit
cygwin
Original issue reported on code.google.com by [email protected]
on 4 Jul 2013 at 11:01
Attachments:
uclient tries to bind the same channel multiple times. This fails with some
turn servers as restund.
uclient uses RTCP port instead of RTP port when you run it without RTCP.
Patch attached.
Original issue reported on code.google.com by [email protected]
on 27 Mar 2013 at 5:20
Attachments:
If multiple DTLS sessions are trying to connect to the server simultaneously,
it may crash. It is recommended to use --no-dtls option, for security, till the
bug is fixed. The bug will be fixed in the next build.
Original issue reported on code.google.com by [email protected]
on 22 Jul 2013 at 2:45
What steps will reproduce the problem?
1. Compile and install application v 1.4.2.4
2. Run
3.
What is the expected output? What do you see instead?
Expect initialize and run.
Segfaults after initialization messages
Ran under debugger and saw that it is crashing on enumerating listeners
Program received signal SIGSEGV, Segmentation fault.
0x000000000040a1f0 in make_local_listeners_list ()
What version of the product are you using? On what operating system?
1.4.2.4
Ubuntu 12.10 (GNU/Linux 3.6.4-xenU x86_64)
Please provide any additional information below.
If V4 IP addresses are specified app initializes OK.
Original issue reported on code.google.com by [email protected]
on 13 Jan 2013 at 6:58
DTLS sockets are not handling the network errors properly
Original issue reported on code.google.com by [email protected]
on 20 Jul 2013 at 8:46
Currently on Cygwin platform we support only single threaded processing. It has
to be improved.
Original issue reported on code.google.com by [email protected]
on 22 Jul 2013 at 3:04
First of all, let me thank you for excellent tool and great docs. This is just
an enhancement request for better log control.
What steps will reproduce the problem?
1. run turnserver with any config
2. output log will go to turnserver_<pid>.log file into uncertain folder and in
uncontrolled fashion.
What is the expected output? What do you see instead?
* would be nice to have config option
What version of the product are you using? On what operating system?
* turnserver-1.7.2.0
* Ubuntu 12.04.2
Please provide any additional information below.
* not critical for me at the moment since I just commented out all the code
which uses _rtpfile.
* in my case looking only for stdout output since turnserver going to be
executed under supervisor (http://supervisord.org/) and all stdout will be
redirected to supervisor controlled location with graceful file rolling and
size limitation.
Original issue reported on code.google.com by [email protected]
on 30 Mar 2013 at 8:22
In media communications, it is RECOMMENDED that all UDP network packets are
sized below MTU. But this is NOT REQUIRED, and the RFC 5766 is not requiring
that, and not enforcing that. But the TURN Server rfc5766-turn-server
unnecessary enforces this requirement: all client-facing UDP sockets have
dont-fragment flag set to 1. This means that the TURN Server will not relay
the packets which have size more than MTU.
Original issue reported on code.google.com by [email protected]
on 9 Jun 2013 at 2:20
What steps will reproduce the problem?
1. Download turnserver-1.5.2.6
2. ./configure
3. make
What is the expected output?
Built turnserver
What do you see instead?
/usr/bin/ld: note: 'clock_gettime@@GLIBC_2.2.5' is defined in DSO
/lib64/librt.so.1 so try adding it to the linker command line
/lib64/librt.so.1: could not read symbols: Invalid operation
What version of the product are you using? On what operating system?
turnserver-1.5.2.6
Amazon linux 2012.09
Please provide any additional information below.
Adding '-lrt' to CFLAGS resolves the issue.
Original issue reported on code.google.com by [email protected]
on 27 Feb 2013 at 7:45
What steps will reproduce the problem?
$ turnserver -c
What is the expected output? What do you see instead?
Expected is a help text. But it produces a crash.
Reported by John Selbie.
Original issue reported on code.google.com by [email protected]
on 12 May 2013 at 4:17
What steps will reproduce the problem?
1.Start turnserver with log to file rather than stdout option.
2.Do "ls -l /var/log/turn*" to display log file(s).
3.
What is the expected output? What do you see instead?
Log file should be closed/re-opened every 24 hours with name that includes date.
The turnserver keeps logging to the same log file forever, requiring a
start/stop to change log files, and name includes process ID rather than date.
What version of the product are you using? On what operating system?
turnserver-1.8.1.1
Ubuntu 12.04.1
Please provide any additional information below.
Log files older than yesterday should be compressed (like syslog).
Original issue reported on code.google.com by [email protected]
on 22 Apr 2013 at 11:35
What steps will reproduce the problem?
1. Use Google Chrome to establish WebRTC session
2. Use the "?transport=tcp" flag while configuring the TURN Server in the
client JS
What is the expected output? What do you see instead?
1. Communication from the client (google chrome [v. 25.0.1364.172 m] should be
in TCP and not in UDP
2. I see that the communication is still in UDP.
The main issue is that if OUTBOUND UDP is blocked, there is no way to establish
WebRTC communication between peers (no STUN RESOLUTION). We need to have a TCP
fallback.
What version of the product are you using? On what operating system?
win 7, Google chrome 25. turn server 1.6.0.1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 19 Mar 2013 at 4:31
PJNATH performs padding even for UDp channels. This is not usual, but it is
allowed per RFC 5766. We do not support padding and the traffic may be
incompatible.
Original issue reported on code.google.com by [email protected]
on 4 Jun 2013 at 8:15
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.