[sr-dev] Exposing additional dialog functions through API
Daniel-Constantin Mierla
miconda at gmail.com
Fri Aug 12 15:33:00 CEST 2011
On 8/12/11 3:27 PM, Jason Penton wrote:
> great, that's perfect!
I forgot to mention that if someone is needing it before, just go ahead
and add, don't wait for me, should not be something complex to
implement. There is one function exported by dlg, so the inter-module
API struct and load function are there.
Cheers,
Daniel
>
> On Fri, Aug 12, 2011 at 3:22 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto: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 <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 <mailto: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
>
>
--
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/2afa700e/attachment-0001.htm>
More information about the sr-dev
mailing list