<html><body bgcolor="#FFFFFF"><div>Hi Jason,</div><div><br></div><div>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.</div><div><br></div><div>A wrapper function can be defined in order to be exported to C API, where to take cae of locking if needed, as well.</div><div><br></div><div>Cheers,</div><div>Daniel<br><br>On Aug 12, 2011, at 4:13 PM, Jason Penton <<a href="mailto:jason.penton@gmail.com">jason.penton@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>great - thanks Daniel, will do.<br><br>Cheers<br>Jason<br><br><div class="gmail_quote">On Fri, Aug 12, 2011 at 3:33 PM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com"><a href="mailto:miconda@gmail.com">miconda@gmail.com</a></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">
<br>
<br>
On 8/12/11 3:27 PM, Jason Penton wrote:
<blockquote type="cite">great, that's perfect!<br>
</blockquote>
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.<br>
<br>
Cheers,<br><font color="#888888">
Daniel</font><div><div></div><div class="h5"><br>
<br>
<blockquote type="cite"><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" target="_blank"><a href="mailto:miconda@gmail.com">miconda@gmail.com</a></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><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"><a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a></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"><a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a></a><br>
</div>
<div>> <mailto:<a href="mailto:timo.reimann@1und1.de" target="_blank"><a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a></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"><a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a></a><br>
> <mailto:<a href="mailto:timo.reimann@1und1.de" target="_blank"><a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a></a>><br>
</div>
<div>
<div>> > <mailto:<a href="mailto:timo.reimann@1und1.de" target="_blank"><a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a></a>
<mailto:<a href="mailto:timo.reimann@1und1.de" target="_blank"><a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a></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"><a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a></a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank"><a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a></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"><a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a></a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank"><a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a></a>
</pre>
</blockquote>
<br>
</div>
</div>
<font color="#888888">
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank"><a href="http://www.asipto.com">http://www.asipto.com</a></a>
Kamailio Advanced Training, Oct 10-13, Berlin: <a href="http://asipto.com/u/kat" target="_blank"><a href="http://asipto.com/u/kat">http://asipto.com/u/kat</a></a>
<a href="http://linkedin.com/in/miconda" target="_blank"><a href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a></a> -- <a href="http://twitter.com/miconda" target="_blank"><a href="http://twitter.com/miconda">http://twitter.com/miconda</a></a></pre>
</font></div>
</blockquote>
</div>
<br>
</blockquote>
<br>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank"><a href="http://www.asipto.com">http://www.asipto.com</a></a>
Kamailio Advanced Training, Oct 10-13, Berlin: <a href="http://asipto.com/u/kat" target="_blank"><a href="http://asipto.com/u/kat">http://asipto.com/u/kat</a></a>
<a href="http://linkedin.com/in/miconda" target="_blank"><a href="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</a></a> -- <a href="http://twitter.com/miconda" target="_blank"><a href="http://twitter.com/miconda">http://twitter.com/miconda</a></a></pre>
</div></div></div>
</blockquote></div><br>
</div></blockquote></body></html>