[reSIProcate] Proposal for adding STUN client support

[Matthias Moetje - TERASENS GmbH]

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/60366db2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TERASE1.jpg
Type: image/jpeg
Size: 2937 bytes
Desc: TERASE1.jpg
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060309/60366db2/attachment.jpg>