[reSIProcate] Proposal for adding STUN client support

[Scott Godin]

A quick note:  storing/accessing pointers to transports outside of the stack thread is not a good idea.  Especially since there are some changes on the table to allow transports to be added/removed at runtime.  I haven't really though much about alternatives though - perhaps queuing some messages to the stack to start a stun test????

 

________________________________

From: resiprocate-devel-bounces at list.sipfoundry.org [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of Matthias Moetje - TERASENS GmbH
Sent: Thursday, March 09, 2006 10:45 AM
To: resiprocate-devel at list.sipfoundry.org
Subject: [reSIProcate] Proposal for adding STUN client support

 

Hi,

 

in my efforts to implement client support for STUN I found 

that it is necessary to modify the UDP transport to implement

this functionality (as Dmytrow already mentioned in a previous

post).

I think this functionality might be of interest for others, too,

so here's a proposal for adding stun client support.

 

Why this is necessary: The STUN functions in stun.cxx work

fine for RTP ports but they can't be used directly for the SIP

UDP ports because the stack is already bound to these ports.

Even when binding with SO_REUSEPORT, the response is received

by the stack and not by the stun function (at least on Windows), 

so it is necessary to do the STUN communication in the UdpTransport

class itself. This class already implements a stun server, so I 

see no reason why the client should be implemented elsewhere.

 

I think the application should have control over the use of the 

discovered public IP address and port (a more automatic and

integrated solution could be added later), therefore the application

would need to get a pointer to the UdpTransport class. This could be 

done by turning

 

void addTransport( TransportType protocol, int port=0, IpVersion version=V4, StunSetting stun=StunDisabled,...); 

 

into 

 

Transport addTransport( TransportType protocol, int port=0, IpVersion version=V4, StunSetting stun=StunDisabled,...);

 

The StunSetting enumeration could be extended to

 

typedef enum
{
   StunDisabled,
   StunEnabled, //Server only

   StunClient,   //Client only

   StunClientServer //Client and Server
} StunSetting;

 

This would be 100% compatible and require no changes to existing 

code nor would it change any existing behaviour.

 

 

UdpTransport would receive two public methods:

 

//returns true if message was sent successfully

bool StunTest(StunAddress4& dest, int testNum);

 

//returns true and discovered address if last StunTest was successful

bool StunResult(StunAddress4* srcAddr);

 

 

Would there be any resons against implementing it 

this way? Any suggestions?

 

Best regards,

Matthias Moetje

 

TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

 

Phone:
Fax:
e-mail:
Web:

 

+49.89.143370-0
+49.89.143370-22
info at terasens.com <mailto:info at terasens.com> 
www.terasens.com <http://www.terasens.com/> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060309/8b628689/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2937 bytes
Desc: image001.jpg
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060309/8b628689/attachment.jpg>