Re: [sr-dev] Exposing additional dialog functions through API

Hey Timo On Fri, Aug 12, 2011 at 2:53 PM, Timo Reimann <timo.reimann(a)1und1.de> wrote: Hey Jason, On 12.08.2011 13:50, Jason Penton wrote: A much easier approach IMHO would be to register a callback to DLGCB_DESTROY or DLGCB_TERMINATE. That way, you'll be notified automatically when the dialog is destroyed/terminated and don't need to deal with implementation details such as hash table keys. You could also use other dialog callbacks to react to specific dialog lifetime phases. See the docs for details. yes, we do this already, BUT we need a link to a dialog that can be used "outside" of the callbacks. For example. Lets take the Rx interface. We could get a message from the network saying there is a problem on the bearer, static the PCC sessions affected. In this case: a) we need to find the associated / affected dialogs b) terminate them If you really need to terminate calls proxy-wise, I agree you need some terminate function. It's usefulness might be restricted in your case as mischievious clients may just ignore your BYE request. I don't know your exact setup, however, so this objection might not count. correct, but dont forget in the IMS case the bearer will be torn down in which case the 'client' wont be able to send or receive RTP ;) Assuming that it holds I think dialog callbacks, again, are the way to hook into the dialog module. Just keep registering for new dialogs (possibly "confirmed" ones only) and make your module logic keep track of credits during the course of the call. Should the account drop to zero while the dialog is still active, force termination. Termination, by the way, could also be implemented by letting your module run a particular Kamailio route on zero credits which, in turn, could call dlg_end_dlg(). That way, you wouldn't need to export another function. I am not strictly against exporting the termination function on C level though, just wanted to mention the route approach. yes this is one of the options we did think about, BUT we thought that if someone wanted to implement an Ro interface they may not want to have to 'configure' the config file to make it work properly and according to the standard. but yest this still remains a good option. I'd be interested to know whether all these scenarios can be covered by means of using the dialog callbacks as they nicely isolate implementation details from dialog usage. If there are cases where callbacks don't suffice, we can think about ways to work around. In my opinion, that should go by enhancing the callback mechanism accordingly. the dialog callbacks work great for Dialog initiated events, but not so nicely when you have triggers/events coming from other stimuli and in which you no longer have access to the appropriate information. I think at a minimum it may be a good thing to expose terminate_dlg at C level API afterall you would think that this would be a natural sort of function to expose. As far as the others are concerned lets see if we can work around. One other thing we were thinking of is adding a rivet gun framework to the dialog module. Here you could effectively added meta information to a dialog through the callbacks for module specific (dialog-relayed) information. So in essence you can think of attaching nuggets of information (rivets) to the dialog in the form a void*. the modules could then also possible pass a code/decode function for the void* to the appropriate information for that module (more like a serialiser/deserialiser actually). I think this could also add some nice value as it will prevent modules having to store extra references in their own code to map data to a dialog. p.s. thanks for you indepth look into this and your valuable comments Cheers Jason Cheers, --Timo _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev