[sr-dev] Exposing additional dialog functions through API
Jason Penton
jason.penton at gmail.com
Fri Aug 12 15:27:33 CEST 2011
great, that's perfect!
On Fri, Aug 12, 2011 at 3:22 PM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:
> 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>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>> 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>>>
>> 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
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>
>
>
> _______________________________________________
> sr-dev mailing listsr-dev at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110812/7161ee7d/attachment-0001.htm>
More information about the sr-dev
mailing list