RE: [reSIProcate] Proposal for adding STUN client support

["Matthias Moetje - TERASENS GmbH" <moetje@xxxxxxxxxxxx>]

OK,

 

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

way..

 

Best,

 

Matthias

 

---

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Matthias Moetje - TERASENS GmbH
Sent: Friday, March 10, 2006 4:40 PM
To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxx]
Gesendet: Do 09.03.2006 22:28
An: Matthias Moetje - TERASENS GmbH; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Matthias Moetje - TERASENS GmbH
Sent: Thursday, March 09, 2006 10:45 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxx www.terasens.com