[reSIProcate] Proposal for adding STUN client support

Bruce Lowekamp lowekamp at sipeerior.com
Thu Mar 9 10:02:23 CST 2006


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 at terasens.com> 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 at terasens.com
> www.terasens.com*
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060309/c9333f6c/attachment.htm>


More information about the resiprocate-devel mailing list