turnserver-devel — Discussions on development of TurnServer

Re: [Turnserver-devel] Need clarification related to permissions w.r.t TurnServer

[sthustfo <sth...@gm...>]

Hi Sebastien,

Thanks for pointing out the mail discussion. I believe that ChannelBind must
deal only with each channel and CreatePermission deal only with permission.
But anyway, the spec is already adopted as a standard.

This behavior in the spec throws up ambiguity at the TURN client end. Having
ChannelBind refresh both the channel and permission does not add any value
as it is. This is because the permission expires every 5 mins and each
channel expires at 10 min. So this means, the TURN client will have to
refresh the permission anyway every 5 mins by sending CreatePermission. And
in order to keep the channel alive, the TURN client has to send ChannelBind
every 10 mins. So I am not sure what is the gain my having this ambiguity in
the spec - that ChannelBind refreshes both the permission and chanel.

I think if we wanted to keep this aspect in the spec, we could have
approached it in another way. By having 10 mins for permissions and 5 mins
for Channels.

The TURNserver must have been involved in many of inter ops with other TURN
clients. How many of them use only channels to manage both the permissions
and channels? That is use, ChannelBind to create permissions and refresh and
also use ChannelBind to install channel? Actually I was hesitant whether to
really put in my views here on the spec's ambiguity, but decided to anyway.
[Hence the delay in the response].

Thanks for hearing me out. Let me know if I am missing anything.



On Mon, Jun 27, 2011 at 1:24 PM, Sebastien Vincent <se...@ji...> wrote:

> Hi,
>
> Sorry for late answer.
>
> I suggest you read the following links (http://www.ietf.org/mail-**
> archive/web/behave/current/**msg04374.html<http://www.ietf.org/mail-archive/web/behave/current/msg04374.html>).
> In short it was decided sometime ago to avoid possible race conditions.
>
> --
> Seb
>
>
>
> Hi all,
>
> I am developing a turn client and using turnserver for testing and
> verification. I have come across an issue in the turn RFC 5766 related
> to permissions and need a clarification. Please clarify how this is
> handled in the turnserver. Also please correct me if I am missing
> something in my interpretation of the spec.
>
> The spec says that (section 8) the client can install or refresh
> permissions using either the CreatePermission request or the
> ChannelBind request. And the permission lifetime is 5 minutes.
>
> Similarly section 11 mentions that a channel binding lasts for 10
> minutes unless refreshed.
>
> Now, here is the problem I am encountering. Now suppose the turn
> client creates an allocation, installs a permission using
> CreatePermission request. TurnServer starts a timer for 5 minutes. And
> then Turn client binds a channel using ChannelBind request. At this
> time, the TurnServer will reset the permission back to 5 minutes
> because of the just received ChannelBind request which refreshes the
> permission. Turn client will start a timer for<10 minutes assuming
> the permission is for 10 minutes.
>
> After 5 minutes, the permission at the TurnServer expires, which is
> not what the turn client wanted.
>
> If the duration of permission is 5 minutes, then why is the duration
> of ChannelBind refresh 10 minutes? This will always result in the
> permissions at the TurnServer expiring well before the Turn client
> refreshes it.
>
> I hope I am not missing anything in the interpretation of the spec
> here. Please state how does the TurnServer behave in this scenario. Do
> correct me if wrong.
>
> Thanks in advance.
>
>

Re: [Turnserver-devel] Need clarification related to permissions w.r.t TurnServer

[Sebastien V. <se...@ji...>]

Hi,

Sorry for late answer.

I suggest you read the following links (http://www.ietf.org/mail-archive/web/behave/current/msg04374.html). In short it was decided sometime ago to avoid possible race conditions.

--
Seb


Hi all,

I am developing a turn client and using turnserver for testing and
verification. I have come across an issue in the turn RFC 5766 related
to permissions and need a clarification. Please clarify how this is
handled in the turnserver. Also please correct me if I am missing
something in my interpretation of the spec.

The spec says that (section 8) the client can install or refresh
permissions using either the CreatePermission request or the
ChannelBind request. And the permission lifetime is 5 minutes.

Similarly section 11 mentions that a channel binding lasts for 10
minutes unless refreshed.

Now, here is the problem I am encountering. Now suppose the turn
client creates an allocation, installs a permission using
CreatePermission request. TurnServer starts a timer for 5 minutes. And
then Turn client binds a channel using ChannelBind request. At this
time, the TurnServer will reset the permission back to 5 minutes
because of the just received ChannelBind request which refreshes the
permission. Turn client will start a timer for<10 minutes assuming
the permission is for 10 minutes.

After 5 minutes, the permission at the TurnServer expires, which is
not what the turn client wanted.

If the duration of permission is 5 minutes, then why is the duration
of ChannelBind refresh 10 minutes? This will always result in the
permissions at the TurnServer expiring well before the Turn client
refreshes it.

I hope I am not missing anything in the interpretation of the spec
here. Please state how does the TurnServer behave in this scenario. Do
correct me if wrong.

Thanks in advance.

[Turnserver-devel] Need clarification related to permissions w.r.t TurnServer

[sthustfo <sth...@gm...>]

Hi all,

I am developing a turn client and using turnserver for testing and
verification. I have come across an issue in the turn RFC 5766 related
to permissions and need a clarification. Please clarify how this is
handled in the turnserver. Also please correct me if I am missing
something in my interpretation of the spec.

The spec says that (section 8) the client can install or refresh
permissions using either the CreatePermission request or the
ChannelBind request. And the permission lifetime is 5 minutes.

Similarly section 11 mentions that a channel binding lasts for 10
minutes unless refreshed.

Now, here is the problem I am encountering. Now suppose the turn
client creates an allocation, installs a permission using
CreatePermission request. TurnServer starts a timer for 5 minutes. And
then Turn client binds a channel using ChannelBind request. At this
time, the TurnServer will reset the permission back to 5 minutes
because of the just received ChannelBind request which refreshes the
permission. Turn client will start a timer for <10 minutes assuming
the permission is for 10 minutes.

After 5 minutes, the permission at the TurnServer expires, which is
not what the turn client wanted.

If the duration of permission is 5 minutes, then why is the duration
of ChannelBind refresh 10 minutes? This will always result in the
permissions at the TurnServer expiring well before the Turn client
refreshes it.

I hope I am not missing anything in the interpretation of the spec
here. Please state how does the TurnServer behave in this scenario. Do
correct me if wrong.

Thanks in advance.

Re: [Turnserver-devel] No voice for some time

[Sebastien V. <se...@ji...>]

Hi Yves,

It seems that X-lite does not support the TURN RFC 5766 (which 
TurnServer implements). Maybe it supports old turn-09 draft (when it 
does not specify to add permissions on channel) but TurnServer does not 
support it anymore.

Can you send us wireshark traces to be sure ?

Regards,
--
Seb

Le 10/05/11 20:57, Yves a écrit :
> Dear Sir / Madam,
>
> I am using TurnServer version 0.4
> The SIP client is x-lite 4.0
>
> Here is the message captured by the wireshark.
>
> STUN Message: Binding Request (the last message repeated many time) ...
> XXX.XXX.XXX.XXX    10.10.0.3    ICMP    Destination unreachable (Port 
> unreachable)
>
>
> At the same time, I run the TurnServer at debug mode. And I got this 
> message.
>
> 02:28:32.027562 [turnserver.c:4230]     Received UDP on a relayed address
> 02:28:32.027578 [turnserver.c:3294]     No permission installed 
> (XXX.XXX.XXX.XXX)
>
> ..... message repeated many time ....
>
> 02:28:32.127629 [turnserver.c:4230]     Received UDP on a relayed address
> 02:28:32.107535 [turnserver.c:3294]     No permission installed 
> (XXX.XXX.XXX.XXX)
>
> I have open the UDP port 3478, UDP port 5060 and UDP port 35000 to 45000.
>
> I even tried to disabled the firewall. However, it is the same.
> I have no idea why I got this ICMP message. Does anyone can tell what 
> is the problem?
> Thanks.
>
> *turnusers.txt*
> demo:testing:demo.com <http://demo.com>
>
> *DEBUG CAPTURE* *
> The ip address are replaced with x.x.x.x*
>
> listen_address = {"x.x.x.x"}
> listen_addressv6 = {}
> udp_port = 3478
> tcp_port = 3478
> tls_port = 5349
> tls = false
> dtls = false
> max_port = 45000
> min_port = 35000
> turn_tcp = false
> tcp_buffer_userspace = true
> tcp_buffer_size = 32768
> daemon = true
> unpriv_user = "turnserver"
> max_client = 50
> max_relay_per_username = 5
> allocation_lifetime = 1800
> nonce_key = "hieKedq"
> ca_file = "./ca.crt"
> cert_file = "./server.crt"
> private_key_file = "./server.key"
>
> realm = "demo.com <http://demo.com>"
> account_method = "file"
> account_file = "/usr/local/etc/turnserver/turnusers.txt"
>
> denied_address { address = "127.0.0.1" mask = 8 port = 0 }
> denied_address { address = "::1" mask = 128 port = 0 }
> bandwidth_per_allocation = 150
> account_db_login = "anonymous"
> account_db_password = "anonymous"
> account_db_name = "turnserver"
> account_db_address = "127.0.0.1"
> account_db_port = 3306
>
> Regards,
> Yves
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

[Turnserver-devel] Helpppp

[Michel F. <mic...@sp...>]

Hello All,

Can anybody help me please?

Regards

[Turnserver-devel] No voice for some time

[Yves <yv...@gm...>]

Dear Sir / Madam,

I am using TurnServer version 0.4
The SIP client is x-lite 4.0

Here is the message captured by the wireshark.

STUN Message: Binding Request (the last message repeated many time) ...
XXX.XXX.XXX.XXX    10.10.0.3    ICMP    Destination unreachable (Port
unreachable)


At the same time, I run the TurnServer at debug mode. And I got this
message.

02:28:32.027562 [turnserver.c:4230]     Received UDP on a relayed address
02:28:32.027578 [turnserver.c:3294]     No permission installed
(XXX.XXX.XXX.XXX)

..... message repeated many time ....

02:28:32.127629 [turnserver.c:4230]     Received UDP on a relayed address
02:28:32.107535 [turnserver.c:3294]     No permission installed
(XXX.XXX.XXX.XXX)

I have open the UDP port 3478, UDP port 5060 and UDP port 35000 to 45000.

I even tried to disabled the firewall. However, it is the same.
I have no idea why I got this ICMP message. Does anyone can tell what is the
problem?
Thanks.

*turnusers.txt*
demo:testing:demo.com

*DEBUG CAPTURE* *
The ip address are replaced with x.x.x.x*

listen_address = {"x.x.x.x"}
listen_addressv6 = {}
udp_port = 3478
tcp_port = 3478
tls_port = 5349
tls = false
dtls = false
max_port = 45000
min_port = 35000
turn_tcp = false
tcp_buffer_userspace = true
tcp_buffer_size = 32768
daemon = true
unpriv_user = "turnserver"
max_client = 50
max_relay_per_username = 5
allocation_lifetime = 1800
nonce_key = "hieKedq"
ca_file = "./ca.crt"
cert_file = "./server.crt"
private_key_file = "./server.key"

realm = "demo.com"
account_method = "file"
account_file = "/usr/local/etc/turnserver/turnusers.txt"

denied_address { address = "127.0.0.1" mask = 8 port = 0 }
denied_address { address = "::1" mask = 128 port = 0 }
bandwidth_per_allocation = 150
account_db_login = "anonymous"
account_db_password = "anonymous"
account_db_name = "turnserver"
account_db_address = "127.0.0.1"
account_db_port = 3306

Regards,
Yves

[Turnserver-devel] UNKNOWN-ATTRIBUTES length bug

[Ryo S. <sat...@gm...>]

Additional patch for UNKNOWN-ATTRIBUTES is attached.

p.39 in rfc5389:
	> In this version of the specification, the normal padding rules
	> for attributes are used instead.

*** trunk/src/protocol.c        2011-03-07 16:48:51.000000000 +0900
--- new/src/protocol.c  2011-03-07 18:59:39.000000000 +0900
***************
*** 563,569 ****
    }

    ret->turn_attr_type = htons(STUN_ATTR_UNKNOWN_ATTRIBUTES);
!   ret->turn_attr_len = htons(len * 2);

    ptr = (uint16_t*)ret->turn_attr_attributes;
    tmp_len = len;
--- 563,569 ----
    }

    ret->turn_attr_type = htons(STUN_ATTR_UNKNOWN_ATTRIBUTES);
!   ret->turn_attr_len = htons(attr_size * 2);

    ptr = (uint16_t*)ret->turn_attr_attributes;
    tmp_len = len;

[Turnserver-devel] byte-order bugs in UNKNOWN-ATTRIBUTES

[Ryo S. <sat...@gm...>]

Hello,

Attached patch contains fixes for byte-order bugs in UNKNOWN-ATTRIBUTES.
This patch is for SVN rev. 186.

There is same problem in turn_attr_create(), fortunately unused.

I seem that 'len > 4' in turn_parse_message() is wrong.

Thank,
Ryo Sato

[Turnserver-devel] Patch for out-of-directory builds

[Jeremy L. <jer...@m4...>]

autoconf/automake supports building outside the source directory (or in a subdirectory) by running the "configure" script from the desired directory. Compiling the C code works just fine, but manpage generation (custom rules in man/Makefile.am) makes assumptions about the location of the input files. The attached patch fixes this.

[Turnserver-devel] turnusers.conf parsing bug in latest SVN

[Youness A. <you...@co...>]

Hi,

I've updated to the latest SVN version of turnserver, and my allocations were 
all returning 401 Unauthorized. I realized that the domain for my users taken 
from /etc/turnusers.conf had a newline in it.
You've introduced the regression in SVN Commit 175 by adding the 'restricted' 
token to the users configuration. You've moved the 'remove newline' code inside 
the 'if(token)' so if a user doesn't have the added ":restricted", then the 
domain is wrong.

Attached is a patch that should fix it. I've moved the 'remove newline' code 
right after the line gets read from the file, so it will work even if new tokens 
get added later on.

Thank you,
Youness.


Index: src/account.c
===================================================================
--- src/account.c	(revision 183)
+++ src/account.c	(working copy)
@@ -168,6 +168,13 @@
        continue;
      }

+    /* replace end of line by NULL character */
+    save_ptr = strchr(line, '\n');
+    if(save_ptr)
+    {
+      *save_ptr = 0x00;
+    }
+
      token = strtok_r(line, delim, &save_ptr);
      if(!token)
      {
@@ -196,13 +203,6 @@

      if(token)
      {
-      /* replace end of line by NULL character */
-      save_ptr = strchr(token, '\n');
-      if(save_ptr)
-      {
-        *save_ptr = 0x00;
-      }
-
        if(!strcmp(token, "authorized"))
        {
          state = AUTHORIZED;

[Turnserver-devel] Issue with listen_address configuration

[Youness A. <you...@co...>]

Hi,

I've been testing TURN RFC5766 support in libnice, and I realized that the way 
turnserver configuration was designed was flawed with regards to 'listen_address'.

You recently(?) added the possibility to specify a list of IP addresses to 
listen_address in turnserver.conf.
What behavior one would expect is that turnserver listens on those IP addresses, 
but that's not what actually happens.
It's also expected that if you set both listen_address and listen_address6, it 
would bind on both ipv4 and ipv6 addresses, but it doesn't do that (from reading 
the code, I didn't actually test it).

First, from the code, it looks like you listen to either "::" or "0.0.0.0" 
depending on whether or not the listen_address6 is defined. This is wrong 
because you should listen on both ipv4 and ipv6 if both are defined, but also, 
because you should listen on the addresses specified by the listen_address 
values, not bind on all interfaces.
Another thing that I think is wrong is that the configuration shouldn't even 
make us specify the IP to listen to, instead, we should specify the interface to 
listen to, because the IP address can change and you don't want to reconfigure 
the server everytime it does.
I understand that turnserver's users are mostly servers with static IPs, but I 
do development using it on a laptop that moves constantly, and it's not only 
annoying, but it's also not a 'normal' behavior if I may say so.

Now the biggest problem I have is that the list of IP addresses in there aren't 
just "addresses to listen on", the algorithm you use when you receive an 
allocation request is like this :
allocate_request:
     get listen_address
     choose a *random* address in the list
     create a socket with that address

so you basically take a random IP address in that list, and try to allocate the 
request on it. Which may or may not fail (and if it fails, you retry 5 times but 
using always the same address previously selected)...
I noticed this when I was testing something locally, and I didn't realize that 
my turnserver.conf had two IP addresses listed for listen_address, one of which 
was invalid (no interface was bound to that IP). So I would send 4 allocate 
request, and they either all succeed, or all fail or a random number of 
allocations would succeed and the others would fail with error 500.
That's what prompted me to jump into the code to figure this out.

The correct behavior should be that the IP to listen to should be the same as 
the IP from which we received the allocation request. So the algorithm should be :
allocate_request(sock, message, saddr, ...):
     if local address of the socket that received \
      the request (saddr) is in listen_address: then
           create a socket with that address

I believe that this way, the result would be much better, with a behavior that 
is more expected and that I believe everyone will be happy with.

Let me know what you think.

Thanks for reading,
Youness.

Re: [Turnserver-devel] Linking error

[Sebastien V. <seb...@tu...>]

Hi Youness,

Thanks for the patch!

It has been included in SVN trunk repository (revision 183).

Regards,
--
Seb

Le 07/01/2011 05:55, Youness Alaoui a écrit :
> Hi,
>
> I'm currently on Fedora 14 and turnserver 0.4 does not build correctly on it.
> The error is at link time and it gives me :
>
> /usr/bin/ld: tls_peer.o: undefined reference to symbol 'ERR_reason_error_string'
> /usr/bin/ld: note: 'ERR_reason_error_string' is defined in DSO
> /lib/libcrypto.so.10 so try adding it to the linker command line
> /lib/libcrypto.so.10: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
>
> After a bit of googling, I found this explanation here :
> http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
>
> To fix it, I just had to add
> AC_CHECK_LIB(crypto, ERR_reason_error_string,,[echo -e "\tPlease install
> libssl-dev";exit])
> in the configure.ac, right after
> AC_CHECK_LIB(ssl, SSL_new,,[echo -e "\tPlease install libssl-dev";exit])
>
> This way, it will link with -lcrypto
> Let me know if you want an actual patch to apply or this one-line change is fine.
>
> Thanks for patching it for the next version!
> Youness.
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel
>    

[Turnserver-devel] Linking error

[Youness A. <you...@co...>]

Hi,

I'm currently on Fedora 14 and turnserver 0.4 does not build correctly on it. 
The error is at link time and it gives me :

/usr/bin/ld: tls_peer.o: undefined reference to symbol 'ERR_reason_error_string'
/usr/bin/ld: note: 'ERR_reason_error_string' is defined in DSO 
/lib/libcrypto.so.10 so try adding it to the linker command line
/lib/libcrypto.so.10: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

After a bit of googling, I found this explanation here :
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange

To fix it, I just had to add
AC_CHECK_LIB(crypto, ERR_reason_error_string,,[echo -e "\tPlease install 
libssl-dev";exit])
in the configure.ac, right after
AC_CHECK_LIB(ssl, SSL_new,,[echo -e "\tPlease install libssl-dev";exit])

This way, it will link with -lcrypto
Let me know if you want an actual patch to apply or this one-line change is fine.

Thanks for patching it for the next version!
Youness.

Re: [Turnserver-devel] Problem with deleting allocations

[Sebastien V. <seb...@tu...>]

Hello Ryo,

Thank you for pointing that.

After a brief look at turnserver code, I think it is safe to not use the 
block/unblock and just use the timer_settime(timerid, 0). Normally after 
setting timer's time to 0 signal should not be sent and as I remove the 
pointer from the expired list right after, the removed allocation will 
not be deleted twice.

I will do some tests with these modifications to see if all work as it 
should.

Regards,
--
Seb


Le 27/12/2010 10:13, Ryo Sato a écrit :
> Hello,
>
> The signal-handler might be called after refreshing a allocation with
> LIFETIME=0.
> See attached the sample source and the result.
>
> OS: Debian 5.0.7
> kernel: Linux turnserver 2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC
> 2010 i686 GNU/Linux
>
> ---
> $ ./posix_timer
> 0
> Create signal(144371720)
> Set timer(3)
> 1
> Create signal(144371736)
> Set timer(3)
> 2
> Block signal
> 3
> 4
> 5
> Set timer(0)
> Delete signal(144371736)
> 6
> Unblock signal
> Realtime signal received
> Realtime signal received<-- !!
> 7
> 8
> ---
>
> Thanks,
> Ryo Sato
>    
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel
>    

[Turnserver-devel] Problem with deleting allocations

[Ryo S. <sat...@gm...>]

Hello,

The signal-handler might be called after refreshing a allocation with
LIFETIME=0.
See attached the sample source and the result.

OS: Debian 5.0.7
kernel: Linux turnserver 2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC
2010 i686 GNU/Linux

---
$ ./posix_timer
0
Create signal(144371720)
Set timer(3)
1
Create signal(144371736)
Set timer(3)
2
Block signal
3
4
5
Set timer(0)
Delete signal(144371736)
6
Unblock signal
Realtime signal received
Realtime signal received   <-- !!
7
8
---

Thanks,
Ryo Sato

[Turnserver-devel] RFC 6062

[Sebastien V. <seb...@tu...>]

Hi,

As you may noticed, the draft "Traversal Using Relays around NAT (TURN) 
Extensions for TCP Allocations" has been released as the RFC6062 
(http://www.rfc-editor.org/rfc/rfc6062.txt).

Of course, TurnServer supports TCP relay allocation for some months. So 
as RFC is out now, if some of you are aware of or are doing a 
open-source "client" TURN-TCP implementation please let me now so that I 
can perform some interroperability tests.

Regards,
--
Sebastien Vincent

[Turnserver-devel] TurnServer 0.4 release

[Sebastien V. <seb...@tu...>]

Hi all,

TURN protocol has finally been published as RFC (RFC 5766) and version 
0.4 of TurnServer is available right now!

TURN-TCP support has been integrated into this release (but disabled by 
default). A brand new multiprotocol (UDP/TCP/TLS/DTLS) TURN client 
example has replaced the old test_turn_tcp/udp/tls/dtls examples. This 
client example can even be compiled on Microsoft Windows (MinGW and 
Visual Studio).

Link to download: 
https://sourceforge.net/projects/turnserver/files/turnserver-0.4.tar.bz2/download

Best regards,
--
Sebastien Vincent

Re: [Turnserver-devel] Confusion on Turn Protocol and TurnServer

[Sumit G. <gam...@gm...>]

Hello,

Thanks for your replies. So if I understand correctly TurnServer doesn't
have ICE implementation. Also, I understand that we cannot use any on
Technique for communication, and we have to HIT and try from Direct IP
connection to Stun or TURN etc. 
Do anyone of you know a Library that already does this, I mean I have seen
that likes of Bitorrent and Skype or Yahoo or MSN works from almost all
computer without any setting on their NAT router[symmetric NAT]. I have
Symmetric NAT at my development place. I understand Yahoo/Skype/MSN does it
well, but I wonder how Bitorrent goes fine, as they cannot use TURN for
obvious reason as otherwise they won't be Torrents if they rely. 

Maybe I miss a concept here again. But I really miss TurnServer
implementation as my project need is not to RELAY through Server as client
is not willing to pay for server bandwidth.

With Regards,
Sumit Gupta

-----Original Message-----
From: Justin Karneges [mailto:ju...@af...] 
Sent: 06 April 2010 22:00
To: tur...@li...; seb...@cp...
Cc: Sumit Gupta
Subject: Re: [Turnserver-devel] Confusion on Turn Protocol and TurnServer

On Tuesday 06 April 2010 08:52:13 Sebastien Vincent wrote:
> Sumit Gupta a écrit :
> > Also now I understand that ICE is what does the direct connection and
> > if this fails then only we should go for TURN technique of relay. So
> > my Question is :
> >
> > 1. My understand about TURN is right ?
>
> Yes. TURN is used only at last resort if both peers cannot have a P2P
> connection (like for example when they are behind a symmetrical
> NAT/firewall).

Small clarification: Fallback to TURN is part of ICE.  Sumit writes, "ICE is

what does the direct connection and if this fails then we should go for 
TURN", but actually ICE encapsulates both direct (STUN) and relayed (TURN) 
mechanisms into a single protocol.  If ICE fails there is no fallback. ;)

-Justin

Re: [Turnserver-devel] Confusion on Turn Protocol and TurnServer

[Justin K. <ju...@af...>]

On Tuesday 06 April 2010 08:52:13 Sebastien Vincent wrote:
> Sumit Gupta a écrit :
> > Also now I understand that ICE is what does the direct connection and
> > if this fails then only we should go for TURN technique of relay. So
> > my Question is :
> >
> > 1. My understand about TURN is right ?
>
> Yes. TURN is used only at last resort if both peers cannot have a P2P
> connection (like for example when they are behind a symmetrical
> NAT/firewall).

Small clarification: Fallback to TURN is part of ICE.  Sumit writes, "ICE is 
what does the direct connection and if this fails then we should go for 
TURN", but actually ICE encapsulates both direct (STUN) and relayed (TURN) 
mechanisms into a single protocol.  If ICE fails there is no fallback. ;)

-Justin

Re: [Turnserver-devel] Confusion on Turn Protocol and TurnServer

[Sebastien V. <seb...@cp...>]

Sumit Gupta a écrit :
>
> Hello,
>
> I am having a slight confusion, that totally put me on my development. 
> I am working on Peer to Peer application, and for this I need to make 
> a Direction connection between peers. On my search I found that STUN 
> is the way to find the Peer address through hole punching. And Turn 
> Servers are above STUN in manner that if hole punching fails they find 
> Peer IP using different techniques. Now as I am learning more about 
> Turn Implementation, I found that TURN actually does the RELY of 
> Packet between peers. So, if that is true then it won’t work for my 
> application, as I need to do Direct connection between clients only. I 
> though using Turn I can control the Port/IP combination and do the 
> transfer of actual data Directly.
>
> Also now I understand that ICE is what does the direct connection and 
> if this fails then only we should go for TURN technique of relay. So 
> my Question is :
>
> 1. My understand about TURN is right ?
>

Yes. TURN is used only at last resort if both peers cannot have a P2P 
connection (like for example when they are behind a symmetrical 
NAT/firewall).

> 2. Irrespective of Question 1, Can I use Turn Server [by S. Vincent] 
> to do what I need, that is does it do the ICE before it goes for TURN 
> concept? If it does, then it is good for me, but if it doesn’t how can 
> I get around the problem?
>

TurnServer is only the server part of TURN protocol (OK there are some 
client examples...). For your needs (have a direct connection) you 
should use ICE on clients. I don't know ICE stack in C# but in C you 
have PJSIP and libnice which implements STUN, TURN and ICE. TURN can be 
used with ICE but in this case you have to setup a TURN server somewhere 
on the internet.

Regards,
--
Sebastien


> Any help is appreciated.
>
> Thanks & Regards,
>
> Sumit Gupta
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ------------------------------------------------------------------------
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel
>   

[Turnserver-devel] Confusion on Turn Protocol and TurnServer

[Sumit G. <gam...@gm...>]

Hello,

 

I am having a slight confusion, that totally put me on my development. I am
working on Peer to Peer application, and for this I need to make a Direction
connection between peers. On my search I found that STUN is the way to find
the Peer address through hole punching. And Turn Servers are above STUN in
manner that if hole punching fails they find Peer IP using different
techniques. Now as I am learning more about Turn Implementation, I found
that TURN actually does the RELY of Packet between peers. So, if that is
true then it won't work for my application, as I need to do Direct
connection between clients only. I though using Turn I can control the
Port/IP combination and do the transfer of actual data Directly. 

 

Also now I understand that ICE is what does the direct connection and if
this fails then only we should go for TURN technique of relay. So my
Question is :

 

1.       My understand about TURN is right ?

2.       Irrespective of Question 1, Can I use Turn Server [by S. Vincent]
to do what I need, that is does it do the ICE before it goes for TURN
concept? If it does, then it is good for me, but if it doesn't how can I get
around the problem?

 

Any help is appreciated.

 

Thanks & Regards,

Sumit Gupta

[Turnserver-devel] Anybody with Sample Client in .NET

[Sumit G. <gam...@gm...>]

Hello,

 

I am kind of new to Turn Server and concept. I am a .NET developer and with
little experience on Linux I am able to configure and install the Turn
Server on my Virtual Linux machine. Now I am looking for a .NET based sample
if available. If not, can you guide me how do I code the one myself. I am
reading through documentation, but I am not good at reading and didn't
understand the flow well. 

 

Any help is appreciated.

 

Thanks,

Sumit Gupta

[Turnserver-devel] what to use for max_relay_per_username?

[Justin K. <ju...@af...>]

The default value is 5.  A single 1-on-1 audio/video call should only need 4 
allocations, but the moment you try to do anything else beyond that you're in 
trouble.  Also if you have a multi-homed system or VPN then you could be in 
trouble too (potentially 8 allocations made during call init, if you have two 
legitimate internet routes, which could distribute in such a way that it 
actually fails your call).  Finally, if the app ever crashes before 
deallocating, then the next call will fail.

Can anyone offer insight about the problems I describe above?  Is it correct 
ICE behavior of a client to try TURN from all network interfaces?  I wonder 
if the max relay value in the server should be something larger like 20.  
Wondering if anyone has deployment experience here...

Thanks,
Justin

[Turnserver-devel] New test client example and TURN-TCP

[Sebastien V. <seb...@tu...>]

Hi all,

I have merged TURN-TCP extension (from turnserver-turn-tcp branch) into 
trunk so now it is time to test it :). I don't know if  existing TURN 
client library (such as PJSIP or libnice) already support TURN-TCP 
extension or their plan to implement it (or not).

I have removed old test_client_* examples and add a brand new 
multiprotocol test client. It can connect with UDP, TCP, TLS and DTLS 
and request UDP or TCP relay.

Finally I want to ask you, what new features do you want to see in next 
TurnServer releases ?

Best regards,
--
Sebastien

[Turnserver-devel] TurnServer 0.3

[Sebastien V. <seb...@tu...>]

Hi all,

A new version of TurnServer is available!

New features includes turn-ipv6-08 draft support, experimental DTLS 
support (not in TURN standard) and credentials reload (via SIGHUP 
signal). It also fix a "stack smashing" bug.

Link to download: 
https://sourceforge.net/projects/turnserver/files/turnserver-0.3.tar.bz2/download


I remember you that TURN-TCP support is the next feature on my TODO 
list. You could test a first version, checkout the sources on the 
turnserver-turn-tcp SVN branch 
(https://turnserver.svn.sourceforge.net/svnroot/turnserver/branches/turnserver-turn-tcp/).

Best regards,
--
Sebastien Vincent