[reSIProcate] STUN Client support

[Matthias Moetje - TERASENS GmbH]

OK,
 
I have checked in the STUN client stuff, now. 
I will add some documentation how to use it 
to the wiki soon.
Best regards,

Matthias Moetje


________________________________

	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, April 06, 2006 9:45 PM
	To: resiprocate-devel at list.sipfoundry.org
	Subject: [reSIProcate] STUN Client support
	
	
	Hi,
	 
	I just finished the implementation of STUN client support. 
	It was much easier than I had expected and it works 
	quite well. (I haven't solved the via problem yet, though)
	 
	This is what I've done:
	 
	SipStack::AddTransport now returns a pointer of type "Transport"
	to the internally created transport. This pointer can be casted
	back to a UdpTransport interface (for STUN client usage).
	 
	I added the following new member variables:
	 
	   mutable resip::Mutex  myMutex;
	   Tuple mStunMappedAddress; // the discovered mapped address
	   bool mStunSuccess; // received a successful response to last STUN test
	
	and these two public functions:
	 
	   bool stunSendTest(const Tuple& dest);
	   bool stunResult(Tuple& mappedAddress); 
	
	The first one lets you initiate a STUN test to the STUN 
	server specified by "dest". It constructs a STUN message
	and adds it to the "mTxFifo". 
	 
	The latter function just returns the discovered mapped address
	and port in case the last STUN test was successful.
	 
	I added some code to the process function in order to process
	the STUN response. It checks the first two bytes (very 
	similar to the existing implementation of STUN server):
	 
	      if (buffer[0] == 1 && buffer[1] == 1 && ipVersion() == V4)
	
	I changed the STUN server message detection from
	 
	      if (buffer[0] == 0 || buffer[0] == 1 && ipVersion() == V4)
	 
	(which was obviously wrong) to 
	 
	      if (buffer[0] == 0 && buffer[1] == 1 && ipVersion() == V4)
	
	Finally I added a Lock to the two STUN functions and to the process
	function for thread safety.
	 
	 
	If nobody has some serious reasons against this implementation
	I would check it in soon, I don't think this will affect existing 
	applications in any way because the mutex is the only real
	effective change for someone who doesn't use STUN client 
	or server functionality.
	 
	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/20060409/33a63a18/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/20060409/33a63a18/attachment.jpg>