great, that's perfect!<br><br><div class="gmail_quote">On Fri, Aug 12, 2011 at 3:22 PM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
DAniel<div><div></div><div class="h5"><br>
<br>
On 8/12/11 3:14 PM, Jason Penton wrote:
<blockquote type="cite">Hey Timo<br>
<br>
<div class="gmail_quote">On Fri, Aug 12, 2011 at 2:53 PM, Timo
Reimann <span dir="ltr"><<a href="mailto:timo.reimann@1und1.de" target="_blank">timo.reimann@1und1.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey Jason,<br>
<div><br>
<br>
On 12.08.2011 13:50, Jason Penton wrote:<br>
> Ok, I agree with you on the reference counting - this
can be avoided by<br>
> keeping the h_entry:h_id pair instead of a pointer to
dlg. The reason I<br>
> was doing the ref was to make sure that the dialog
module does not<br>
> delete a dialog under a modules feet (in which case a
module would hold<br>
> a pointer to memory that has been freed). However, to
avoid this we can<br>
> just call lookup_dlg passing in the entry:id pair.
(another reason why<br>
> we would need lookup_dlg to be exposed ;)<br>
<br>
</div>
A much easier approach IMHO would be to register a callback to<br>
DLGCB_DESTROY or DLGCB_TERMINATE. That way, you'll be notified<br>
automatically when the dialog is destroyed/terminated and
don't need to<br>
deal with implementation details such as hash table keys.<br>
<br>
You could also use other dialog callbacks to react to specific
dialog<br>
lifetime phases. See the docs for details.<br>
</blockquote>
<div><br>
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:<br>
<br>
a) we need to find the associated / affected dialogs<br>
b) terminate them<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><br>
<br>
> If we just use as one example the Ro interface we have
built.<br>
> Effectivley Ro is used in the IMS world for online
charging (i.e.<br>
> realtime charing during the call). So naturally, this
module is dialog<br>
> aware. What we do is keep a mapping between the dialog
and the<br>
> particular Ro session (Ro session exists between
Kamailio and an OCS<br>
> (online charging system). This is the reason for
storing the dialog<br>
> pointer or id pairs. Now, when we run out of credit -
the OCS will deny<br>
> a new batch of requested credit. In this case we lookup
the<br>
> corresponding dialog associated to the Ro session and
tear it down,<br>
> using terminate_dlg function<br>
<br>
</div>
If you really need to terminate calls proxy-wise, I agree you
need some<br>
terminate function. It's usefulness might be restricted in
your case as<br>
mischievious clients may just ignore your BYE request. I don't
know your<br>
exact setup, however, so this objection might not count.<br>
</blockquote>
<div><br>
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 ;)<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
Assuming that it holds I think dialog callbacks, again, are
the way to<br>
hook into the dialog module. Just keep registering for new
dialogs<br>
(possibly "confirmed" ones only) and make your module logic
keep track<br>
of credits during the course of the call. Should the account
drop to<br>
zero while the dialog is still active, force termination.<br>
<br>
Termination, by the way, could also be implemented by letting
your<br>
module run a particular Kamailio route on zero credits which,
in turn,<br>
could call dlg_end_dlg(). That way, you wouldn't need to
export another<br>
function. I am not strictly against exporting the termination
function<br>
on C level though, just wanted to mention the route approach.<br>
</blockquote>
<div><br>
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.<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><br>
<br>
<br>
> I really think there are a number of scenarios where
these extended API<br>
> functions could be used so as to ensure modules don't
have to replicate<br>
> what alrady exists in the dialog module, from both
memory and processing<br>
> perspective.<br>
<br>
</div>
I'd be interested to know whether all these scenarios can be
covered by<br>
means of using the dialog callbacks as they nicely isolate<br>
implementation details from dialog usage. If there are cases
where<br>
callbacks don't suffice, we can think about ways to work
around. In my<br>
opinion, that should go by enhancing the callback mechanism
accordingly.<br>
</blockquote>
<div><br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
p.s. thanks for you indepth look into this and your valuable
comments<br>
<br>
Cheers <br>
Jason<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
<br>
Cheers,<br>
<font color="#888888"><br>
--Timo<br>
</font>
<div><br>
<br>
<br>
> On Fri, Aug 12, 2011 at 12:58 PM, Timo Reimann <<a href="mailto:timo.reimann@1und1.de" target="_blank">timo.reimann@1und1.de</a><br>
</div>
<div>> <mailto:<a href="mailto:timo.reimann@1und1.de" target="_blank">timo.reimann@1und1.de</a>>>
wrote:<br>
><br>
> Hey Jason,<br>
><br>
><br>
> On 12.08.2011 12:54, Jason Penton wrote:<br>
> > this wont be available to configuration users
but to other modules<br>
> > through API.<br>
><br>
> Ok, thanks for clarifying this. Still, allowing
other modules to fiddle<br>
> with referencing counting is a no-go IMHO.<br>
><br>
><br>
> > On phone now so will respond to use cases when
I'm back at my PC<br>
><br>
> Sounds good!<br>
><br>
><br>
> Cheers,<br>
><br>
> --Timo<br>
><br>
><br>
><br>
> > On Aug 12, 2011 12:48 PM, "Timo Reimann" <<a href="mailto:timo.reimann@1und1.de" target="_blank">timo.reimann@1und1.de</a><br>
> <mailto:<a href="mailto:timo.reimann@1und1.de" target="_blank">timo.reimann@1und1.de</a>><br>
</div>
<div>
<div>> > <mailto:<a href="mailto:timo.reimann@1und1.de" target="_blank">timo.reimann@1und1.de</a>
<mailto:<a href="mailto:timo.reimann@1und1.de" target="_blank">timo.reimann@1und1.de</a>>>>
wrote:<br>
> >> Hey,<br>
> >><br>
> >><br>
> >> On 12.08.2011 12:33, Jason Penton wrote:<br>
> >>> We are currently refactoring and
cleaning the various IMS<br>
> modules for<br>
> >>> inclusion into SR, diameter_rx,
diameter_cxdx, diameter_ro, etc.<br>
> >>><br>
> >>> One thing we have noticed is that
the use of dialog module functions<br>
> >>> would make the code alot better and
cleaner, so 2 questions:<br>
> >>><br>
> >>> 1. why is the Dialog module not
exposing more if its methods?<br>
> >>> 2. Can we put in a patch to expose
the ones we require.<br>
> >>><br>
> >>> Currently, we have exposed and are
using the following:<br>
> >>><br>
> >>> lookup_dlg;<br>
> >>> terminate_dlg;<br>
> >>> get_dlg;<br>
> >>> unref_dlg;<br>
> >>> ref_dlg;<br>
> >><br>
> >> I strongly opt against exporting any
functions related to reference<br>
> >> management. It's already hard to handle
reference counting properly<br>
> >> inside the module; allowing
configuration users to touch that part of<br>
> >> the module will likely result in all
kinds of ugly bugs. IMHO,<br>
> it's best<br>
> >> to keep it internal and provide
functions to whatever feature you<br>
> like.<br>
> >> There's already a bunch of dialog PVs
and (more recently) the very<br>
> >> generic dialog variable mechanism which
allows you to do a series of<br>
> > things.<br>
> >><br>
> >> Regarding the other functions you
mentioned, can you outline what<br>
> your<br>
> >> use case for those is?<br>
> >><br>
> >><br>
> >> Cheers,<br>
> >><br>
> >> --Timo<br>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
sr-dev mailing list
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
</blockquote>
<br>
</div></div><font color="#888888"><pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Kamailio Advanced Training, Oct 10-13, Berlin: <a href="http://asipto.com/u/kat" target="_blank">http://asipto.com/u/kat</a>
<a href="http://linkedin.com/in/miconda" target="_blank">http://linkedin.com/in/miconda</a> -- <a href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a></pre>
</font></div>
</blockquote></div><br>