[sr-dev] Exposing additional dialog functions through API

[Jason Penton]

Hey Timo,

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 ;)

Ok Scenarios:

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

I hope this explains one of the scenarios.

We have a similar scenario with the Rx interface where we store links
between dialogs and PCC (policy and charging control) sessions - think of
this as QoS bandwidth reservation on EPC network.

Hope this makes sense.

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.

Cheers
Jason


On Fri, Aug 12, 2011 at 12:58 PM, Timo Reimann <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>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110812/552aa88c/attachment.htm>