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. > 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. > > > All these options will give you the possibility to do all the crazy > combinations from script. At least I think so :) -- Dan _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users