[sr-dev] Exposing additional dialog functions through API

Jason Penton jason.penton at gmail.com
Fri Aug 12 16:13:48 CEST 2011


great - thanks Daniel, will do.

Cheers
Jason

On Fri, Aug 12, 2011 at 3:33 PM, Daniel-Constantin Mierla <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> 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
>>
>>
>
> --
> 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/910ef7ad/attachment-0001.htm>


More information about the sr-dev mailing list