[reSIProcate] Proposal for adding STUN client support

Mon Mar 13 13:03:31 CST 2006

OK, 

if there are no other comments I'll start implementing it that
way..

Best, 

Matthias

________________________________

	From: resiprocate-devel-bounces at list.sipfoundry.org [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of Matthias Moetje - TERASENS GmbH
	Sent: Friday, March 10, 2006 4:40 PM
	To: Scott Godin; resiprocate-devel at list.sipfoundry.org
	Subject: AW: [reSIProcate] Proposal for adding STUN client support

	Hi Scott,

	I had thought about that. Of course the methods would need to be made thread safe.

	First I though about an additional class like StunClientHandler that you could pass with the
	AddTransport method. But it would impose the exact same problems, and stun server is 
	integrated into UdpTransport anyway, so this wouldn't make much sense.

	Making the transaction controller handle not only SIP messages but also stun
	requests and responses (and possibly make them even travel through dum)
	sounds like a lot of work. 

	If the application would create a custom transport object and use the other AddTransport
	method, we have the same result already, that the application has a reference to a
	transport. So we would not create any new behaviour. After all it is the application that
	is responsible for adding transports and thus for knowing about the validity of the transport
	pointer.

	If you are planning for the ability to remove transports, this could be even a benefit, because
	you could do just the following to temporarily disable a transport:

	Transport myTransport = stack.AddTransport(....);

	//remove transport
	stack.RemoveTransport(myTransport);

	//re-add 
	stack.AddTransport(myTransport);

	The only alternative that comes to my mind would be to let UdpTransport make the 
	modifications to the SIP message (via and contact) directly, so the application wouldn't 
	need to communicate with the application at all. But this will require a little bit more
	like interval checking of the current stun information, blocking a message as long
	until the stun information is known (when the stack was just started)...

	What do you (or others) think?

	Matthias

________________________________

	Von: Scott Godin [mailto:slgodin at icescape.com]
	Gesendet: Do 09.03.2006 22:28
	An: Matthias Moetje - TERASENS GmbH; resiprocate-devel at list.sipfoundry.org
	Betreff: RE: [reSIProcate] Proposal for adding STUN client support

	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/20060313/f0ccf91e/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/20060313/f0ccf91e/attachment.jpg>