Re: [reSIProcate] Proposal for adding STUN client support

["Bruce Lowekamp" <lowekamp@xxxxxxxxxxxxx>]

Personally, I think this would be an excellent idea.  Discovering the mapped address (externally visible address) is the most useful thing stun can do. 

Coincidentally, you don't actually need a stun server to do that (you do to determine NAT type).  If all you want is your mapped address, any resiprocate stack that you can communicate with can determine your mapped address for you.  All that's missing is the client interface.

(more comments inline)

On 3/9/06, Matthias Moetje - TERASENS GmbH <moetje@xxxxxxxxxxxx> wrote:

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.

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);

I think it would be a terribly bad idea to expose StunAddress4 anywhere.  The stun code's habit of keeping addresses in host format is just bizarre.  I would map it from the Stun* types into resip Tuple types before returning it.  Also, personally I wouldn't want to expose the testNum thing, or at least I would want a method that returns the mapped address without requiring the user to specify a test number. 

Something like:

bool stunQueryMapped(const Tuple&  dest);

bool stunResult(Tuple& mappedAddress);

Bruce


 

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

 

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel