Anthony,
I need your help in clarifying something.
I my module load function I am using this to bind a handler to a
specific event (channel create) :
if (switch_event_bind(modname, SWITCH_EVENT_CHANNEL_CREATE,
SWITCH_EVENT_SUBCLASS_ANY, my_on_create_handler, NULL) !=
SWITCH_STATUS_SUCCESS) {
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR,
"Couldn't bind!\n");
return SWITCH_STATUS_GENERR;
}
Then in my my_on_create_handler routine I have :
static void my_on_create_handler(switch_event_t *event) {
char* uuid = switch_event_get_header(event, "Unique-ID");
switch_core_session_t *session;
session = switch_core_session_locate(uuid);
}
this is only for test purposes. My handler does nothing else than
creating a pointer to the session that
triggered the event. Everything compiles just fine. When I am running
freeswitch everything goes
as expected (my handling routine is called and a session is indeed
returned on my local session variable)
except from one thing : I can see doing a "ps -eLf" that the session
threads of my call get stuck and never get terminated.
I can also tell that they are stuck by that error message in my console
:
switch_core_session_hupall() Giving up with 42 sessions remaining
which makes sense since I initiated 21 bridged calls.
Is the reference (pointer) to the session the cause of all these? Does
FS considers that
since there are still references to a session the session should not be
terminated? If yes,
how can I destroy this reference (after I have used it)?
Anthony Minessale wrote:
No problem, I have the advantage That I
have implemented
this technique all over the place ;)
Your event handler is the recipient end of that same algorithm.
In fact the events are a very good thing to pass into queues.
You could clone the event and insert the clone into the queue and when
you pop it from the
backend thread you can just destroy it there then.
On Fri, Jan 30, 2009 at 8:27 AM,
Apostolos
Pantsiopoulos
<regs@kinetix.gr>
wrote:
Wow. I didn't expect so
much detailing :)
Thanks for the idea.
My implementation is different though, but yours seems to be better.
I will conclude what I started doing now and get back to you with the
results.
If something is wrong against my implementation I will try doing it
your way.
Thanks again!
Anthony Minessale wrote:
use a queue object to send the data in a
dynamic struct to
the other thread.
1) create a global queue.
2) create a struct with all the info you need to send.
on the event handler.
1) malloc a new struct of that type.
2) memset it to all 0.
3) populate the struct.
4) write the data into the queue.
launch a thread at startup that does a blocking wait on the same queue
1) pop the void pointer off the queue.
2) cast it into your struct.
3) extract the data from the struct and send it over radius.
4) destroy the struct with free and loop.
On Fri, Jan 30, 2009 at 5:14 AM,
Apostolos
Pantsiopoulos
<regs@kinetix.gr>
wrote:
Hi,
I am tweaking the mod_radius_cdr module to archive the behavior
that most NASes have (i.e. accounting packets are sent in a separate
thread so that the submission does not interfere with the execution of
the call). While doing that, however, I bumped into another behavior of
the module that I think is not desirable (at least by me) :
While on a bridge, the module sends one acct start packet at the
beginning of the originating
leg (on_routing event handler) and two acct stop packets at the end of
each leg
(inbound and outbound). My opinion is that it should send one accounting
start
packet at the beginning of each call leg (inbound, outbound) resulting
to a total
number of two acct start packets. It is generally accepted that acct
start/stop packets
come in pairs so that billing applications can handle them accordingly.
Some NAS's radius radius implementations have some other
configuration modes
like the Cisco's RADIUS Packet Suppression. When in this mode the Cisco
NAS
sends only an accounting start/stop pair at the end of a final dialpeer
attempt (and suppresses
all the previous failed dialpeer attempts) thus resulting to less
network traffic. Other
NASes (such as MERA MVTS) can send a start/stop pair for each leg OR a
start/stop
pair for each end to end call, depending on the configuration. Opensips
follows
the star/stop pair by call leg paradigm. No matter what the
implementation, all of them
always send a acct start/stop pair. This is a common thing. And all the
billing platforms
can deal only with paired start/stops.
The current module behavior (one start two stops) can complicate
things since the
radius server would not know how to match the second stop packet with
its equivalent start.
Before I get the infamous answer "pathes welcomed" I would like to
state that I am
already involved in changing this behavior (through a patch). So my real
question is this :
I noticed that the module uses the switch_core_add_state_handler
function to register
its handler table :
switch_core_add_state_handler(&state_handlers);
So the on_routing ( or the on_execute) event happens only when the
inbound call is started.
When the outbound call is initiated no handler is available to hook up a
function and
send the proper acct start packet.
Should the module register its handlers using the
switch_channel_add_state_handler() function instead?
And if yes, how could the module pass the channel as a parameter to the
function since channels
are created and destroyed dynamically (and the module when initialized
does not have that info).
I would greatly appreciate your help in pinpointing a proper way to
call my event handling
routines on a per call leg basis.
--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs@kinetix.gr
-------------------------------------------
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
--
Anthony Minessale II
FreeSWITCH
http://www.freeswitch.org/
ClueCon
http://www.cluecon.com/
AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/
PAYPAL:anthony.minessale@gmail.com
IRC:
irc.freenode.net
#freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:213-799-1400
--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs@kinetix.gr
-------------------------------------------
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net
#freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:213-799-1400
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs@kinetix.gr
-------------------------------------------