turnserver-users — General discussions about TurnServer

[Turnserver-users] Install TurnServer-0.5 on centos / x86

[Gentle Y. <no...@gm...>]

Hi all:

I tried to install TurnServer-0.5 on centos (x86, ipv4) with the following
shell:

autoreconf -i
./configure --enable-debug-build


make
make install

And it looks like everything is ok, but when I run the command "turnserver
-c /usr/local/etc/turn/turnserver.conf"  at "/usr/local/etc/turn/" ,it just
output the text in turnserver.conf and then it's over without any system
process . Is there something wrong or I missed ? Many thanks.

Chris

Re: [Turnserver-users] Using Test Turn Client...

[Bill C. <bc...@co...>]

Thanks for your prompt replies.  We give it a shot today.

Regards,
Bill Clark

Sent from my iPhone

On Feb 16, 2012, at 12:41 AM, "Sebastien Vincent" <se...@ji...<mailto:se...@ji...>> wrote:

Hi Bill,

Please keep the message on the mailing-list (I CC it).

See inline.

Le 16/02/12 09:23, Bill Clark a écrit :
Thanks, Sebastien.

If we want to test the second case (listen), does the turn server return the allocated port to turn client so it can be sent via SIP answer SDP payload?  The peer can the connect back to turn client on allocated IP and port.

Yes when the TURN server returns the allocated IP/port the client.


Is the test turn client setup to perform this second scenario?  If so, how would I get around the fact peer address and port are required command line arguments?


Yes it can, there are some comments in the code ("netstat...") for the location of the test. But as test_turn_client is only a "test" tool, it performs the two cases (first the connect, then it listens for incoming connection). So you can simply put peer address/port of an echo service or simply disable part of the code that do the first way.

Best regards,
--
Seb


Thanks again for your help.

Regards,
Bill Clark

Sent from my iPhone

On Feb 15, 2012, at 11:59 PM, "Sebastien Vincent" <<mailto:se...@ji...>se...@ji...<mailto:se...@ji...>> wrote:

Hi Bill,

See inline.

Le 15/02/12 20:27, Bill Clark a écrit :
Hello –

We recently found this project to provide TCP Relay and we’re in the evaluation process.  Unfortunately I have not found documentation describing proper use and setup of Test Turn Client.

Q.  Can someone please point me to (or provide) instructions of establishing a TCP relay between two clients which transmit data?

Here are the actors schema of how works TURN-TCP:

TURN-TCP client <--------> TURN server <-------> standard TCP server (HTTP, SSH, ...) or standard TCP client (telnet, ...)

In fact there are two ways to make a TCP relay:
- the TURN-TCP client establish the connection (connect);
- the TURN-TCP client receive the connection (listen).

If you have not did it, I suggest you to read the TURN-TCP specification (<http://tools.ietf.org/html/rfc6062>http://tools.ietf.org/html/rfc6062) to better understand all the concepts.

Let's consider the following situation:
- TURN server : 192.168.0.254
- TURN-TCP client: 192.168.0.1
- TCP server: 192.168.0.5 running an HTTP server on port 80
- domain: <http://yourdomain.org> yourdomain.org<http://yourdomain.org>
- user/password: test/1234

Basically to test the first way (connect) with the test_turn_client, you need to run:
./test_turn_client -t tcp -s 192.168.0.254 -p 192.168.0.5 -w 80 -r tcp -t test -g 1234 -d <http://yourdomain.org> yourdomain.org<http://yourdomain.org>

To test the second way (another standard client connect to TURN-TCP client), it is a bit more complicated you have to run a nestat -aptn on the TURN server, get the port allocated by the TURN-CLIENT and do a connection on that port from a standard TCP client (like telnet) IIRC in the 10 seconds after running the above test_turn_client command.

We have the turn server running on standard ports 3478, basic authentication (file test/1234) and configured to allow TURN-TCP (turn_tcp = true).
Another area of clarification that would help is determining values to provide test_turn_client peer address and port.  What should these values be for each test_turn_client instance?

The peer address and port is the address/port of the peer you want to contact (connect), typically in the above case it is the HTTP server.

Best regards,
--
Seb


Thank you in advanced.

Regards,
Bill Clark



------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
<http://www.accelacomm.com/jaw/sfnl/114/51521223/>http://www.accelacomm.com/jaw/sfnl/114/51521223/



_______________________________________________
Turnserver-users mailing list
<mailto:Tur...@li...>Tur...@li...<mailto:Tur...@li...>
<https://lists.sourceforge.net/lists/listinfo/turnserver-users>https://lists.sourceforge.net/lists/listinfo/turnserver-users


------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
<http://www.accelacomm.com/jaw/sfnl/114/51521223/>http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Turnserver-users mailing list
<mailto:Tur...@li...>Tur...@li...<mailto:Tur...@li...>
<https://lists.sourceforge.net/lists/listinfo/turnserver-users>https://lists.sourceforge.net/lists/listinfo/turnserver-users

Re: [Turnserver-users] Using Test Turn Client...

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

Hi Bill,

Please keep the message on the mailing-list (I CC it).

See inline.

Le 16/02/12 09:23, Bill Clark a écrit :
> Thanks, Sebastien.
>
> If we want to test the second case (listen), does the turn server 
> return the allocated port to turn client so it can be sent via SIP 
> answer SDP payload?  The peer can the connect back to turn client on 
> allocated IP and port.

Yes when the TURN server returns the allocated IP/port the client.

>
> Is the test turn client setup to perform this second scenario?  If so, 
> how would I get around the fact peer address and port are required 
> command line arguments?
>

Yes it can, there are some comments in the code ("netstat...") for the 
location of the test. But as test_turn_client is only a "test" tool, it 
performs the two cases (first the connect, then it listens for incoming 
connection). So you can simply put peer address/port of an echo service 
or simply disable part of the code that do the first way.

Best regards,
--
Seb


> Thanks again for your help.
>
> Regards,
> Bill Clark
>
> Sent from my iPhone
>
> On Feb 15, 2012, at 11:59 PM, "Sebastien Vincent" <se...@ji... 
> <mailto:se...@ji...>> wrote:
>
>> Hi Bill,
>>
>> See inline.
>>
>> Le 15/02/12 20:27, Bill Clark a écrit :
>>>
>>> Hello –
>>>
>>> We recently found this project to provide TCP Relay and we’re in the 
>>> evaluation process.  Unfortunately I have not found documentation 
>>> describing proper use and setup of Test Turn Client.
>>>
>>> Q.  Can someone please point me to (or provide) instructions of 
>>> establishing a TCP relay between two clients which transmit data?
>>>
>>
>> Here are the actors schema of how works TURN-TCP:
>>
>> TURN-TCP client <--------> TURN server <-------> standard TCP server 
>> (HTTP, SSH, ...) or standard TCP client (telnet, ...)
>>
>> In fact there are two ways to make a TCP relay:
>> - the TURN-TCP client establish the connection (connect);
>> - the TURN-TCP client receive the connection (listen).
>>
>> If you have not did it, I suggest you to read the TURN-TCP 
>> specification (http://tools.ietf.org/html/rfc6062) to better 
>> understand all the concepts.
>>
>> Let's consider the following situation:
>> - TURN server : 192.168.0.254
>> - TURN-TCP client: 192.168.0.1
>> - TCP server: 192.168.0.5 running an HTTP server on port 80
>> - domain: yourdomain.org <http://yourdomain.org>
>> - user/password: test/1234
>>
>> Basically to test the first way (connect) with the test_turn_client, 
>> you need to run:
>> ./test_turn_client -t tcp -s 192.168.0.254 -p 192.168.0.5 -w 80 -r 
>> tcp -t test -g 1234 -d yourdomain.org <http://yourdomain.org>
>>
>> To test the second way (another standard client connect to TURN-TCP 
>> client), it is a bit more complicated you have to run a nestat -aptn 
>> on the TURN server, get the port allocated by the TURN-CLIENT and do 
>> a connection on that port from a standard TCP client (like telnet) 
>> IIRC in the 10 seconds after running the above test_turn_client command.
>>
>>> We have the turn server running on standard ports 3478, basic 
>>> authentication (file test/1234) and configured to allow TURN-TCP 
>>> (turn_tcp = true).
>>>
>>> Another area of clarification that would help is determining values 
>>> to provide test_turn_client peer address and port.  What should 
>>> these values be for each test_turn_client instance?
>>>
>>
>> The peer address and port is the address/port of the peer you want to 
>> contact (connect), typically in the above case it is the HTTP server.
>>
>> Best regards,
>> --
>> Seb
>>
>>> Thank you in advanced.
>>>
>>> Regards,
>>>
>>> Bill Clark
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization&  Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>>
>>>
>>> _______________________________________________
>>> Turnserver-users mailing list
>>> Tur...@li...  <mailto:Tur...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/turnserver-users
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Turnserver-users mailing list
>> Tur...@li... 
>> <mailto:Tur...@li...>
>> https://lists.sourceforge.net/lists/listinfo/turnserver-users

Re: [Turnserver-users] Using Test Turn Client...

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

Hi Bill,

See inline.

Le 15/02/12 20:27, Bill Clark a écrit :
>
> Hello --
>
> We recently found this project to provide TCP Relay and we're in the 
> evaluation process.  Unfortunately I have not found documentation 
> describing proper use and setup of Test Turn Client.
>
> Q.  Can someone please point me to (or provide) instructions of 
> establishing a TCP relay between two clients which transmit data?
>

Here are the actors schema of how works TURN-TCP:

TURN-TCP client <--------> TURN server <-------> standard TCP server 
(HTTP, SSH, ...) or standard TCP client (telnet, ...)

In fact there are two ways to make a TCP relay:
- the TURN-TCP client establish the connection (connect);
- the TURN-TCP client receive the connection (listen).

If you have not did it, I suggest you to read the TURN-TCP specification 
(http://tools.ietf.org/html/rfc6062) to better understand all the concepts.

Let's consider the following situation:
- TURN server : 192.168.0.254
- TURN-TCP client: 192.168.0.1
- TCP server: 192.168.0.5 running an HTTP server on port 80
- domain: yourdomain.org
- user/password: test/1234

Basically to test the first way (connect) with the test_turn_client, you 
need to run:
./test_turn_client -t tcp -s 192.168.0.254 -p 192.168.0.5 -w 80 -r tcp 
-t test -g 1234 -d yourdomain.org

To test the second way (another standard client connect to TURN-TCP 
client), it is a bit more complicated you have to run a nestat -aptn on 
the TURN server, get the port allocated by the TURN-CLIENT and do a 
connection on that port from a standard TCP client (like telnet) IIRC in 
the 10 seconds after running the above test_turn_client command.

> We have the turn server running on standard ports 3478, basic 
> authentication (file test/1234) and configured to allow TURN-TCP 
> (turn_tcp = true).
>
> Another area of clarification that would help is determining values to 
> provide test_turn_client peer address and port.  What should these 
> values be for each test_turn_client instance?
>

The peer address and port is the address/port of the peer you want to 
contact (connect), typically in the above case it is the HTTP server.

Best regards,
--
Seb

> Thank you in advanced.
>
> Regards,
>
> Bill Clark
>
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Turnserver-users mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-users

[Turnserver-users] Using Test Turn Client...

[Bill C. <bc...@co...>]

Hello -

We recently found this project to provide TCP Relay and we're in the evaluation process.  Unfortunately I have not found documentation describing proper use and setup of Test Turn Client.

Q.  Can someone please point me to (or provide) instructions of establishing a TCP relay between two clients which transmit data?
We have the turn server running on standard ports 3478, basic authentication (file test/1234) and configured to allow TURN-TCP (turn_tcp = true).
Another area of clarification that would help is determining values to provide test_turn_client peer address and port.  What should these values be for each test_turn_client instance?

Thank you in advanced.

Regards,
Bill Clark

Re: [Turnserver-users] TCP ConnectionAttempt Problem

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

Hi Nigel,

Bad STUN transaction ID in ConnectionBind response is fixed in SVN revision
205.

Thanks.

Regards,
--
Seb

2012/1/16 Sebastien Vincent <se...@ji...>

>  Hi Nigel,
>
> Le 15/01/12 20:45, Nigel Pattinson a écrit :
>
> Thanks Sebastien. I found one more problem - the response to a
> ConnectionBind request comes back with a different transaction id to what
> the request used.
>
>
> Thanks, we will check and try to fix it this week.
>
> BTW previous problem (missing XOR-PEER-ADDRESS attribute in
> ConnectionAttempt) is fixed in latest SVN revision.
>
> Regards,
> --
> Seb
>
>
>  Cheers
> Nigel
>
>  On Fri, Jan 13, 2012 at 8:31 PM, Sebastien Vincent <se...@ji...> wrote:
>
>>  Hi Nigel,
>>
>> Thanks, good catch!
>>
>> We will add the missing attribute shortly, probably this week-end.
>>
>> Regards,
>> --
>> Seb
>>
>> Le 13/01/12 02:16, Nigel Pattinson a écrit :
>>
>>  Hi
>>
>>  I am attempting to use TurnServer to relay TCP traffic in line with RFC
>> 6062. Allocation and permissions are working fine, but when a permitted
>> peer attempts to connect to the relayed transport address, my TURN client
>> receives a ConnectionAttempt indication which is lacking the
>> XOR-PEER-ADDRESS attribute (the CONNECTION-ID attribute is present). I
>> looked at the code in turnserver_handle_tcp_incoming_connection and it does
>> seem to be missing the relevant code.
>>
>>  Thanks
>> Nigel Pattinson
>> nig...@ka...
>>
>>
>>
>>  ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Mar 27 - Feb 2
>> Save $400 by Jan. 27
>> Register now!http://p.sf.net/sfu/rsa-sfdev2dev2
>>
>>
>>
>> _______________________________________________
>> Turnserver-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/turnserver-users
>>
>>
>>
>
>

Re: [Turnserver-users] TCP ConnectionAttempt Problem

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

Hi Nigel,

Le 15/01/12 20:45, Nigel Pattinson a écrit :
> Thanks Sebastien. I found one more problem - the response to a 
> ConnectionBind request comes back with a different transaction id to 
> what the request used.

Thanks, we will check and try to fix it this week.

BTW previous problem (missing XOR-PEER-ADDRESS attribute in 
ConnectionAttempt) is fixed in latest SVN revision.

Regards,
--
Seb
>
> Cheers
> Nigel
>
> On Fri, Jan 13, 2012 at 8:31 PM, Sebastien Vincent <se...@ji... 
> <mailto:se...@ji...>> wrote:
>
>     Hi Nigel,
>
>     Thanks, good catch!
>
>     We will add the missing attribute shortly, probably this week-end.
>
>     Regards,
>     --
>     Seb
>
>     Le 13/01/12 02:16, Nigel Pattinson a écrit :
>>     Hi
>>
>>     I am attempting to use TurnServer to relay TCP traffic in line
>>     with RFC 6062. Allocation and permissions are working fine, but
>>     when a permitted peer attempts to connect to the relayed
>>     transport address, my TURN client receives a ConnectionAttempt
>>     indication which is lacking the XOR-PEER-ADDRESS attribute (the
>>     CONNECTION-ID attribute is present). I looked at the code
>>     in turnserver_handle_tcp_incoming_connection and it does seem to
>>     be missing the relevant code.
>>
>>     Thanks
>>     Nigel Pattinson
>>     nig...@ka... <mailto:nig...@ka...>
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     RSA(R) Conference 2012
>>     Mar 27 - Feb 2
>>     Save $400 by Jan. 27
>>     Register now!
>>     http://p.sf.net/sfu/rsa-sfdev2dev2
>>
>>
>>     _______________________________________________
>>     Turnserver-users mailing list
>>     Tur...@li...  <mailto:Tur...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/turnserver-users
>
>

Re: [Turnserver-users] TCP ConnectionAttempt Problem

[Nigel P. <nig...@ka...>]

Thanks Sebastien. I found one more problem - the response to a
ConnectionBind request comes back with a different transaction id to what
the request used.

Cheers
Nigel

On Fri, Jan 13, 2012 at 8:31 PM, Sebastien Vincent <se...@ji...> wrote:

>  Hi Nigel,
>
> Thanks, good catch!
>
> We will add the missing attribute shortly, probably this week-end.
>
> Regards,
> --
> Seb
>
> Le 13/01/12 02:16, Nigel Pattinson a écrit :
>
> Hi
>
>  I am attempting to use TurnServer to relay TCP traffic in line with RFC
> 6062. Allocation and permissions are working fine, but when a permitted
> peer attempts to connect to the relayed transport address, my TURN client
> receives a ConnectionAttempt indication which is lacking the
> XOR-PEER-ADDRESS attribute (the CONNECTION-ID attribute is present). I
> looked at the code in turnserver_handle_tcp_incoming_connection and it does
> seem to be missing the relevant code.
>
>  Thanks
> Nigel Pattinson
> nig...@ka...
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!http://p.sf.net/sfu/rsa-sfdev2dev2
>
>
>
> _______________________________________________
> Turnserver-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/turnserver-users
>
>
>

Re: [Turnserver-users] TCP ConnectionAttempt Problem

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

Hi Nigel,

Thanks, good catch!

We will add the missing attribute shortly, probably this week-end.

Regards,
--
Seb

Le 13/01/12 02:16, Nigel Pattinson a écrit :
> Hi
>
> I am attempting to use TurnServer to relay TCP traffic in line with 
> RFC 6062. Allocation and permissions are working fine, but when a 
> permitted peer attempts to connect to the relayed transport address, 
> my TURN client receives a ConnectionAttempt indication which is 
> lacking the XOR-PEER-ADDRESS attribute (the CONNECTION-ID attribute is 
> present). I looked at the code 
> in turnserver_handle_tcp_incoming_connection and it does seem to be 
> missing the relevant code.
>
> Thanks
> Nigel Pattinson
> nig...@ka... <mailto:nig...@ka...>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
>
>
> _______________________________________________
> Turnserver-users mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-users

[Turnserver-users] TCP ConnectionAttempt Problem

[Nigel P. <nig...@ka...>]

Hi

I am attempting to use TurnServer to relay TCP traffic in line with RFC
6062. Allocation and permissions are working fine, but when a permitted
peer attempts to connect to the relayed transport address, my TURN client
receives a ConnectionAttempt indication which is lacking the
XOR-PEER-ADDRESS attribute (the CONNECTION-ID attribute is present). I
looked at the code in turnserver_handle_tcp_incoming_connection and it does
seem to be missing the relevant code.

Thanks
Nigel Pattinson
nig...@ka...

Re: [Turnserver-users] Bad magic cookie

[Atomic <at...@ba...>]

Hi Sebastien,
thanks for the confirmation.
Regards.

Antonio

In data lunedì 03 ottobre 2011 08:40:25, Sebastien Vincent ha scritto:
> Hi,
> 
> Sorry for late response.
> 
> Yes TurnServer only supports RFC 5389 and has no support for RFC 3489 yet.
> 
> Regards,
> --
> Seb

Re: [Turnserver-users] Bad magic cookie

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

Hi,

Sorry for late response.

Yes TurnServer only supports RFC 5389 and has no support for RFC 3489 yet.

Regards,
--
Seb

Le 26/09/11 16:02, atomic a écrit :
> Probably I can answer by myself...
> The SIP clients I used, and all the SIP clients I know, implements 
> RFC3489.
> In the new RFC5389 there is a dedicated field for the Magic cookie in 
> the STUN Binding request, instead in the old implementation the Magic 
> cookie was part of the Transaction ID field.
> From the RFC5389:
> "12.2. Changes to Server Processing
> A STUN server can detect when a given Binding request message was sent 
> from an RFC 3489 <http://tools.ietf.org/html/rfc3489> [RFC3489 
> <http://tools.ietf.org/html/rfc3489>] client by the absence of the 
> correct value in the magic cookie field. When the server detects an 
> RFC 3489 <http://tools.ietf.org/html/rfc3489> client, it SHOULD copy 
> the value seen in the magic cookie field in the Binding request to the 
> magic cookie field in the Binding response message, and insert a 
> MAPPED-ADDRESS attribute instead of an XOR- MAPPED-ADDRESS attribute."
> It seems that this mechanism is not implemented on Turnserver, because 
> when a request without Magic cookie field arrives, Turnserver drops 
> the request.
> Is this correct?


> Regards,
> Antonio.
> > Hi all,
> > I compiled turnserver 0.5 and also tried with SVN.
> When a SIP client sends a "Stun Binding Request" to the turnserver, I 
> don't see any response from it.
> Running turnserver with debug enabled, after receiving the STUN 
> request from the client, turnserver prints the error "Bad magic cookie".
> > Could you please suggest the solution for this issue?
> Thanks.
> Best Regards.
> >
> Antonio
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
>
>
> _______________________________________________
> Turnserver-users mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-users

Re: [Turnserver-users] Bad magic cookie

[atomic <at...@ba...>]

Probably I can answer by myself...
The SIP clients I used, and all the SIP clients I know, implements RFC3489.
In the new RFC5389 there is a dedicated field for the Magic cookie in the STUN Binding request, instead in the old implementation the Magic cookie was part of the Transaction ID field.From the RFC5389:"12.2.  Changes to Server ProcessingA STUN server can detect when a given Binding request message was
   sent from an RFC 3489 [RFC3489] client by the absence of the correct
   value in the magic cookie field.  When the server detects an RFC 3489
   client, it SHOULD copy the value seen in the magic cookie field in
   the Binding request to the magic cookie field in the Binding response
   message, and insert a MAPPED-ADDRESS attribute instead of an XOR-
   MAPPED-ADDRESS attribute."
 
It seems that this mechanism is not implemented on Turnserver, because when a request without Magic cookie field arrives, Turnserver drops the request.
Is this correct? Regards,
Antonio. 
 




> Hi all,
> I compiled turnserver 0.5 and also tried with SVN.When a SIP client sends a "Stun Binding Request" to the turnserver, I don't see any response from it.Running
 turnserver with debug enabled, after receiving the STUN request from 
the client, turnserver prints the error "Bad magic cookie".
> Could you please suggest the solution for this issue?Thanks.Best Regards.
>  Antonio 

[Turnserver-users] Bad magic cookie

[atomic <at...@ba...>]

Hi all,
I compiled turnserver 0.5 and also tried with SVN.When a SIP client sends a "Stun Binding Request" to the turnserver, I don't see any response from it.Running
 turnserver with debug enabled, after receiving the STUN request from 
the client, turnserver prints the error "Bad magic cookie".
Could you please suggest the solution for this issue?Thanks.Best Regards.
 Antonio 

[Turnserver-users] Setiing up a TURN Server behind a NAT - Amazon EC2

[Milesh J. <mjethwa@4DInteractive.co.uk>]

Hi,

 

I tried to set up TurnServer-0.5 on an amazon ec2 instance. The public
IP address and internal IP addresses are different but have a 1 to 1
mapping so that all traffic sent to the public address forwarded to the
internal IP address at the same ports.

 

In the tunserver.conf I first set the listening IPv4 to the public
address but this failed to create the listening socket for the
allocations. I changed the config listening iPv4 to the internal IP and
it did the allocation but the relay address that is passed to the sip ua
is my internal IP address.

 

Is there a config setting that I have missed that should resolve this
issue or is this a limitation in TurnSever, when the server is behind a
NAT?

 

Kind regards 

M Jethwa

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom it is addressed. If you have received this e-mail in error you must not copy, distribute or take any action in reliance on it. Please notify the sender by e-mail or telephone.
4D utilise an anti-virus system (by Webroot Email Security Service) and therefore any files sent via e-mail will have been checked for known viruses. You are however advised to run your own virus check before opening any attachments received as we will not in any event accept any liability whatsoever once an e-mail and/or any attachment is received. Any views expressed by an individual within this e-mail do not necessarily reflect the views of 4D Interactive Ltd.

Re: [Turnserver-users] status of turnserver

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

Hi Ahmad,

Yes the project is ready for production. We have a running TurnServer at 
the company I work for (BlueJimp), and we have also installed it for 
some of our customers.

TURN protocol can be used with ICE protocol (RFC5245) to provide NAT 
traversal.

--
Seb

Le 30/06/11 06:18, Ahmad Faya a écrit :
> Hi,
> I just found this project, have give it a try and it looks good.
> I have some questions :
>
> 1. is this project ready to production use? If not yet, any problem list that need to be solved?
>
> 2. Is turnsever already used in real world? ANy example?
>
> Thanks
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Turnserver-users mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-users

[Turnserver-users] status of turnserver

[Ahmad F. <ahm...@ya...>]

Hi,
I just found this project, have give it a try and it looks good.
I have some questions :

1. is this project ready to production use? If not yet, any problem list that need to be solved?

2. Is turnsever already used in real world? ANy example?

Thanks

Re: [Turnserver-users] Performance

[Emil I. <em...@ji...>]

Hey Michel,

На 16.05.11 10:45, Michel Freiha написа:
> Hello Sebastien, thanks a lot for the reply...just a question that come
> to my head....Do you think 1 TURN server can handle 100MB per sec if we
> Install it on a good hardware like XEON 16 cores with 32 Gbytes as RAM
> or the software does not support such amount of traffic?

Our personal feeling is that it should work with even less. Still, as I
already indicated to you privately, we have not conducted comprehensive
performance testing and this is no more than a guess.

Emil
> 
> Regards
> 
> Regards
> 
> On Fri, May 13, 2011 at 4:39 PM, Sebastien Vincent <se...@ji...
> <mailto:se...@ji...>> wrote:
> 
>     Hi Michel,
> 
>     Sorry for very late answer,
> 
>     I would say that a Pentium IV and 1,5/2 Go of memory is sufficient.
> 
>     I cannot tell you precisely how many connections it can handle but
>     technically speaking TurnServer uses select() to manage sockets
>     (i.e. no threads) so it should be scalable.
> 
>     Regards,
>     --
>     Seb
> 
>     Le 06/05/11 12:51, Michel Freiha a écrit :
>>     Dear All,
>>
>>     I would like to ask please if some of you can provide me some
>>     useful information about this TURN server regarding its
>>     performance and specially how many Concurrent UDP or TCP users can
>>     handle and what is Minimum Hardware requirement
>>
>>     Regards
>>
>>     -- 
>>     *Michel Freiha
>>     Technical Manager
>>     Splendor telecom (www.splendor.net <http://www.splendor.net>)
>>     Beirut, Lebanon
>>     Phone: +9611373725/ext 116
>>     FAX: +9611375554*
>>
>>
>>     ------------------------------------------------------------------------------
>>     WhatsUp Gold - Download Free Network Management Software
>>     The most intuitive, comprehensive, and cost-effective network 
>>     management toolset available today.  Delivers lowest initial 
>>     acquisition cost and overall TCO of any competing solution.
>>     http://p.sf.net/sfu/whatsupgold-sd
>>
>>
>>     _______________________________________________
>>     Turnserver-users mailing list
>>     Tur...@li... <mailto:Tur...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/turnserver-users
> 
> 
>     ------------------------------------------------------------------------------
>     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-users mailing list
>     Tur...@li...
>     <mailto:Tur...@li...>
>     https://lists.sourceforge.net/lists/listinfo/turnserver-users
> 
> 
> 
> 
> -- 
> *Michel Freiha
> Technical Manager
> Splendor telecom (www.splendor.net <http://www.splendor.net>)
> Beirut, Lebanon
> Phone: +9611373725/ext 116
> FAX: +9611375554*
> 
> 
> 
> ------------------------------------------------------------------------------
> 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-users mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-users

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
em...@ji...                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

Re: [Turnserver-users] Performance

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

Hello Sebastien, thanks a lot for the reply...just a question that come to
my head....Do you think 1 TURN server can handle 100MB per sec if we Install
it on a good hardware like XEON 16 cores with 32 Gbytes as RAM or the
software does not support such amount of traffic?

Regards

Regards

On Fri, May 13, 2011 at 4:39 PM, Sebastien Vincent <se...@ji...> wrote:

>  Hi Michel,
>
> Sorry for very late answer,
>
> I would say that a Pentium IV and 1,5/2 Go of memory is sufficient.
>
> I cannot tell you precisely how many connections it can handle but
> technically speaking TurnServer uses select() to manage sockets (i.e. no
> threads) so it should be scalable.
>
> Regards,
> --
> Seb
>
> Le 06/05/11 12:51, Michel Freiha a écrit :
>
> Dear All,
>
> I would like to ask please if some of you can provide me some useful
> information about this TURN server regarding its performance and specially
> how many Concurrent UDP or TCP users can handle and what is Minimum Hardware
> requirement
>
> Regards
>
> --
>  *Michel Freiha
> Technical Manager
> Splendor telecom (www.splendor.net)
> Beirut, Lebanon
> Phone: +9611373725/ext 116
> FAX: +9611375554*
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.http://p.sf.net/sfu/whatsupgold-sd
>
>
> _______________________________________________
> Turnserver-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/turnserver-users
>
>
>
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-users
>
>


-- 
*Michel Freiha
Technical Manager
Splendor telecom (www.splendor.net)
Beirut, Lebanon
Phone: +9611373725/ext 116
FAX: +9611375554*

Re: [Turnserver-users] Performance

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

Hi Michel,

Sorry for very late answer,

I would say that a Pentium IV and 1,5/2 Go of memory is sufficient.

I cannot tell you precisely how many connections it can handle but 
technically speaking TurnServer uses select() to manage sockets (i.e. no 
threads) so it should be scalable.

Regards,
--
Seb

Le 06/05/11 12:51, Michel Freiha a écrit :
> Dear All,
>
> I would like to ask please if some of you can provide me some useful 
> information about this TURN server regarding its performance and 
> specially how many Concurrent UDP or TCP users can handle and what is 
> Minimum Hardware requirement
>
> Regards
>
> -- 
> *Michel Freiha
> Technical Manager
> Splendor telecom (www.splendor.net <http://www.splendor.net>)
> Beirut, Lebanon
> Phone: +9611373725/ext 116
> FAX: +9611375554*
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
>
>
> _______________________________________________
> Turnserver-users mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-users

[Turnserver-users] Performance

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

Dear All,

I would like to ask please if some of you can provide me some useful
information about this TURN server regarding its performance and specially
how many Concurrent UDP or TCP users can handle and what is Minimum Hardware
requirement

Regards

-- 
*Michel Freiha
Technical Manager
Splendor telecom (www.splendor.net)
Beirut, Lebanon
Phone: +9611373725/ext 116
FAX: +9611375554*

Re: [Turnserver-users] TurnServer disable TURN authentication

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

Hi Remi,

No there is not a possibility to disable authentication. TURN RFC 5766 
section 4 says :

"[RFC5389] specifies an authentication mechanism called the long-term
    credential mechanism.  TURN servers and clients MUST implement this
    mechanism.  The server MUST demand that all requests from the client
    be authenticated using this mechanism, or that a equally strong or
    stronger mechanism for client authentication is used."


By the way I don't think flash implements the last draft-16/RFC of TURN. 
In my knowledge flash supports only draft version 8 
(http://www.adobe.com/devnet/flashplayer/articles/rtmfp_cirrus_app.html) 
and TurnServer development has been started with draft version 9. FYI a 
lot of things change from version 8/9 to RFC5766.

Regards,
--
Seb

Le 21/01/2011 10:57, remi humbert a écrit :
> Hi,
>
> Is there a way to disable authentication for TURN ?
> I would like to use it with flash which does not support TURN 
> authentication yet.
>
> Regards
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
>
>
> _______________________________________________
> Turnserver-users mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-users
>    

[Turnserver-users] TurnServer disable TURN authentication

[remi h. <mi...@gm...>]

Hi,

Is there a way to disable authentication for TURN ?
I would like to use it with flash which does not support TURN authentication
yet.

Regards

Re: [Turnserver-users] TCP extensions, multiple connections

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

Hi,

Oh sorry I read a little bit too quickly. We will investigate your problem
in the following week.

Regards,
--
Seb

2010/12/30 Peter Neuss <ak...@gm...>

> Hi,
>
> RFC 5766 says: "This specification describes only UDP allocations.".
> I'm particularly interested in the TCP extentions.
>
> Thanks,
>
> Peter
>
>
> On Thu, Dec 30, 2010 at 8:24 PM, Sebastien Vincent
> <se...@si...> wrote:
> > Hi Peter,
> >
> > Please see RFC 5766. The draft you mentionned is outdated.
> >
> > Regards,
> > --
> > Seb
> >
> > 2010/12/30 Peter Neuss <ak...@gm...>
> >>
> >> Hi,
> >>
> >> I've been trying to use the turnserver with tcp connections.  I would
> >> like to use one allocation to connect to multiple peers, with
> >> according to the doc seems possibile.  However I can't get it to
> >> work...the first "client_send_connect" works but the second fails. In
> >> "turnserver_process_connect" the test that "an outgoing connection
> >> already exists" fails.  I tried disabling this test but it still
> >> doesn't work.
> >> I'm a bit confused by the fact that this test doesn't even check the
> >> peer address...in the doc "Traversal Using Relays around NAT (TURN)
> >> Extensions for TCP Allocations - draft-ietf-behave-turn-tcp-07" it
> >> seems that one allocation should be usable for multiple different
> >> peers; the only limitation is one connection per allocation per peer.
> >> Can somebody enlighten me please?
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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-users mailing list
> >> Tur...@li...
> >> https://lists.sourceforge.net/lists/listinfo/turnserver-users
> >
> >
>

[Turnserver-users] TCP extensions, multiple connections

[Peter N. <ak...@gm...>]

Hi,

I've been trying to use the turnserver with tcp connections.  I would
like to use one allocation to connect to multiple peers, with
according to the doc seems possibile.  However I can't get it to
work...the first "client_send_connect" works but the second fails. In
"turnserver_process_connect" the test that "an outgoing connection
already exists" fails.  I tried disabling this test but it still
doesn't work.
I'm a bit confused by the fact that this test doesn't even check the
peer address...in the doc "Traversal Using Relays around NAT (TURN)
Extensions for TCP Allocations - draft-ietf-behave-turn-tcp-07" it
seems that one allocation should be usable for multiple different
peers; the only limitation is one connection per allocation per peer.
Can somebody enlighten me please?

Thanks,

Peter