You are right about the stop packet.
But what about the acct start packet?
If I put that on the session's thread that holds
the call from continuing.
Maybe a mixed solution (the acct start uses an event handler
and the acct stop uses a state handler) will be my last resort.
Anthony Minessale wrote:
What other flow of the call are you waiting for?
The hangup state handler is close to the last thing executed by the
session thread before it's destroyed.
The session thread has nothing better to do while it's waiting for the
reply.
On Mon, Feb 2, 2009 at 4:49 PM, r...@kinetix.gr
<mailto:r...@kinetix.gr> <r...@kinetix.gr <mailto:r...@kinetix.gr>> wrote:
If the session thread makes the radius connection (and waits for
it to complete)
the flow of the call will be interrupted until the the radius code
finishes (current implementation).
this is why I figured that I need another thread in order to let
the session continue
whatever steps it needs until the completion of the call. this
parallel thread (radius thread)
could continue trying to send the radius packet even after the end
of the call/session (desired
implementation).
I undesrtand now that the session_locate function stands in the
way of I am trying to accomplish
but I am afraid that using the session's thread (instead of a
parallel one) would not meet my needs.
I examined the code of the function and saw that it locks the
session and that I need to unlock it myself.
Although it works on the creation of a channel it does not work on
the hangup (I get a core dump).
I'll continue with it tomorrow.
The state event handler is not suitable because I need to get an
acct start on both call legs of a bridge
and none of the state handlers in the state handler table does
that for the b-leg.
Anthony Minessale wrote:
The session runs in it's own thread when you use session_locate
to find a pointer to the session you stop that session from
exiting until you release it from the same thread you called
session_locate from.
So the session could have just done the radius connection itself
in it's perfectly good existing thread.
now you are detaining the session and creating a new thread thus
wasting the session thread.
instead of an event handler you may want to use a state handler
so you can run the stuff in the session thread.
On Mon, Feb 2, 2009 at 11:18 AM, r...@kinetix.gr
<mailto:r...@kinetix.gr> <r...@kinetix.gr
<mailto:r...@kinetix.gr>> wrote:
Correct me if I am wrong, but wouldn't a fifo queue (along
with its processing thread)
process the radius packets to be sent in a sequential manner?
And If a packet submission
got stuck for retries*timeout secs wouldn't that affect the
packets that wait in the queue?
What I am trying to implement is different. I want the
transmission of the radius packets
to be independent of any sequence or order... That's why I am
creating a new thread
for each one, then detaching the thread, stalling the session
with a lock until I get all the
info I want from it and in the end notifying the calling
function that it is free to continue (even to destroy the
session).
Also, does the event message contain all the possible info
for a session/channel/profile of a
call leg?
Anthony Minessale wrote:
when you call session = switch_core_session_locate(uuid);
if session is not NULL you MUST
switch_core_session_rwunlock(session) before you exit your
function.
I have already pointed out 2 times now that you should not
try to session_locate the session, you should be using the
data for the event for this, and dup the event and hand the
info to a backend thread over a fifo queue?
On Mon, Feb 2, 2009 at 6:02 AM, Apostolos Pantsiopoulos
<r...@kinetix.gr <mailto:r...@kinetix.gr>> wrote:
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 <r...@kinetix.gr
<mailto:r...@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 <r...@kinetix.gr
<mailto:r...@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: r...@kinetix.gr <mailto:r...@kinetix.gr>
-------------------------------------------
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
<mailto: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_miness...@hotmail.com
<mailto:msn%3aanthony_miness...@hotmail.com>
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
<mailto:paypal%3aanthony.miness...@gmail.com>
IRC: irc.freenode.net <http://irc.freenode.net>
#freeswitch
FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org
<mailto:sip%3a...@conference.freeswitch.org>
iax:gu...@conference.freeswitch.org/888
<http://iax:gu...@conference.freeswitch.org/888>
googletalk:conf+...@conference.freeswitch.org
<mailto:googletalk%3aconf%2b...@conference.freeswitch.org>
pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
<mailto: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: r...@kinetix.gr <mailto:r...@kinetix.gr>
-------------------------------------------
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
<mailto: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_miness...@hotmail.com
<mailto:msn%3aanthony_miness...@hotmail.com>
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
<mailto:paypal%3aanthony.miness...@gmail.com>
IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org
<mailto:sip%3a...@conference.freeswitch.org>
iax:gu...@conference.freeswitch.org/888
<http://iax:gu...@conference.freeswitch.org/888>
googletalk:conf+...@conference.freeswitch.org
<mailto:googletalk%3aconf%2b...@conference.freeswitch.org>
pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
<mailto: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: r...@kinetix.gr <mailto:r...@kinetix.gr>
-------------------------------------------
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
<mailto: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_miness...@hotmail.com
<mailto:msn%3aanthony_miness...@hotmail.com>
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
<mailto:paypal%3aanthony.miness...@gmail.com>
IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org
<mailto:sip%3a...@conference.freeswitch.org>
iax:gu...@conference.freeswitch.org/888
<http://iax:gu...@conference.freeswitch.org/888>
googletalk:conf+...@conference.freeswitch.org
<mailto:googletalk%3aconf%2b...@conference.freeswitch.org>
pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
<mailto: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
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
<mailto: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_miness...@hotmail.com
<mailto:msn%3aanthony_miness...@hotmail.com>
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
<mailto:paypal%3aanthony.miness...@gmail.com>
IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org
<mailto:sip%3a...@conference.freeswitch.org>
iax:gu...@conference.freeswitch.org/888
<http://iax:gu...@conference.freeswitch.org/888>
googletalk:conf+...@conference.freeswitch.org
<mailto:googletalk%3aconf%2b...@conference.freeswitch.org>
pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ Freeswitch-dev
mailing list Freeswitch-dev@lists.freeswitch.org
<mailto: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
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
<mailto: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_miness...@hotmail.com
<mailto:msn%3aanthony_miness...@hotmail.com>
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
<mailto:paypal%3aanthony.miness...@gmail.com>
IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org
<mailto:sip%3a...@conference.freeswitch.org>
iax:gu...@conference.freeswitch.org/888
<http://iax:gu...@conference.freeswitch.org/888>
googletalk:conf+...@conference.freeswitch.org
<mailto:googletalk%3aconf%2b...@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: r...@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
