[reSIProcate] keepalivemanager stun over udp
Justin Matthews
jmatthewsr at gmail.com
Mon Jun 14 21:05:48 CDT 2010
Thanks Scott. For just adding the STUN keep-alive functionality my
preference would be to enhance the KeepAliveManager as the code will be
fairly straightforward. The basic keep-alive functionality would then be
contained in a single class, a simple convenience for finding the basic
keep-alive mechanisms and keeping the number of source files to a minimum.
My .02.
-justin
From: slgodin at gmail.com [mailto:slgodin at gmail.com] On Behalf Of Scott Godin
Sent: Sunday, June 13, 2010 12:01 PM
To: Justin Matthews
Cc: resiprocate-devel
Subject: Re: [reSIProcate] keepalivemanager stun over udp
I think it would be possible for you to:
-sub-class the KeepaliveManager
-pass your udp transport pointer to your new class constructor, before you
call setKeepAliveManager()
-override the process method and have it do Stun keepalives, instead of
CRLFCRLF keepalives
All without modifying DUM or resip. You could even contribute your
StunKeepAliveManager implementation to opensource. : )
Scott
On Sat, Jun 12, 2010 at 9:58 AM, Justin Matthews <jmatthewsr at gmail.com>
wrote:
It looks like it would be possible to use STUN as a keep-alive mechanism for
UDP using the KeepAliveManager in DUM. One implementation would be to pass
in a UdpTransport pointer when adding a target to the KeepAliveManager.
Passing the UdpTransport pointer around requires some additional care and
management if the UdpTransport is ever destroyed to avoid creating an
invalid pointer, but it looks like the stack doesn't currently
support/expose sending a STUN request to a particular target.
Any thoughts and/or objections to passing a UdpTransport pointer to
KeepAliveManager::add()? If the pointer is null then the current behavior
would be used (send CRLF), if not then a STUN request would be tried and
fallback to CRLF if it fails.
Thanks.
-justin
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20100614/e3a3c102/attachment.htm>
More information about the resiprocate-devel
mailing list