AW: [reSIProcate] Proposal for adding STUN client support

Fri Mar 10 09:40:18 CST 2006

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/20060310/8047caf1/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/20060310/8047caf1/attachment.jpg>