<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Wow. I didn't expect so much detailing :)<br>
<br>
Thanks for the idea.<br>
<br>
My implementation is different though, but yours seems to be better.<br>
<br>
I will conclude what I started doing now and get back to you with the
results.<br>
<br>
If something is wrong against my implementation I will try doing it
your way.<br>
<br>
Thanks again!<br>
<br>
Anthony Minessale wrote:
<blockquote
cite="mid:191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com"
type="cite">use a queue object to send the data in a dynamic struct to
the other thread.<br>
<br>
1) create a global queue.<br>
2) create a struct with all the info you need to send.<br>
<br>
on the event handler.<br>
<br>
1) malloc a new struct of that type.<br>
2) memset it to all 0.<br>
3) populate the struct.<br>
4) write the data into the queue.<br>
<br>
launch a thread at startup that does a blocking wait on the same queue<br>
<br>
1) pop the void pointer off the queue.<br>
2) cast it into your struct.<br>
3) extract the data from the struct and send it over radius.<br>
4) destroy the struct with free and loop.<br>
<br>
<br>
<div class="gmail_quote">On Fri, Jan 30, 2009 at 5:14 AM, Apostolos
Pantsiopoulos <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:regs@kinetix.gr">regs@kinetix.gr</a>></span> wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
I am tweaking the mod_radius_cdr module to archive the behavior<br>
that most NASes have (i.e. accounting packets are sent in a separate<br>
thread so that the submission does not interfere with the execution of<br>
the call). While doing that, however, I bumped into another behavior of<br>
the module that I think is not desirable (at least by me) :<br>
<br>
While on a bridge, the module sends one acct start packet at the<br>
beginning of the originating<br>
leg (on_routing event handler) and two acct stop packets at the end of<br>
each leg<br>
(inbound and outbound). My opinion is that it should send one accounting<br>
start<br>
packet at the beginning of each call leg (inbound, outbound) resulting<br>
to a total<br>
number of two acct start packets. It is generally accepted that acct<br>
start/stop packets<br>
come in pairs so that billing applications can handle them accordingly.<br>
<br>
Some NAS's radius radius implementations have some other<br>
configuration modes<br>
like the Cisco's RADIUS Packet Suppression. When in this mode the Cisco
NAS<br>
sends only an accounting start/stop pair at the end of a final dialpeer<br>
attempt (and suppresses<br>
all the previous failed dialpeer attempts) thus resulting to less<br>
network traffic. Other<br>
NASes (such as MERA MVTS) can send a start/stop pair for each leg OR a<br>
start/stop<br>
pair for each end to end call, depending on the configuration. Opensips<br>
follows<br>
the star/stop pair by call leg paradigm. No matter what the<br>
implementation, all of them<br>
always send a acct start/stop pair. This is a common thing. And all the<br>
billing platforms<br>
can deal only with paired start/stops.<br>
<br>
The current module behavior (one start two stops) can complicate<br>
things since the<br>
radius server would not know how to match the second stop packet with<br>
its equivalent start.<br>
<br>
Before I get the infamous answer "pathes welcomed" I would like to<br>
state that I am<br>
already involved in changing this behavior (through a patch). So my real<br>
question is this :<br>
<br>
I noticed that the module uses the switch_core_add_state_handler<br>
function to register<br>
its handler table :<br>
<br>
switch_core_add_state_handler(&state_handlers);<br>
<br>
So the on_routing ( or the on_execute) event happens only when the<br>
inbound call is started.<br>
When the outbound call is initiated no handler is available to hook up a<br>
function and<br>
send the proper acct start packet.<br>
<br>
Should the module register its handlers using the<br>
switch_channel_add_state_handler() function instead?<br>
And if yes, how could the module pass the channel as a parameter to the<br>
function since channels<br>
are created and destroyed dynamically (and the module when initialized<br>
does not have that info).<br>
<br>
I would greatly appreciate your help in pinpointing a proper way to<br>
call my event handling<br>
routines on a per call leg basis.<br>
<br>
<br>
--<br>
-------------------------------------------<br>
Apostolos Pantsiopoulos<br>
Kinetix Tele.com R & D<br>
email: <a moz-do-not-send="true" href="mailto:regs@kinetix.gr">regs@kinetix.gr</a><br>
-------------------------------------------<br>
<br>
<br>
_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a><br>
<a moz-do-not-send="true"
href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev"
target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a moz-do-not-send="true"
href="http://lists.freeswitch.org/mailman/options/freeswitch-dev"
target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a moz-do-not-send="true" href="http://www.freeswitch.org"
target="_blank">http://www.freeswitch.org</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a moz-do-not-send="true" href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>
ClueCon <a moz-do-not-send="true" href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>
AIM: anthm<br>
<a moz-do-not-send="true"
href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a moz-do-not-send="true"
href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a moz-do-not-send="true" href="http://irc.freenode.net">irc.freenode.net</a>
#freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a moz-do-not-send="true"
href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br>
<a moz-do-not-send="true"
href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a moz-do-not-send="true"
href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:213-799-1400<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Freeswitch-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a>
UNSUBSCRIBE:<a class="moz-txt-link-freetext" href="http://lists.freeswitch.org/mailman/options/freeswitch-dev">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a>
<a class="moz-txt-link-freetext" href="http://www.freeswitch.org">http://www.freeswitch.org</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: <a class="moz-txt-link-abbreviated" href="mailto:regs@kinetix.gr">regs@kinetix.gr</a>
------------------------------------------- </pre>
</body>
</html>