[sr-dev] Exposing additional dialog functions through API
Jason Penton
jason.penton at gmail.com
Fri Aug 12 17:54:10 CEST 2011
yeah agree, ok will do that
cheers
Jason
On Fri, Aug 12, 2011 at 5:44 PM, Daniel-Constantine Mierla <
miconda at gmail.com> wrote:
> Hi Jason,
>
> I wonder if it wouldn't be better to give the dialog I'd tokens as
> parameter to the function you just exported to C API. Then search for dialog
> and gets its pointer before calling the dlg bye function. It should be safer
> than working with the dlg pointer from outside, since the dialog may be
> destroyed at any moment by dialog module and the pointer becomes invalid.
>
> A wrapper function can be defined in order to be exported to C API, where
> to take cae of locking if needed, as well.
>
> Cheers,
> Daniel
>
>
> On Aug 12, 2011, at 4:13 PM, Jason Penton <jason.penton at gmail.com> wrote:
>
> great - thanks Daniel, will do.
>
> Cheers
> Jason
>
> On Fri, Aug 12, 2011 at 3:33 PM, Daniel-Constantin Mierla <<miconda at gmail.com>
> miconda at gmail.com> wrote:
>
>>
>>
>> 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>
>> 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>
>>> 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>
>>>> timo.reimann at 1und1.de
>>>> > <mailto: <timo.reimann at 1und1.de>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>
>>>> timo.reimann at 1und1.de
>>>> > <mailto: <timo.reimann at 1und1.de>timo.reimann at 1und1.de>
>>>> > > <mailto: <timo.reimann at 1und1.de>timo.reimann at 1und1.de <mailto:<timo.reimann at 1und1.de>
>>>> 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>sr-dev at lists.sip-router.org
>>>> <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev>
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing list <sr-dev at lists.sip-router.org>sr-dev at lists.sip-router.org <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla -- <http://www.asipto.com>http://www.asipto.com
>>> Kamailio Advanced Training, Oct 10-13, Berlin: <http://asipto.com/u/kat>http://asipto.com/u/kat <http://linkedin.com/in/miconda>http://linkedin.com/in/miconda -- <http://twitter.com/miconda>http://twitter.com/miconda
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierla -- <http://www.asipto.com>http://www.asipto.com
>> Kamailio Advanced Training, Oct 10-13, Berlin: <http://asipto.com/u/kat>http://asipto.com/u/kat <http://linkedin.com/in/miconda>http://linkedin.com/in/miconda -- <http://twitter.com/miconda>http://twitter.com/miconda
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110812/92b0cd0f/attachment-0001.htm>
More information about the sr-dev
mailing list