14 Aug
2011
14 Aug
'11
1:19 a.m.
Hey Jason,
Am 12.08.2011 um 15:14 schrieb Jason Penton:
Ok, I suspected something like this but my level of knowledge regarding IMS is quite
limited. :) Thanks for clearing this up.
On 12.08.2011 13:50, Jason Penton wrote:
Ok, problem understood now. The way to do a) by means of the callback mechanism is to
store a minimum set of data for each active callback in order to make the proper
association when required. Obviously, this can be tedious and resource-consuming in
high-call scenarios as you would need to keep a lot of "linking" data at any
time.
The major alternative in my point of view, however, is to walk the entire dialog hash
table in order to find the calls which are to be terminated. If the number of dialogs is
large this may take a lot of time because of the walk itself and the fact that you'd
have to block all other processes requesting hash table access by means of table locking
(which is required to avoid table inconsistency). I am not sure if this is something you
would want to do in many scenarios.
So what approach in terms of API and implementation do you have in mind in order to
achieve a) ?
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.
Good point. And as Daniel already pointed out, there's no reason to hide functions
available to the configuration file from module users.
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).
This sounds pretty much like the dialog variable functionality added recently with the
exception of the code/decode function. As of now, dialog variables are just strings and
have no typing notion associated to them. So one idea I could think of is to add
code/decode functions to the dialog variables to achieve the rivet gun framework you
described.
Cheers,
--Timo
> On Fri, Aug 12, 2011 at 12:58 PM, Timo Reimann
<timo.reimann(a)1und1.de
> <mailto:timo.reimann@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(a)1und1.de
> <mailto:timo.reimann@1und1.de>
> > <mailto:timo.reimann@1und1.de
<mailto:timo.reimann@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