| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
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@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin 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@xxxxxxxxx> 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
|