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

great, that's perfect! On Fri, Aug 12, 2011 at 3:22 PM, Daniel-Constantin Mierla &lt;miconda(a)gmail.com > Hello, > > exporting through C api the functions to create/terminate dialogs is on > some to-do list for myself, with the primary goal to make them available on > Lua/other embedded language interpreters. > > I would prefer as well not to export the low level implementation details > unless really necessary, but anything that is exported to config or MI/RPC > interfaces should be safe to be exported to the inter-module C api. > > Cheers, > DAniel > > > On 8/12/11 3:14 PM, Jason Penton wrote: > > Hey Timo > > On Fri, Aug 12, 2011 at 2:53 PM, Timo Reimann &lt;timo.reimann(a)1und1.de&gt;wrote;wrote: > >> Hey Jason, >> >> >> On 12.08.2011 13:50, Jason Penton wrote: >> > Ok, I agree with you on the reference counting - this can be avoided by >> > keeping the h_entry:h_id pair instead of a pointer to dlg. The reason I >> > was doing the ref was to make sure that the dialog module does not >> > delete a dialog under a modules feet (in which case a module would hold >> > a pointer to memory that has been freed). However, to avoid this we can >> > just call lookup_dlg passing in the entry:id pair. (another reason why >> > we would need lookup_dlg to be exposed ;) >> >> 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 we just use as one example the Ro interface we have built. >> > Effectivley Ro is used in the IMS world for online charging (i.e. >> > realtime charing during the call). So naturally, this module is dialog >> > aware. What we do is keep a mapping between the dialog and the >> > particular Ro session (Ro session exists between Kamailio and an OCS >> > (online charging system). This is the reason for storing the dialog >> > pointer or id pairs. Now, when we run out of credit - the OCS will deny >> > a new batch of requested credit. In this case we lookup the >> > corresponding dialog associated to the Ro session and tear it down, >> > using terminate_dlg function >> >> 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 really think there are a number of scenarios where these extended API >> > functions could be used so as to ensure modules don't have to replicate >> > what alrady exists in the dialog module, from both memory and processing >> > perspective. >> >> 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 >> >> >> >> > On Fri, Aug 12, 2011 at 12:58 PM, Timo Reimann &lt;timo.reimann(a)1und1.de >> > <mailto:timo.reimann@1und1.de>>> > >> > Hey Jason, >> > >> > >> > On 12.08.2011 12:54, Jason Penton wrote: >> > > this wont be available to configuration users but to other modules >> > > through API. >> > >> > Ok, thanks for clarifying this. Still, allowing other modules to >> fiddle >> > with referencing counting is a no-go IMHO. >> > >> > >> > > On phone now so will respond to use cases when I'm back at my PC >> > >> > Sounds good! >> > >> > >> > Cheers, >> > >> > --Timo >> > >> > >> > >> > > On Aug 12, 2011 12:48 PM, "Timo Reimann" &lt;timo.reimann(a)1und1.de >> > <mailto:timo.reimann@1und1.de> >> > > <mailto:timo.reimann@1und1.de <mailto:timo.reimann@1und1.de>>> >>> > >> Hey, >> > >> >> > >> >> > >> On 12.08.2011 12:33, Jason Penton wrote: >> > >>> We are currently refactoring and cleaning the various IMS >> > modules for >> > >>> inclusion into SR, diameter_rx, diameter_cxdx, diameter_ro, etc. >> > >>> >> > >>> One thing we have noticed is that the use of dialog module >> functions >> > >>> would make the code alot better and cleaner, so 2 questions: >> > >>> >> > >>> 1. why is the Dialog module not exposing more if its methods? >> > >>> 2. Can we put in a patch to expose the ones we require. >> > >>> >> > >>> Currently, we have exposed and are using the following: >> > >>> >> > >>> lookup_dlg; >> > >>> terminate_dlg; >> > >>> get_dlg; >> > >>> unref_dlg; >> > >>> ref_dlg; >> > >> >> > >> I strongly opt against exporting any functions related to >> reference >> > >> management. It's already hard to handle reference counting >> properly >> > >> inside the module; allowing configuration users to touch that >> part of >> > >> the module will likely result in all kinds of ugly bugs. IMHO, >> > it's best >> > >> to keep it internal and provide functions to whatever feature you >> > like. >> > >> There's already a bunch of dialog PVs and (more recently) the >> very >> > >> generic dialog variable mechanism which allows you to do a series >> of >> > > things. >> > >> >> > >> Regarding the other functions you mentioned, can you outline what >> > your >> > >> use case for those is? >> > >> >> > >> >> > >> 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 listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > -- > Daniel-Constantin Mierla -- http://www.asipto.com > Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda > >