[sr-dev] Exposing additional dialog functions through API
Daniel-Constantin Mierla
miconda at gmail.com
Fri Aug 12 15:22:28 CEST 2011
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 <timo.reimann at 1und1.de
> <mailto:timo.reimann at 1und1.de>> 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
> <timo.reimann at 1und1.de <mailto:timo.reimann at 1und1.de>
> > <mailto:timo.reimann at 1und1.de <mailto:timo.reimann at 1und1.de>>>
> wrote:
> >
> > 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"
> <timo.reimann at 1und1.de <mailto:timo.reimann at 1und1.de>
> > <mailto:timo.reimann at 1und1.de <mailto:timo.reimann at 1und1.de>>
> > > <mailto:timo.reimann at 1und1.de <mailto:timo.reimann at 1und1.de>
> <mailto:timo.reimann at 1und1.de <mailto:timo.reimann at 1und1.de>>>> wrote:
> > >> 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 at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://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/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110812/ff1be047/attachment.htm>
More information about the sr-dev
mailing list