reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] reTurn TestAsyncClient TLS mode fail

Scott, 

sendToUnframed () works! I can send and receive to external test peer and I can get onSendSuccess, onReceiveSuccess events!

But there are some other things to change as well, for example, the refresh function is refreshAllocation( ) which is not suitable to STUN. I need to create a new StunAsyncSocket class instead of using the TurnAsyncSocket.

Https://www.resiprocate.org/Stun_support introduced another solution for STUN client which claims "obviously this implementation is Asynchronous".  I'm wondering if this approach is much easier, ie, if I follow the steps to create a socket then the connection is automatically  refreshed by resip stack and in addition, I can have a Asynchronous STUN client?

Tom





Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Scott Godin <slgodin@xxxxxxxxx>
Date: 5/5/16 6:55 AM (GMT-08:00)
To: Tom Chen <chentom60@xxxxxxxxxxx>
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] reTurn TestAsyncClient TLS mode fail

As long as you call connect before send you can send raw data without an allocation.  sendTo will not work without an allocation.

See the code in TurnAsyncSocket::doSendFramed:

void 
TurnAsyncSocket::doSendFramed(boost::shared_ptr<DataBuffer>& data)
{
   if(mActiveDestination)
   {
      sendToRemotePeer(*mActiveDestination, data);
   }
   else if(mAsyncSocketBase.isConnected())
   {
      DebugLog(<<"Sending to connected peer");
      sendToUnframed(mAsyncSocketBase.getConnectedAddress(), mAsyncSocketBase.getConnectedPort(), data);
   }
   else
   {
      DebugLog(<<"no allocation, can't send!");
   }
}

Best Regards,
Scott

On Wed, May 4, 2016 at 12:09 AM, Tom Chen <chentom60@xxxxxxxxxxx> wrote:
Scott,
 
Yes, I know. In OnBindSuccess, I do not do allocation but instead, sending data to test peer directly. However, in the TurnAsyncSocket’s send function, it notices that it has not done channel binding, then it still sends channel bind request automatically to server. See the log below.
 

# TestAsyncClient 10.113.54.60 3478 10.113.54.61

INFO | 20000709-075409.029 |  | RESIP:DNS | 1081618432 | DnsUtil.cxx:233 | Local IP address for  is 169.254.6.91

INFO | 20000709-075409.034 |  | RESIP:TEST | 1081618432 | TestAsyncClient.cxx:296 | Using 10.113.54.61 as local IP address.

INFO | 20000709-075409.066 |  | RESIP:TEST | 1081618432 | TestAsyncClient.cxx:95 | MyTurnAsyncSocketHandler::onConnectSuccess: socketDest=10, address=10.113.54.60, port=3478

INFO | 20000709-075409.073 |  | RESIP:TEST | 1081618432 | TestAsyncClient.cxx:122 | MyTurnAsyncSocketHandler::onBindingSuccess: socketDest=10, reflexive=[UDP 10.113.54.61:40353], serverTuple=[UDP 10.113.54.60:3478]

INFO | 20000709-075409.073 |  | RESIP:TEST | 1081618432 | TestAsyncClient.cxx:133 | CLIENT: Sending: This test is for wrapped Turn Data!    <<== Sending Data to peer

INFO | 20000709-075409.075 |  | RESIP:TEST | 1081618432 | TestAsyncClient.cxx:206 | MyTurnAsyncSocketHandler::onChannelBindRequestSent: socketDest=10 channelNumber=29634    <<== TurnAsyncSocket do channelbinding

ERR | 20000709-075409.080 |  | RETURN | 1081618432 | TurnAsyncSocket.cxx:754 | TurnAsyncSocket::handleChannelBindResponse: Received ChannelBindResponse error: 437

WARNING | 20000709-075409.080 |  | RESIP:TEST | 1081618432 | TestAsyncClient.cxx:214 | MyTurnAsyncSocketHandler::onChannelBindFailure: socketDest=10 error=437(asio.misc error).

 

 

Tom

 
Sent: Tuesday, May 3, 2016 7:45 PM
Subject: Re: [reSIProcate-users] reTurn TestAsyncClient TLS mode fail
 
Bind requests do not require an allocation.
 
Scott
 
On Tue, May 3, 2016 at 7:56 PM, Tom Chen <chentom60@xxxxxxxxxxx> wrote:
Scott ,
 
My idea to use TurnAsyncSocket for STUN client doesn't work as it always sends channel Binding requests which also require Turn Allocation , so it is designed for TURN client only, not for both.
 
Tom
 
 
Sent from my Verizon, Samsung Galaxy smartphone
 
 
-------- Original message --------
From: Tom Chen <chentom60@xxxxxxxxxxx>
Date: 5/3/16 2:40 PM (GMT-08:00)
Subject: Re: [reSIProcate-users] reTurn TestAsyncClient TLS mode fail
 
Hi Scott, 
 
The rutil\stun\ Stun.cxx doesn't have any onReceiveSuccess, onBindSuccess etc events as seen in TurnAsyncUdpSocket, so it is Synchronous model. I am wondering why it doesn't have an Asynchronous model as Turn client in TestAsyncClient.cxx.
 
Is it possible to use the TurnAsyncUdpSocket for STUN Asychronous client also which has lots of similar functions except a few TURN specific Allocation, channel Binding etc functions?
 
Tom
 
 
 
Sent from my Verizon, Samsung Galaxy smartphone
 
 
-------- Original message --------
Date: 5/3/16 11:41 AM (GMT-08:00)
To: Tom Chen <chentom60@xxxxxxxxxxx>
Subject: Re: reTurn TestAsyncClient TLS mode fail
 
Glad you got it working.  Besides the AsyncTest app you have already been playing with, there is also the recon project that is part of the resip git repo.  There is information about recon on the wiki.
 
Best Regards,
Scott

Sent from my iPhone

On May 3, 2016, at 2:21 PM, Tom Chen <chentom60@xxxxxxxxxxx> wrote:

 
Scott,
 
Thank you!  The TLS mode works now.
 
By the way, is there any Asynchronous STUN  client class, example?
 
Tom
 
 
-------- Original message --------
Date: 5/2/16 4:11 PM (GMT-08:00)
To: Tom Chen <chentom60@xxxxxxxxxxx>
Subject: Re: reTurn TestAsyncClient TLS mode fail
 
 
They *should* be interoperable.
 
Scott

Sent from my iPhone

On May 2, 2016, at 6:40 PM, Tom Chen <chentom60@xxxxxxxxxxx> wrote:

Scott,
 
Thank you for your help!
I'm wondering why these two TURN servers behave differently? is there any specification to follow?
 
Tom
 
 
 
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------
From: Scott Godin <sgodin@xxxxxxxxxxxxxxx>
Date: 5/2/16 7:59 AM (GMT-08:00)
To: Tom Chen <chentom60@xxxxxxxxxxx>
Subject: Re: reTurn TestAsyncClient TLS mode fail
 
Hi Tom,
 
Last time I checked TLS works fine in reTurn server and client APIs.  Your wireshark trace shows a SSL/TLS Hello being sent to your server, then there is no response from the server.  We do not support the turnserver (http://turnserver.sourceforge.net/) project here.  You could try using the reTurn TURN server instead.
 
Scott
 
 
 
On Fri, Apr 29, 2016 at 10:21 PM, Tom Chen <chentom60@xxxxxxxxxxx> wrote:

Hello,

 

I have successfully tested TURN client reTurn/client/test/TestAsyncClient.cxx in UDP mode, however, somehow, the TLS mode always fails. From the shell screen of turnserver, I can see that the TCP/TLS connection has been established successfully, so the cert file (the ca.perm in the same directory) seems to be confirmed ok:

 

0: IPv4. TCP listener opened on : 10.113.54.60:3478

0: IPv4. TCP listener opened on : 10.113.54.60:3479

18: IPv4. tcp or tls connected to: 10.113.54.61:51575

 

But then nothing happens, the onConnectSuccess or Failure events of the TestAsyncClient.cxx are not observed. I am wondering why? I am not sure if my TURN server was started correctly? Or TestAsyncClient.cxx needs some extra work? Can someone help me to figure out?

 

My setup is like this:

TestAsyncClient is running at 10.113.54.61

turnserver at 10.113.54.60

UDP echo server at 10.113.54.57 (should I use a TCP echo server as test peer instead?)

 

Turn Server Start script:

turnserver -v --log-file /tmp/turn.log -f --min-port=32355 --max-port=65535 --no-stun=1 -r ip:port -c /etc/turnserver/turnserver.conf --cert /home/tom/workspace/resiprocate-1.9.10/reTurn/client/test/ca.pem

 

Turn Client Start script:

#TestAsyncClient 10.113.54.60 3479 10.113.54.61

INFO | 20000705-060733.809 |  | RESIP:DNS | 1075036160 | DnsUtil.cxx:233 | Local IP address for  is 169.254.6.91

INFO | 20000705-060733.813 |  | RESIP:TEST | 1075036160 | TestAsyncClient.cxx:279 | Using 10.113.54.61 as local IP address.

 

Attached is the trace captured on the TURN server, TCP packet #546 ~ 552 are for communication establishment between TURN server (10.113.54.60) and client (10.113.54.61). I used “ip.addr==10.113.54.61” as packet filter for Wireshark.

 

Tom




Statement Of Confidentiality:

This electronic message transmission, and all attachments, contains information from Extron Electronics which is confidential and privileged. The information is for the exclusive viewing or use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by a "reply to sender only" message and destroy all electronic and hard copies of the communication, including attachments.