Dan Pascu wrote: > > On 11 Jun 2009, at 12:23, Bogdan-Andrei Iancu wrote: >>> Anyway, I'm open to patch submissions. But first let's see if these >>> additions really serve real use cases that are not covered by the >>> existing design, or just provide suboptimal solutions that could be >>> achieved with the existing code. I'd like to hear some arguments and >>> examples of real use cases for them. I'm interested to avoid getting >>> in the creeping featurism zone. >> >> From my personal opinion , what makes sense here is: >> - to be able to enable/disable pinging from script (per each >> REGISTER or dialog) - I guess the module already does this > > This already works. > >> >> - to allow custom ping interval per ping session (similar as we do >> with timeouts in TM - setting an AVP when enabling the ping, maybe) > > As I said, I can see why this could be useful. > >> >> - to allow selection of ping type (UDP versus SIP) by simply >> setting a flag (like we do now in nathelper - default is UDP ping and >> if you set an extra flag, you get SIP ping). >> > > I explicitly did not implement UDP pings, because over 40% of the > routers out there will not keep the NAT open if they do not receive > something from inside the NAT. As a consequence UDP pings are useless > with those devices and unfortunately you cannot know which work and > which don't. While UDP pings are cheaper and thus more appealing, in > their case it applies the rule that you get what you pay for.
I agree with you - to be honest I'm using only SIP ping ....so should we obsolete the UDP ping :) ? > >> So three infos: if ping or not, the interval and the type - maybe we >> can combine all this into an enable_ping() functions ? > > No extra function is needed, just some extra avps. makes sense - if there are not so many vals to push. Regards, Bogdan _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users