From regs at kinetix.gr  Mon Feb  2 04:02:07 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Mon, 02 Feb 2009 14:02:07 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>	<49830E65.9060106@kinetix.gr>
	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>
Message-ID: <4986E0BF.4020208@kinetix.gr>

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 at kinetix.gr <mailto:regs at 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 at kinetix.gr <mailto:regs at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>         -------------------------------------------
>>
>>
>>         _______________________________________________
>>         Freeswitch-dev mailing list
>>         Freeswitch-dev at lists.freeswitch.org
>>         <mailto:Freeswitch-dev at 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 at hotmail.com
>>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>>     FreeSWITCH Developer Conference
>>     sip:888 at conference.freeswitch.org
>>     <mailto:sip%3A888 at conference.freeswitch.org>
>>     iax:guest at conference.freeswitch.org/888
>>     <http://iax:guest at conference.freeswitch.org/888>
>>     googletalk:conf+888 at conference.freeswitch.org
>>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>     pstn:213-799-1400
>>     ------------------------------------------------------------------------
>>     _______________________________________________ Freeswitch-dev
>>     mailing list Freeswitch-dev at lists.freeswitch.org
>>     <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>     ------------------------------------------- 
>
>
>     _______________________________________________
>     Freeswitch-dev mailing list
>     Freeswitch-dev at lists.freeswitch.org
>     <mailto:Freeswitch-dev at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090202/d0038f69/attachment-0001.html 

From mike at jerris.com  Mon Feb  2 07:15:45 2009
From: mike at jerris.com (Michael Jerris)
Date: Mon, 2 Feb 2009 10:15:45 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
Message-ID: <47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>

We already have debian files in tree that should work, if they don't,  
we would appreciate all patches back in to tree.

Mike

On Jan 31, 2009, at 11:28 AM, Nicholas Santos wrote:

> Hi, I'm the current owner of the Freeswitch package on Debian  
> Testing (Lenny).
>
> I'm just beginning to package it, if there's something that I should  
> know before I package it, just say it. I'm here to do my best on  
> this that I consider a great step.
>
> Thanks in advance,
> Nicholas Amorim.
>
> PS: By the way, what a great piece of software! :)


From anthony.minessale at gmail.com  Mon Feb  2 07:44:23 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Mon, 2 Feb 2009 09:44:23 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <4986E0BF.4020208@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>
	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>
	<49830E65.9060106@kinetix.gr>
	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>
	<4986E0BF.4020208@kinetix.gr>
Message-ID: <191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>

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 <regs at 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 <regs at 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 at 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 at kinetix.gr
>>> -------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: regs at kinetix.gr
>> -------------------------------------------
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090202/17884082/attachment-0001.html 

From regs at kinetix.gr  Mon Feb  2 09:18:10 2009
From: regs at kinetix.gr (regs at kinetix.gr)
Date: Mon, 02 Feb 2009 19:18:10 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>	<49830E65.9060106@kinetix.gr>	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>	<4986E0BF.4020208@kinetix.gr>
	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>
Message-ID: <49872AD2.1070104@kinetix.gr>

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 
> <regs at kinetix.gr <mailto:regs at 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
>>     <regs at kinetix.gr <mailto:regs at 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 at kinetix.gr <mailto:regs at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>             -------------------------------------------
>>>
>>>
>>>             _______________________________________________
>>>             Freeswitch-dev mailing list
>>>             Freeswitch-dev at lists.freeswitch.org
>>>             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>         IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>>         FreeSWITCH Developer Conference
>>>         sip:888 at conference.freeswitch.org
>>>         <mailto:sip%3A888 at conference.freeswitch.org>
>>>         iax:guest at conference.freeswitch.org/888
>>>         <http://iax:guest at conference.freeswitch.org/888>
>>>         googletalk:conf+888 at conference.freeswitch.org
>>>         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>         pstn:213-799-1400
>>>         ------------------------------------------------------------------------
>>>         _______________________________________________
>>>         Freeswitch-dev mailing list
>>>         Freeswitch-dev at lists.freeswitch.org
>>>         <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>         ------------------------------------------- 
>>
>>
>>         _______________________________________________
>>         Freeswitch-dev mailing list
>>         Freeswitch-dev at lists.freeswitch.org
>>         <mailto:Freeswitch-dev at 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 at hotmail.com
>>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>>     FreeSWITCH Developer Conference
>>     sip:888 at conference.freeswitch.org
>>     <mailto:sip%3A888 at conference.freeswitch.org>
>>     iax:guest at conference.freeswitch.org/888
>>     <http://iax:guest at conference.freeswitch.org/888>
>>     googletalk:conf+888 at conference.freeswitch.org
>>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>     pstn:213-799-1400
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     Freeswitch-dev mailing list
>>     Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>     ------------------------------------------- 
>
>
>     _______________________________________________
>     Freeswitch-dev mailing list
>     Freeswitch-dev at lists.freeswitch.org
>     <mailto:Freeswitch-dev at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090202/0f8ba5f9/attachment-0001.html 

From anthony.minessale at gmail.com  Mon Feb  2 09:28:28 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Mon, 2 Feb 2009 11:28:28 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <49872AD2.1070104@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>
	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>
	<49830E65.9060106@kinetix.gr>
	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>
	<4986E0BF.4020208@kinetix.gr>
	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>
	<49872AD2.1070104@kinetix.gr>
Message-ID: <191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>

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, regs at kinetix.gr <regs at 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 <regs at 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 <regs at 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 at 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 at kinetix.gr
>>>> -------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing list
>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> -------------------------------------------
>>> Apostolos Pantsiopoulos
>>> Kinetix Tele.com R & D
>>> email: regs at kinetix.gr
>>> -------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: regs at kinetix.gr
>> -------------------------------------------
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090202/54764857/attachment-0001.html 

From anthony.minessale at gmail.com  Mon Feb  2 09:32:05 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Mon, 2 Feb 2009 11:32:05 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>
	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>
	<49830E65.9060106@kinetix.gr>
	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>
	<4986E0BF.4020208@kinetix.gr>
	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>
	<49872AD2.1070104@kinetix.gr>
	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>
Message-ID: <191c3a030902020932n4210ad9fj2577d7144fef0269@mail.gmail.com>

also? what is in the session that is not already in the event?

you should probably be looking for the channel_originate event not
channel_create where you will have all the data about the channel that you
need just in the event itself.


On Mon, Feb 2, 2009 at 11:28 AM, Anthony Minessale <
anthony.minessale at gmail.com> 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, regs at kinetix.gr <regs at 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 <regs at 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 <
>>> regs at 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 at 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 at kinetix.gr
>>>>> -------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing list
>>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>> IRC: irc.freenode.net #freeswitch
>>>>
>>>> FreeSWITCH Developer Conference
>>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>>> iax:guest at conference.freeswitch.org/888
>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>> pstn:213-799-1400
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>
>>>>
>>>>
>>>> --
>>>> -------------------------------------------
>>>> Apostolos Pantsiopoulos
>>>> Kinetix Tele.com R & D
>>>> email: regs at kinetix.gr
>>>> -------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing list
>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> -------------------------------------------
>>> Apostolos Pantsiopoulos
>>> Kinetix Tele.com R & D
>>> email: regs at kinetix.gr
>>> -------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090202/9cbd927e/attachment-0001.html 

From nicholas at montrealconsultoria.com.br  Mon Feb  2 10:09:25 2009
From: nicholas at montrealconsultoria.com.br (Nicholas Santos)
Date: Mon, 2 Feb 2009 15:09:25 -0300
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>
Message-ID: <8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>

Although those debian files surely do they job, they fail to accomplish all
debian rules and standards, so I'm changing a lot of things and surely I'll
sent back those patchs into tree.

On Mon, Feb 2, 2009 at 12:15 PM, Michael Jerris <mike at jerris.com> wrote:

> We already have debian files in tree that should work, if they don't,
> we would appreciate all patches back in to tree.
>
> Mike
>
> On Jan 31, 2009, at 11:28 AM, Nicholas Santos wrote:
>
> > Hi, I'm the current owner of the Freeswitch package on Debian
> > Testing (Lenny).
> >
> > I'm just beginning to package it, if there's something that I should
> > know before I package it, just say it. I'm here to do my best on
> > this that I consider a great step.
> >
> > Thanks in advance,
> > Nicholas Amorim.
> >
> > PS: By the way, what a great piece of software! :)
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090202/7cb05ea1/attachment.html 

From brian at freeswitch.org  Mon Feb  2 10:13:44 2009
From: brian at freeswitch.org (Brian West)
Date: Mon, 2 Feb 2009 12:13:44 -0600
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>
	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
Message-ID: <09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>

Nicholas,
	Do you want to have svn commit and control over the debs?  Someone to  
maintain them?  I'm also looking for someone to watch over and work  
the RPM spec file too.... Anyone Anyone?  Email me off list of find me  
on IRC bkw_ in #freeswitch on irc.freenode.net

/b

On Feb 2, 2009, at 12:09 PM, Nicholas Santos wrote:

> Although those debian files surely do they job, they fail to  
> accomplish all debian rules and standards, so I'm changing a lot of  
> things and surely I'll sent back those patchs into tree.



From regs at kinetix.gr  Mon Feb  2 14:49:54 2009
From: regs at kinetix.gr (regs at kinetix.gr)
Date: Tue, 03 Feb 2009 00:49:54 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>	<49830E65.9060106@kinetix.gr>	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>	<4986E0BF.4020208@kinetix.gr>	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>	<49872AD2.1070104@kinetix.gr>
	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>
Message-ID: <49877892.7000308@kinetix.gr>

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, regs at kinetix.gr 
> <mailto:regs at kinetix.gr> <regs at kinetix.gr <mailto:regs at 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
>>     <regs at kinetix.gr <mailto:regs at 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
>>>         <regs at kinetix.gr <mailto:regs at 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 at kinetix.gr
>>>>             <mailto:regs at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>                 -------------------------------------------
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 Freeswitch-dev mailing list
>>>>                 Freeswitch-dev at lists.freeswitch.org
>>>>                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>             IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>>
>>>>             FreeSWITCH Developer Conference
>>>>             sip:888 at conference.freeswitch.org
>>>>             <mailto:sip%3A888 at conference.freeswitch.org>
>>>>             iax:guest at conference.freeswitch.org/888
>>>>             <http://iax:guest at conference.freeswitch.org/888>
>>>>             googletalk:conf+888 at conference.freeswitch.org
>>>>             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>             pstn:213-799-1400
>>>>             ------------------------------------------------------------------------
>>>>             _______________________________________________
>>>>             Freeswitch-dev mailing list
>>>>             Freeswitch-dev at lists.freeswitch.org
>>>>             <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>             ------------------------------------------- 
>>>
>>>
>>>             _______________________________________________
>>>             Freeswitch-dev mailing list
>>>             Freeswitch-dev at lists.freeswitch.org
>>>             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>         IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>>         FreeSWITCH Developer Conference
>>>         sip:888 at conference.freeswitch.org
>>>         <mailto:sip%3A888 at conference.freeswitch.org>
>>>         iax:guest at conference.freeswitch.org/888
>>>         <http://iax:guest at conference.freeswitch.org/888>
>>>         googletalk:conf+888 at conference.freeswitch.org
>>>         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>         pstn:213-799-1400
>>>         ------------------------------------------------------------------------
>>>
>>>         _______________________________________________
>>>         Freeswitch-dev mailing list
>>>         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>         ------------------------------------------- 
>>
>>
>>         _______________________________________________
>>         Freeswitch-dev mailing list
>>         Freeswitch-dev at lists.freeswitch.org
>>         <mailto:Freeswitch-dev at 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 at hotmail.com
>>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>>     FreeSWITCH Developer Conference
>>     sip:888 at conference.freeswitch.org
>>     <mailto:sip%3A888 at conference.freeswitch.org>
>>     iax:guest at conference.freeswitch.org/888
>>     <http://iax:guest at conference.freeswitch.org/888>
>>     googletalk:conf+888 at conference.freeswitch.org
>>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>     pstn:213-799-1400
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     Freeswitch-dev mailing list
>>     Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>     <mailto:Freeswitch-dev at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/cbb088ab/attachment-0001.html 

From regs at kinetix.gr  Mon Feb  2 14:52:32 2009
From: regs at kinetix.gr (regs at kinetix.gr)
Date: Tue, 03 Feb 2009 00:52:32 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <191c3a030902020932n4210ad9fj2577d7144fef0269@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>	<49830E65.9060106@kinetix.gr>	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>	<4986E0BF.4020208@kinetix.gr>	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>	<49872AD2.1070104@kinetix.gr>	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>
	<191c3a030902020932n4210ad9fj2577d7144fef0269@mail.gmail.com>
Message-ID: <49877930.80503@kinetix.gr>

I have not gone very deep in the event mechanisms.
I'll have a look at it.


Anthony Minessale wrote:
> also? what is in the session that is not already in the event?
>
> you should probably be looking for the channel_originate event not 
> channel_create where you will have all the data about the channel that 
> you need just in the event itself.
>
>
> On Mon, Feb 2, 2009 at 11:28 AM, Anthony Minessale 
> <anthony.minessale at gmail.com <mailto:anthony.minessale at gmail.com>> 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, regs at kinetix.gr
>     <mailto:regs at kinetix.gr> <regs at kinetix.gr
>     <mailto:regs at 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
>>         <regs at kinetix.gr <mailto:regs at 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
>>>             <regs at kinetix.gr <mailto:regs at 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 at kinetix.gr
>>>>                 <mailto:regs at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>                     -------------------------------------------
>>>>
>>>>
>>>>                     _______________________________________________
>>>>                     Freeswitch-dev mailing list
>>>>                     Freeswitch-dev at lists.freeswitch.org
>>>>                     <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>                 <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>                 GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>                 <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>                 IRC: irc.freenode.net <http://irc.freenode.net>
>>>>                 #freeswitch
>>>>
>>>>                 FreeSWITCH Developer Conference
>>>>                 sip:888 at conference.freeswitch.org
>>>>                 <mailto:sip%3A888 at conference.freeswitch.org>
>>>>                 iax:guest at conference.freeswitch.org/888
>>>>                 <http://iax:guest at conference.freeswitch.org/888>
>>>>                 googletalk:conf+888 at conference.freeswitch.org
>>>>                 <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>                 pstn:213-799-1400
>>>>                 ------------------------------------------------------------------------
>>>>                 _______________________________________________
>>>>                 Freeswitch-dev mailing list
>>>>                 Freeswitch-dev at lists.freeswitch.org
>>>>                 <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>                 ------------------------------------------- 
>>>
>>>
>>>                 _______________________________________________
>>>                 Freeswitch-dev mailing list
>>>                 Freeswitch-dev at lists.freeswitch.org
>>>                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>             IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>>             FreeSWITCH Developer Conference
>>>             sip:888 at conference.freeswitch.org
>>>             <mailto:sip%3A888 at conference.freeswitch.org>
>>>             iax:guest at conference.freeswitch.org/888
>>>             <http://iax:guest at conference.freeswitch.org/888>
>>>             googletalk:conf+888 at conference.freeswitch.org
>>>             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>             pstn:213-799-1400
>>>             ------------------------------------------------------------------------
>>>
>>>             _______________________________________________
>>>             Freeswitch-dev mailing list
>>>             Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>             ------------------------------------------- 
>>
>>
>>             _______________________________________________
>>             Freeswitch-dev mailing list
>>             Freeswitch-dev at lists.freeswitch.org
>>             <mailto:Freeswitch-dev at 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 at hotmail.com
>>         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>         IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>>         FreeSWITCH Developer Conference
>>         sip:888 at conference.freeswitch.org
>>         <mailto:sip%3A888 at conference.freeswitch.org>
>>         iax:guest at conference.freeswitch.org/888
>>         <http://iax:guest at conference.freeswitch.org/888>
>>         googletalk:conf+888 at conference.freeswitch.org
>>         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>         pstn:213-799-1400
>>         ------------------------------------------------------------------------
>>
>>         _______________________________________________
>>         Freeswitch-dev mailing list
>>         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>         <mailto:Freeswitch-dev at 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 at hotmail.com
>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
>     FreeSWITCH Developer Conference
>     sip:888 at conference.freeswitch.org
>     <mailto:sip%3A888 at conference.freeswitch.org>
>     iax:guest at conference.freeswitch.org/888
>     <http://iax:guest at conference.freeswitch.org/888>
>     googletalk:conf+888 at conference.freeswitch.org
>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>     pstn:213-799-1400
>
>
>
>
> -- 
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/f344c550/attachment-0001.html 

From anthony.minessale at gmail.com  Mon Feb  2 15:22:38 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Mon, 2 Feb 2009 17:22:38 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <49877892.7000308@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>
	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>
	<49830E65.9060106@kinetix.gr>
	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>
	<4986E0BF.4020208@kinetix.gr>
	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>
	<49872AD2.1070104@kinetix.gr>
	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>
	<49877892.7000308@kinetix.gr>
Message-ID: <191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>

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, regs at kinetix.gr <regs at 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, regs at kinetix.gr <regs at 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 <regs at 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 <
>>> regs at 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 at 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 at kinetix.gr
>>>>> -------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing list
>>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>> IRC: irc.freenode.net #freeswitch
>>>>
>>>> FreeSWITCH Developer Conference
>>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>>> iax:guest at conference.freeswitch.org/888
>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>> pstn:213-799-1400
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>
>>>>
>>>>
>>>> --
>>>> -------------------------------------------
>>>> Apostolos Pantsiopoulos
>>>> Kinetix Tele.com R & D
>>>> email: regs at kinetix.gr
>>>> -------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing list
>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> -------------------------------------------
>>> Apostolos Pantsiopoulos
>>> Kinetix Tele.com R & D
>>> email: regs at kinetix.gr
>>> -------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090202/5d3ca559/attachment-0001.html 

From regs at kinetix.gr  Mon Feb  2 23:31:30 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Tue, 03 Feb 2009 09:31:30 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>	<49830E65.9060106@kinetix.gr>	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>	<4986E0BF.4020208@kinetix.gr>	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>	<49872AD2.1070104@kinetix.gr>	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>	<49877892.7000308@kinetix.gr>
	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>
Message-ID: <4987F2D2.1030303@kinetix.gr>

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, regs at kinetix.gr 
> <mailto:regs at kinetix.gr> <regs at kinetix.gr <mailto:regs at 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, regs at kinetix.gr
>>     <mailto:regs at kinetix.gr> <regs at kinetix.gr
>>     <mailto:regs at 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
>>>         <regs at kinetix.gr <mailto:regs at 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 <regs at kinetix.gr
>>>>             <mailto:regs at 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 at kinetix.gr
>>>>>                 <mailto:regs at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>                     -------------------------------------------
>>>>>
>>>>>
>>>>>                     _______________________________________________
>>>>>                     Freeswitch-dev mailing list
>>>>>                     Freeswitch-dev at lists.freeswitch.org
>>>>>                     <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>                 <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>                 GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>                 <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>                 IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>                 #freeswitch
>>>>>
>>>>>                 FreeSWITCH Developer Conference
>>>>>                 sip:888 at conference.freeswitch.org
>>>>>                 <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>                 iax:guest at conference.freeswitch.org/888
>>>>>                 <http://iax:guest at conference.freeswitch.org/888>
>>>>>                 googletalk:conf+888 at conference.freeswitch.org
>>>>>                 <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>                 pstn:213-799-1400
>>>>>                 ------------------------------------------------------------------------
>>>>>                 _______________________________________________
>>>>>                 Freeswitch-dev mailing list
>>>>>                 Freeswitch-dev at lists.freeswitch.org
>>>>>                 <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>                 ------------------------------------------- 
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 Freeswitch-dev mailing list
>>>>                 Freeswitch-dev at lists.freeswitch.org
>>>>                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>             IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>>
>>>>             FreeSWITCH Developer Conference
>>>>             sip:888 at conference.freeswitch.org
>>>>             <mailto:sip%3A888 at conference.freeswitch.org>
>>>>             iax:guest at conference.freeswitch.org/888
>>>>             <http://iax:guest at conference.freeswitch.org/888>
>>>>             googletalk:conf+888 at conference.freeswitch.org
>>>>             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>             pstn:213-799-1400
>>>>             ------------------------------------------------------------------------
>>>>
>>>>             _______________________________________________
>>>>             Freeswitch-dev mailing list
>>>>             Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>             ------------------------------------------- 
>>>
>>>
>>>             _______________________________________________
>>>             Freeswitch-dev mailing list
>>>             Freeswitch-dev at lists.freeswitch.org
>>>             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>         IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>>         FreeSWITCH Developer Conference
>>>         sip:888 at conference.freeswitch.org
>>>         <mailto:sip%3A888 at conference.freeswitch.org>
>>>         iax:guest at conference.freeswitch.org/888
>>>         <http://iax:guest at conference.freeswitch.org/888>
>>>         googletalk:conf+888 at conference.freeswitch.org
>>>         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>         pstn:213-799-1400
>>>         ------------------------------------------------------------------------
>>>
>>>         _______________________________________________
>>>         Freeswitch-dev mailing list
>>>         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>         <mailto:Freeswitch-dev at 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 at hotmail.com
>>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>>     FreeSWITCH Developer Conference
>>     sip:888 at conference.freeswitch.org
>>     <mailto:sip%3A888 at conference.freeswitch.org>
>>     iax:guest at conference.freeswitch.org/888
>>     <http://iax:guest at conference.freeswitch.org/888>
>>     googletalk:conf+888 at conference.freeswitch.org
>>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>     pstn:213-799-1400
>>     ------------------------------------------------------------------------
>>     _______________________________________________ Freeswitch-dev
>>     mailing list Freeswitch-dev at lists.freeswitch.org
>>     <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>     <mailto:Freeswitch-dev at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/dff56075/attachment-0001.html 

From regs at kinetix.gr  Tue Feb  3 02:59:42 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Tue, 03 Feb 2009 12:59:42 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <4987F2D2.1030303@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030901300610v238feaf6nfcf79203811eb8b8@mail.gmail.com>	<49830E65.9060106@kinetix.gr>	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>	<4986E0BF.4020208@kinetix.gr>	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>	<49872AD2.1070104@kinetix.gr>	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>	<49877892.7000308@kinetix.gr>	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>
	<4987F2D2.1030303@kinetix.gr>
Message-ID: <4988239E.4040201@kinetix.gr>

I came to the following conclusions :

In the case of the acct start I cannot use the CHANNEL_ORIGINATE event 
since
it is fired only once (I want to send one acct start for each leg)

If I use the CHANNEL_CREATE event for the acct start I am a little sort 
on info
since the event does not contain much. So I need to get the info from 
the session.

On the acct stop it is better to use the info from the event (lots of 
info - easy to duplicate).

I was hoping to implement a uniform way to get data for both start and 
stop but it seems
that this is not the case.


Apostolos Pantsiopoulos wrote:
> 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, regs at kinetix.gr 
>> <mailto:regs at kinetix.gr> <regs at kinetix.gr <mailto:regs at 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, regs at kinetix.gr
>>>     <mailto:regs at kinetix.gr> <regs at kinetix.gr
>>>     <mailto:regs at 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
>>>>         <regs at kinetix.gr <mailto:regs at 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 <regs at kinetix.gr
>>>>>             <mailto:regs at 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 at kinetix.gr
>>>>>>                 <mailto:regs at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>>                     -------------------------------------------
>>>>>>
>>>>>>
>>>>>>                     _______________________________________________
>>>>>>                     Freeswitch-dev mailing list
>>>>>>                     Freeswitch-dev at lists.freeswitch.org
>>>>>>                     <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>                 <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>                 GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>                 <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>                 IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>>                 #freeswitch
>>>>>>
>>>>>>                 FreeSWITCH Developer Conference
>>>>>>                 sip:888 at conference.freeswitch.org
>>>>>>                 <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>                 iax:guest at conference.freeswitch.org/888
>>>>>>                 <http://iax:guest at conference.freeswitch.org/888>
>>>>>>                 googletalk:conf+888 at conference.freeswitch.org
>>>>>>                 <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>                 pstn:213-799-1400
>>>>>>                 ------------------------------------------------------------------------
>>>>>>                 _______________________________________________
>>>>>>                 Freeswitch-dev mailing list
>>>>>>                 Freeswitch-dev at lists.freeswitch.org
>>>>>>                 <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>                 ------------------------------------------- 
>>>>>
>>>>>
>>>>>                 _______________________________________________
>>>>>                 Freeswitch-dev mailing list
>>>>>                 Freeswitch-dev at lists.freeswitch.org
>>>>>                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>             IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>             #freeswitch
>>>>>
>>>>>             FreeSWITCH Developer Conference
>>>>>             sip:888 at conference.freeswitch.org
>>>>>             <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>             iax:guest at conference.freeswitch.org/888
>>>>>             <http://iax:guest at conference.freeswitch.org/888>
>>>>>             googletalk:conf+888 at conference.freeswitch.org
>>>>>             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>             pstn:213-799-1400
>>>>>             ------------------------------------------------------------------------
>>>>>
>>>>>             _______________________________________________
>>>>>             Freeswitch-dev mailing list
>>>>>             Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>             ------------------------------------------- 
>>>>
>>>>
>>>>             _______________________________________________
>>>>             Freeswitch-dev mailing list
>>>>             Freeswitch-dev at lists.freeswitch.org
>>>>             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>         IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>>
>>>>         FreeSWITCH Developer Conference
>>>>         sip:888 at conference.freeswitch.org
>>>>         <mailto:sip%3A888 at conference.freeswitch.org>
>>>>         iax:guest at conference.freeswitch.org/888
>>>>         <http://iax:guest at conference.freeswitch.org/888>
>>>>         googletalk:conf+888 at conference.freeswitch.org
>>>>         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>         pstn:213-799-1400
>>>>         ------------------------------------------------------------------------
>>>>
>>>>         _______________________________________________
>>>>         Freeswitch-dev mailing list
>>>>         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>>         <mailto:Freeswitch-dev at 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 at hotmail.com
>>>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>>     FreeSWITCH Developer Conference
>>>     sip:888 at conference.freeswitch.org
>>>     <mailto:sip%3A888 at conference.freeswitch.org>
>>>     iax:guest at conference.freeswitch.org/888
>>>     <http://iax:guest at conference.freeswitch.org/888>
>>>     googletalk:conf+888 at conference.freeswitch.org
>>>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>     pstn:213-799-1400
>>>     ------------------------------------------------------------------------
>>>     _______________________________________________ Freeswitch-dev
>>>     mailing list Freeswitch-dev at lists.freeswitch.org
>>>     <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>     <mailto:Freeswitch-dev at 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 at hotmail.com 
>> <mailto:MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
>> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org 
>> <mailto:sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888 
>> <http://iax:guest at conference.freeswitch.org/888>
>> googletalk:conf+888 at conference.freeswitch.org 
>> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at kinetix.gr
> ------------------------------------------- 
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/cc6ea1e6/attachment-0001.html 

From anthony.minessale at gmail.com  Tue Feb  3 06:03:57 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Tue, 3 Feb 2009 08:03:57 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <4988239E.4040201@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>
	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>
	<4986E0BF.4020208@kinetix.gr>
	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>
	<49872AD2.1070104@kinetix.gr>
	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>
	<49877892.7000308@kinetix.gr>
	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>
	<4987F2D2.1030303@kinetix.gr> <4988239E.4040201@kinetix.gr>
Message-ID: <191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>

or everything is already in the right place the way it already is.....?

If all you want to do is background the start packet, then just take the
info in the place where the existing code gets it (routing state change) and
create your own switch_event or private struct, add the data to it and
launch a thread to run the radius in it's own thread.

I still think making the radius not be down or have short timeouts across a
list of servers is a better place to fix it than making FS launch a bonus
thread per established call to run the radius start packets in the bg.

I also still think that if you insist on not listing to my previous point,
pushing all the packets to a fifo queue is better than launching a new
thread per call because if the server is down and timing out why would you
want to have 250 threads up at once all blocking on the dead radius instead
of a queue of them that could withstand a bit of downtime by stacking up the
start packet requests and unloading them in order when it returned.



On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:

>  I came to the following conclusions :
>
> In the case of the acct start I cannot use the CHANNEL_ORIGINATE event
> since
> it is fired only once (I want to send one acct start for each leg)
>
> If I use the CHANNEL_CREATE event for the acct start I am a little sort on
> info
> since the event does not contain much. So I need to get the info from the
> session.
>
> On the acct stop it is better to use the info from the event (lots of info
> - easy to duplicate).
>
> I was hoping to implement a uniform way to get data for both start and stop
> but it seems
> that this is not the case.
>
>
>
> Apostolos Pantsiopoulos wrote:
>
> 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, regs at kinetix.gr <regs at 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, regs at kinetix.gr <regs at 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 <regs at 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 <
>>>> regs at 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 at 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 at kinetix.gr
>>>>>> -------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing list
>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>> IRC: irc.freenode.net #freeswitch
>>>>>
>>>>> FreeSWITCH Developer Conference
>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>> iax:guest at conference.freeswitch.org/888
>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>> pstn:213-799-1400
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -------------------------------------------
>>>>> Apostolos Pantsiopoulos
>>>>> Kinetix Tele.com R & D
>>>>> email: regs at kinetix.gr
>>>>> -------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing list
>>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>> IRC: irc.freenode.net #freeswitch
>>>>
>>>> FreeSWITCH Developer Conference
>>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>>> iax:guest at conference.freeswitch.org/888
>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>> pstn:213-799-1400
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>
>>>>
>>>>
>>>> --
>>>> -------------------------------------------
>>>> Apostolos Pantsiopoulos
>>>> Kinetix Tele.com R & D
>>>> email: regs at kinetix.gr
>>>> -------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing list
>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/6f75f1e0/attachment-0001.html 

From regs at kinetix.gr  Tue Feb  3 06:41:13 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Tue, 03 Feb 2009 16:41:13 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030901300814u4d6315dbk752cd059b38c98b3@mail.gmail.com>	<4986E0BF.4020208@kinetix.gr>	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>	<49872AD2.1070104@kinetix.gr>	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>	<49877892.7000308@kinetix.gr>	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>	<4987F2D2.1030303@kinetix.gr>
	<4988239E.4040201@kinetix.gr>
	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>
Message-ID: <49885789.5000905@kinetix.gr>

Even if my intention was not to send the acct start in a separate thread
we are still missing an acct start at the setup of the b-leg of a bridge.
The on_routing handler cannot do that (it is called only for the a-leg).
I tried on_init (which I thought was called at the setup of a channel) but
it didn't invoke my handler even for the a-leg. An event on the other hand
(create_channel) which is triggered correctly does not carry all the info
needed for an acct start packet to be filled (not even at a min level). The
event originate_channel is also called only once during a bridge, so it 
cannot
be used either.

So it is not only a matter of thread vs non threaded (or multiple 
threads vs one thread).
It is also a matter of when and how many times (2 for a simple bridge) 
to call an
acct start routine.

So we either need to create one more state handler that gets called in 
such a
manner that can be used for b-legs too. Or an event of the same kind 
that carries all the info
needed by radius acct start.
Both ways (adding a state-handler or adding a new event) I think require
changes to the FS core architecture. I must admit, however, that my
understanding of the FS source code is still on a newbie level so the above
conclusions might be wrong.


Anthony Minessale wrote:
> or everything is already in the right place the way it already is.....?
>
> If all you want to do is background the start packet, then just take 
> the info in the place where the existing code gets it (routing state 
> change) and create your own switch_event or private struct, add the 
> data to it and launch a thread to run the radius in it's own thread.
>
> I still think making the radius not be down or have short timeouts 
> across a list of servers is a better place to fix it than making FS 
> launch a bonus thread per established call to run the radius start 
> packets in the bg.
>
> I also still think that if you insist on not listing to my previous 
> point, pushing all the packets to a fifo queue is better than 
> launching a new thread per call because if the server is down and 
> timing out why would you want to have 250 threads up at once all 
> blocking on the dead radius instead of a queue of them that could 
> withstand a bit of downtime by stacking up the start packet requests 
> and unloading them in order when it returned.
>
>
>
> On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos 
> <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>
>     I came to the following conclusions :
>
>     In the case of the acct start I cannot use the CHANNEL_ORIGINATE
>     event since
>     it is fired only once (I want to send one acct start for each leg)
>
>     If I use the CHANNEL_CREATE event for the acct start I am a little
>     sort on info
>     since the event does not contain much. So I need to get the info
>     from the session.
>
>     On the acct stop it is better to use the info from the event (lots
>     of info - easy to duplicate).
>
>     I was hoping to implement a uniform way to get data for both start
>     and stop but it seems
>     that this is not the case.
>
>
>
>     Apostolos Pantsiopoulos wrote:
>>     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, regs at kinetix.gr
>>>     <mailto:regs at kinetix.gr> <regs at kinetix.gr
>>>     <mailto:regs at 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, regs at kinetix.gr
>>>>         <mailto:regs at kinetix.gr> <regs at kinetix.gr
>>>>         <mailto:regs at 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 <regs at kinetix.gr
>>>>>             <mailto:regs at 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 <regs at kinetix.gr
>>>>>>                 <mailto:regs at 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 at kinetix.gr
>>>>>>>                     <mailto:regs at 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 at kinetix.gr
>>>>>>>                         <mailto:regs at kinetix.gr>
>>>>>>>                         -------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>                         _______________________________________________
>>>>>>>                         Freeswitch-dev mailing list
>>>>>>>                         Freeswitch-dev at lists.freeswitch.org
>>>>>>>                         <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>                     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>                     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>                     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>                     IRC: irc.freenode.net
>>>>>>>                     <http://irc.freenode.net> #freeswitch
>>>>>>>
>>>>>>>                     FreeSWITCH Developer Conference
>>>>>>>                     sip:888 at conference.freeswitch.org
>>>>>>>                     <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>                     iax:guest at conference.freeswitch.org/888
>>>>>>>                     <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>                     googletalk:conf+888 at conference.freeswitch.org
>>>>>>>                     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>                     pstn:213-799-1400
>>>>>>>                     ------------------------------------------------------------------------
>>>>>>>                     _______________________________________________
>>>>>>>                     Freeswitch-dev mailing list
>>>>>>>                     Freeswitch-dev at lists.freeswitch.org
>>>>>>>                     <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>>                     ------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>                     _______________________________________________
>>>>>>                     Freeswitch-dev mailing list
>>>>>>                     Freeswitch-dev at lists.freeswitch.org
>>>>>>                     <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>                 <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>                 GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>                 <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>                 IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>>                 #freeswitch
>>>>>>
>>>>>>                 FreeSWITCH Developer Conference
>>>>>>                 sip:888 at conference.freeswitch.org
>>>>>>                 <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>                 iax:guest at conference.freeswitch.org/888
>>>>>>                 <http://iax:guest at conference.freeswitch.org/888>
>>>>>>                 googletalk:conf+888 at conference.freeswitch.org
>>>>>>                 <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>                 pstn:213-799-1400
>>>>>>                 ------------------------------------------------------------------------
>>>>>>
>>>>>>                 _______________________________________________
>>>>>>                 Freeswitch-dev mailing list
>>>>>>                 Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>                 ------------------------------------------- 
>>>>>
>>>>>
>>>>>                 _______________________________________________
>>>>>                 Freeswitch-dev mailing list
>>>>>                 Freeswitch-dev at lists.freeswitch.org
>>>>>                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>             IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>             #freeswitch
>>>>>
>>>>>             FreeSWITCH Developer Conference
>>>>>             sip:888 at conference.freeswitch.org
>>>>>             <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>             iax:guest at conference.freeswitch.org/888
>>>>>             <http://iax:guest at conference.freeswitch.org/888>
>>>>>             googletalk:conf+888 at conference.freeswitch.org
>>>>>             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>             pstn:213-799-1400
>>>>>             ------------------------------------------------------------------------
>>>>>
>>>>>             _______________________________________________
>>>>>             Freeswitch-dev mailing list
>>>>>             Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>>>             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>         IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>>
>>>>         FreeSWITCH Developer Conference
>>>>         sip:888 at conference.freeswitch.org
>>>>         <mailto:sip%3A888 at conference.freeswitch.org>
>>>>         iax:guest at conference.freeswitch.org/888
>>>>         <http://iax:guest at conference.freeswitch.org/888>
>>>>         googletalk:conf+888 at conference.freeswitch.org
>>>>         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>         pstn:213-799-1400
>>>>         ------------------------------------------------------------------------
>>>>         _______________________________________________
>>>>         Freeswitch-dev mailing list
>>>>         Freeswitch-dev at lists.freeswitch.org
>>>>         <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>>         <mailto:Freeswitch-dev at 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 at hotmail.com
>>>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>>     FreeSWITCH Developer Conference
>>>     sip:888 at conference.freeswitch.org
>>>     <mailto:sip%3A888 at conference.freeswitch.org>
>>>     iax:guest at conference.freeswitch.org/888
>>>     <http://iax:guest at conference.freeswitch.org/888>
>>>     googletalk:conf+888 at conference.freeswitch.org
>>>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>     pstn:213-799-1400
>>>     ------------------------------------------------------------------------
>>>
>>>     _______________________________________________
>>>     Freeswitch-dev mailing list
>>>     Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>     ------------------------------------------- 
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     Freeswitch-dev mailing list
>>     Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>     ------------------------------------------- 
>
>
>     _______________________________________________
>     Freeswitch-dev mailing list
>     Freeswitch-dev at lists.freeswitch.org
>     <mailto:Freeswitch-dev at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/7059ad39/attachment-0001.html 

From ctrix+fs at navynet.it  Tue Feb  3 03:29:21 2009
From: ctrix+fs at navynet.it (Massimo "Ctrix" Cetra)
Date: Tue, 03 Feb 2009 12:29:21 +0100
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
	<09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
Message-ID: <49882A91.5080509@navynet.it>

Brian West ha scritto:
> Nicholas,
> 	Do you want to have svn commit and control over the debs?  Someone to  
> maintain them?  I'm also looking for someone to watch over and work  
> the RPM spec file too.... Anyone Anyone?  Email me off list of find me  
> on IRC bkw_ in #freeswitch on irc.freenode.net

Brian, be careful.

The debian standards wants daemons to be installed in fixed places (for
example, freeswitch in /usr/sbin fs_cli in /usr/bin, modules in
/usr/lib/freeswitch/ and so on)

Even if having the official patches in trunk would be a very good
option, probabily it will break the freeswitch rules to have a common
pattern among all build systems (that is everything in /opt/freeswitch).

I know you wanted everything in /opt/freeswitch to handle support
requests better.

This is just FYI!

Max



From mike at jerris.com  Tue Feb  3 07:50:56 2009
From: mike at jerris.com (Michael Jerris)
Date: Tue, 3 Feb 2009 10:50:56 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <49882A91.5080509@navynet.it>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
	<09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
	<49882A91.5080509@navynet.it>
Message-ID: <8A09CDAF-B0EB-4C7A-A6F0-EA2E04577178@jerris.com>

I do want to get enough into our configure that these changes are just  
a matter of changing configure options and not having to put patches  
all over to do it.  I think this is doable.

Mike

On Feb 3, 2009, at 6:29 AM, Massimo Ctrix Cetra wrote:

> Brian West ha scritto:
>> Nicholas,
>> 	Do you want to have svn commit and control over the debs?  Someone  
>> to
>> maintain them?  I'm also looking for someone to watch over and work
>> the RPM spec file too.... Anyone Anyone?  Email me off list of find  
>> me
>> on IRC bkw_ in #freeswitch on irc.freenode.net
>
> Brian, be careful.
>
> The debian standards wants daemons to be installed in fixed places  
> (for
> example, freeswitch in /usr/sbin fs_cli in /usr/bin, modules in
> /usr/lib/freeswitch/ and so on)
>
> Even if having the official patches in trunk would be a very good
> option, probabily it will break the freeswitch rules to have a common
> pattern among all build systems (that is everything in /opt/ 
> freeswitch).
>
> I know you wanted everything in /opt/freeswitch to handle support
> requests better.
>
> This is just FYI!
>
> Max



From nicholas at montrealconsultoria.com.br  Tue Feb  3 08:54:44 2009
From: nicholas at montrealconsultoria.com.br (Nicholas Santos)
Date: Tue, 3 Feb 2009 13:54:44 -0300
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <8A09CDAF-B0EB-4C7A-A6F0-EA2E04577178@jerris.com>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>
	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
	<09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
	<49882A91.5080509@navynet.it>
	<8A09CDAF-B0EB-4C7A-A6F0-EA2E04577178@jerris.com>
Message-ID: <8171bb3b0902030854ydb7be6dv72d7a6d0968f21a9@mail.gmail.com>

In a first look, it can be temporarily solved by using symbolic links.

>From the Debian Policy:

"If your package creates or uses configuration files outside of /etc, and it
is not feasible to modify the package to use /etc directly, put the files in
/etc and create symbolic links to those files from the location that the
package requires."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/4248d121/attachment.html 

From brian at freeswitch.org  Tue Feb  3 08:57:48 2009
From: brian at freeswitch.org (Brian West)
Date: Tue, 3 Feb 2009 10:57:48 -0600
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <49882A91.5080509@navynet.it>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
	<09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
	<49882A91.5080509@navynet.it>
Message-ID: <6E600F82-3740-4F2A-A4D2-1A12F41F57C4@freeswitch.org>

I came to the conclusion that it doesn't matter what we want, people  
will package it like they want... we might as well be involved in it  
than turn people away which in the end will increase support time  
because you have ten people making a package for debian vs one  
official package.

/b

On Feb 3, 2009, at 5:29 AM, Massimo Ctrix Cetra wrote:

> Brian, be careful.
>
> The debian standards wants daemons to be installed in fixed places  
> (for
> example, freeswitch in /usr/sbin fs_cli in /usr/bin, modules in
> /usr/lib/freeswitch/ and so on)
>
> Even if having the official patches in trunk would be a very good
> option, probabily it will break the freeswitch rules to have a common
> pattern among all build systems (that is everything in /opt/ 
> freeswitch).
>
> I know you wanted everything in /opt/freeswitch to handle support
> requests better.
>
> This is just FYI!
>
> Max



From anthony.minessale at gmail.com  Tue Feb  3 12:37:12 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Tue, 3 Feb 2009 14:37:12 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <49885789.5000905@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>
	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>
	<49872AD2.1070104@kinetix.gr>
	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>
	<49877892.7000308@kinetix.gr>
	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>
	<4987F2D2.1030303@kinetix.gr> <4988239E.4040201@kinetix.gr>
	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>
	<49885789.5000905@kinetix.gr>
Message-ID: <191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>

I updated the core today in a way that you will not get that event handler
on both inbound and outbound legs.


On Tue, Feb 3, 2009 at 8:41 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:

>  Even if my intention was not to send the acct start in a separate thread
> we are still missing an acct start at the setup of the b-leg of a bridge.
> The on_routing handler cannot do that (it is called only for the a-leg).
> I tried on_init (which I thought was called at the setup of a channel) but
> it didn't invoke my handler even for the a-leg. An event on the other hand
> (create_channel) which is triggered correctly does not carry all the info
> needed for an acct start packet to be filled (not even at a min level). The
>
> event originate_channel is also called only once during a bridge, so it
> cannot
> be used either.
>
> So it is not only a matter of thread vs non threaded (or multiple threads
> vs one thread).
> It is also a matter of when and how many times (2 for a simple bridge) to
> call an
> acct start routine.
>
> So we either need to create one more state handler that gets called in such
> a
> manner that can be used for b-legs too. Or an event of the same kind that
> carries all the info
> needed by radius acct start.
> Both ways (adding a state-handler or adding a new event) I think require
> changes to the FS core architecture. I must admit, however, that my
> understanding of the FS source code is still on a newbie level so the above
> conclusions might be wrong.
>
>
>
> Anthony Minessale wrote:
>
> or everything is already in the right place the way it already is.....?
>
> If all you want to do is background the start packet, then just take the
> info in the place where the existing code gets it (routing state change) and
> create your own switch_event or private struct, add the data to it and
> launch a thread to run the radius in it's own thread.
>
> I still think making the radius not be down or have short timeouts across a
> list of servers is a better place to fix it than making FS launch a bonus
> thread per established call to run the radius start packets in the bg.
>
> I also still think that if you insist on not listing to my previous point,
> pushing all the packets to a fifo queue is better than launching a new
> thread per call because if the server is down and timing out why would you
> want to have 250 threads up at once all blocking on the dead radius instead
> of a queue of them that could withstand a bit of downtime by stacking up the
> start packet requests and unloading them in order when it returned.
>
>
>
> On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:
>
>> I came to the following conclusions :
>>
>> In the case of the acct start I cannot use the CHANNEL_ORIGINATE event
>> since
>> it is fired only once (I want to send one acct start for each leg)
>>
>> If I use the CHANNEL_CREATE event for the acct start I am a little sort on
>> info
>> since the event does not contain much. So I need to get the info from the
>> session.
>>
>> On the acct stop it is better to use the info from the event (lots of info
>> - easy to duplicate).
>>
>> I was hoping to implement a uniform way to get data for both start and
>> stop but it seems
>> that this is not the case.
>>
>>
>> Apostolos Pantsiopoulos wrote:
>>
>> 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, regs at kinetix.gr <regs at 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, regs at kinetix.gr <regs at 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 <
>>>> regs at 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 <
>>>>> regs at 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 at 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 at kinetix.gr
>>>>>>> -------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Freeswitch-dev mailing list
>>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>> IRC: irc.freenode.net #freeswitch
>>>>>>
>>>>>> FreeSWITCH Developer Conference
>>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>>> iax:guest at conference.freeswitch.org/888
>>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>> pstn:213-799-1400
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -------------------------------------------
>>>>>> Apostolos Pantsiopoulos
>>>>>> Kinetix Tele.com R & D
>>>>>> email: regs at kinetix.gr
>>>>>> -------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing list
>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>> IRC: irc.freenode.net #freeswitch
>>>>>
>>>>> FreeSWITCH Developer Conference
>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>> iax:guest at conference.freeswitch.org/888
>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>> pstn:213-799-1400
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -------------------------------------------
>>>>> Apostolos Pantsiopoulos
>>>>> Kinetix Tele.com R & D
>>>>> email: regs at kinetix.gr
>>>>> -------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing list
>>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>> IRC: irc.freenode.net #freeswitch
>>>>
>>>> FreeSWITCH Developer Conference
>>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>>> iax:guest at conference.freeswitch.org/888
>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>> pstn:213-799-1400
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing list
>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: regs at kinetix.gr
>> -------------------------------------------
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: regs at kinetix.gr
>> -------------------------------------------
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/f5988330/attachment-0001.html 

From regs at kinetix.gr  Tue Feb  3 13:13:17 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Tue, 03 Feb 2009 23:13:17 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030902020744x7a11f710j5d62615fc8ded347@mail.gmail.com>	<49872AD2.1070104@kinetix.gr>	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>	<49877892.7000308@kinetix.gr>	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>	<4987F2D2.1030303@kinetix.gr>
	<4988239E.4040201@kinetix.gr>	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>	<49885789.5000905@kinetix.gr>
	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>
Message-ID: <4988B36D.2020800@kinetix.gr>

"you will not get that event handler"

please tell me that this "not" meant to be a "now"

Anthony Minessale wrote:
> I updated the core today in a way that you will not get that event 
> handler on both inbound and outbound legs.
>
>
> On Tue, Feb 3, 2009 at 8:41 AM, Apostolos Pantsiopoulos 
> <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>
>     Even if my intention was not to send the acct start in a separate
>     thread
>     we are still missing an acct start at the setup of the b-leg of a
>     bridge.
>     The on_routing handler cannot do that (it is called only for the
>     a-leg).
>     I tried on_init (which I thought was called at the setup of a
>     channel) but
>     it didn't invoke my handler even for the a-leg. An event on the
>     other hand
>     (create_channel) which is triggered correctly does not carry all
>     the info
>     needed for an acct start packet to be filled (not even at a min
>     level). The
>     event originate_channel is also called only once during a bridge,
>     so it cannot
>     be used either.
>
>     So it is not only a matter of thread vs non threaded (or multiple
>     threads vs one thread).
>     It is also a matter of when and how many times (2 for a simple
>     bridge) to call an
>     acct start routine.
>
>     So we either need to create one more state handler that gets
>     called in such a
>     manner that can be used for b-legs too. Or an event of the same
>     kind that carries all the info
>     needed by radius acct start.
>     Both ways (adding a state-handler or adding a new event) I think
>     require
>     changes to the FS core architecture. I must admit, however, that my
>     understanding of the FS source code is still on a newbie level so
>     the above
>     conclusions might be wrong.
>
>
>
>     Anthony Minessale wrote:
>>     or everything is already in the right place the way it already
>>     is.....?
>>
>>     If all you want to do is background the start packet, then just
>>     take the info in the place where the existing code gets it
>>     (routing state change) and create your own switch_event or
>>     private struct, add the data to it and launch a thread to run the
>>     radius in it's own thread.
>>
>>     I still think making the radius not be down or have short
>>     timeouts across a list of servers is a better place to fix it
>>     than making FS launch a bonus thread per established call to run
>>     the radius start packets in the bg.
>>
>>     I also still think that if you insist on not listing to my
>>     previous point, pushing all the packets to a fifo queue is better
>>     than launching a new thread per call because if the server is
>>     down and timing out why would you want to have 250 threads up at
>>     once all blocking on the dead radius instead of a queue of them
>>     that could withstand a bit of downtime by stacking up the start
>>     packet requests and unloading them in order when it returned.
>>
>>
>>
>>     On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos
>>     <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>>
>>         I came to the following conclusions :
>>
>>         In the case of the acct start I cannot use the
>>         CHANNEL_ORIGINATE event since
>>         it is fired only once (I want to send one acct start for each
>>         leg)
>>
>>         If I use the CHANNEL_CREATE event for the acct start I am a
>>         little sort on info
>>         since the event does not contain much. So I need to get the
>>         info from the session.
>>
>>         On the acct stop it is better to use the info from the event
>>         (lots of info - easy to duplicate).
>>
>>         I was hoping to implement a uniform way to get data for both
>>         start and stop but it seems
>>         that this is not the case.
>>
>>
>>
>>         Apostolos Pantsiopoulos wrote:
>>>         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, regs at kinetix.gr
>>>>         <mailto:regs at kinetix.gr> <regs at kinetix.gr
>>>>         <mailto:regs at 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, regs at kinetix.gr
>>>>>             <mailto:regs at kinetix.gr> <regs at kinetix.gr
>>>>>             <mailto:regs at 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 <regs at kinetix.gr
>>>>>>                 <mailto:regs at 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 <regs at kinetix.gr
>>>>>>>                     <mailto:regs at 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 at kinetix.gr
>>>>>>>>                         <mailto:regs at 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 at kinetix.gr
>>>>>>>>                             <mailto:regs at kinetix.gr>
>>>>>>>>                             -------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>                             _______________________________________________
>>>>>>>>                             Freeswitch-dev mailing list
>>>>>>>>                             Freeswitch-dev at lists.freeswitch.org
>>>>>>>>                             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>>                         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>>                         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>>                         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>>                         IRC: irc.freenode.net
>>>>>>>>                         <http://irc.freenode.net> #freeswitch
>>>>>>>>
>>>>>>>>                         FreeSWITCH Developer Conference
>>>>>>>>                         sip:888 at conference.freeswitch.org
>>>>>>>>                         <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>>                         iax:guest at conference.freeswitch.org/888
>>>>>>>>                         <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>>                         googletalk:conf+888 at conference.freeswitch.org
>>>>>>>>                         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>>                         pstn:213-799-1400
>>>>>>>>                         ------------------------------------------------------------------------
>>>>>>>>                         _______________________________________________
>>>>>>>>                         Freeswitch-dev mailing list
>>>>>>>>                         Freeswitch-dev at lists.freeswitch.org
>>>>>>>>                         <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>>>                         ------------------------------------------- 
>>>>>>>
>>>>>>>
>>>>>>>                         _______________________________________________
>>>>>>>                         Freeswitch-dev mailing list
>>>>>>>                         Freeswitch-dev at lists.freeswitch.org
>>>>>>>                         <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>                     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>                     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>                     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>                     IRC: irc.freenode.net
>>>>>>>                     <http://irc.freenode.net> #freeswitch
>>>>>>>
>>>>>>>                     FreeSWITCH Developer Conference
>>>>>>>                     sip:888 at conference.freeswitch.org
>>>>>>>                     <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>                     iax:guest at conference.freeswitch.org/888
>>>>>>>                     <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>                     googletalk:conf+888 at conference.freeswitch.org
>>>>>>>                     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>                     pstn:213-799-1400
>>>>>>>                     ------------------------------------------------------------------------
>>>>>>>
>>>>>>>                     _______________________________________________
>>>>>>>                     Freeswitch-dev mailing list
>>>>>>>                     Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>>                     ------------------------------------------- 
>>>>>>
>>>>>>
>>>>>>                     _______________________________________________
>>>>>>                     Freeswitch-dev mailing list
>>>>>>                     Freeswitch-dev at lists.freeswitch.org
>>>>>>                     <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>                 <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>                 GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>                 <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>                 IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>>                 #freeswitch
>>>>>>
>>>>>>                 FreeSWITCH Developer Conference
>>>>>>                 sip:888 at conference.freeswitch.org
>>>>>>                 <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>                 iax:guest at conference.freeswitch.org/888
>>>>>>                 <http://iax:guest at conference.freeswitch.org/888>
>>>>>>                 googletalk:conf+888 at conference.freeswitch.org
>>>>>>                 <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>                 pstn:213-799-1400
>>>>>>                 ------------------------------------------------------------------------
>>>>>>
>>>>>>                 _______________________________________________
>>>>>>                 Freeswitch-dev mailing list
>>>>>>                 Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>>>>                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>             IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>             #freeswitch
>>>>>
>>>>>             FreeSWITCH Developer Conference
>>>>>             sip:888 at conference.freeswitch.org
>>>>>             <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>             iax:guest at conference.freeswitch.org/888
>>>>>             <http://iax:guest at conference.freeswitch.org/888>
>>>>>             googletalk:conf+888 at conference.freeswitch.org
>>>>>             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>             pstn:213-799-1400
>>>>>             ------------------------------------------------------------------------
>>>>>             _______________________________________________
>>>>>             Freeswitch-dev mailing list
>>>>>             Freeswitch-dev at lists.freeswitch.org
>>>>>             <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>>>             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>         IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>>
>>>>         FreeSWITCH Developer Conference
>>>>         sip:888 at conference.freeswitch.org
>>>>         <mailto:sip%3A888 at conference.freeswitch.org>
>>>>         iax:guest at conference.freeswitch.org/888
>>>>         <http://iax:guest at conference.freeswitch.org/888>
>>>>         googletalk:conf+888 at conference.freeswitch.org
>>>>         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>         pstn:213-799-1400
>>>>         ------------------------------------------------------------------------
>>>>
>>>>         _______________________________________________
>>>>         Freeswitch-dev mailing list
>>>>         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>         ------------------------------------------- 
>>>         ------------------------------------------------------------------------
>>>
>>>         _______________________________________________
>>>         Freeswitch-dev mailing list
>>>         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>         ------------------------------------------- 
>>
>>
>>         _______________________________________________
>>         Freeswitch-dev mailing list
>>         Freeswitch-dev at lists.freeswitch.org
>>         <mailto:Freeswitch-dev at 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 at hotmail.com
>>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>>     FreeSWITCH Developer Conference
>>     sip:888 at conference.freeswitch.org
>>     <mailto:sip%3A888 at conference.freeswitch.org>
>>     iax:guest at conference.freeswitch.org/888
>>     <http://iax:guest at conference.freeswitch.org/888>
>>     googletalk:conf+888 at conference.freeswitch.org
>>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>     pstn:213-799-1400
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     Freeswitch-dev mailing list
>>     Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>     ------------------------------------------- 
>
>
>     _______________________________________________
>     Freeswitch-dev mailing list
>     Freeswitch-dev at lists.freeswitch.org
>     <mailto:Freeswitch-dev at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/612bcf74/attachment-0001.html 

From anthony.minessale at gmail.com  Tue Feb  3 13:18:07 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Tue, 3 Feb 2009 15:18:07 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <4988B36D.2020800@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>
	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>
	<49877892.7000308@kinetix.gr>
	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>
	<4987F2D2.1030303@kinetix.gr> <4988239E.4040201@kinetix.gr>
	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>
	<49885789.5000905@kinetix.gr>
	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>
	<4988B36D.2020800@kinetix.gr>
Message-ID: <191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>

yes,

you will *now* get the event handler on both legs.


On Tue, Feb 3, 2009 at 3:13 PM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:

>  "you will not get that event handler"
>
> please tell me that this "not" meant to be a "now"
>
>
> Anthony Minessale wrote:
>
> I updated the core today in a way that you will not get that event handler
> on both inbound and outbound legs.
>
>
> On Tue, Feb 3, 2009 at 8:41 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:
>
>>  Even if my intention was not to send the acct start in a separate thread
>> we are still missing an acct start at the setup of the b-leg of a bridge.
>> The on_routing handler cannot do that (it is called only for the a-leg).
>> I tried on_init (which I thought was called at the setup of a channel) but
>>
>> it didn't invoke my handler even for the a-leg. An event on the other hand
>>
>> (create_channel) which is triggered correctly does not carry all the info
>> needed for an acct start packet to be filled (not even at a min level).
>> The
>> event originate_channel is also called only once during a bridge, so it
>> cannot
>> be used either.
>>
>> So it is not only a matter of thread vs non threaded (or multiple threads
>> vs one thread).
>> It is also a matter of when and how many times (2 for a simple bridge) to
>> call an
>> acct start routine.
>>
>> So we either need to create one more state handler that gets called in
>> such a
>> manner that can be used for b-legs too. Or an event of the same kind that
>> carries all the info
>> needed by radius acct start.
>> Both ways (adding a state-handler or adding a new event) I think require
>> changes to the FS core architecture. I must admit, however, that my
>> understanding of the FS source code is still on a newbie level so the
>> above
>> conclusions might be wrong.
>>
>>
>> Anthony Minessale wrote:
>>
>> or everything is already in the right place the way it already is.....?
>>
>> If all you want to do is background the start packet, then just take the
>> info in the place where the existing code gets it (routing state change) and
>> create your own switch_event or private struct, add the data to it and
>> launch a thread to run the radius in it's own thread.
>>
>> I still think making the radius not be down or have short timeouts across
>> a list of servers is a better place to fix it than making FS launch a bonus
>> thread per established call to run the radius start packets in the bg.
>>
>> I also still think that if you insist on not listing to my previous point,
>> pushing all the packets to a fifo queue is better than launching a new
>> thread per call because if the server is down and timing out why would you
>> want to have 250 threads up at once all blocking on the dead radius instead
>> of a queue of them that could withstand a bit of downtime by stacking up the
>> start packet requests and unloading them in order when it returned.
>>
>>
>>
>> On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:
>>
>>> I came to the following conclusions :
>>>
>>> In the case of the acct start I cannot use the CHANNEL_ORIGINATE event
>>> since
>>> it is fired only once (I want to send one acct start for each leg)
>>>
>>> If I use the CHANNEL_CREATE event for the acct start I am a little sort
>>> on info
>>> since the event does not contain much. So I need to get the info from the
>>> session.
>>>
>>> On the acct stop it is better to use the info from the event (lots of
>>> info - easy to duplicate).
>>>
>>> I was hoping to implement a uniform way to get data for both start and
>>> stop but it seems
>>> that this is not the case.
>>>
>>>
>>> Apostolos Pantsiopoulos wrote:
>>>
>>> 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, regs at kinetix.gr <regs at 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, regs at kinetix.gr <regs at 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 <
>>>>> regs at 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 <
>>>>>> regs at 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 at 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 at kinetix.gr
>>>>>>>> -------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Freeswitch-dev mailing list
>>>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>> IRC: irc.freenode.net #freeswitch
>>>>>>>
>>>>>>> FreeSWITCH Developer Conference
>>>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>>>> iax:guest at conference.freeswitch.org/888
>>>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>> pstn:213-799-1400
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -------------------------------------------
>>>>>>> Apostolos Pantsiopoulos
>>>>>>> Kinetix Tele.com R & D
>>>>>>> email: regs at kinetix.gr
>>>>>>> -------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Freeswitch-dev mailing list
>>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>> IRC: irc.freenode.net #freeswitch
>>>>>>
>>>>>> FreeSWITCH Developer Conference
>>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>>> iax:guest at conference.freeswitch.org/888
>>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>> pstn:213-799-1400
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -------------------------------------------
>>>>>> Apostolos Pantsiopoulos
>>>>>> Kinetix Tele.com R & D
>>>>>> email: regs at kinetix.gr
>>>>>> -------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing list
>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>> IRC: irc.freenode.net #freeswitch
>>>>>
>>>>> FreeSWITCH Developer Conference
>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>> iax:guest at conference.freeswitch.org/888
>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>> pstn:213-799-1400
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing list
>>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>> IRC: irc.freenode.net #freeswitch
>>>>
>>>> FreeSWITCH Developer Conference
>>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>>> iax:guest at conference.freeswitch.org/888
>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>> pstn:213-799-1400
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing list
>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> -------------------------------------------
>>> Apostolos Pantsiopoulos
>>> Kinetix Tele.com R & D
>>> email: regs at kinetix.gr
>>> -------------------------------------------
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> -------------------------------------------
>>> Apostolos Pantsiopoulos
>>> Kinetix Tele.com R & D
>>> email: regs at kinetix.gr
>>> -------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: regs at kinetix.gr
>> -------------------------------------------
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/c4da767a/attachment-0001.html 

From regs at kinetix.gr  Tue Feb  3 13:33:21 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Tue, 03 Feb 2009 23:33:21 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030902020928g534e2c63y476a78e087f32be5@mail.gmail.com>	<49877892.7000308@kinetix.gr>	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>	<4987F2D2.1030303@kinetix.gr>
	<4988239E.4040201@kinetix.gr>	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>	<49885789.5000905@kinetix.gr>	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>	<4988B36D.2020800@kinetix.gr>
	<191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>
Message-ID: <4988B821.2000805@kinetix.gr>

Cheers!

One clarification though :

Would that be a state handler? Or an event handler?
And what is its name?

Anthony Minessale wrote:
> yes,
>
> you will *now* get the event handler on both legs.
>
>
> On Tue, Feb 3, 2009 at 3:13 PM, Apostolos Pantsiopoulos 
> <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>
>     "you will not get that event handler"
>
>     please tell me that this "not" meant to be a "now"
>
>
>     Anthony Minessale wrote:
>>     I updated the core today in a way that you will not get that
>>     event handler on both inbound and outbound legs.
>>
>>
>>     On Tue, Feb 3, 2009 at 8:41 AM, Apostolos Pantsiopoulos
>>     <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>>
>>         Even if my intention was not to send the acct start in a
>>         separate thread
>>         we are still missing an acct start at the setup of the b-leg
>>         of a bridge.
>>         The on_routing handler cannot do that (it is called only for
>>         the a-leg).
>>         I tried on_init (which I thought was called at the setup of a
>>         channel) but
>>         it didn't invoke my handler even for the a-leg. An event on
>>         the other hand
>>         (create_channel) which is triggered correctly does not carry
>>         all the info
>>         needed for an acct start packet to be filled (not even at a
>>         min level). The
>>         event originate_channel is also called only once during a
>>         bridge, so it cannot
>>         be used either.
>>
>>         So it is not only a matter of thread vs non threaded (or
>>         multiple threads vs one thread).
>>         It is also a matter of when and how many times (2 for a
>>         simple bridge) to call an
>>         acct start routine.
>>
>>         So we either need to create one more state handler that gets
>>         called in such a
>>         manner that can be used for b-legs too. Or an event of the
>>         same kind that carries all the info
>>         needed by radius acct start.
>>         Both ways (adding a state-handler or adding a new event) I
>>         think require
>>         changes to the FS core architecture. I must admit, however,
>>         that my
>>         understanding of the FS source code is still on a newbie
>>         level so the above
>>         conclusions might be wrong.
>>
>>
>>
>>         Anthony Minessale wrote:
>>>         or everything is already in the right place the way it
>>>         already is.....?
>>>
>>>         If all you want to do is background the start packet, then
>>>         just take the info in the place where the existing code gets
>>>         it (routing state change) and create your own switch_event
>>>         or private struct, add the data to it and launch a thread to
>>>         run the radius in it's own thread.
>>>
>>>         I still think making the radius not be down or have short
>>>         timeouts across a list of servers is a better place to fix
>>>         it than making FS launch a bonus thread per established call
>>>         to run the radius start packets in the bg.
>>>
>>>         I also still think that if you insist on not listing to my
>>>         previous point, pushing all the packets to a fifo queue is
>>>         better than launching a new thread per call because if the
>>>         server is down and timing out why would you want to have 250
>>>         threads up at once all blocking on the dead radius instead
>>>         of a queue of them that could withstand a bit of downtime by
>>>         stacking up the start packet requests and unloading them in
>>>         order when it returned.
>>>
>>>
>>>
>>>         On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos
>>>         <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>>>
>>>             I came to the following conclusions :
>>>
>>>             In the case of the acct start I cannot use the
>>>             CHANNEL_ORIGINATE event since
>>>             it is fired only once (I want to send one acct start for
>>>             each leg)
>>>
>>>             If I use the CHANNEL_CREATE event for the acct start I
>>>             am a little sort on info
>>>             since the event does not contain much. So I need to get
>>>             the info from the session.
>>>
>>>             On the acct stop it is better to use the info from the
>>>             event (lots of info - easy to duplicate).
>>>
>>>             I was hoping to implement a uniform way to get data for
>>>             both start and stop but it seems
>>>             that this is not the case.
>>>
>>>
>>>
>>>             Apostolos Pantsiopoulos wrote:
>>>>             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, regs at kinetix.gr
>>>>>             <mailto:regs at kinetix.gr> <regs at kinetix.gr
>>>>>             <mailto:regs at 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, regs at kinetix.gr
>>>>>>                 <mailto:regs at kinetix.gr> <regs at kinetix.gr
>>>>>>                 <mailto:regs at 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 <regs at kinetix.gr
>>>>>>>                     <mailto:regs at 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
>>>>>>>>                         <regs at kinetix.gr
>>>>>>>>                         <mailto:regs at 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 at kinetix.gr
>>>>>>>>>                             <mailto:regs at 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 at kinetix.gr
>>>>>>>>>                                 <mailto:regs at kinetix.gr>
>>>>>>>>>                                 -------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                 _______________________________________________
>>>>>>>>>                                 Freeswitch-dev mailing list
>>>>>>>>>                                 Freeswitch-dev at lists.freeswitch.org
>>>>>>>>>                                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>>>                             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>>>                             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>>>                             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>>>                             IRC: irc.freenode.net
>>>>>>>>>                             <http://irc.freenode.net> #freeswitch
>>>>>>>>>
>>>>>>>>>                             FreeSWITCH Developer Conference
>>>>>>>>>                             sip:888 at conference.freeswitch.org
>>>>>>>>>                             <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>>>                             iax:guest at conference.freeswitch.org/888
>>>>>>>>>                             <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>>>                             googletalk:conf+888 at conference.freeswitch.org
>>>>>>>>>                             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>>>                             pstn:213-799-1400
>>>>>>>>>                             ------------------------------------------------------------------------
>>>>>>>>>                             _______________________________________________
>>>>>>>>>                             Freeswitch-dev mailing list
>>>>>>>>>                             Freeswitch-dev at lists.freeswitch.org
>>>>>>>>>                             <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>>>>                             ------------------------------------------- 
>>>>>>>>
>>>>>>>>
>>>>>>>>                             _______________________________________________
>>>>>>>>                             Freeswitch-dev mailing list
>>>>>>>>                             Freeswitch-dev at lists.freeswitch.org
>>>>>>>>                             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>>                         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>>                         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>>                         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>>                         IRC: irc.freenode.net
>>>>>>>>                         <http://irc.freenode.net> #freeswitch
>>>>>>>>
>>>>>>>>                         FreeSWITCH Developer Conference
>>>>>>>>                         sip:888 at conference.freeswitch.org
>>>>>>>>                         <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>>                         iax:guest at conference.freeswitch.org/888
>>>>>>>>                         <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>>                         googletalk:conf+888 at conference.freeswitch.org
>>>>>>>>                         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>>                         pstn:213-799-1400
>>>>>>>>                         ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>                         _______________________________________________
>>>>>>>>                         Freeswitch-dev mailing list
>>>>>>>>                         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>>>                         ------------------------------------------- 
>>>>>>>
>>>>>>>
>>>>>>>                         _______________________________________________
>>>>>>>                         Freeswitch-dev mailing list
>>>>>>>                         Freeswitch-dev at lists.freeswitch.org
>>>>>>>                         <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>                     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>                     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>                     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>                     IRC: irc.freenode.net
>>>>>>>                     <http://irc.freenode.net> #freeswitch
>>>>>>>
>>>>>>>                     FreeSWITCH Developer Conference
>>>>>>>                     sip:888 at conference.freeswitch.org
>>>>>>>                     <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>                     iax:guest at conference.freeswitch.org/888
>>>>>>>                     <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>                     googletalk:conf+888 at conference.freeswitch.org
>>>>>>>                     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>                     pstn:213-799-1400
>>>>>>>                     ------------------------------------------------------------------------
>>>>>>>
>>>>>>>                     _______________________________________________
>>>>>>>                     Freeswitch-dev mailing list
>>>>>>>                     Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>>>>>                     <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>                 <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>                 GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>                 <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>                 IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>>                 #freeswitch
>>>>>>
>>>>>>                 FreeSWITCH Developer Conference
>>>>>>                 sip:888 at conference.freeswitch.org
>>>>>>                 <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>                 iax:guest at conference.freeswitch.org/888
>>>>>>                 <http://iax:guest at conference.freeswitch.org/888>
>>>>>>                 googletalk:conf+888 at conference.freeswitch.org
>>>>>>                 <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>                 pstn:213-799-1400
>>>>>>                 ------------------------------------------------------------------------
>>>>>>                 _______________________________________________
>>>>>>                 Freeswitch-dev mailing list
>>>>>>                 Freeswitch-dev at lists.freeswitch.org
>>>>>>                 <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>>>>                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>             IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>             #freeswitch
>>>>>
>>>>>             FreeSWITCH Developer Conference
>>>>>             sip:888 at conference.freeswitch.org
>>>>>             <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>             iax:guest at conference.freeswitch.org/888
>>>>>             <http://iax:guest at conference.freeswitch.org/888>
>>>>>             googletalk:conf+888 at conference.freeswitch.org
>>>>>             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>             pstn:213-799-1400
>>>>>             ------------------------------------------------------------------------
>>>>>
>>>>>             _______________________________________________
>>>>>             Freeswitch-dev mailing list
>>>>>             Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>             ------------------------------------------- 
>>>>             ------------------------------------------------------------------------
>>>>
>>>>             _______________________________________________
>>>>             Freeswitch-dev mailing list
>>>>             Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>             ------------------------------------------- 
>>>
>>>
>>>             _______________________________________________
>>>             Freeswitch-dev mailing list
>>>             Freeswitch-dev at lists.freeswitch.org
>>>             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>         IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>>         FreeSWITCH Developer Conference
>>>         sip:888 at conference.freeswitch.org
>>>         <mailto:sip%3A888 at conference.freeswitch.org>
>>>         iax:guest at conference.freeswitch.org/888
>>>         <http://iax:guest at conference.freeswitch.org/888>
>>>         googletalk:conf+888 at conference.freeswitch.org
>>>         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>         pstn:213-799-1400
>>>         ------------------------------------------------------------------------
>>>
>>>         _______________________________________________
>>>         Freeswitch-dev mailing list
>>>         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>         ------------------------------------------- 
>>
>>
>>         _______________________________________________
>>         Freeswitch-dev mailing list
>>         Freeswitch-dev at lists.freeswitch.org
>>         <mailto:Freeswitch-dev at 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 at hotmail.com
>>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>>     FreeSWITCH Developer Conference
>>     sip:888 at conference.freeswitch.org
>>     <mailto:sip%3A888 at conference.freeswitch.org>
>>     iax:guest at conference.freeswitch.org/888
>>     <http://iax:guest at conference.freeswitch.org/888>
>>     googletalk:conf+888 at conference.freeswitch.org
>>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>     pstn:213-799-1400
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     Freeswitch-dev mailing list
>>     Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>     ------------------------------------------- 
>
>
>     _______________________________________________
>     Freeswitch-dev mailing list
>     Freeswitch-dev at lists.freeswitch.org
>     <mailto:Freeswitch-dev at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/66ee1a61/attachment-0001.html 

From anthony.minessale at gmail.com  Tue Feb  3 14:32:10 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Tue, 3 Feb 2009 16:32:10 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions
In-Reply-To: <4988B821.2000805@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>
	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>
	<4987F2D2.1030303@kinetix.gr> <4988239E.4040201@kinetix.gr>
	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>
	<49885789.5000905@kinetix.gr>
	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>
	<4988B36D.2020800@kinetix.gr>
	<191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>
	<4988B821.2000805@kinetix.gr>
Message-ID: <191c3a030902031432j3cfcc39drcfa35f5d284b5959@mail.gmail.com>

the same one that is already in there now the my_on_routing will now get
called for both legs.


On Tue, Feb 3, 2009 at 3:33 PM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:

>  Cheers!
>
> One clarification though :
>
> Would that be a state handler? Or an event handler?
> And what is its name?
>
>
> Anthony Minessale wrote:
>
> yes,
>
> you will *now* get the event handler on both legs.
>
>
> On Tue, Feb 3, 2009 at 3:13 PM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:
>
>>  "you will not get that event handler"
>>
>>  please tell me that this "not" meant to be a "now"
>>
>> Anthony Minessale wrote:
>>
>> I updated the core today in a way that you will not get that event handler
>> on both inbound and outbound legs.
>>
>>
>> On Tue, Feb 3, 2009 at 8:41 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:
>>
>>> Even if my intention was not to send the acct start in a separate thread
>>> we are still missing an acct start at the setup of the b-leg of a bridge.
>>> The on_routing handler cannot do that (it is called only for the a-leg).
>>> I tried on_init (which I thought was called at the setup of a channel)
>>> but
>>> it didn't invoke my handler even for the a-leg. An event on the other
>>> hand
>>> (create_channel) which is triggered correctly does not carry all the info
>>>
>>> needed for an acct start packet to be filled (not even at a min level).
>>> The
>>> event originate_channel is also called only once during a bridge, so it
>>> cannot
>>> be used either.
>>>
>>> So it is not only a matter of thread vs non threaded (or multiple threads
>>> vs one thread).
>>> It is also a matter of when and how many times (2 for a simple bridge) to
>>> call an
>>> acct start routine.
>>>
>>> So we either need to create one more state handler that gets called in
>>> such a
>>> manner that can be used for b-legs too. Or an event of the same kind that
>>> carries all the info
>>> needed by radius acct start.
>>> Both ways (adding a state-handler or adding a new event) I think require
>>> changes to the FS core architecture. I must admit, however, that my
>>> understanding of the FS source code is still on a newbie level so the
>>> above
>>> conclusions might be wrong.
>>>
>>>
>>> Anthony Minessale wrote:
>>>
>>> or everything is already in the right place the way it already is.....?
>>>
>>> If all you want to do is background the start packet, then just take the
>>> info in the place where the existing code gets it (routing state change) and
>>> create your own switch_event or private struct, add the data to it and
>>> launch a thread to run the radius in it's own thread.
>>>
>>> I still think making the radius not be down or have short timeouts across
>>> a list of servers is a better place to fix it than making FS launch a bonus
>>> thread per established call to run the radius start packets in the bg.
>>>
>>> I also still think that if you insist on not listing to my previous
>>> point, pushing all the packets to a fifo queue is better than launching a
>>> new thread per call because if the server is down and timing out why would
>>> you want to have 250 threads up at once all blocking on the dead radius
>>> instead of a queue of them that could withstand a bit of downtime by
>>> stacking up the start packet requests and unloading them in order when it
>>> returned.
>>>
>>>
>>>
>>> On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos <regs at kinetix.gr
>>> > wrote:
>>>
>>>> I came to the following conclusions :
>>>>
>>>> In the case of the acct start I cannot use the CHANNEL_ORIGINATE event
>>>> since
>>>> it is fired only once (I want to send one acct start for each leg)
>>>>
>>>> If I use the CHANNEL_CREATE event for the acct start I am a little sort
>>>> on info
>>>> since the event does not contain much. So I need to get the info from
>>>> the session.
>>>>
>>>> On the acct stop it is better to use the info from the event (lots of
>>>> info - easy to duplicate).
>>>>
>>>> I was hoping to implement a uniform way to get data for both start and
>>>> stop but it seems
>>>> that this is not the case.
>>>>
>>>>
>>>> Apostolos Pantsiopoulos wrote:
>>>>
>>>> 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, regs at kinetix.gr <regs at 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, regs at kinetix.gr <regs at 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 <
>>>>>> regs at 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 <
>>>>>>> regs at 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 at 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 at kinetix.gr
>>>>>>>>> -------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Freeswitch-dev mailing list
>>>>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>> IRC: irc.freenode.net #freeswitch
>>>>>>>>
>>>>>>>> FreeSWITCH Developer Conference
>>>>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>>>>> iax:guest at conference.freeswitch.org/888
>>>>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>> pstn:213-799-1400
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> -------------------------------------------
>>>>>>>> Apostolos Pantsiopoulos
>>>>>>>> Kinetix Tele.com R & D
>>>>>>>> email: regs at kinetix.gr
>>>>>>>> -------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Freeswitch-dev mailing list
>>>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>> IRC: irc.freenode.net #freeswitch
>>>>>>>
>>>>>>> FreeSWITCH Developer Conference
>>>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>>>> iax:guest at conference.freeswitch.org/888
>>>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>> pstn:213-799-1400
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -------------------------------------------
>>>>>>> Apostolos Pantsiopoulos
>>>>>>> Kinetix Tele.com R & D
>>>>>>> email: regs at kinetix.gr
>>>>>>> -------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Freeswitch-dev mailing list
>>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>> IRC: irc.freenode.net #freeswitch
>>>>>>
>>>>>> FreeSWITCH Developer Conference
>>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>>> iax:guest at conference.freeswitch.org/888
>>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>> pstn:213-799-1400
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing list
>>>>>> Freeswitch-dev at 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 at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>>> IRC: irc.freenode.net #freeswitch
>>>>>
>>>>> FreeSWITCH Developer Conference
>>>>> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>>>> iax:guest at conference.freeswitch.org/888
>>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>> pstn:213-799-1400
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing list
>>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>>> IRC: irc.freenode.net #freeswitch
>>>>
>>>> FreeSWITCH Developer Conference
>>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>>> iax:guest at conference.freeswitch.org/888
>>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>> pstn:213-799-1400
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>
>>>>
>>>>
>>>> --
>>>> -------------------------------------------
>>>> Apostolos Pantsiopoulos
>>>> Kinetix Tele.com R & D
>>>> email: regs at kinetix.gr
>>>> -------------------------------------------
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>>
>>>>
>>>>
>>>> --
>>>> -------------------------------------------
>>>> Apostolos Pantsiopoulos
>>>> Kinetix Tele.com R & D
>>>> email: regs at kinetix.gr
>>>> -------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing list
>>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>>
>>>
>>>
>>> --
>>> -------------------------------------------
>>> Apostolos Pantsiopoulos
>>> Kinetix Tele.com R & D
>>> email: regs at kinetix.gr
>>> -------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: regs at kinetix.gr
>> -------------------------------------------
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/01d6c549/attachment-0001.html 

From f.koliqi at gmail.com  Tue Feb  3 14:32:53 2009
From: f.koliqi at gmail.com (Fadil Berisha)
Date: Tue, 3 Feb 2009 17:32:53 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <6E600F82-3740-4F2A-A4D2-1A12F41F57C4@freeswitch.org>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>
	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
	<09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
	<49882A91.5080509@navynet.it>
	<6E600F82-3740-4F2A-A4D2-1A12F41F57C4@freeswitch.org>
Message-ID: <5c7d82f20902031432y10ee84bif183da6b4afb6aab@mail.gmail.com>

Deb official package need to be in accordance with  debian rules. This apply
also for debian files in trunk. As they are, I think, they  need second
look. On Ubuntu -8.10 you can compile fresswitch with no problem, but
problems are during creating packages (version 1.0.2) - I needed them to
install in machine with compiler. At least, I got problem with -Werror
(needed to modify Makefile) and I find that post install debian file does
not  create proper ownership for directory freswitch.

koliqi


On Tue, Feb 3, 2009 at 11:57 AM, Brian West <brian at freeswitch.org> wrote:

> I came to the conclusion that it doesn't matter what we want, people
> will package it like they want... we might as well be involved in it
> than turn people away which in the end will increase support time
> because you have ten people making a package for debian vs one
> official package.
>
> /b
>
> On Feb 3, 2009, at 5:29 AM, Massimo Ctrix Cetra wrote:
>
> > Brian, be careful.
> >
> > The debian standards wants daemons to be installed in fixed places
> > (for
> > example, freeswitch in /usr/sbin fs_cli in /usr/bin, modules in
> > /usr/lib/freeswitch/ and so on)
> >
> > Even if having the official patches in trunk would be a very good
> > option, probabily it will break the freeswitch rules to have a common
> > pattern among all build systems (that is everything in /opt/
> > freeswitch).
> >
> > I know you wanted everything in /opt/freeswitch to handle support
> > requests better.
> >
> > This is just FYI!
> >
> > Max
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/ec6e03dd/attachment.html 

From mike at jerris.com  Tue Feb  3 15:38:13 2009
From: mike at jerris.com (Michael Jerris)
Date: Tue, 3 Feb 2009 18:38:13 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <5c7d82f20902031432y10ee84bif183da6b4afb6aab@mail.gmail.com>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>
	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
	<09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
	<49882A91.5080509@navynet.it>
	<6E600F82-3740-4F2A-A4D2-1A12F41F57C4@freeswitch.org>
	<5c7d82f20902031432y10ee84bif183da6b4afb6aab@mail.gmail.com>
Message-ID: <B4C6A7F2-FCD0-4761-B4C8-01893599067A@jerris.com>

If your having issues that require you to remove -Werror we would much  
rather fix them for real, I have fixed all of those issues I believe  
in trunk, can you please check out trunk and confirm that they are all  
fixed.

Mike

On Feb 3, 2009, at 5:32 PM, Fadil Berisha wrote:

> Deb official package need to be in accordance with  debian rules.  
> This apply also for debian files in trunk. As they are, I think,  
> they  need second look. On Ubuntu -8.10 you can compile fresswitch  
> with no problem, but problems are during creating packages (version  
> 1.0.2) - I needed them to install in machine with compiler. At  
> least, I got problem with -Werror (needed to modify Makefile) and I  
> find that post install debian file does not  create proper ownership  
> for directory freswitch.
>
> koliqi
>



From f.koliqi at gmail.com  Tue Feb  3 18:46:30 2009
From: f.koliqi at gmail.com (Fadil Berisha)
Date: Tue, 3 Feb 2009 21:46:30 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <B4C6A7F2-FCD0-4761-B4C8-01893599067A@jerris.com>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>
	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
	<09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
	<49882A91.5080509@navynet.it>
	<6E600F82-3740-4F2A-A4D2-1A12F41F57C4@freeswitch.org>
	<5c7d82f20902031432y10ee84bif183da6b4afb6aab@mail.gmail.com>
	<B4C6A7F2-FCD0-4761-B4C8-01893599067A@jerris.com>
Message-ID: <5c7d82f20902031846o607e8ee7ya2c9a8d82b8616a5@mail.gmail.com>

Hi Mike

Here is results from dpkg-buildpackage -d

creating testanalog
cc1: warnings being treated as errors
src/testapp.c: In function 'main':
src/testapp.c:48: error: format '%lu' expects type 'long unsigned int', but
argument 2 has type 'zap_size_t'
src/testapp.c:52: error: format '%lu' expects type 'long unsigned int', but
argument 2 has type 'zap_size_t'
src/testapp.c:54: error: format '%lu' expects type 'long unsigned int', but
argument 2 has type 'zap_size_t'
make[7]: *** [testapp-testapp.o] Error 1
make[7]: Leaving directory `/home/devel/freeswitch/libs/openzap'
make[6]: *** [../libopenzap.so] Error 2
make[6]: Leaving directory `/home/devel/freeswitch/libs/openzap/mod_openzap'
make[5]: *** [all] Error 1
make[5]: Leaving directory `/home/devel/freeswitch/libs/openzap/mod_openzap'
make[4]: *** [../../libs/openzap/mod_openzap-all] Error 1
make[4]: Leaving directory `/home/devel/freeswitch/src/mod'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/devel/freeswitch/src'
Making all in build
make[3]: Entering directory `/home/devel/freeswitch/build'
 +-------- FreeSWITCH Build Complete -----------+
 + FreeSWITCH has been successfully built.      +
 + Install by running:                          +
 +                                              +
 +               /usr/bin/make install                   +
 +----------------------------------------------+
make[3]: Leaving directory `/home/devel/freeswitch/build'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/devel/freeswitch'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/devel/freeswitch'
make: *** [build-stamp] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2


koliqi



On Tue, Feb 3, 2009 at 6:38 PM, Michael Jerris <mike at jerris.com> wrote:

> If your having issues that require you to remove -Werror we would much
> rather fix them for real, I have fixed all of those issues I believe
> in trunk, can you please check out trunk and confirm that they are all
> fixed.
>
> Mike
>
> On Feb 3, 2009, at 5:32 PM, Fadil Berisha wrote:
>
> > Deb official package need to be in accordance with  debian rules.
> > This apply also for debian files in trunk. As they are, I think,
> > they  need second look. On Ubuntu -8.10 you can compile fresswitch
> > with no problem, but problems are during creating packages (version
> > 1.0.2) - I needed them to install in machine with compiler. At
> > least, I got problem with -Werror (needed to modify Makefile) and I
> > find that post install debian file does not  create proper ownership
> > for directory freswitch.
> >
> > koliqi
> >
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090203/677c372a/attachment.html 

From mike at jerris.com  Tue Feb  3 21:02:01 2009
From: mike at jerris.com (Michael Jerris)
Date: Wed, 4 Feb 2009 00:02:01 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <5c7d82f20902031846o607e8ee7ya2c9a8d82b8616a5@mail.gmail.com>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>
	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
	<09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
	<49882A91.5080509@navynet.it>
	<6E600F82-3740-4F2A-A4D2-1A12F41F57C4@freeswitch.org>
	<5c7d82f20902031432y10ee84bif183da6b4afb6aab@mail.gmail.com>
	<B4C6A7F2-FCD0-4761-B4C8-01893599067A@jerris.com>
	<5c7d82f20902031846o607e8ee7ya2c9a8d82b8616a5@mail.gmail.com>
Message-ID: <B9F9974D-AEB9-4EED-869C-189D1B6D878C@jerris.com>

This issue was already fixed in svn trunk.

Mike


On Feb 3, 2009, at 9:46 PM, Fadil Berisha wrote:

> Hi Mike
>
> Here is results from dpkg-buildpackage -d
>
> creating testanalog
> cc1: warnings being treated as errors
> src/testapp.c: In function 'main':
> src/testapp.c:48: error: format '%lu' expects type 'long unsigned  
> int', but argument 2 has type 'zap_size_t'
> src/testapp.c:52: error: format '%lu' expects type 'long unsigned  
> int', but argument 2 has type 'zap_size_t'
> src/testapp.c:54: error: format '%lu' expects type 'long unsigned  
> int', but argument 2 has type 'zap_size_t'
> make[7]: *** [testapp-testapp.o] Error 1
> make[7]: Leaving directory `/home/devel/freeswitch/libs/openzap'
> make[6]: *** [../libopenzap.so] Error 2
> make[6]: Leaving directory `/home/devel/freeswitch/libs/openzap/ 
> mod_openzap'
> make[5]: *** [all] Error 1
> make[5]: Leaving directory `/home/devel/freeswitch/libs/openzap/ 
> mod_openzap'
> make[4]: *** [../../libs/openzap/mod_openzap-all] Error 1
> make[4]: Leaving directory `/home/devel/freeswitch/src/mod'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/home/devel/freeswitch/src'
> Making all in build
> make[3]: Entering directory `/home/devel/freeswitch/build'
>  +-------- FreeSWITCH Build Complete -----------+
>  + FreeSWITCH has been successfully built.      +
>  + Install by running:                          +
>  +                                              +
>  +               /usr/bin/make install                   +
>  +----------------------------------------------+
> make[3]: Leaving directory `/home/devel/freeswitch/build'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/devel/freeswitch'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/devel/freeswitch'
> make: *** [build-stamp] Error 2
> dpkg-buildpackage: failure: debian/rules build gave error exit  
> status 2
>
>
> koliqi



From f.koliqi at gmail.com  Tue Feb  3 22:08:27 2009
From: f.koliqi at gmail.com (Fadil Berisha)
Date: Wed, 4 Feb 2009 01:08:27 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <B9F9974D-AEB9-4EED-869C-189D1B6D878C@jerris.com>
References: <8171bb3b0901310828i72b9c0dj389b9ed7bc791540@mail.gmail.com>
	<47330689-9A51-4011-91D8-6B561E1D2224@jerris.com>
	<8171bb3b0902021009t634bf6cdq871049326848eb80@mail.gmail.com>
	<09548985-B5DB-473C-B057-CC80CEBC3245@freeswitch.org>
	<49882A91.5080509@navynet.it>
	<6E600F82-3740-4F2A-A4D2-1A12F41F57C4@freeswitch.org>
	<5c7d82f20902031432y10ee84bif183da6b4afb6aab@mail.gmail.com>
	<B4C6A7F2-FCD0-4761-B4C8-01893599067A@jerris.com>
	<5c7d82f20902031846o607e8ee7ya2c9a8d82b8616a5@mail.gmail.com>
	<B9F9974D-AEB9-4EED-869C-189D1B6D878C@jerris.com>
Message-ID: <5c7d82f20902032208o67bffd45ndbf4260a27d973a0@mail.gmail.com>

I submitted fresh result from today's svn trunk. If issue was already fixed
and appears only on my Ubuntu-8.10 system - no problem.

koliqi


On Wed, Feb 4, 2009 at 12:02 AM, Michael Jerris <mike at jerris.com> wrote:

> This issue was already fixed in svn trunk.
>
> Mike
>
>
> On Feb 3, 2009, at 9:46 PM, Fadil Berisha wrote:
>
> > Hi Mike
> >
> > Here is results from dpkg-buildpackage -d
> >
> > creating testanalog
> > cc1: warnings being treated as errors
> > src/testapp.c: In function 'main':
> > src/testapp.c:48: error: format '%lu' expects type 'long unsigned
> > int', but argument 2 has type 'zap_size_t'
> > src/testapp.c:52: error: format '%lu' expects type 'long unsigned
> > int', but argument 2 has type 'zap_size_t'
> > src/testapp.c:54: error: format '%lu' expects type 'long unsigned
> > int', but argument 2 has type 'zap_size_t'
> > make[7]: *** [testapp-testapp.o] Error 1
> > make[7]: Leaving directory `/home/devel/freeswitch/libs/openzap'
> > make[6]: *** [../libopenzap.so] Error 2
> > make[6]: Leaving directory `/home/devel/freeswitch/libs/openzap/
> > mod_openzap'
> > make[5]: *** [all] Error 1
> > make[5]: Leaving directory `/home/devel/freeswitch/libs/openzap/
> > mod_openzap'
> > make[4]: *** [../../libs/openzap/mod_openzap-all] Error 1
> > make[4]: Leaving directory `/home/devel/freeswitch/src/mod'
> > make[3]: *** [all-recursive] Error 1
> > make[3]: Leaving directory `/home/devel/freeswitch/src'
> > Making all in build
> > make[3]: Entering directory `/home/devel/freeswitch/build'
> >  +-------- FreeSWITCH Build Complete -----------+
> >  + FreeSWITCH has been successfully built.      +
> >  + Install by running:                          +
> >  +                                              +
> >  +               /usr/bin/make install                   +
> >  +----------------------------------------------+
> > make[3]: Leaving directory `/home/devel/freeswitch/build'
> > make[2]: *** [all-recursive] Error 1
> > make[2]: Leaving directory `/home/devel/freeswitch'
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory `/home/devel/freeswitch'
> > make: *** [build-stamp] Error 2
> > dpkg-buildpackage: failure: debian/rules build gave error exit
> > status 2
> >
> >
> > koliqi
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090204/d2bffd21/attachment-0001.html 

From a05davdi at student.his.se  Tue Feb  3 22:53:48 2009
From: a05davdi at student.his.se (David Dikman (a05davdi))
Date: Wed, 4 Feb 2009 07:53:48 +0100
Subject: [Freeswitch-dev] Manual Attended Transfer using 3 channels
References: <647269A02EDE50418961A365DEBD522C407E8B@studms1.STUDENT.HIS.local>
Message-ID: <647269A02EDE50418961A365DEBD522C407E8C@studms1.STUDENT.HIS.local>

Hi,
I'm currently implementing an operator to direct calls with using freeswitch and event socket. 
The operator should be able to do an attended transfer, that is the operator is supposed to be able to recieve a call, call another party and switch back and forward between these to before eventually bridging them together. (I cannot use att_xfer since it doesn't have the behaviour we wish).

I've gotten everything to work fine up 'till the point where the operator has called a second party and whishes to switch back to the first party and this is where I need some help.

I use event socket for sending the api commands but if I could just get a hint of how to do it manually (with console) I could probably convert it (or how to do it in js).

These are the steps I go through now: (notice that I'm trying to use only 3 channels so that the operator needn't park channels on phone)

* Originate call between inbound call and operator (Gives me what i'll refer to as Leg A and Leg B)
* Hold Leg A (gives music to Leg A)
* Transfer Leg B to Ext XX (Gives me Leg C, now I've got one call from A-B and one from B-C)
* Unhold Leg B (I can talk between B and C)

What should be the next step?
I've tried holding C and then bridging, transfering, intercepting etc but nothing works. Whatever I do the call between Leg A and Leg B disappears and no sound between the two. I can bridge A->C and get them to talk to each other but I would also like to be able to switch back from B->C to A-B.
 
I've been guessing my way around this for quite some time now and I would really appreciate some help.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090204/4530e4f4/attachment.html 

From anthony.minessale at gmail.com  Wed Feb  4 08:28:22 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Wed, 4 Feb 2009 10:28:22 -0600
Subject: [Freeswitch-dev] Manual Attended Transfer using 3 channels
In-Reply-To: <647269A02EDE50418961A365DEBD522C407E8C@studms1.STUDENT.HIS.local>
References: <647269A02EDE50418961A365DEBD522C407E8B@studms1.STUDENT.HIS.local>
	<647269A02EDE50418961A365DEBD522C407E8C@studms1.STUDENT.HIS.local>
Message-ID: <191c3a030902040828h6f43fbb8n7b5953a47cff9cde@mail.gmail.com>

uuid_transfer <either uuid of bridged call> -both park inline

now they are both parked.

uuid_bridge <uuid> <another uuid>

now they are bridged




On Wed, Feb 4, 2009 at 12:53 AM, David Dikman (a05davdi) <
a05davdi at student.his.se> wrote:

>  Hi,
> I'm currently implementing an operator to direct calls with using
> freeswitch and event socket.
> The operator should be able to do an attended transfer, that is the
> operator is supposed to be able to recieve a call, call another party and
> switch back and forward between these to before eventually bridging them
> together. (I cannot use att_xfer since it doesn't have the behaviour we
> wish).
>
> I've gotten everything to work fine up 'till the point where the operator
> has called a second party and whishes to switch back to the first party and
> this is where I need some help.
>
> I use event socket for sending the api commands but if I could just get a
> hint of how to do it manually (with console) I could probably convert it (or
> how to do it in js).
>
> These are the steps I go through now: (notice that I'm trying to use only 3
> channels so that the operator needn't park channels on phone)
>
> * Originate call between inbound call and operator (Gives me what i'll
> refer to as Leg A and Leg B)
> * Hold Leg A (gives music to Leg A)
> * Transfer Leg B to Ext XX (Gives me Leg C, now I've got one call from A-B
> and one from B-C)
> * Unhold Leg B (I can talk between B and C)
>
> What should be the next step?
> I've tried holding C and then bridging, transfering, intercepting etc but
> nothing works. Whatever I do the call between Leg A and Leg B disappears and
> no sound between the two. I can bridge A->C and get them to talk to each
> other but I would also like to be able to switch back from B->C to A-B.
>
> I've been guessing my way around this for quite some time now and I would
> really appreciate some help.
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090204/d7893b17/attachment.html 

From mike at jerris.com  Wed Feb  4 08:35:15 2009
From: mike at jerris.com (Michael Jerris)
Date: Wed, 04 Feb 2009 11:35:15 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <5c7d82f20902032208o67bffd45ndbf4260a27d973a0@mail.gmail.com>
Message-ID: <C5AF2DF3.1427C%mike@jerris.com>

I misread the issue, please update again and test.

Mike


On 2/4/09 1:08 AM, "Fadil Berisha" <f.koliqi at gmail.com> wrote:

> I submitted fresh result from today's svn trunk. If issue was already fixed
> and appears only on my Ubuntu-8.10 system - no problem.
> 
> koliqi
> 
> 
> On Wed, Feb 4, 2009 at 12:02 AM, Michael Jerris <mike at jerris.com> wrote:
>> This issue was already fixed in svn trunk.
>> 
>> Mike
>> 
>> 
>> On Feb 3, 2009, at 9:46 PM, Fadil Berisha wrote:
>> 
>>> > Hi Mike
>>> >
>>> > Here is results from dpkg-buildpackage -d
>>> >
>>> > creating testanalog
>>> > cc1: warnings being treated as errors
>>> > src/testapp.c: In function 'main':
>>> > src/testapp.c:48: error: format '%lu' expects type 'long unsigned
>>> > int', but argument 2 has type 'zap_size_t'
>>> > src/testapp.c:52: error: format '%lu' expects type 'long unsigned
>>> > int', but argument 2 has type 'zap_size_t'
>>> > src/testapp.c:54: error: format '%lu' expects type 'long unsigned
>>> > int', but argument 2 has type 'zap_size_t'
>>> > make[7]: *** [testapp-testapp.o] Error 1
>>> > make[7]: Leaving directory `/home/devel/freeswitch/libs/openzap'
>>> > make[6]: *** [../libopenzap.so] Error 2
>>> > make[6]: Leaving directory `/home/devel/freeswitch/libs/openzap/
>>> > mod_openzap'
>>> > make[5]: *** [all] Error 1
>>> > make[5]: Leaving directory `/home/devel/freeswitch/libs/openzap/
>>> > mod_openzap'
>>> > make[4]: *** [../../libs/openzap/mod_openzap-all] Error 1
>>> > make[4]: Leaving directory `/home/devel/freeswitch/src/mod'
>>> > make[3]: *** [all-recursive] Error 1
>>> > make[3]: Leaving directory `/home/devel/freeswitch/src'
>>> > Making all in build
>>> > make[3]: Entering directory `/home/devel/freeswitch/build'
>>> >  +-------- FreeSWITCH Build Complete -----------+
>>> >  + FreeSWITCH has been successfully built.      +
>>> >  + Install by running:                          +
>>> >  +                                              +
>>> >  +               /usr/bin/make install                   +
>>> >  +----------------------------------------------+
>>> > make[3]: Leaving directory `/home/devel/freeswitch/build'
>>> > make[2]: *** [all-recursive] Error 1
>>> > make[2]: Leaving directory `/home/devel/freeswitch'
>>> > make[1]: *** [all] Error 2
>>> > make[1]: Leaving directory `/home/devel/freeswitch'
>>> > make: *** [build-stamp] Error 2
>>> > dpkg-buildpackage: failure: debian/rules build gave error exit
>>> > status 2
>>> >
>>> >
>>> > koliqi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090204/3cb82f44/attachment.html 

From f.koliqi at gmail.com  Wed Feb  4 19:07:29 2009
From: f.koliqi at gmail.com (Fadil Berisha)
Date: Wed, 4 Feb 2009 22:07:29 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <C5AF2DF3.1427C%mike@jerris.com>
References: <5c7d82f20902032208o67bffd45ndbf4260a27d973a0@mail.gmail.com>
	<C5AF2DF3.1427C%mike@jerris.com>
Message-ID: <5c7d82f20902041907g323f607di35410a32e7b52891@mail.gmail.com>

this is result from revision 11649, warning error is now in testcid.c, will
assist until getting clean code from warning errors.

cc1: warnings being treated as errors
src/testcid.c: In function 'main':
src/testcid.c:70: error: format '%lu' expects type 'long unsigned int', but
argument 2 has type 'zap_size_t'

koliqi


On Wed, Feb 4, 2009 at 11:35 AM, Michael Jerris <mike at jerris.com> wrote:

>  I misread the issue, please update again and test.
>
> Mike
>
>
>
> On 2/4/09 1:08 AM, "Fadil Berisha" <f.koliqi at gmail.com> wrote:
>
> I submitted fresh result from today's svn trunk. If issue was already fixed
> and appears only on my Ubuntu-8.10 system - no problem.
>
> koliqi
>
>
> On Wed, Feb 4, 2009 at 12:02 AM, Michael Jerris <mike at jerris.com> wrote:
>
> This issue was already fixed in svn trunk.
>
> Mike
>
>
> On Feb 3, 2009, at 9:46 PM, Fadil Berisha wrote:
>
> > Hi Mike
> >
> > Here is results from dpkg-buildpackage -d
> >
> > creating testanalog
> > cc1: warnings being treated as errors
> > src/testapp.c: In function 'main':
> > src/testapp.c:48: error: format '%lu' expects type 'long unsigned
> > int', but argument 2 has type 'zap_size_t'
> > src/testapp.c:52: error: format '%lu' expects type 'long unsigned
> > int', but argument 2 has type 'zap_size_t'
> > src/testapp.c:54: error: format '%lu' expects type 'long unsigned
> > int', but argument 2 has type 'zap_size_t'
> > make[7]: *** [testapp-testapp.o] Error 1
> > make[7]: Leaving directory `/home/devel/freeswitch/libs/openzap'
> > make[6]: *** [../libopenzap.so] Error 2
> > make[6]: Leaving directory `/home/devel/freeswitch/libs/openzap/
> > mod_openzap'
> > make[5]: *** [all] Error 1
> > make[5]: Leaving directory `/home/devel/freeswitch/libs/openzap/
> > mod_openzap'
> > make[4]: *** [../../libs/openzap/mod_openzap-all] Error 1
> > make[4]: Leaving directory `/home/devel/freeswitch/src/mod'
> > make[3]: *** [all-recursive] Error 1
> > make[3]: Leaving directory `/home/devel/freeswitch/src'
> > Making all in build
> > make[3]: Entering directory `/home/devel/freeswitch/build'
> >  +-------- FreeSWITCH Build Complete -----------+
> >  + FreeSWITCH has been successfully built.      +
> >  + Install by running:                          +
> >  +                                              +
> >  +               /usr/bin/make install                   +
> >  +----------------------------------------------+
> > make[3]: Leaving directory `/home/devel/freeswitch/build'
> > make[2]: *** [all-recursive] Error 1
> > make[2]: Leaving directory `/home/devel/freeswitch'
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory `/home/devel/freeswitch'
> > make: *** [build-stamp] Error 2
> > dpkg-buildpackage: failure: debian/rules build gave error exit
> > status 2
> >
> >
> > koliqi
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090204/128486cc/attachment-0001.html 

From mike at jerris.com  Wed Feb  4 19:26:40 2009
From: mike at jerris.com (Michael Jerris)
Date: Wed, 4 Feb 2009 22:26:40 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <5c7d82f20902041907g323f607di35410a32e7b52891@mail.gmail.com>
References: <5c7d82f20902032208o67bffd45ndbf4260a27d973a0@mail.gmail.com>
	<C5AF2DF3.1427C%mike@jerris.com>
	<5c7d82f20902041907g323f607di35410a32e7b52891@mail.gmail.com>
Message-ID: <671A9B36-B1A1-4FC6-923F-1894C980512E@jerris.com>

Missed one, fixed, how about now?

Mike

On Feb 4, 2009, at 10:07 PM, Fadil Berisha wrote:

> this is result from revision 11649, warning error is now in  
> testcid.c, will assist until getting clean code from warning errors.
>
> cc1: warnings being treated as errors
> src/testcid.c: In function 'main':
> src/testcid.c:70: error: format '%lu' expects type 'long unsigned  
> int', but argument 2 has type 'zap_size_t'
>
> koliqi
>



From a05davdi at student.his.se  Wed Feb  4 23:04:02 2009
From: a05davdi at student.his.se (David Dikman (a05davdi))
Date: Thu, 5 Feb 2009 08:04:02 +0100
Subject: [Freeswitch-dev] Manual Attended Transfer using 3 channels
References: <647269A02EDE50418961A365DEBD522C407E8B@studms1.STUDENT.HIS.local><647269A02EDE50418961A365DEBD522C407E8C@studms1.STUDENT.HIS.local>
	<191c3a030902040828h6f43fbb8n7b5953a47cff9cde@mail.gmail.com>
Message-ID: <647269A02EDE50418961A365DEBD522C407E8D@studms1.STUDENT.HIS.local>


It works so splendidly!
Only curious thing is that I need to give a destination on the transfer, ie:
uuid_transfer <uuid> -both park inline <some extension>


Too bad the 'park inline' wasn't mentioned Anywhere in the wiki, think I'll post a page on it.
Thanks a hundred times over!


-----Ursprungligt meddelande-----
Fr?n: freeswitch-dev-bounces at lists.freeswitch.org genom Anthony Minessale
Skickat: on 2009-02-04 17:28
Till: freeswitch-dev at lists.freeswitch.org
?mne: Re: [Freeswitch-dev] Manual Attended Transfer using 3 channels
 
uuid_transfer <either uuid of bridged call> -both park inline

now they are both parked.

uuid_bridge <uuid> <another uuid>

now they are bridged




On Wed, Feb 4, 2009 at 12:53 AM, David Dikman (a05davdi) <
a05davdi at student.his.se> wrote:

>  Hi,
> I'm currently implementing an operator to direct calls with using
> freeswitch and event socket.
> The operator should be able to do an attended transfer, that is the
> operator is supposed to be able to recieve a call, call another party and
> switch back and forward between these to before eventually bridging them
> together. (I cannot use att_xfer since it doesn't have the behaviour we
> wish).
>
> I've gotten everything to work fine up 'till the point where the operator
> has called a second party and whishes to switch back to the first party and
> this is where I need some help.
>
> I use event socket for sending the api commands but if I could just get a
> hint of how to do it manually (with console) I could probably convert it (or
> how to do it in js).
>
> These are the steps I go through now: (notice that I'm trying to use only 3
> channels so that the operator needn't park channels on phone)
>
> * Originate call between inbound call and operator (Gives me what i'll
> refer to as Leg A and Leg B)
> * Hold Leg A (gives music to Leg A)
> * Transfer Leg B to Ext XX (Gives me Leg C, now I've got one call from A-B
> and one from B-C)
> * Unhold Leg B (I can talk between B and C)
>
> What should be the next step?
> I've tried holding C and then bridging, transfering, intercepting etc but
> nothing works. Whatever I do the call between Leg A and Leg B disappears and
> no sound between the two. I can bridge A->C and get them to talk to each
> other but I would also like to be able to switch back from B->C to A-B.
>
> I've been guessing my way around this for quite some time now and I would
> really appreciate some help.
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090205/f0799445/attachment.html 

From brian at freeswitch.org  Wed Feb  4 23:19:59 2009
From: brian at freeswitch.org (Brian West)
Date: Thu, 5 Feb 2009 01:19:59 -0600
Subject: [Freeswitch-dev] Manual Attended Transfer using 3 channels
In-Reply-To: <647269A02EDE50418961A365DEBD522C407E8D@studms1.STUDENT.HIS.local>
References: <647269A02EDE50418961A365DEBD522C407E8B@studms1.STUDENT.HIS.local><647269A02EDE50418961A365DEBD522C407E8C@studms1.STUDENT.HIS.local>
	<191c3a030902040828h6f43fbb8n7b5953a47cff9cde@mail.gmail.com>
	<647269A02EDE50418961A365DEBD522C407E8D@studms1.STUDENT.HIS.local>
Message-ID: <23FD9592-B2DC-4262-A34C-B191D6BD5450@freeswitch.org>


On Feb 5, 2009, at 1:04 AM, David Dikman (a05davdi) wrote:

>
> It works so splendidly!
> Only curious thing is that I need to give a destination on the  
> transfer, ie:
> uuid_transfer <uuid> -both park inline <some extension>
>
>
> Too bad the 'park inline' wasn't mentioned Anywhere in the wiki,  
> think I'll post a page on it.
> Thanks a hundred times over!

http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_InlineDialplan

;)

/b

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090205/c2c0105c/attachment.html 

From f.koliqi at gmail.com  Thu Feb  5 00:29:08 2009
From: f.koliqi at gmail.com (Fadil Berisha)
Date: Thu, 5 Feb 2009 03:29:08 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <671A9B36-B1A1-4FC6-923F-1894C980512E@jerris.com>
References: <5c7d82f20902032208o67bffd45ndbf4260a27d973a0@mail.gmail.com>
	<C5AF2DF3.1427C%mike@jerris.com>
	<5c7d82f20902041907g323f607di35410a32e7b52891@mail.gmail.com>
	<671A9B36-B1A1-4FC6-923F-1894C980512E@jerris.com>
Message-ID: <5c7d82f20902050029t3197bfe1n54ec372dde026d44@mail.gmail.com>

Revision 11653 is clean and no any warning error.  deb binary package
building stops at final stage because  dh_install looks for modules at
debian/tmp//opt/freeswitch/mod but they are created in diferent directory
debian/tmp/usr/lib/freeswitch/modules. Here is mesage

dh_install --sourcedir=debian/tmp
cp: cannot stat `debian/tmp//opt/freeswitch/mod/mod_openzap.so': No such
file or directory
dh_install: command returned error code 256
----------------------------------------------------------------

In rules, configure should be --with-modinstdir=/opt/freeswitch/mod  is that
right?

koliqi



On Wed, Feb 4, 2009 at 10:26 PM, Michael Jerris <mike at jerris.com> wrote:

> Missed one, fixed, how about now?
>
> Mike
>
> On Feb 4, 2009, at 10:07 PM, Fadil Berisha wrote:
>
> > this is result from revision 11649, warning error is now in
> > testcid.c, will assist until getting clean code from warning errors.
> >
> > cc1: warnings being treated as errors
> > src/testcid.c: In function 'main':
> > src/testcid.c:70: error: format '%lu' expects type 'long unsigned
> > int', but argument 2 has type 'zap_size_t'
> >
> > koliqi
> >
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090205/5009ac14/attachment.html 

From a05davdi at student.his.se  Thu Feb  5 01:07:49 2009
From: a05davdi at student.his.se (David Dikman (a05davdi))
Date: Thu, 5 Feb 2009 10:07:49 +0100
Subject: [Freeswitch-dev] Manual Attended Transfer using 3 channels
References: <647269A02EDE50418961A365DEBD522C407E8B@studms1.STUDENT.HIS.local><647269A02EDE50418961A365DEBD522C407E8C@studms1.STUDENT.HIS.local><191c3a030902040828h6f43fbb8n7b5953a47cff9cde@mail.gmail.com><647269A02EDE50418961A365DEBD522C407E8D@studms1.STUDENT.HIS.local>
	<23FD9592-B2DC-4262-A34C-B191D6BD5450@freeswitch.org>
Message-ID: <647269A02EDE50418961A365DEBD522C407E8E@studms1.STUDENT.HIS.local>

My bad, only its hard to find if the concept of 'inline' isn't know to you.
Tested again with:

uuid_transfer c01c9016-6f76-0642-863b-64f8d1bbf1ed -both park inline

aswell, and it work now without having to specify anything more.

-----Ursprungligt meddelande-----
Fr?n: freeswitch-dev-bounces at lists.freeswitch.org genom Brian West
Skickat: to 2009-02-05 08:19
Till: freeswitch-dev at lists.freeswitch.org
?mne: Re: [Freeswitch-dev] Manual Attended Transfer using 3 channels
 

On Feb 5, 2009, at 1:04 AM, David Dikman (a05davdi) wrote:

>
> It works so splendidly!
> Only curious thing is that I need to give a destination on the  
> transfer, ie:
> uuid_transfer <uuid> -both park inline <some extension>
>
>
> Too bad the 'park inline' wasn't mentioned Anywhere in the wiki,  
> think I'll post a page on it.
> Thanks a hundred times over!

http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_InlineDialplan

;)

/b


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090205/a8934886/attachment.html 

From nicholas at montrealconsultoria.com.br  Thu Feb  5 09:30:21 2009
From: nicholas at montrealconsultoria.com.br (Nicholas Amorim)
Date: Thu, 5 Feb 2009 14:30:21 -0300
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <5c7d82f20902050029t3197bfe1n54ec372dde026d44@mail.gmail.com>
References: <5c7d82f20902032208o67bffd45ndbf4260a27d973a0@mail.gmail.com>
	<C5AF2DF3.1427C%mike@jerris.com>
	<5c7d82f20902041907g323f607di35410a32e7b52891@mail.gmail.com>
	<671A9B36-B1A1-4FC6-923F-1894C980512E@jerris.com>
	<5c7d82f20902050029t3197bfe1n54ec372dde026d44@mail.gmail.com>
Message-ID: <8171bb3b0902050930q6b4f792h40fdb112dbe2ffcd@mail.gmail.com>

I've just fixed it, update and try again please.

On Thu, Feb 5, 2009 at 5:29 AM, Fadil Berisha <f.koliqi at gmail.com> wrote:

> Revision 11653 is clean and no any warning error.  deb binary package
> building stops at final stage because  dh_install looks for modules at
> debian/tmp//opt/freeswitch/mod but they are created in diferent directory
> debian/tmp/usr/lib/freeswitch/modules. Here is mesage
>
> dh_install --sourcedir=debian/tmp
> cp: cannot stat `debian/tmp//opt/freeswitch/mod/mod_openzap.so': No such
> file or directory
> dh_install: command returned error code 256
> ----------------------------------------------------------------
>
> In rules, configure should be --with-modinstdir=/opt/freeswitch/mod  is
> that right?
>
> koliqi
>
>
>
>
> On Wed, Feb 4, 2009 at 10:26 PM, Michael Jerris <mike at jerris.com> wrote:
>
>> Missed one, fixed, how about now?
>>
>> Mike
>>
>> On Feb 4, 2009, at 10:07 PM, Fadil Berisha wrote:
>>
>> > this is result from revision 11649, warning error is now in
>> > testcid.c, will assist until getting clean code from warning errors.
>> >
>> > cc1: warnings being treated as errors
>> > src/testcid.c: In function 'main':
>> > src/testcid.c:70: error: format '%lu' expects type 'long unsigned
>> > int', but argument 2 has type 'zap_size_t'
>> >
>> > koliqi
>> >
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090205/02e98f95/attachment-0001.html 

From f.koliqi at gmail.com  Thu Feb  5 16:18:06 2009
From: f.koliqi at gmail.com (Fadil Berisha)
Date: Thu, 5 Feb 2009 19:18:06 -0500
Subject: [Freeswitch-dev] Freeswitch on Debian repository
In-Reply-To: <8171bb3b0902050930q6b4f792h40fdb112dbe2ffcd@mail.gmail.com>
References: <5c7d82f20902032208o67bffd45ndbf4260a27d973a0@mail.gmail.com>
	<C5AF2DF3.1427C%mike@jerris.com>
	<5c7d82f20902041907g323f607di35410a32e7b52891@mail.gmail.com>
	<671A9B36-B1A1-4FC6-923F-1894C980512E@jerris.com>
	<5c7d82f20902050029t3197bfe1n54ec372dde026d44@mail.gmail.com>
	<8171bb3b0902050930q6b4f792h40fdb112dbe2ffcd@mail.gmail.com>
Message-ID: <5c7d82f20902051618p418cd044je7e4b949feb76683@mail.gmail.com>

Now rev. 11661,  building deb binaries  on Ubuntu-8.10 is OK. No problems at
all.

koliqi


On Thu, Feb 5, 2009 at 12:30 PM, Nicholas Amorim <
nicholas at montrealconsultoria.com.br> wrote:

> I've just fixed it, update and try again please.
>
>
> On Thu, Feb 5, 2009 at 5:29 AM, Fadil Berisha <f.koliqi at gmail.com> wrote:
>
>> Revision 11653 is clean and no any warning error.  deb binary package
>> building stops at final stage because  dh_install looks for modules at
>> debian/tmp//opt/freeswitch/mod but they are created in diferent directory
>> debian/tmp/usr/lib/freeswitch/modules. Here is mesage
>>
>> dh_install --sourcedir=debian/tmp
>> cp: cannot stat `debian/tmp//opt/freeswitch/mod/mod_openzap.so': No such
>> file or directory
>> dh_install: command returned error code 256
>> ----------------------------------------------------------------
>>
>> In rules, configure should be --with-modinstdir=/opt/freeswitch/mod  is
>> that right?
>>
>> koliqi
>>
>>
>>
>>
>> On Wed, Feb 4, 2009 at 10:26 PM, Michael Jerris <mike at jerris.com> wrote:
>>
>>> Missed one, fixed, how about now?
>>>
>>> Mike
>>>
>>> On Feb 4, 2009, at 10:07 PM, Fadil Berisha wrote:
>>>
>>> > this is result from revision 11649, warning error is now in
>>> > testcid.c, will assist until getting clean code from warning errors.
>>> >
>>> > cc1: warnings being treated as errors
>>> > src/testcid.c: In function 'main':
>>> > src/testcid.c:70: error: format '%lu' expects type 'long unsigned
>>> > int', but argument 2 has type 'zap_size_t'
>>> >
>>> > koliqi
>>> >
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090205/e8f7876c/attachment.html 

From kristian.kielhofner at gmail.com  Mon Feb  9 00:02:18 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Mon, 9 Feb 2009 03:02:18 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
Message-ID: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>

Hello everyone,

  I started a project using Asterisk + Ecasound to do call quality analysis:

http://www.voip-info.org/wiki/view/Recqual

  I'd like to expand on this concept (that's about all there is).  I
just don't have as much time to spend on this as I'd like.

  It seems to me that Ecasound could be built into FreeSWITCH as a mod:

http://ecasound.seul.org/ecasound/developer.php

  What I'm thinking is FreeSWITCH could dial a remote resource and
give some params to mod_ecasound with the quality/type of audio it is
expecting.  Mod_ecasound could report what it's getting.  For
instance, you could dial any standard milliwatt test line and
mod_ecasound would tell you how mangled the received audio is.
Obviously you could also call your own resources, loop back into other
areas of the dialplan, etc.

  I don't know how well suited ecasound is to doing this kind of
analysis in real time or if it's the best way of going about this but
it does seem like FreeSWITCH is an ideal platform for any future
recqual development.

  Thoughts?

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From brian at freeswitch.org  Mon Feb  9 00:27:16 2009
From: brian at freeswitch.org (Brian West)
Date: Mon, 9 Feb 2009 02:27:16 -0600
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
Message-ID: <6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>

Ecasound is GPL so direct integration is out of the question if it  
requires linking to anything provided by  Ecasound.

/b

On Feb 9, 2009, at 2:02 AM, Kristian Kielhofner wrote:

> Hello everyone,
>
>  I started a project using Asterisk + Ecasound to do call quality  
> analysis:
>
> http://www.voip-info.org/wiki/view/Recqual
>
>  I'd like to expand on this concept (that's about all there is).  I
> just don't have as much time to spend on this as I'd like.
>
>  It seems to me that Ecasound could be built into FreeSWITCH as a mod:
>
> http://ecasound.seul.org/ecasound/developer.php
>
>  What I'm thinking is FreeSWITCH could dial a remote resource and
> give some params to mod_ecasound with the quality/type of audio it is
> expecting.  Mod_ecasound could report what it's getting.  For
> instance, you could dial any standard milliwatt test line and
> mod_ecasound would tell you how mangled the received audio is.
> Obviously you could also call your own resources, loop back into other
> areas of the dialplan, etc.
>
>  I don't know how well suited ecasound is to doing this kind of
> analysis in real time or if it's the best way of going about this but
> it does seem like FreeSWITCH is an ideal platform for any future
> recqual development.



From william.suffill at gmail.com  Mon Feb  9 06:35:33 2009
From: william.suffill at gmail.com (William Suffill)
Date: Mon, 9 Feb 2009 09:35:33 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
Message-ID: <6b65470d0902090635l57ebb9f1i8aa3436cb8e15b1a@mail.gmail.com>

Well placing calls and analyzing the results after the fact would avoid any
licensing issues. As long as you have recordings that could be processed the
concept should still work.


- W

PS: Yes haven't had any coffee yet so might me out of my mind =)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090209/d110a3bb/attachment.html 

From anthony.minessale at gmail.com  Mon Feb  9 07:30:54 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Mon, 9 Feb 2009 09:30:54 -0600
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
Message-ID: <191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>

Maybe they are not as religious as some about why it's GPL, you can always
ask them if they are interested in cooperating and perhaps grant lgpl in our
case.  MPL after all is even less restrictive than GPL, it's only up to the
GPL author if it's compat with us or not.




On Mon, Feb 9, 2009 at 2:27 AM, Brian West <brian at freeswitch.org> wrote:

> Ecasound is GPL so direct integration is out of the question if it
> requires linking to anything provided by  Ecasound.
>
> /b
>
> On Feb 9, 2009, at 2:02 AM, Kristian Kielhofner wrote:
>
> > Hello everyone,
> >
> >  I started a project using Asterisk + Ecasound to do call quality
> > analysis:
> >
> > http://www.voip-info.org/wiki/view/Recqual
> >
> >  I'd like to expand on this concept (that's about all there is).  I
> > just don't have as much time to spend on this as I'd like.
> >
> >  It seems to me that Ecasound could be built into FreeSWITCH as a mod:
> >
> > http://ecasound.seul.org/ecasound/developer.php
> >
> >  What I'm thinking is FreeSWITCH could dial a remote resource and
> > give some params to mod_ecasound with the quality/type of audio it is
> > expecting.  Mod_ecasound could report what it's getting.  For
> > instance, you could dial any standard milliwatt test line and
> > mod_ecasound would tell you how mangled the received audio is.
> > Obviously you could also call your own resources, loop back into other
> > areas of the dialplan, etc.
> >
> >  I don't know how well suited ecasound is to doing this kind of
> > analysis in real time or if it's the best way of going about this but
> > it does seem like FreeSWITCH is an ideal platform for any future
> > recqual development.
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090209/b729eda0/attachment.html 

From kristian.kielhofner at gmail.com  Mon Feb  9 08:19:10 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Mon, 9 Feb 2009 11:19:10 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <6b65470d0902090635l57ebb9f1i8aa3436cb8e15b1a@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<6b65470d0902090635l57ebb9f1i8aa3436cb8e15b1a@mail.gmail.com>
Message-ID: <2d9149cd0902090819nfae6d60xb3497d3940faaf@mail.gmail.com>

William,

  That's what I do now and it's somewhat clunky.

  There is one advantage: you can continually tweak ecasound params to
look for other audio issues and reprocess the files.  Other than that
it seems like a module is the way to go.

On Mon, Feb 9, 2009 at 9:35 AM, William Suffill
<william.suffill at gmail.com> wrote:
> Well placing calls and analyzing the results after the fact would avoid any
> licensing issues. As long as you have recordings that could be processed the
> concept should still work.
>
>
> - W
>
> PS: Yes haven't had any coffee yet so might me out of my mind =)
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>



-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From brian at freeswitch.org  Mon Feb  9 08:22:26 2009
From: brian at freeswitch.org (Brian West)
Date: Mon, 9 Feb 2009 10:22:26 -0600
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
Message-ID: <31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>

This is true... I have in the past asked authors of libs if they would  
do LGPL and in most cases they do so.  ;)

/b

On Feb 9, 2009, at 9:30 AM, Anthony Minessale wrote:

> Maybe they are not as religious as some about why it's GPL, you can  
> always ask them if they are interested in cooperating and perhaps  
> grant lgpl in our case.  MPL after all is even less restrictive than  
> GPL, it's only up to the GPL author if it's compat with us or not.
>



From kristian.kielhofner at gmail.com  Mon Feb  9 08:37:45 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Mon, 9 Feb 2009 11:37:45 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
	<31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
Message-ID: <2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>

I've asked...

On Mon, Feb 9, 2009 at 11:22 AM, Brian West <brian at freeswitch.org> wrote:
> This is true... I have in the past asked authors of libs if they would
> do LGPL and in most cases they do so.  ;)
>
> /b
>
> On Feb 9, 2009, at 9:30 AM, Anthony Minessale wrote:
>
>> Maybe they are not as religious as some about why it's GPL, you can
>> always ask them if they are interested in cooperating and perhaps
>> grant lgpl in our case.  MPL after all is even less restrictive than
>> GPL, it's only up to the GPL author if it's compat with us or not.
>>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>



-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From kristian.kielhofner at gmail.com  Mon Feb  9 10:00:47 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Mon, 9 Feb 2009 13:00:47 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
	<31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
	<2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>
Message-ID: <2d9149cd0902091000l632972c1i857513a018f7536d@mail.gmail.com>

One more thing...

Would it matter if the code for the module lives out of tree?  Or is
it the compiling, linking, loading, etc that's the problem?

On Mon, Feb 9, 2009 at 11:37 AM, Kristian Kielhofner
<kristian.kielhofner at gmail.com> wrote:
> I've asked...
>
> On Mon, Feb 9, 2009 at 11:22 AM, Brian West <brian at freeswitch.org> wrote:
>> This is true... I have in the past asked authors of libs if they would
>> do LGPL and in most cases they do so.  ;)
>>
>> /b
>>
>> On Feb 9, 2009, at 9:30 AM, Anthony Minessale wrote:
>>
>>> Maybe they are not as religious as some about why it's GPL, you can
>>> always ask them if they are interested in cooperating and perhaps
>>> grant lgpl in our case.  MPL after all is even less restrictive than
>>> GPL, it's only up to the GPL author if it's compat with us or not.
>>>
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>
>
>
> --
> Kristian Kielhofner
> http://blog.krisk.org
> http://www.submityoursip.com
> http://www.astlinux.org
> http://www.star2star.com
>



-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From brian at freeswitch.org  Mon Feb  9 10:04:57 2009
From: brian at freeswitch.org (Brian West)
Date: Mon, 9 Feb 2009 12:04:57 -0600
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <2d9149cd0902091000l632972c1i857513a018f7536d@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
	<31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
	<2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>
	<2d9149cd0902091000l632972c1i857513a018f7536d@mail.gmail.com>
Message-ID: <DFE052D2-2C6E-4A39-97F8-5565AE95DBD2@freeswitch.org>

Well the end user is free to combine anything they wish... its the  
distribution that gets you! ;)

/b

On Feb 9, 2009, at 12:00 PM, Kristian Kielhofner wrote:

> One more thing...
>
> Would it matter if the code for the module lives out of tree?  Or is
> it the compiling, linking, loading, etc that's the problem?



From kristian.kielhofner at gmail.com  Mon Feb  9 10:24:15 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Mon, 9 Feb 2009 13:24:15 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <DFE052D2-2C6E-4A39-97F8-5565AE95DBD2@freeswitch.org>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
	<31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
	<2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>
	<2d9149cd0902091000l632972c1i857513a018f7536d@mail.gmail.com>
	<DFE052D2-2C6E-4A39-97F8-5565AE95DBD2@freeswitch.org>
Message-ID: <2d9149cd0902091024k765251bbhf73432a933e555c0@mail.gmail.com>

So, for example:

mod_ecasound could live out of tree and it would be up to the user to
download, compile, and install it?

Is there currently much of a mechanism for building out of tree
modules for FreeSWITCH (like Apache apxs)?

I hate to see good technology be stifled by licensing issues and it
seems to me the MPL vs. GPL issue comes up quite a bit.  Don't get me
wrong; I'd much rather see everything in tree for a variety of
reasons.  However, licensing is licensing.

On Mon, Feb 9, 2009 at 1:04 PM, Brian West <brian at freeswitch.org> wrote:
> Well the end user is free to combine anything they wish... its the
> distribution that gets you! ;)
>
> /b
>
> On Feb 9, 2009, at 12:00 PM, Kristian Kielhofner wrote:
>
>> One more thing...
>>
>> Would it matter if the code for the module lives out of tree?  Or is
>> it the compiling, linking, loading, etc that's the problem?
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>



-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From brian at freeswitch.org  Mon Feb  9 10:28:59 2009
From: brian at freeswitch.org (Brian West)
Date: Mon, 9 Feb 2009 12:28:59 -0600
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <2d9149cd0902091024k765251bbhf73432a933e555c0@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
	<31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
	<2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>
	<2d9149cd0902091000l632972c1i857513a018f7536d@mail.gmail.com>
	<DFE052D2-2C6E-4A39-97F8-5565AE95DBD2@freeswitch.org>
	<2d9149cd0902091024k765251bbhf73432a933e555c0@mail.gmail.com>
Message-ID: <4E5FDD8C-B033-45E8-8940-B7F823EFED53@freeswitch.org>

fsxs exists for such a purpose.

/b

On Feb 9, 2009, at 12:24 PM, Kristian Kielhofner wrote:

> So, for example:
>
> mod_ecasound could live out of tree and it would be up to the user to
> download, compile, and install it?
>
> Is there currently much of a mechanism for building out of tree
> modules for FreeSWITCH (like Apache apxs)?
>
> I hate to see good technology be stifled by licensing issues and it
> seems to me the MPL vs. GPL issue comes up quite a bit.  Don't get me
> wrong; I'd much rather see everything in tree for a variety of
> reasons.  However, licensing is licensing.



From kristian.kielhofner at gmail.com  Mon Feb  9 10:38:29 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Mon, 9 Feb 2009 13:38:29 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <4E5FDD8C-B033-45E8-8940-B7F823EFED53@freeswitch.org>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
	<31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
	<2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>
	<2d9149cd0902091000l632972c1i857513a018f7536d@mail.gmail.com>
	<DFE052D2-2C6E-4A39-97F8-5565AE95DBD2@freeswitch.org>
	<2d9149cd0902091024k765251bbhf73432a933e555c0@mail.gmail.com>
	<4E5FDD8C-B033-45E8-8940-B7F823EFED53@freeswitch.org>
Message-ID: <2d9149cd0902091038k45c70e6em9efebb594b9ece96@mail.gmail.com>

What haven't you guys thought of? ;)

On Mon, Feb 9, 2009 at 1:28 PM, Brian West <brian at freeswitch.org> wrote:
> fsxs exists for such a purpose.
>
> /b
>

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From msc at freeswitch.org  Mon Feb  9 10:49:15 2009
From: msc at freeswitch.org (Michael Collins)
Date: Mon, 9 Feb 2009 10:49:15 -0800
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <2d9149cd0902091038k45c70e6em9efebb594b9ece96@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
	<31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
	<2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>
	<2d9149cd0902091000l632972c1i857513a018f7536d@mail.gmail.com>
	<DFE052D2-2C6E-4A39-97F8-5565AE95DBD2@freeswitch.org>
	<2d9149cd0902091024k765251bbhf73432a933e555c0@mail.gmail.com>
	<4E5FDD8C-B033-45E8-8940-B7F823EFED53@freeswitch.org>
	<2d9149cd0902091038k45c70e6em9efebb594b9ece96@mail.gmail.com>
Message-ID: <87f2f3b90902091049k43180b49kc8ccc22d90d33439@mail.gmail.com>

On Mon, Feb 9, 2009 at 10:38 AM, Kristian Kielhofner
<kristian.kielhofner at gmail.com> wrote:
> What haven't you guys thought of? ;)

Not much, at least from my 3 years of interacting with the FS devs... :)
-MC


From anthony.minessale at gmail.com  Mon Feb  9 11:31:58 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Mon, 9 Feb 2009 13:31:58 -0600
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <87f2f3b90902091049k43180b49kc8ccc22d90d33439@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<191c3a030902090730u48d73e29jb0b9024271946ff6@mail.gmail.com>
	<31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
	<2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>
	<2d9149cd0902091000l632972c1i857513a018f7536d@mail.gmail.com>
	<DFE052D2-2C6E-4A39-97F8-5565AE95DBD2@freeswitch.org>
	<2d9149cd0902091024k765251bbhf73432a933e555c0@mail.gmail.com>
	<4E5FDD8C-B033-45E8-8940-B7F823EFED53@freeswitch.org>
	<2d9149cd0902091038k45c70e6em9efebb594b9ece96@mail.gmail.com>
	<87f2f3b90902091049k43180b49kc8ccc22d90d33439@mail.gmail.com>
Message-ID: <191c3a030902091131p7f3755d1s7eb034c45df843a1@mail.gmail.com>

Also, you can just unpack an out of tree mod into src/mod/mod_foo folder ,
add it to modules.conf and build it.
mod_openzap works that way we check it out separately with the openzap lib
and reference the folder in modules.conf

When you said you asked, was that just today you asked and they did not
answer yet?
or, you have asked in the past and they said no?

You can also defeat gpl/mpl linking issues by doing it over a socket which
is kinda dumb and should be all you need to prove it's not worth bothering
to try and outlaw any 2 open source applications from being linked
regardless of the license.





On Mon, Feb 9, 2009 at 12:49 PM, Michael Collins <msc at freeswitch.org> wrote:

> On Mon, Feb 9, 2009 at 10:38 AM, Kristian Kielhofner
> <kristian.kielhofner at gmail.com> wrote:
> > What haven't you guys thought of? ;)
>
> Not much, at least from my 3 years of interacting with the FS devs... :)
> -MC
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090209/41973e89/attachment.html 

From kristian.kielhofner at gmail.com  Mon Feb  9 12:14:20 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Mon, 9 Feb 2009 15:14:20 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <191c3a030902091131p7f3755d1s7eb034c45df843a1@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<31B6D7F1-B5B4-46F3-A684-84277879AB02@freeswitch.org>
	<2d9149cd0902090837o6197d51fka9e25352bd4302c0@mail.gmail.com>
	<2d9149cd0902091000l632972c1i857513a018f7536d@mail.gmail.com>
	<DFE052D2-2C6E-4A39-97F8-5565AE95DBD2@freeswitch.org>
	<2d9149cd0902091024k765251bbhf73432a933e555c0@mail.gmail.com>
	<4E5FDD8C-B033-45E8-8940-B7F823EFED53@freeswitch.org>
	<2d9149cd0902091038k45c70e6em9efebb594b9ece96@mail.gmail.com>
	<87f2f3b90902091049k43180b49kc8ccc22d90d33439@mail.gmail.com>
	<191c3a030902091131p7f3755d1s7eb034c45df843a1@mail.gmail.com>
Message-ID: <2d9149cd0902091214y5351099au38c404fce5c3bf04@mail.gmail.com>

On Mon, Feb 9, 2009 at 2:31 PM, Anthony Minessale
<anthony.minessale at gmail.com> wrote:
> Also, you can just unpack an out of tree mod into src/mod/mod_foo folder ,
> add it to modules.conf and build it.
> mod_openzap works that way we check it out separately with the openzap lib
> and reference the folder in modules.conf

Ah yes, I've seen that.

> When you said you asked, was that just today you asked and they did not
> answer yet?
> or, you have asked in the past and they said no?

I asked today and I have not heard back yet.

> You can also defeat gpl/mpl linking issues by doing it over a socket which
> is kinda dumb and should be all you need to prove it's not worth bothering
> to try and outlaw any 2 open source applications from being linked
> regardless of the license.

I don't want no sockets! ;)

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From regs at kinetix.gr  Tue Feb 10 08:34:43 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Tue, 10 Feb 2009 18:34:43 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions [first
 patch created]
In-Reply-To: <191c3a030902031432j3cfcc39drcfa35f5d284b5959@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>	<4987F2D2.1030303@kinetix.gr>
	<4988239E.4040201@kinetix.gr>	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>	<49885789.5000905@kinetix.gr>	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>	<4988B36D.2020800@kinetix.gr>	<191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>	<4988B821.2000805@kinetix.gr>
	<191c3a030902031432j3cfcc39drcfa35f5d284b5959@mail.gmail.com>
Message-ID: <4991ACA3.4060803@kinetix.gr>

Hi,

    I have finished coding  the first version of my patch for 
mod_radius_cdr.
The patch allows the module to behave differently than the current
implementation. Instead of blocking the call until the radius packet
is send, my implementation allows the call to continue its execution steps.
The task of sending the radius packet is now relayed to another thread.
The same configuration about timeouts and retries is used. The key 
difference
in my implementation is that the call does not fail nor does it block in 
case
the radius server is down or slow in responding.

    I implemented the whole thing - following Anthony's algorithm and
guidelines - with a queue and some radius processing threads. Both the
queue size and the number of threads is hard coded for now (at least until
I get the consensus for the general idea).

    I noticed while tweaking the module that there might be a memory leak
problem. I monitored the freeswitch process using the simple top linux 
program
and the sipp call generator. When the radius module is activated then FS 
starts
consuming more memory in a linear manner. I used a 10 calls / sec rate with
sipp (zero call length) and the memory  reached 200 MB in just a few 
minutes.
At first I suspected my additions to the module to be the problem, but I 
found
out that the same thing happened using the module in its current svn state
(i.e. without my patch).

    I followed the wiki's guidelines for creating a patch, but I don't 
know how the
whole patch submitting "protocol" works. Should I create an account on 
jira? Should
I post the patch here first until it is in an "acceptable" state? Should 
I send the patch
to a code maintainer and let him decide what to do?

    I am attaching the patch along with the whole file I changed (in 
case someone
wants to just browse the code) until I get some feedback from the 
maintainers
regarding the above questions.

P.S. If someone is eager to work with me in solving the possible memory 
leak
please contact me directly or through the list. I am not a very good c 
coder and
debugging c is somewhat new to me. So, any help would be welcomed.

Anthony Minessale wrote:
> the same one that is already in there now the my_on_routing will now 
> get called for both legs.
>
>
> On Tue, Feb 3, 2009 at 3:33 PM, Apostolos Pantsiopoulos 
> <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>
>     Cheers!
>
>     One clarification though :
>
>     Would that be a state handler? Or an event handler?
>     And what is its name?
>
>
>     Anthony Minessale wrote:
>>     yes,
>>
>>     you will *now* get the event handler on both legs.
>>
>>
>>     On Tue, Feb 3, 2009 at 3:13 PM, Apostolos Pantsiopoulos
>>     <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>>
>>         "you will not get that event handler"
>>
>>         please tell me that this "not" meant to be a "now"
>>
>>
>>         Anthony Minessale wrote:
>>>         I updated the core today in a way that you will not get that
>>>         event handler on both inbound and outbound legs.
>>>
>>>
>>>         On Tue, Feb 3, 2009 at 8:41 AM, Apostolos Pantsiopoulos
>>>         <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>>>
>>>             Even if my intention was not to send the acct start in a
>>>             separate thread
>>>             we are still missing an acct start at the setup of the
>>>             b-leg of a bridge.
>>>             The on_routing handler cannot do that (it is called only
>>>             for the a-leg).
>>>             I tried on_init (which I thought was called at the setup
>>>             of a channel) but
>>>             it didn't invoke my handler even for the a-leg. An event
>>>             on the other hand
>>>             (create_channel) which is triggered correctly does not
>>>             carry all the info
>>>             needed for an acct start packet to be filled (not even
>>>             at a min level). The
>>>             event originate_channel is also called only once during
>>>             a bridge, so it cannot
>>>             be used either.
>>>
>>>             So it is not only a matter of thread vs non threaded (or
>>>             multiple threads vs one thread).
>>>             It is also a matter of when and how many times (2 for a
>>>             simple bridge) to call an
>>>             acct start routine.
>>>
>>>             So we either need to create one more state handler that
>>>             gets called in such a
>>>             manner that can be used for b-legs too. Or an event of
>>>             the same kind that carries all the info
>>>             needed by radius acct start.
>>>             Both ways (adding a state-handler or adding a new event)
>>>             I think require
>>>             changes to the FS core architecture. I must admit,
>>>             however, that my
>>>             understanding of the FS source code is still on a newbie
>>>             level so the above
>>>             conclusions might be wrong.
>>>
>>>
>>>
>>>             Anthony Minessale wrote:
>>>>             or everything is already in the right place the way it
>>>>             already is.....?
>>>>
>>>>             If all you want to do is background the start packet,
>>>>             then just take the info in the place where the existing
>>>>             code gets it (routing state change) and create your own
>>>>             switch_event or private struct, add the data to it and
>>>>             launch a thread to run the radius in it's own thread.
>>>>
>>>>             I still think making the radius not be down or have
>>>>             short timeouts across a list of servers is a better
>>>>             place to fix it than making FS launch a bonus thread
>>>>             per established call to run the radius start packets in
>>>>             the bg.
>>>>
>>>>             I also still think that if you insist on not listing to
>>>>             my previous point, pushing all the packets to a fifo
>>>>             queue is better than launching a new thread per call
>>>>             because if the server is down and timing out why would
>>>>             you want to have 250 threads up at once all blocking on
>>>>             the dead radius instead of a queue of them that could
>>>>             withstand a bit of downtime by stacking up the start
>>>>             packet requests and unloading them in order when it
>>>>             returned.
>>>>
>>>>
>>>>
>>>>             On Tue, Feb 3, 2009 at 4:59 AM, Apostolos Pantsiopoulos
>>>>             <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>>>>
>>>>                 I came to the following conclusions :
>>>>
>>>>                 In the case of the acct start I cannot use the
>>>>                 CHANNEL_ORIGINATE event since
>>>>                 it is fired only once (I want to send one acct
>>>>                 start for each leg)
>>>>
>>>>                 If I use the CHANNEL_CREATE event for the acct
>>>>                 start I am a little sort on info
>>>>                 since the event does not contain much. So I need to
>>>>                 get the info from the session.
>>>>
>>>>                 On the acct stop it is better to use the info from
>>>>                 the event (lots of info - easy to duplicate).
>>>>
>>>>                 I was hoping to implement a uniform way to get data
>>>>                 for both start and stop but it seems
>>>>                 that this is not the case.
>>>>
>>>>
>>>>
>>>>                 Apostolos Pantsiopoulos wrote:
>>>>>                 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, regs at kinetix.gr
>>>>>>                 <mailto:regs at kinetix.gr> <regs at kinetix.gr
>>>>>>                 <mailto:regs at 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,
>>>>>>>                     regs at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>>>                     <regs at kinetix.gr <mailto:regs at 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
>>>>>>>>                         <regs at kinetix.gr
>>>>>>>>                         <mailto:regs at 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
>>>>>>>>>                             <regs at kinetix.gr
>>>>>>>>>                             <mailto:regs at 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 at kinetix.gr
>>>>>>>>>>                                 <mailto:regs at 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 at kinetix.gr
>>>>>>>>>>                                     <mailto:regs at kinetix.gr>
>>>>>>>>>>                                     -------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                                     _______________________________________________
>>>>>>>>>>                                     Freeswitch-dev mailing list
>>>>>>>>>>                                     Freeswitch-dev at lists.freeswitch.org
>>>>>>>>>>                                     <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>>>>                                 <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>>>>                                 GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>>>>                                 <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>>>>                                 IRC: irc.freenode.net
>>>>>>>>>>                                 <http://irc.freenode.net>
>>>>>>>>>>                                 #freeswitch
>>>>>>>>>>
>>>>>>>>>>                                 FreeSWITCH Developer Conference
>>>>>>>>>>                                 sip:888 at conference.freeswitch.org
>>>>>>>>>>                                 <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>>>>                                 iax:guest at conference.freeswitch.org/888
>>>>>>>>>>                                 <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>>>>                                 googletalk:conf+888 at conference.freeswitch.org
>>>>>>>>>>                                 <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>>>>                                 pstn:213-799-1400
>>>>>>>>>>                                 ------------------------------------------------------------------------
>>>>>>>>>>                                 _______________________________________________
>>>>>>>>>>                                 Freeswitch-dev mailing list
>>>>>>>>>>                                 Freeswitch-dev at lists.freeswitch.org
>>>>>>>>>>                                 <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>>>>>                                 ------------------------------------------- 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                 _______________________________________________
>>>>>>>>>                                 Freeswitch-dev mailing list
>>>>>>>>>                                 Freeswitch-dev at lists.freeswitch.org
>>>>>>>>>                                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>>>                             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>>>                             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>>>                             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>>>                             IRC: irc.freenode.net
>>>>>>>>>                             <http://irc.freenode.net> #freeswitch
>>>>>>>>>
>>>>>>>>>                             FreeSWITCH Developer Conference
>>>>>>>>>                             sip:888 at conference.freeswitch.org
>>>>>>>>>                             <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>>>                             iax:guest at conference.freeswitch.org/888
>>>>>>>>>                             <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>>>                             googletalk:conf+888 at conference.freeswitch.org
>>>>>>>>>                             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>>>                             pstn:213-799-1400
>>>>>>>>>                             ------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>                             _______________________________________________
>>>>>>>>>                             Freeswitch-dev mailing list
>>>>>>>>>                             Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>>>>                             ------------------------------------------- 
>>>>>>>>
>>>>>>>>
>>>>>>>>                             _______________________________________________
>>>>>>>>                             Freeswitch-dev mailing list
>>>>>>>>                             Freeswitch-dev at lists.freeswitch.org
>>>>>>>>                             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>>                         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>>                         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>>                         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>>                         IRC: irc.freenode.net
>>>>>>>>                         <http://irc.freenode.net> #freeswitch
>>>>>>>>
>>>>>>>>                         FreeSWITCH Developer Conference
>>>>>>>>                         sip:888 at conference.freeswitch.org
>>>>>>>>                         <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>>                         iax:guest at conference.freeswitch.org/888
>>>>>>>>                         <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>>                         googletalk:conf+888 at conference.freeswitch.org
>>>>>>>>                         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>>                         pstn:213-799-1400
>>>>>>>>                         ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>                         _______________________________________________
>>>>>>>>                         Freeswitch-dev mailing list
>>>>>>>>                         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>>>>>>                         <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>>                     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>>                     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>>                     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>>                     IRC: irc.freenode.net
>>>>>>>                     <http://irc.freenode.net> #freeswitch
>>>>>>>
>>>>>>>                     FreeSWITCH Developer Conference
>>>>>>>                     sip:888 at conference.freeswitch.org
>>>>>>>                     <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>>                     iax:guest at conference.freeswitch.org/888
>>>>>>>                     <http://iax:guest at conference.freeswitch.org/888>
>>>>>>>                     googletalk:conf+888 at conference.freeswitch.org
>>>>>>>                     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>>                     pstn:213-799-1400
>>>>>>>                     ------------------------------------------------------------------------
>>>>>>>                     _______________________________________________
>>>>>>>                     Freeswitch-dev mailing list
>>>>>>>                     Freeswitch-dev at lists.freeswitch.org
>>>>>>>                     <mailto:Freeswitch-dev at 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 at lists.freeswitch.org
>>>>>>                     <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>>>                 <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>>>                 GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>>>                 <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>>>                 IRC: irc.freenode.net <http://irc.freenode.net>
>>>>>>                 #freeswitch
>>>>>>
>>>>>>                 FreeSWITCH Developer Conference
>>>>>>                 sip:888 at conference.freeswitch.org
>>>>>>                 <mailto:sip%3A888 at conference.freeswitch.org>
>>>>>>                 iax:guest at conference.freeswitch.org/888
>>>>>>                 <http://iax:guest at conference.freeswitch.org/888>
>>>>>>                 googletalk:conf+888 at conference.freeswitch.org
>>>>>>                 <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>>>                 pstn:213-799-1400
>>>>>>                 ------------------------------------------------------------------------
>>>>>>
>>>>>>                 _______________________________________________
>>>>>>                 Freeswitch-dev mailing list
>>>>>>                 Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>>                 ------------------------------------------- 
>>>>>                 ------------------------------------------------------------------------
>>>>>
>>>>>                 _______________________________________________
>>>>>                 Freeswitch-dev mailing list
>>>>>                 Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>>                 ------------------------------------------- 
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 Freeswitch-dev mailing list
>>>>                 Freeswitch-dev at lists.freeswitch.org
>>>>                 <mailto:Freeswitch-dev at 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 at hotmail.com
>>>>             <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>>             GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>>             <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>>             IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>>
>>>>             FreeSWITCH Developer Conference
>>>>             sip:888 at conference.freeswitch.org
>>>>             <mailto:sip%3A888 at conference.freeswitch.org>
>>>>             iax:guest at conference.freeswitch.org/888
>>>>             <http://iax:guest at conference.freeswitch.org/888>
>>>>             googletalk:conf+888 at conference.freeswitch.org
>>>>             <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>>             pstn:213-799-1400
>>>>             ------------------------------------------------------------------------
>>>>
>>>>             _______________________________________________
>>>>             Freeswitch-dev mailing list
>>>>             Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>>             ------------------------------------------- 
>>>
>>>
>>>             _______________________________________________
>>>             Freeswitch-dev mailing list
>>>             Freeswitch-dev at lists.freeswitch.org
>>>             <mailto:Freeswitch-dev at 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 at hotmail.com
>>>         <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>>         GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>>         <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>>         IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>>         FreeSWITCH Developer Conference
>>>         sip:888 at conference.freeswitch.org
>>>         <mailto:sip%3A888 at conference.freeswitch.org>
>>>         iax:guest at conference.freeswitch.org/888
>>>         <http://iax:guest at conference.freeswitch.org/888>
>>>         googletalk:conf+888 at conference.freeswitch.org
>>>         <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>>         pstn:213-799-1400
>>>         ------------------------------------------------------------------------
>>>
>>>         _______________________________________________
>>>         Freeswitch-dev mailing list
>>>         Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>>         ------------------------------------------- 
>>
>>
>>         _______________________________________________
>>         Freeswitch-dev mailing list
>>         Freeswitch-dev at lists.freeswitch.org
>>         <mailto:Freeswitch-dev at 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 at hotmail.com
>>     <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>     GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>     <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>     IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>>     FreeSWITCH Developer Conference
>>     sip:888 at conference.freeswitch.org
>>     <mailto:sip%3A888 at conference.freeswitch.org>
>>     iax:guest at conference.freeswitch.org/888
>>     <http://iax:guest at conference.freeswitch.org/888>
>>     googletalk:conf+888 at conference.freeswitch.org
>>     <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>     pstn:213-799-1400
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     Freeswitch-dev mailing list
>>     Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at 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 at kinetix.gr <mailto:regs at kinetix.gr>
>     ------------------------------------------- 
>
>
>     _______________________________________________
>     Freeswitch-dev mailing list
>     Freeswitch-dev at lists.freeswitch.org
>     <mailto:Freeswitch-dev at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090210/59bd0ddd/attachment-0001.html 
-------------- next part --------------
/* 
 * FreeSWITCH Modular Media Switching Software Library / Soft-Switch Application
 * Copyright (C) 2005/2006, Anthony Minessale II <anthmct at yahoo.com>
 *
 * Version: MPL 1.1
 *
 * The contents of this file are subject to the Mozilla Public License Version
 * 1.1 (the "License"); you may not use this file except in compliance with
 * the License. You may obtain a copy of the License at
 * http://www.mozilla.org/MPL/
 *
 * Software distributed under the License is distributed on an "AS IS" basis,
 * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
 * for the specific language governing rights and limitations under the
 * License.
 *
 * The Original Code is FreeSWITCH Modular Media Switching Software Library / Soft-Switch Application
 *
 * The Initial Developer of the Original Code is
 * Anthony Minessale II <anthmct at yahoo.com>
 * Portions created by the Initial Developer are Copyright (C)
 * the Initial Developer. All Rights Reserved.
 *
 * Contributor(s):
 * 
 * Chris Parker <cparker at segv.org>
 *
 *
 * mod_radius_cdr.c -- RADIUS CDR Module
 *
 */

#include <switch.h>
#include <sys/stat.h>
#include <freeradius-client.h>
#include "mod_radius_cdr.h"

SWITCH_MODULE_LOAD_FUNCTION(mod_radius_cdr_load);
SWITCH_MODULE_SHUTDOWN_FUNCTION(mod_radius_cdr_shutdown);
SWITCH_MODULE_DEFINITION(mod_radius_cdr, mod_radius_cdr_load, mod_radius_cdr_shutdown, NULL);

switch_memory_pool_t *module_pool = NULL;
switch_queue_t *rad_queue = NULL;

static struct {
	int shutdown;
	switch_thread_rwlock_t *rwlock;
} globals = { 0 };

static char cf[] = "mod_radius_cdr.conf";
static char my_dictionary[PATH_MAX];
static char my_seqfile[PATH_MAX];
static char *my_deadtime;		/* 0 */
static char *my_timeout;		/* 5 */
static char *my_retries;		/* 3 */
static char my_servers[SERVER_MAX][255];

struct acct_packet {

	rc_handle *rad_config;
	VALUE_PAIR *data;

};

static void *SWITCH_THREAD_FUNC process_packets(switch_thread_t *thread, void *ptr){

	void *pop = NULL;

	while(1){

		if(switch_queue_pop(rad_queue,&pop) != SWITCH_STATUS_SUCCESS || !pop){

			switch_yield(1000);
			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] nothing to do thread is sleeping\n");		

		} else {

		        struct acct_packet *tmp = (struct acct_packet *) pop;

		        if (rc_acct(tmp->rad_config, 0, tmp->data) == OK_RC) {
		                switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] RADIUS Accounting Packet OK\n");
	        	} else {
        	        	switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] RADIUS Accounting Packet FAILED\n");
	        	}


			switch_safe_free(tmp->data);
			switch_safe_free(tmp->rad_config);
			switch_safe_free(tmp);

		}

	}

	return 0;

}

static rc_handle *my_radius_init(void)
{
	int i = 0;
	rc_handle *rad_config;

	rad_config = rc_new();

	if (rad_config == NULL) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] Error initializing rc_handle!\n");
		return NULL;
	}

	rad_config = rc_config_init(rad_config);

	if (rad_config == NULL) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "error initializing radius config!\n");
		rc_destroy(rad_config);
		return NULL;
	}

	/* Some hardcoded ( for now ) defaults needed to initialize radius */
	if (rc_add_config(rad_config, "auth_order", "radius", "mod_radius_cdr.c", 0) != 0) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "setting auth_order = radius failed\n");
		rc_destroy(rad_config);
		return NULL;
	}

	if (rc_add_config(rad_config, "seqfile", my_seqfile, "mod_radius_cdr.c", 0) != 0) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "setting seqfile = %s failed\n", my_seqfile);
		rc_destroy(rad_config);
		return NULL;
	}


	/* Add the module configs to initialize rad_config */

	for (i = 0; i < SERVER_MAX && my_servers[i][0] != '\0'; i++) {
		if (rc_add_config(rad_config, "acctserver", my_servers[i], cf, 0) != 0) {
			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "setting acctserver = %s failed\n", my_servers[i]);
			rc_destroy(rad_config);
			return NULL;
		}
	}

	if (rc_add_config(rad_config, "dictionary", my_dictionary, cf, 0) != 0) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed setting dictionary = %s failed\n", my_dictionary);
		rc_destroy(rad_config);
		return NULL;
	}

	if (rc_add_config(rad_config, "radius_deadtime", my_deadtime, cf, 0) != 0) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "setting radius_deadtime = %s failed\n", my_deadtime);
		rc_destroy(rad_config);
		return NULL;
	}

	if (rc_add_config(rad_config, "radius_timeout", my_timeout, cf, 0) != 0) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "setting radius_timeout = %s failed\n", my_timeout);
		rc_destroy(rad_config);
		return NULL;
	}

	if (rc_add_config(rad_config, "radius_retries", my_retries, cf, 0) != 0) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "setting radius_retries = %s failed\n", my_retries);
		rc_destroy(rad_config);
		return NULL;
	}

	/* Read the dictionary file(s) */
	if (rc_read_dictionary(rad_config, rc_conf_str(rad_config, "dictionary")) != 0) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "reading dictionary file(s): %s\n", my_dictionary);
		rc_destroy(rad_config);
		return NULL;
	}

	return rad_config;
}

static switch_status_t my_on_routing(switch_core_session_t *session)
{
	switch_xml_t cdr;
	switch_channel_t *channel = switch_core_session_get_channel(session);
	rc_handle *rad_config;
	VALUE_PAIR *send = NULL;
	//uint32_t client_port = 0;
	uint32_t status_type = PW_STATUS_START;
	switch_time_t callstartdate = 0;
	switch_time_t callanswerdate = 0;
	switch_time_t callenddate = 0;
	switch_time_t calltransferdate = 0;

	char *uuid_str;

	switch_time_exp_t tm;
	char buffer[32];

	switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] Entering my_on_routing\n");

	if (globals.shutdown) {
		return SWITCH_STATUS_SUCCESS;
	}

	if(channel) {
		const char *disable_flag = switch_channel_get_variable(channel, "disable_radius_start");
		if(switch_true(disable_flag)) {
			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] Not Sending RADIUS Start\n");
			return SWITCH_STATUS_SUCCESS;
		}
	}

	switch_thread_rwlock_rdlock(globals.rwlock);

	rad_config = my_radius_init();

	if (rad_config == NULL) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] Error initializing radius, Start packet not logged.\n");
		goto end;
	}

	if (switch_ivr_generate_xml_cdr(session, &cdr) == SWITCH_STATUS_SUCCESS) {
		uuid_str = switch_core_session_get_uuid(session);
	} else {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] Error Generating Data!\n");
		goto end;
	}

	/* Create the radius packet */

	/* Set Status Type */
	if (rc_avpair_add(rad_config, &send, PW_ACCT_STATUS_TYPE, &status_type, -1, 0) == NULL) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] Failed setting Acct-Status-Type: Start\n");
		rc_destroy(rad_config);
		goto end;
	}

	if (rc_avpair_add(rad_config, &send, PW_ACCT_SESSION_ID, uuid_str, -1, 0) == NULL) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] Failed adding Acct-Session-ID: %s\n", uuid_str);
		rc_destroy(rad_config);
		goto end;
	}

	/* Add VSAs */

	if (channel) {
		/*switch_call_cause_t   cause; */
		switch_caller_profile_t *profile;

		/*
		   cause = switch_channel_get_cause(channel);
		   if (rc_avpair_add(rad_config, &send, PW_FS_HANGUPCAUSE, &cause, -1, PW_FS_PEC) == NULL) {
		   switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Hangupcause: %d\n", cause);
		   rc_destroy(rad_config);
		   return SWITCH_STATUS_TERM;
		   }
		 */

		profile = switch_channel_get_caller_profile(channel);

		if (profile) {

			callstartdate = profile->times->created;
			callanswerdate = profile->times->answered;
			calltransferdate = profile->times->transferred;
			callenddate = profile->times->hungup;

			if (profile->username) {
				if (rc_avpair_add(rad_config, &send, PW_USER_NAME, (void *) profile->username, -1, 0) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding User-Name: %s\n", profile->username);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->caller_id_number) {
				if (rc_avpair_add(rad_config, &send, PW_FS_SRC, (void *) profile->caller_id_number, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Src: %s\n", profile->caller_id_number);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->caller_id_name) {
				if (rc_avpair_add(rad_config, &send, PW_FS_CLID, (void *) profile->caller_id_name, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-CLID: %s\n", profile->caller_id_name);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->destination_number) {
				if (rc_avpair_add(rad_config, &send, PW_FS_DST, (void *) profile->destination_number, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Dst: %s\n", profile->destination_number);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->dialplan) {
				if (rc_avpair_add(rad_config, &send, PW_FS_DIALPLAN, (void *) profile->dialplan, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Dialplan: %s\n", profile->dialplan);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->network_addr) {
				if (rc_avpair_add(rad_config, &send, PW_FRAMED_IP_ADDRESS, (void *) profile->network_addr, -1, 0) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Framed-IP-Address: %s\n", profile->network_addr);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->rdnis) {
				if (rc_avpair_add(rad_config, &send, PW_FS_RDNIS, (void *) profile->rdnis, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-RDNIS: %s\n", profile->rdnis);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->context) {
				if (rc_avpair_add(rad_config, &send, PW_FS_CONTEXT, (void *) profile->context, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Context: %s\n", profile->context);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->ani) {
				if (rc_avpair_add(rad_config, &send, PW_FS_ANI, (void *) profile->ani, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-ANI: %s\n", profile->ani);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->aniii) {
				if (rc_avpair_add(rad_config, &send, PW_FS_ANIII, (void *) profile->aniii, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-ANIII: %s\n", profile->aniii);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->source) {
				if (rc_avpair_add(rad_config, &send, PW_FS_SOURCE, (void *) profile->source, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Source: %s\n", profile->source);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (callstartdate > 0) {
				switch_time_exp_lt(&tm, callstartdate);
				switch_snprintf(buffer, sizeof(buffer), "%04u-%02u-%02uT%02u:%02u:%02u.%06u%+03d%02d",
								tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
								tm.tm_hour, tm.tm_min, tm.tm_sec, tm.tm_usec, tm.tm_gmtoff / 3600, tm.tm_gmtoff % 3600);
				if (rc_avpair_add(rad_config, &send, PW_FS_CALLSTARTDATE, &buffer, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Callstartdate: %s\n", buffer);
					rc_destroy(rad_config);
					goto end;
				}
			}

			if (callanswerdate > 0) {
				switch_time_exp_lt(&tm, callanswerdate);
				switch_snprintf(buffer, sizeof(buffer), "%04u-%02u-%02uT%02u:%02u:%02u.%06u%+03d%02d",
								tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
								tm.tm_hour, tm.tm_min, tm.tm_sec, tm.tm_usec, tm.tm_gmtoff / 3600, tm.tm_gmtoff % 3600);
				if (rc_avpair_add(rad_config, &send, PW_FS_CALLANSWERDATE, &buffer, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Callanswerdate: %s\n", buffer);
					rc_destroy(rad_config);
					goto end;
				}
			}

			if (calltransferdate > 0) {
				switch_time_exp_lt(&tm, calltransferdate);
				switch_snprintf(buffer, sizeof(buffer), "%04u-%02u-%02uT%02u:%02u:%02u.%06u%+03d%02d",
								tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
								tm.tm_hour, tm.tm_min, tm.tm_sec, tm.tm_usec, tm.tm_gmtoff / 3600, tm.tm_gmtoff % 3600);
				if (rc_avpair_add(rad_config, &send, PW_FS_CALLTRANSFERDATE, &buffer, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Calltransferdate: %s\n", buffer);
					rc_destroy(rad_config);
					goto end;
				}
			}

			if (callenddate > 0) {
				switch_time_exp_lt(&tm, callenddate);
				switch_snprintf(buffer, sizeof(buffer), "%04u-%02u-%02uT%02u:%02u:%02u.%06u%+03d%02d",
								tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
								tm.tm_hour, tm.tm_min, tm.tm_sec, tm.tm_usec, tm.tm_gmtoff / 3600, tm.tm_gmtoff % 3600);
				if (rc_avpair_add(rad_config, &send, PW_FS_CALLENDDATE, &buffer, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Callenddate: %s\n", buffer);
					rc_destroy(rad_config);
					goto end;
				}
			}

			if (profile->caller_extension && 
				profile->caller_extension->last_application && 
				profile->caller_extension->last_application->application_name) {
				if (rc_avpair_add(rad_config, &send, PW_FS_LASTAPP,
								  (void *) profile->caller_extension->last_application->application_name, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Lastapp: %s\n", profile->source);
					rc_destroy(rad_config);
					goto end;
				}
			}
		} else {
			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "profile == NULL\n");
		}
	}

	struct acct_packet *acct_start = NULL;

	acct_start = malloc(sizeof(&acct_start));
	
	memset(acct_start, 0, sizeof(&acct_start));

	acct_start->rad_config = rad_config;
	acct_start->data = send;

	switch_queue_push(rad_queue,acct_start);

 end:
	switch_thread_rwlock_unlock(globals.rwlock);
	return (SWITCH_STATUS_SUCCESS);
}

static switch_status_t my_on_hangup(switch_core_session_t *session)
{
	switch_xml_t cdr;
	switch_channel_t *channel = switch_core_session_get_channel(session);
	rc_handle *rad_config;
	VALUE_PAIR *send = NULL;
	uint32_t status_type = PW_STATUS_STOP;
	switch_time_t callstartdate = 0;
	switch_time_t callanswerdate = 0;
	switch_time_t callenddate = 0;
	switch_time_t calltransferdate = 0;
	switch_time_t billusec = 0;
	uint32_t billsec = 0;
	char *uuid_str;

	switch_time_exp_t tm;
	char buffer[32] = "";

	if (globals.shutdown) {
		return SWITCH_STATUS_FALSE;
	}


	if(channel) {
		const char *disable_flag = switch_channel_get_variable(channel, "disable_radius_stop");
		if(switch_true(disable_flag)) {
			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] Not Sending RADIUS Stop\n");
			return SWITCH_STATUS_SUCCESS;
		}
	}

	switch_thread_rwlock_rdlock(globals.rwlock);

	switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] Entering my_on_hangup\n");

	rad_config = my_radius_init();

	if (rad_config == NULL) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] Error initializing radius, session not logged.\n");
		goto end;
	}

	if (switch_ivr_generate_xml_cdr(session, &cdr) == SWITCH_STATUS_SUCCESS) {
		uuid_str = switch_core_session_get_uuid(session);
	} else {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] Error Generating Data!\n");
		goto end;
	}

	/* Create the radius packet */

	/* Set Status Type */
	if (rc_avpair_add(rad_config, &send, PW_ACCT_STATUS_TYPE, &status_type, -1, 0) == NULL) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Acct-Session-ID: %s\n", uuid_str);
		rc_destroy(rad_config);
		goto end;
	}

	if (rc_avpair_add(rad_config, &send, PW_ACCT_SESSION_ID, uuid_str, -1, 0) == NULL) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Acct-Session-ID: %s\n", uuid_str);
		rc_destroy(rad_config);
		goto end;
	}

	/* Add VSAs */

	if (channel) {
		switch_call_cause_t cause;
		switch_caller_profile_t *profile;

		cause = switch_channel_get_cause(channel);
		if (rc_avpair_add(rad_config, &send, PW_FS_HANGUPCAUSE, &cause, -1, PW_FS_PEC) == NULL) {
			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Hangupcause: %d\n", cause);
			rc_destroy(rad_config);
			goto end;
		}

		profile = switch_channel_get_caller_profile(channel);

		if (profile) {

			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] Calculating billable time\n");

			/* calculate billable time */
			callstartdate = profile->times->created;
			callanswerdate = profile->times->answered;
			calltransferdate = profile->times->transferred;
			callenddate = profile->times->hungup;

			if (switch_channel_test_flag(channel, CF_ANSWERED)) {
				if (callstartdate && callanswerdate) {
					if (callenddate)
						billusec = callenddate - callanswerdate;
					else if (calltransferdate)
						billusec = calltransferdate - callanswerdate;
				}
			} else if (switch_channel_test_flag(channel, CF_TRANSFER)) {
				if (callanswerdate && calltransferdate)
					billusec = calltransferdate - callanswerdate;
			}
			billsec = (billusec / 1000000);

			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] Finished calculating billable time\n");

			if (profile->username) {
				if (rc_avpair_add(rad_config, &send, PW_USER_NAME, (void *) profile->username, -1, 0) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding User-Name: %s\n", profile->username);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->caller_id_number) {
				if (rc_avpair_add(rad_config, &send, PW_FS_SRC, (void *) profile->caller_id_number, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Src: %s\n", profile->caller_id_number);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->caller_id_name) {
				if (rc_avpair_add(rad_config, &send, PW_FS_CLID, (void *) profile->caller_id_name, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-CLID: %s\n", profile->caller_id_name);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->destination_number) {
				if (rc_avpair_add(rad_config, &send, PW_FS_DST, (void *) profile->destination_number, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Dst: %s\n", profile->destination_number);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->dialplan) {
				if (rc_avpair_add(rad_config, &send, PW_FS_DIALPLAN, (void *) profile->dialplan, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Dialplan: %s\n", profile->dialplan);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->network_addr) {
				if (rc_avpair_add(rad_config, &send, PW_FRAMED_IP_ADDRESS, (void *) profile->network_addr, -1, 0) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Framed-IP-Address: %s\n", profile->network_addr);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->rdnis) {
				if (rc_avpair_add(rad_config, &send, PW_FS_RDNIS, (void *) profile->rdnis, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-RDNIS: %s\n", profile->rdnis);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->context) {
				if (rc_avpair_add(rad_config, &send, PW_FS_CONTEXT, (void *) profile->context, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Context: %s\n", profile->context);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->ani) {
				if (rc_avpair_add(rad_config, &send, PW_FS_ANI, (void *) profile->ani, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-ANI: %s\n", profile->ani);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->aniii) {
				if (rc_avpair_add(rad_config, &send, PW_FS_ANIII, (void *) profile->aniii, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-ANIII: %s\n", profile->aniii);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->source) {
				if (rc_avpair_add(rad_config, &send, PW_FS_SOURCE, (void *) profile->source, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Source: %s\n", profile->source);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (profile->caller_extension && profile->caller_extension->last_application && 
			    profile->caller_extension->last_application->application_name) {
				if (rc_avpair_add(rad_config, &send, PW_FS_LASTAPP,
								  (void *) profile->caller_extension->last_application->application_name, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Lastapp: %s\n", profile->source);
					rc_destroy(rad_config);
					goto end;
				}
			}
			if (rc_avpair_add(rad_config, &send, PW_FS_BILLUSEC, &billusec, -1, PW_FS_PEC) == NULL) {
				switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Billusec: %u\n", (uint32_t) billusec);
				rc_destroy(rad_config);
				goto end;
			}

			if (callstartdate > 0) {
				switch_time_exp_lt(&tm, callstartdate);
				switch_snprintf(buffer, sizeof(buffer), "%04u-%02u-%02uT%02u:%02u:%02u.%06u%+03d%02d",
								tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
								tm.tm_hour, tm.tm_min, tm.tm_sec, tm.tm_usec, tm.tm_gmtoff / 3600, tm.tm_gmtoff % 3600);
				if (rc_avpair_add(rad_config, &send, PW_FS_CALLSTARTDATE, &buffer, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Callstartdate: %s\n", buffer);
					rc_destroy(rad_config);
					goto end;
				}
			}

			if (callanswerdate > 0) {
				switch_time_exp_lt(&tm, callanswerdate);
				switch_snprintf(buffer, sizeof(buffer), "%04u-%02u-%02uT%02u:%02u:%02u.%06u%+03d%02d",
								tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
								tm.tm_hour, tm.tm_min, tm.tm_sec, tm.tm_usec, tm.tm_gmtoff / 3600, tm.tm_gmtoff % 3600);
				if (rc_avpair_add(rad_config, &send, PW_FS_CALLANSWERDATE, &buffer, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Callanswerdate: %s\n", buffer);
					rc_destroy(rad_config);
					goto end;
				}
			}

			if (calltransferdate > 0) {
				switch_time_exp_lt(&tm, calltransferdate);
				switch_snprintf(buffer, sizeof(buffer), "%04u-%02u-%02uT%02u:%02u:%02u.%06u%+03d%02d",
								tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
								tm.tm_hour, tm.tm_min, tm.tm_sec, tm.tm_usec, tm.tm_gmtoff / 3600, tm.tm_gmtoff % 3600);
				if (rc_avpair_add(rad_config, &send, PW_FS_CALLTRANSFERDATE, &buffer, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Calltransferdate: %s\n", buffer);
					rc_destroy(rad_config);
					goto end;
				}
			}

			if (callenddate > 0) {
				switch_time_exp_lt(&tm, callenddate);
				switch_snprintf(buffer, sizeof(buffer), "%04u-%02u-%02uT%02u:%02u:%02u.%06u%+03d%02d",
								tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
								tm.tm_hour, tm.tm_min, tm.tm_sec, tm.tm_usec, tm.tm_gmtoff / 3600, tm.tm_gmtoff % 3600);
				if (rc_avpair_add(rad_config, &send, PW_FS_CALLENDDATE, &buffer, -1, PW_FS_PEC) == NULL) {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Freeswitch-Callenddate: %s\n", buffer);
					rc_destroy(rad_config);
					goto end;
				}
			}

			if (rc_avpair_add(rad_config, &send, PW_ACCT_SESSION_TIME, &billsec, -1, 0) == NULL) {
				switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "failed adding Acct-Session-Time: %u\n", billsec);
				rc_destroy(rad_config);
				goto end;
			}
		} else {				/* no profile, can't create data to send */
			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "profile == NULL\n");
		}
	}

	struct acct_packet *acct_stop = NULL;

	acct_stop = malloc(sizeof(&acct_stop));

        memset(acct_stop, 0, sizeof(&acct_stop));

        acct_stop->rad_config = rad_config;
        acct_stop->data = send;

        switch_queue_push(rad_queue,acct_stop);

 end:
	switch_thread_rwlock_unlock(globals.rwlock);
	return (SWITCH_STATUS_SUCCESS);
}

static switch_status_t load_config(void)
{
	switch_xml_t cfg, xml, settings, param;

	int num_servers = 0;
	int i = 0;

	my_timeout = "5";
	my_retries = "3";
	my_deadtime = "0";
	strncpy(my_seqfile, "/var/run/radius.seq", PATH_MAX - 1);
	strncpy(my_dictionary, "/usr/local/freeswitch/conf/radius/dictionary", PATH_MAX - 1);

	for (i = 0; i < SERVER_MAX; i++) {
		my_servers[i][0] = '\0';
	}

	if (!(xml = switch_xml_open_cfg(cf, &cfg, NULL))) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "Open of %s failed\n", cf);
		return SWITCH_STATUS_TERM;
	}

	if ((settings = switch_xml_child(cfg, "settings"))) {
		for (param = switch_xml_child(settings, "param"); param; param = param->next) {
			char *var = (char *) switch_xml_attr_soft(param, "name");
			char *val = (char *) switch_xml_attr_soft(param, "value");

			if (!strcmp(var, "acctserver")) {
				if (num_servers < SERVER_MAX) {
					strncpy(my_servers[num_servers], val, 255 - 1);
					num_servers++;
				} else {
					switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR,
									  "you can only specify %d radius servers, ignoring excess server entry\n", SERVER_MAX);
				}
			} else if (!strcmp(var, "dictionary")) {
				strncpy(my_dictionary, val, PATH_MAX - 1);
			} else if (!strcmp(var, "seqfile")) {
				strncpy(my_seqfile, val, PATH_MAX - 1);
			} else if (!strcmp(var, "radius_timeout")) {
				my_timeout = strdup(val);
			} else if (!strcmp(var, "radius_retries")) {
				my_retries = strdup(val);
			} else if (!strcmp(var, "radius_deadtime")) {
				my_deadtime = strdup(val);
			}
		}
	}

	switch_xml_free(xml);

	if (num_servers < 1) {
		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "you must specify at least 1 radius server\n");
		return SWITCH_STATUS_TERM;
	}

	/* If we made it this far, we succeeded */
	return SWITCH_STATUS_SUCCESS;
}

static const switch_state_handler_table_t state_handlers = {
	/*.on_init */ NULL,
	/*.on_routing */ my_on_routing,
	/*.on_execute */ NULL,
	/*.on_hangup */ my_on_hangup,
	/*.on_exchange_media */ NULL,
	/*.on_soft_execute */ NULL
};

SWITCH_MODULE_LOAD_FUNCTION(mod_radius_cdr_load)
{

	switch_thread_rwlock_create(&globals.rwlock, pool);

	if (load_config() != SWITCH_STATUS_SUCCESS) {
		return SWITCH_STATUS_TERM;
	}

	if (switch_core_new_memory_pool(&module_pool) != SWITCH_STATUS_SUCCESS) {
                switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "Could not create pool for module\n");
                return SWITCH_STATUS_TERM;
        }

	// the queue limit could be configurable but we leave it hardcoded for now

        switch_queue_create(&rad_queue, 10000, module_pool);

	/* test global state handlers */
        switch_core_add_state_handler(&state_handlers);

	// the queue processing threads number could be configurable but we leave it hardcoded for now

	switch_thread_t *thread[10];
	switch_threadattr_t *thd_attr = NULL;

        switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "Initializing radius threads\n");

        switch_threadattr_create(&thd_attr, pool);
        switch_threadattr_detach_set(thd_attr, 1);
	switch_threadattr_stacksize_set(thd_attr, SWITCH_THREAD_STACKSIZE);

	for(int i=0;i<10;i++){

	        switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "Creating radius thread\n");

	        switch_thread_create(&thread[i], thd_attr, process_packets, &i, pool);

	}

	*module_interface = switch_loadable_module_create_module_interface(pool, modname);

	/* indicate that the module should continue to be loaded */
	return SWITCH_STATUS_SUCCESS;
}


SWITCH_MODULE_SHUTDOWN_FUNCTION(mod_radius_cdr_shutdown)
{

	globals.shutdown = 1;
	switch_core_remove_state_handler(&state_handlers);
	switch_thread_rwlock_wrlock(globals.rwlock);
	switch_thread_rwlock_unlock(globals.rwlock);

	return SWITCH_STATUS_SUCCESS;
}

/* For Emacs:
 * Local Variables:
 * mode:c
 * indent-tabs-mode:t
 * tab-width:4
 * c-basic-offset:4
 * End:
 * For VIM:
 * vim:set softtabstop=4 shiftwidth=4 tabstop=4 expandtab:
 */
-------------- next part --------------
Index: src/mod/event_handlers/mod_radius_cdr/mod_radius_cdr.c
===================================================================
--- src/mod/event_handlers/mod_radius_cdr/mod_radius_cdr.c	(revision 11727)
+++ src/mod/event_handlers/mod_radius_cdr/mod_radius_cdr.c	(working copy)
@@ -1,6 +1,6 @@
 /* 
  * FreeSWITCH Modular Media Switching Software Library / Soft-Switch Application
- * Copyright (C) 2005/2006, Anthony Minessale II <anthm at freeswitch.org>
+ * Copyright (C) 2005/2006, Anthony Minessale II <anthmct at yahoo.com>
  *
  * Version: MPL 1.1
  *
@@ -17,7 +17,7 @@
  * The Original Code is FreeSWITCH Modular Media Switching Software Library / Soft-Switch Application
  *
  * The Initial Developer of the Original Code is
- * Anthony Minessale II <anthm at freeswitch.org>
+ * Anthony Minessale II <anthmct at yahoo.com>
  * Portions created by the Initial Developer are Copyright (C)
  * the Initial Developer. All Rights Reserved.
  *
@@ -39,6 +39,9 @@
 SWITCH_MODULE_SHUTDOWN_FUNCTION(mod_radius_cdr_shutdown);
 SWITCH_MODULE_DEFINITION(mod_radius_cdr, mod_radius_cdr_load, mod_radius_cdr_shutdown, NULL);
 
+switch_memory_pool_t *module_pool = NULL;
+switch_queue_t *rad_queue = NULL;
+
 static struct {
 	int shutdown;
 	switch_thread_rwlock_t *rwlock;
@@ -52,6 +55,47 @@
 static char *my_retries;		/* 3 */
 static char my_servers[SERVER_MAX][255];
 
+struct acct_packet {
+
+	rc_handle *rad_config;
+	VALUE_PAIR *data;
+
+};
+
+static void *SWITCH_THREAD_FUNC process_packets(switch_thread_t *thread, void *ptr){
+
+	void *pop = NULL;
+
+	while(1){
+
+		if(switch_queue_pop(rad_queue,&pop) != SWITCH_STATUS_SUCCESS || !pop){
+
+			switch_yield(1000);
+			switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] nothing to do thread is sleeping\n");		
+
+		} else {
+
+		        struct acct_packet *tmp = (struct acct_packet *) pop;
+
+		        if (rc_acct(tmp->rad_config, 0, tmp->data) == OK_RC) {
+		                switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] RADIUS Accounting Packet OK\n");
+	        	} else {
+        	        	switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] RADIUS Accounting Packet FAILED\n");
+	        	}
+
+
+			switch_safe_free(tmp->data);
+			switch_safe_free(tmp->rad_config);
+			switch_safe_free(tmp);
+
+		}
+
+	}
+
+	return 0;
+
+}
+
 static rc_handle *my_radius_init(void)
 {
 	int i = 0;
@@ -135,9 +179,8 @@
 	switch_xml_t cdr;
 	switch_channel_t *channel = switch_core_session_get_channel(session);
 	rc_handle *rad_config;
-	switch_status_t retval = SWITCH_STATUS_TERM;
 	VALUE_PAIR *send = NULL;
-	uint32_t client_port = 0;
+	//uint32_t client_port = 0;
 	uint32_t status_type = PW_STATUS_START;
 	switch_time_t callstartdate = 0;
 	switch_time_t callanswerdate = 0;
@@ -152,7 +195,7 @@
 	switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] Entering my_on_routing\n");
 
 	if (globals.shutdown) {
-		return SWITCH_STATUS_FALSE;
+		return SWITCH_STATUS_SUCCESS;
 	}
 
 	if(channel) {
@@ -358,17 +401,20 @@
 		}
 	}
 
-	if (rc_acct(rad_config, client_port, send) == OK_RC) {
-		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "[mod_radius_cdr] RADIUS Accounting OK\n");
-		retval = SWITCH_STATUS_SUCCESS;
-	} else {
-		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "[mod_radius_cdr] RADIUS Accounting Failed\n");
-		retval = SWITCH_STATUS_TERM;
-	}
-	rc_avpair_free(send);
+	struct acct_packet *acct_start = NULL;
+
+	acct_start = malloc(sizeof(&acct_start));
+	
+	memset(acct_start, 0, sizeof(&acct_start));
+
+	acct_start->rad_config = rad_config;
+	acct_start->data = send;
+
+	switch_queue_push(rad_queue,acct_start);
+
  end:
 	switch_thread_rwlock_unlock(globals.rwlock);
-	return (retval);
+	return (SWITCH_STATUS_SUCCESS);
 }
 
 static switch_status_t my_on_hangup(switch_core_session_t *session)
@@ -376,9 +422,7 @@
 	switch_xml_t cdr;
 	switch_channel_t *channel = switch_core_session_get_channel(session);
 	rc_handle *rad_config;
-	switch_status_t retval = SWITCH_STATUS_TERM;
 	VALUE_PAIR *send = NULL;
-	uint32_t client_port = 0;
 	uint32_t status_type = PW_STATUS_STOP;
 	switch_time_t callstartdate = 0;
 	switch_time_t callanswerdate = 0;
@@ -627,18 +671,20 @@
 		}
 	}
 
-	if (rc_acct(rad_config, client_port, send) == OK_RC) {
-		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "RADIUS Accounting OK\n");
-		retval = SWITCH_STATUS_SUCCESS;
-	} else {
-		switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "RADIUS Accounting Failed\n");
-		retval = SWITCH_STATUS_TERM;
-	}
-	rc_avpair_free(send);
+	struct acct_packet *acct_stop = NULL;
 
+	acct_stop = malloc(sizeof(&acct_stop));
+
+        memset(acct_stop, 0, sizeof(&acct_stop));
+
+        acct_stop->rad_config = rad_config;
+        acct_stop->data = send;
+
+        switch_queue_push(rad_queue,acct_stop);
+
  end:
 	switch_thread_rwlock_unlock(globals.rwlock);
-	return (retval);
+	return (SWITCH_STATUS_SUCCESS);
 }
 
 static switch_status_t load_config(void)
@@ -719,9 +765,37 @@
 		return SWITCH_STATUS_TERM;
 	}
 
+	if (switch_core_new_memory_pool(&module_pool) != SWITCH_STATUS_SUCCESS) {
+                switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "Could not create pool for module\n");
+                return SWITCH_STATUS_TERM;
+        }
+
+	// the queue limit could be configurable but we leave it hardcoded for now
+
+        switch_queue_create(&rad_queue, 10000, module_pool);
+
 	/* test global state handlers */
-	switch_core_add_state_handler(&state_handlers);
+        switch_core_add_state_handler(&state_handlers);
 
+	// the queue processing threads number could be configurable but we leave it hardcoded for now
+
+	switch_thread_t *thread[10];
+	switch_threadattr_t *thd_attr = NULL;
+
+        switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "Initializing radius threads\n");
+
+        switch_threadattr_create(&thd_attr, pool);
+        switch_threadattr_detach_set(thd_attr, 1);
+	switch_threadattr_stacksize_set(thd_attr, SWITCH_THREAD_STACKSIZE);
+
+	for(int i=0;i<10;i++){
+
+	        switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "Creating radius thread\n");
+
+	        switch_thread_create(&thread[i], thd_attr, process_packets, &i, pool);
+
+	}
+
 	*module_interface = switch_loadable_module_create_module_interface(pool, modname);
 
 	/* indicate that the module should continue to be loaded */

From intralanman at freeswitch.org  Tue Feb 10 12:39:42 2009
From: intralanman at freeswitch.org (Raymond Chandler)
Date: Tue, 10 Feb 2009 15:39:42 -0500
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions [first
 patch created]
In-Reply-To: <4991ACA3.4060803@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>	<4987F2D2.1030303@kinetix.gr>	<4988239E.4040201@kinetix.gr>	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>	<49885789.5000905@kinetix.gr>	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>	<4988B36D.2020800@kinetix.gr>	<191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>	<4988B821.2000805@kinetix.gr>	<191c3a030902031432j3cfcc39drcfa35f5d284b5959@mail.gmail.com>
	<4991ACA3.4060803@kinetix.gr>
Message-ID: <4991E60E.8050604@freeswitch.org>

Apostolos Pantsiopoulos wrote:
>
>     I noticed while tweaking the module that there might be a memory leak
> problem. I monitored the freeswitch process using the simple top linux 
> program
> and the sipp call generator. When the radius module is activated then 
> FS starts
> consuming more memory in a linear manner. I used a 10 calls / sec rate 
> with
> sipp (zero call length) and the memory  reached 200 MB in just a few 
> minutes.
if you let it run, does it keep using more and more memory? or does it 
top out somewhere?
> At first I suspected my additions to the module to be the problem, but 
> I found
> out that the same thing happened using the module in its current svn 
> state
> (i.e. without my patch).
>
>     I followed the wiki's guidelines for creating a patch, but I don't 
> know how the
> whole patch submitting "protocol" works. Should I create an account on 
> jira?
yes
> Should
> I post the patch here first until it is in an "acceptable" state? 
no
> Should I send the patch
> to a code maintainer and let him decide what to do?
yes, through jira


-Ray


From anthony.minessale at gmail.com  Tue Feb 10 16:35:51 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Tue, 10 Feb 2009 18:35:51 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions [first
	patch created]
In-Reply-To: <4991E60E.8050604@freeswitch.org>
References: <4982E0FF.8070805@kinetix.gr>
	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>
	<49885789.5000905@kinetix.gr>
	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>
	<4988B36D.2020800@kinetix.gr>
	<191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>
	<4988B821.2000805@kinetix.gr>
	<191c3a030902031432j3cfcc39drcfa35f5d284b5959@mail.gmail.com>
	<4991ACA3.4060803@kinetix.gr> <4991E60E.8050604@freeswitch.org>
Message-ID: <191c3a030902101635l160490cbk15c197b5049991aa@mail.gmail.com>

check that you are freeing the objs you pop from the queue.


On Tue, Feb 10, 2009 at 2:39 PM, Raymond Chandler <
intralanman at freeswitch.org> wrote:

> Apostolos Pantsiopoulos wrote:
> >
> >     I noticed while tweaking the module that there might be a memory leak
> > problem. I monitored the freeswitch process using the simple top linux
> > program
> > and the sipp call generator. When the radius module is activated then
> > FS starts
> > consuming more memory in a linear manner. I used a 10 calls / sec rate
> > with
> > sipp (zero call length) and the memory  reached 200 MB in just a few
> > minutes.
> if you let it run, does it keep using more and more memory? or does it
> top out somewhere?
> > At first I suspected my additions to the module to be the problem, but
> > I found
> > out that the same thing happened using the module in its current svn
> > state
> > (i.e. without my patch).
> >
> >     I followed the wiki's guidelines for creating a patch, but I don't
> > know how the
> > whole patch submitting "protocol" works. Should I create an account on
> > jira?
> yes
> > Should
> > I post the patch here first until it is in an "acceptable" state?
> no
> > Should I send the patch
> > to a code maintainer and let him decide what to do?
> yes, through jira
>
>
> -Ray
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090210/3d5aeef9/attachment.html 

From regs at kinetix.gr  Wed Feb 11 03:07:59 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Wed, 11 Feb 2009 13:07:59 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions [first
 patch created]
In-Reply-To: <191c3a030902101635l160490cbk15c197b5049991aa@mail.gmail.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>	<49885789.5000905@kinetix.gr>	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>	<4988B36D.2020800@kinetix.gr>	<191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>	<4988B821.2000805@kinetix.gr>	<191c3a030902031432j3cfcc39drcfa35f5d284b5959@mail.gmail.com>	<4991ACA3.4060803@kinetix.gr>
	<4991E60E.8050604@freeswitch.org>
	<191c3a030902101635l160490cbk15c197b5049991aa@mail.gmail.com>
Message-ID: <4992B18F.5030104@kinetix.gr>

I am freeing them. As I stated before this memory growth happened even
before my modifications, i.e. in the state the module was in the svn 
(without
queues, threads etc.)

I will create an account on jira and upload the patch there.

Anthony Minessale wrote:
> check that you are freeing the objs you pop from the queue.
>
>
> On Tue, Feb 10, 2009 at 2:39 PM, Raymond Chandler 
> <intralanman at freeswitch.org <mailto:intralanman at freeswitch.org>> wrote:
>
>     Apostolos Pantsiopoulos wrote:
>     >
>     >     I noticed while tweaking the module that there might be a
>     memory leak
>     > problem. I monitored the freeswitch process using the simple top
>     linux
>     > program
>     > and the sipp call generator. When the radius module is activated
>     then
>     > FS starts
>     > consuming more memory in a linear manner. I used a 10 calls /
>     sec rate
>     > with
>     > sipp (zero call length) and the memory  reached 200 MB in just a few
>     > minutes.
>     if you let it run, does it keep using more and more memory? or does it
>     top out somewhere?
>     > At first I suspected my additions to the module to be the
>     problem, but
>     > I found
>     > out that the same thing happened using the module in its current svn
>     > state
>     > (i.e. without my patch).
>     >
>     >     I followed the wiki's guidelines for creating a patch, but I
>     don't
>     > know how the
>     > whole patch submitting "protocol" works. Should I create an
>     account on
>     > jira?
>     yes
>     > Should
>     > I post the patch here first until it is in an "acceptable" state?
>     no
>     > Should I send the patch
>     > to a code maintainer and let him decide what to do?
>     yes, through jira
>
>
>     -Ray
>
>     _______________________________________________
>     Freeswitch-dev mailing list
>     Freeswitch-dev at lists.freeswitch.org
>     <mailto:Freeswitch-dev at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest at conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090211/93b52c0b/attachment.html 

From sshen at oa.com.au  Mon Feb  9 16:17:17 2009
From: sshen at oa.com.au (Scott Shen)
Date: Tue, 10 Feb 2009 11:17:17 +1100
Subject: [Freeswitch-dev] Some Sample C programs in using FreeSwitch APIs
Message-ID: <4462DF002246D44CB823FA4F985539940C83281A50@oa-exchange1.oa.com.au>


Can any one provide some C programs showing how to use FreeSwitch APIs to build an UAC or UAS?

Thanks & Regards
Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090210/ee2664e6/attachment-0001.html 

From freeswitch-dev at lists.rupa.com  Wed Feb 11 14:31:50 2009
From: freeswitch-dev at lists.rupa.com (Rupa Schomaker (lists))
Date: Wed, 11 Feb 2009 16:31:50 -0600
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions [first
 patch created]
In-Reply-To: <4991ACA3.4060803@kinetix.gr>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>	<4987F2D2.1030303@kinetix.gr>	<4988239E.4040201@kinetix.gr>	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>	<49885789.5000905@kinetix.gr>	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>	<4988B36D.2020800@kinetix.gr>	<191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>	<4988B821.2000805@kinetix.gr>	<191c3a030902031432j3cfcc39drcfa35f5d284b5959@mail.gmail.com>
	<4991ACA3.4060803@kinetix.gr>
Message-ID: <499351D6.8040906@lists.rupa.com>

On 2/10/2009 10:34 AM, Apostolos Pantsiopoulos wrote:
> > P.S. If someone is eager to work with me in solving the possible
> > memory leak please contact me directly or through the list. I am not
> > a very good c coder and debugging c is somewhat new to me. So, any
> > help would be welcomed.

If you jump on irc I can help you with valgrind.  It helped me track
down some memory leaks in mod_lcr.

The basic idea is to run valgrind on your freeswitch binary:

valgrind --tool=memcheck --log-file-exactly=vg.log --leak-check=full
--leak-resolution=high --show-reachable=yes bin/freeswitch -vg

(all one line).  I'm running a diff version of valgrind, so the log file
argument is --log-file=vg.log not --log-file-exactly.

The methodology I used was to:

1) start freeswitch with the module unloaded
2) load the module
3) run some simple test cases (don't hit it with sipp right away)
4) unload the module
5) then shutdown freeswitch

You'll see "leaks" from sofia and some other modules.  But don't focus
on those.  Search the logfile for your module.  In my case, I looked for
"lcr".

valgrind will show you allocations that weren't properly freed.


I completely moved mod_lcr to using the pool based allocator.  This
greatly simplified memory management.  If everything is allocated in the
pool, you can free once the pool and everything gets freed.  You do need
to consider the lifecycle of your pool though.  In your case, you are
tossing copies to another thread and that thread is long running.  So,
you either need to periodically free your pool (every N log entries
processed) or forget the pool and free per entry.

If doing every N log entries -- keep in mind locking (so you don't try
to free the pool while the session thread is allocating memory from your
pool to copy the event into).  Also, you probably want two pools.  One
for your log lived objects (config data, connection to radius, etc) and
one for short lived objects (the events).

I think I typed too much, jump over to irc when you get a chance.  I'm
quite busy today, but in general can help.

--Rupa




From brian at freeswitch.org  Wed Feb 11 14:37:52 2009
From: brian at freeswitch.org (Brian West)
Date: Wed, 11 Feb 2009 16:37:52 -0600
Subject: [Freeswitch-dev] Some Sample C programs in using FreeSwitch APIs
In-Reply-To: <4462DF002246D44CB823FA4F985539940C83281A50@oa-exchange1.oa.com.au>
References: <4462DF002246D44CB823FA4F985539940C83281A50@oa-exchange1.oa.com.au>
Message-ID: <1F8673EA-1D0E-405D-AA11-C9E7D8BEFD99@freeswitch.org>

What purpose are you looking to use FreeSWITCH for?

/b

On Feb 9, 2009, at 6:17 PM, Scott Shen wrote:

>
> Can any one provide some C programs showing how to use FreeSwitch  
> APIs to build an UAC or UAS?
>
> Thanks & Regards
> Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090211/2dbad904/attachment.html 

From sshen at oa.com.au  Wed Feb 11 17:28:40 2009
From: sshen at oa.com.au (Scott Shen)
Date: Thu, 12 Feb 2009 12:28:40 +1100
Subject: [Freeswitch-dev] Some Sample C programs in using FreeSwitch APIs
In-Reply-To: <1F8673EA-1D0E-405D-AA11-C9E7D8BEFD99@freeswitch.org>
Message-ID: <4462DF002246D44CB823FA4F985539940CAF51EB78@oa-exchange1.oa.com.au>

Extend FS to suit some customized requirements, for example to create a module in C to replace "bridge" application function, I had a look on mod_dptools, no problem to understand that, but have no idea how session/channel/stream/settings etc are linked together, think a simple UAC might be a good reference point



-----Original Message-----
From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Brian West
Sent: Thursday, 12 February 2009 9:38 AM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Some Sample C programs in using FreeSwitch APIs

What purpose are you looking to use FreeSWITCH for?

/b

On Feb 9, 2009, at 6:17 PM, Scott Shen wrote:




Can any one provide some C programs showing how to use FreeSwitch APIs to build an UAC or UAS?

Thanks & Regards
Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090212/3138adc5/attachment.html 

From brian at freeswitch.org  Wed Feb 11 17:36:02 2009
From: brian at freeswitch.org (Brian West)
Date: Wed, 11 Feb 2009 19:36:02 -0600
Subject: [Freeswitch-dev] Some Sample C programs in using FreeSwitch APIs
In-Reply-To: <4462DF002246D44CB823FA4F985539940CAF51EB78@oa-exchange1.oa.com.au>
References: <4462DF002246D44CB823FA4F985539940CAF51EB78@oa-exchange1.oa.com.au>
Message-ID: <6114C6CD-49AF-434C-BDE2-5EBB97F0127D@freeswitch.org>

does the current bridge function not work?  The bridge is wrapped in  
the core switch_ivr_* functions which takes care of this stuff... I  
can't see a clear reason you would want to replace that can you  
describe what you're wanting to accomplish because that function does  
many neat and interesting things.  You're basically describing ripping  
the core out of FreeSWITCH and replacing it with something else... Can  
you hope on #freeswitch on irc.freenode.net and lets talk about your  
need or maybe you can email me off list.

/b

On Feb 11, 2009, at 7:28 PM, Scott Shen wrote:

> Extend FS to suit some customized requirements, for example to  
> create a module in C to replace ?bridge? application function, I had  
> a look on mod_dptools, no problem to understand that, but have no  
> idea how session/channel/stream/settings etc are linked together,  
> think a simple UAC might be a good reference point
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090211/025f334c/attachment.html 

From anthony.minessale at gmail.com  Wed Feb 11 20:20:25 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Wed, 11 Feb 2009 22:20:25 -0600
Subject: [Freeswitch-dev] Some Sample C programs in using FreeSwitch APIs
In-Reply-To: <4462DF002246D44CB823FA4F985539940C83281A50@oa-exchange1.oa.com.au>
References: <AcmLFO6xIbgl8bNmTvqo0m/gywUNzw==>
	<4462DF002246D44CB823FA4F985539940C83281A50@oa-exchange1.oa.com.au>
Message-ID: <191c3a030902112020qa5f5e3fn5333a6df17851dae@mail.gmail.com>

every file in src/mod/*/mod_*/*.c?? is more or less an example.

most of bridge code is in switch_ivr_bridge.c




On Mon, Feb 9, 2009 at 6:17 PM, Scott Shen <sshen at oa.com.au> wrote:

>
>
> Can any one provide some C programs showing how to use FreeSwitch APIs to
> build an UAC or UAS?
>
>
>
> Thanks & Regards
>
> Scott
>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090211/1dc8b4cb/attachment.html 

From regs at kinetix.gr  Thu Feb 12 00:48:34 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Thu, 12 Feb 2009 10:48:34 +0200
Subject: [Freeswitch-dev] mod_radius_cdr behavior and questions [first
 patch created]
In-Reply-To: <499351D6.8040906@lists.rupa.com>
References: <4982E0FF.8070805@kinetix.gr>	<191c3a030902021522s57e5da09lb70416dd3c40eacd@mail.gmail.com>	<4987F2D2.1030303@kinetix.gr>	<4988239E.4040201@kinetix.gr>	<191c3a030902030603t623daf59rd61ab60c012598ae@mail.gmail.com>	<49885789.5000905@kinetix.gr>	<191c3a030902031237j2068f2acwcc34cd7f64064eca@mail.gmail.com>	<4988B36D.2020800@kinetix.gr>	<191c3a030902031318u54bc02c4gf988cb4643367c26@mail.gmail.com>	<4988B821.2000805@kinetix.gr>	<191c3a030902031432j3cfcc39drcfa35f5d284b5959@mail.gmail.com>	<4991ACA3.4060803@kinetix.gr>
	<499351D6.8040906@lists.rupa.com>
Message-ID: <4993E262.108@kinetix.gr>

Thanks for the info. I will try valgrind later today.

As I wrote before, the memory leak seems to be present even before
I introduced the new thread-depended mechanism for radius.
I will try troubleshoot it there, instead of troubleshooting my patch, so
that it gets solved on both.

Rupa Schomaker (lists) wrote:
> On 2/10/2009 10:34 AM, Apostolos Pantsiopoulos wrote:
>   
>>> P.S. If someone is eager to work with me in solving the possible
>>> memory leak please contact me directly or through the list. I am not
>>> a very good c coder and debugging c is somewhat new to me. So, any
>>> help would be welcomed.
>>>       
>
> If you jump on irc I can help you with valgrind.  It helped me track
> down some memory leaks in mod_lcr.
>
> The basic idea is to run valgrind on your freeswitch binary:
>
> valgrind --tool=memcheck --log-file-exactly=vg.log --leak-check=full
> --leak-resolution=high --show-reachable=yes bin/freeswitch -vg
>
> (all one line).  I'm running a diff version of valgrind, so the log file
> argument is --log-file=vg.log not --log-file-exactly.
>
> The methodology I used was to:
>
> 1) start freeswitch with the module unloaded
> 2) load the module
> 3) run some simple test cases (don't hit it with sipp right away)
> 4) unload the module
> 5) then shutdown freeswitch
>
> You'll see "leaks" from sofia and some other modules.  But don't focus
> on those.  Search the logfile for your module.  In my case, I looked for
> "lcr".
>
> valgrind will show you allocations that weren't properly freed.
>
>
> I completely moved mod_lcr to using the pool based allocator.  This
> greatly simplified memory management.  If everything is allocated in the
> pool, you can free once the pool and everything gets freed.  You do need
> to consider the lifecycle of your pool though.  In your case, you are
> tossing copies to another thread and that thread is long running.  So,
> you either need to periodically free your pool (every N log entries
> processed) or forget the pool and free per entry.
>
> If doing every N log entries -- keep in mind locking (so you don't try
> to free the pool while the session thread is allocating memory from your
> pool to copy the event into).  Also, you probably want two pools.  One
> for your log lived objects (config data, connection to radius, etc) and
> one for short lived objects (the events).
>
> I think I typed too much, jump over to irc when you get a chance.  I'm
> quite busy today, but in general can help.
>
> --Rupa
>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at kinetix.gr
------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090212/f20cd973/attachment-0001.html 

From steveu at coppice.org  Fri Feb 13 03:56:29 2009
From: steveu at coppice.org (Steve Underwood)
Date: Fri, 13 Feb 2009 19:56:29 +0800
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <2d9149cd0902090819nfae6d60xb3497d3940faaf@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>	<6b65470d0902090635l57ebb9f1i8aa3436cb8e15b1a@mail.gmail.com>
	<2d9149cd0902090819nfae6d60xb3497d3940faaf@mail.gmail.com>
Message-ID: <49955FED.70209@coppice.org>

Hi Kristian,

What you are doing now looks very elementary, and there is no real 
reason to use ecasound. I don't know what you intend to do as you flesh 
out this quality assessment, but its not clear to me where ecasound 
would ever be a big benefit in such a tool.

Not using ecasound certainly simplifies its licencing issues. :-)

Regards,
Steve


Kristian Kielhofner wrote:
> William,
>
>   That's what I do now and it's somewhat clunky.
>
>   There is one advantage: you can continually tweak ecasound params to
> look for other audio issues and reprocess the files.  Other than that
> it seems like a module is the way to go.
>
> On Mon, Feb 9, 2009 at 9:35 AM, William Suffill
> <william.suffill at gmail.com> wrote:
>   
>> Well placing calls and analyzing the results after the fact would avoid any
>> licensing issues. As long as you have recordings that could be processed the
>> concept should still work.
>>
>>
>> - W
>>
>> PS: Yes haven't had any coffee yet so might me out of my mind =)
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>>
>>     
>
>
>
>   



From kristian.kielhofner at gmail.com  Fri Feb 13 08:09:54 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Fri, 13 Feb 2009 11:09:54 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <49955FED.70209@coppice.org>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<6b65470d0902090635l57ebb9f1i8aa3436cb8e15b1a@mail.gmail.com>
	<2d9149cd0902090819nfae6d60xb3497d3940faaf@mail.gmail.com>
	<49955FED.70209@coppice.org>
Message-ID: <2d9149cd0902130809s63ef5a31y4155371428eda6fc@mail.gmail.com>

Steve,

  At the moment it is very elementary and probably easily reproduced.
It's also the first check I could come up with and it was good enough
to help me identify my issues.  As this tool/concept gets exposed to
the real world and used in different applications, scenarios, etc it
would be /very/ convenient to have the full power of ecasound and the
LADSPA plugin architecture available at our disposal from FS.

   There are plenty of people out there (hint, hint) that know far
more about audio processing, etc than I do.  I'm sure they could come
up with some very, very cool applications once FS audio can be put
through ecasound/LADSPA (think mod_soundtouch on steroids).  I don't
want my lack of understanding and foresight to get in their way.

  Ecasound looks like the right tool for job and I'd hate to let
something small like "licensing" get in the way ;)  I've already
e-mailed the creator for an LGPL exception but the message bounced.
I'm looking for other addresses and contacts.

  Hmmm...  Maybe we could skip ecasound and just implement a LADSPA
host in FS (LADSPA is LGPL).  My only concern here is the ability to
write LADSPA plugins.  The barrier to entry and learning curve is
certainly higher than some basic ecasound params.

On Fri, Feb 13, 2009 at 6:56 AM, Steve Underwood <steveu at coppice.org> wrote:
> Hi Kristian,
>
> What you are doing now looks very elementary, and there is no real
> reason to use ecasound. I don't know what you intend to do as you flesh
> out this quality assessment, but its not clear to me where ecasound
> would ever be a big benefit in such a tool.
>
> Not using ecasound certainly simplifies its licencing issues. :-)
>
> Regards,
> Steve
>

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From steveu at coppice.org  Fri Feb 13 09:38:40 2009
From: steveu at coppice.org (Steve Underwood)
Date: Sat, 14 Feb 2009 01:38:40 +0800
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <2d9149cd0902130809s63ef5a31y4155371428eda6fc@mail.gmail.com>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>	<6b65470d0902090635l57ebb9f1i8aa3436cb8e15b1a@mail.gmail.com>	<2d9149cd0902090819nfae6d60xb3497d3940faaf@mail.gmail.com>	<49955FED.70209@coppice.org>
	<2d9149cd0902130809s63ef5a31y4155371428eda6fc@mail.gmail.com>
Message-ID: <4995B020.2080402@coppice.org>

Kristian Kielhofner wrote:
> Steve,
>
>   At the moment it is very elementary and probably easily reproduced.
> It's also the first check I could come up with and it was good enough
> to help me identify my issues.  As this tool/concept gets exposed to
> the real world and used in different applications, scenarios, etc it
> would be /very/ convenient to have the full power of ecasound and the
> LADSPA plugin architecture available at our disposal from FS.
>
>    There are plenty of people out there (hint, hint) that know far
> more about audio processing, etc than I do.  I'm sure they could come
> up with some very, very cool applications once FS audio can be put
> through ecasound/LADSPA (think mod_soundtouch on steroids).  I don't
> want my lack of understanding and foresight to get in their way.
>
>   Ecasound looks like the right tool for job and I'd hate to let
> something small like "licensing" get in the way ;)  I've already
> e-mailed the creator for an LGPL exception but the message bounced.
> I'm looking for other addresses and contacts.
>
>   Hmmm...  Maybe we could skip ecasound and just implement a LADSPA
> host in FS (LADSPA is LGPL).  My only concern here is the ability to
> write LADSPA plugins.  The barrier to entry and learning curve is
> certainly higher than some basic ecasound params.
>   
Well, I had a look through ecasound, and it looks pretty useful for 
someone doing recording. It looks pretty useless for call analysis, though.

As for mod_soundtouch, the current version is largely a toy, as it takes 
too much compute time for serious application. There will probably be a 
more telephony oriented version of the same concept available in the not 
too distant future.

Steve



From gmaruzz at celliax.org  Fri Feb 13 10:15:08 2009
From: gmaruzz at celliax.org (Giovanni Maruzzelli)
Date: Fri, 13 Feb 2009 19:15:08 +0100
Subject: [Freeswitch-dev] Skypiax (Skype Network endpoint) for FreeSWITCH
Message-ID: <7b197bef0902131015k456dee87x8f0f1b7059f1b49c@mail.gmail.com>

Hello FreeSWITCHers,

mod_skypiax is available for testing, feature requests, bug hunting.

I would like to ask the help of you all to make Skypiax robust and
feature full on FreeSWITCH, and particularly of Massimo Cetra (CtRiX
on IRC), that has developed mod_airpe (another Skype endpoint).

I've written a first documentation on Skypiax installation and usage
at: http://wiki.freeswitch.org/wiki/Skypiax
and there is a Jira module at:
http://jira.freeswitch.org/browse/MODSKYPIAX

So, please, test the software, edit the wiki page both for style and
content, file bug reports and feature requests.

FreeSWITCH is now the platform of first development for me, so the
FreeSWITCH part of Skypiax is more tested (if any) and the code is
more readable compared to the Asterisk part where lot of legacy from
my other projects clutter the code.

But Skypiax strive to be available as a Skype compatible endpoint for
all the opensource telephony community, and in the near time the
Asterisk part will be cleaned much more, and documented.

As you will see, the code is made by skypiax_protocol.c (the
interaction with Skype client), mod_skypiax.c (the interaction with
FreeSWITCH), chan_skypiax.c (the interaction with Asterisk).

Please consider me available for all infos, clarifications, discussions, etc.

I would like to thanks all the peoples that helped me via mail and IRC
(so bad to have different timezones, isn't?), the *very early
adopters*, the testers, the patchers, and you all.
Particularly Anthony Minessale, Michael Jerris, Brian West, Michael
Collins, Ken Rice, Seven Du, Clif Cox, Hristo Trendev, Rehan Allah
Wala, Jason Garland and Antonio Gallo.

>From the wiki page (http://wiki.freeswitch.org/wiki/Skypiax):

 WHAT IS SKYPIAX

This software (Skypiax) uses the Skype API but is not endorsed,
certified or otherwise approved in any way by Skype.

Skypiax is an endpoint (channel driver) that uses the Skype client as
an interface to the Skype network, and allows incoming and outgoing
Skype calls to/from FreeSWITCH (that can be bridged, originated,
answered, etc. as in all other endpoints, e.g. sofia/SIP).

Skypiax works in FreeSWITCH (FS) on both Linux and Windows, at both
8khz and 16khz (Skype client has 16khz audio I/O). Skypiax works on
Asterisk too, at 8khz, on Linux and Windows (through CygWin).

Think of Skypiax as similar to OpenZAP for analog lines. For each
channel you need an interface (a Skype client). So, for example, two
concurrent calls would need two channels, and therefor two Skype
clients running on your FreeSWITCH server.

If your Skype client(s) have Skype credits, then Skypiax works for
SkypeOut calls as well.

Sincerely,

Giovanni Maruzzelli
=========================================
www.celliax.org
via Pierlombardo 9, 20135 Milano
Italy
gmaruzz at celliax dot org
Cell : +39-347-2665618
Fax : +39-02-87390039




On Thu, Jan 15, 2009 at 6:39 PM, Giovanni Maruzzelli
<gmaruzz at celliax.org> wrote:
> Hi FreeSWITCH developers
>
> I would like to propose to the community my plans, so we can discuss
> and coordinate efforts.
>
> I developed a couple of channel drivers for Asterisk in the past
> (works on both Linux and Windows), and I would like to port them to FS
> and further enhance them.
>
> The two endpoints are:
> - Skypiax, Skype compatible, makes and receives calls to/from Skype
> network and Skypeout service, using the Skype client as interface.
> - Celliax, GSM and SMS endpoint, makes and receives voice calls and
> SMSs to/from the GSM/CDMA network, using second hand cellphones and/or
> embedded professional devices as interfaces
>
> My aims are:
>
> a) port both endpoints from Asterisk to FreeSWITCH
> b) have both endpoints continue to support at least Linux and Windows on FS
> c) I would like better having most of the endpoints code working for
> both FreeSWITCH and Asterisk, maintaining separated the code that
> interface with the GSM and Skype network, from the code that interface
> with the core.
>
> Skypiax, the skype compatible endpoint, is a fork of celliax, the GSM
> endpoint, and they share the same skeleton and logic, so porting
> celliax after having ported skypiax will be easier and faster :-).
>
> Current situation and next steps:
> 1) skypiax (http://wiki.freeswitch.org/wiki/Skypiax) is now available
> for testing and debugging, needs to be polished and cleaned
> 2) starting mid next week (I'll be back in office), I want to
> integrate into skypiax the code and ideas from mod_airpe of Massimo
> (ctrix), that has developed an alternative Skype compatible module,
> and coordinate any future development with him and any other
> interested developer
> 3) begin the porting of celliax to FS, aiming at a pre-beta release
> for Linux and Windows during February.
> 4) coordinate further development of celliax with any other developer
> interested in GSM, SMSs, CDMA, IDEN, AT commands, FBUS commands,
> embedded devices, audio sampling
>
> I am gmaruzz on #freeswitch and #freeswitch-dev, you can find more
> info at www.celliax.org.
>
> Sincerely,
>
> Giovanni Maruzzelli
> =========================================
> www.celliax.org
> via Pierlombardo 9, 20135 Milano
> Italy
> gmaruzz at celliax dot org
> Cell : +39-347-2665618
> Fax : +39-02-87390039
>


From mitul at enterux.com  Fri Feb 13 10:55:19 2009
From: mitul at enterux.com (Mitul Limbani)
Date: Sat, 14 Feb 2009 00:25:19 +0530
Subject: [Freeswitch-dev] Skypiax (Skype Network endpoint) for FreeSWITCH
In-Reply-To: <7b197bef0902131015k456dee87x8f0f1b7059f1b49c@mail.gmail.com>
References: <7b197bef0902131015k456dee87x8f0f1b7059f1b49c@mail.gmail.com>
Message-ID: <899B0770-C0BD-4077-BA91-D6EA51B11DDB@enterux.com>

Giovanni,

Nice stuff I shall test this out.

Regards,
Mitul Limbani,
Founder & CEO,
Enterux Solutions Pvt Ltd,
The Enterprise Linux Company(r),
http://www.enterux.com/


On 13-Feb-09, at 23:45, Giovanni Maruzzelli <gmaruzz at celliax.org> wrote:

> Hello FreeSWITCHers,
>
> mod_skypiax is available for testing, feature requests, bug hunting.
>
> I would like to ask the help of you all to make Skypiax robust and
> feature full on FreeSWITCH, and particularly of Massimo Cetra (CtRiX
> on IRC), that has developed mod_airpe (another Skype endpoint).
>
> I've written a first documentation on Skypiax installation and usage
> at: http://wiki.freeswitch.org/wiki/Skypiax
> and there is a Jira module at:
> http://jira.freeswitch.org/browse/MODSKYPIAX
>
> So, please, test the software, edit the wiki page both for style and
> content, file bug reports and feature requests.
>
> FreeSWITCH is now the platform of first development for me, so the
> FreeSWITCH part of Skypiax is more tested (if any) and the code is
> more readable compared to the Asterisk part where lot of legacy from
> my other projects clutter the code.
>
> But Skypiax strive to be available as a Skype compatible endpoint for
> all the opensource telephony community, and in the near time the
> Asterisk part will be cleaned much more, and documented.
>
> As you will see, the code is made by skypiax_protocol.c (the
> interaction with Skype client), mod_skypiax.c (the interaction with
> FreeSWITCH), chan_skypiax.c (the interaction with Asterisk).
>
> Please consider me available for all infos, clarifications,  
> discussions, etc.
>
> I would like to thanks all the peoples that helped me via mail and IRC
> (so bad to have different timezones, isn't?), the *very early
> adopters*, the testers, the patchers, and you all.
> Particularly Anthony Minessale, Michael Jerris, Brian West, Michael
> Collins, Ken Rice, Seven Du, Clif Cox, Hristo Trendev, Rehan Allah
> Wala, Jason Garland and Antonio Gallo.
>
>> From the wiki page (http://wiki.freeswitch.org/wiki/Skypiax):
>
> WHAT IS SKYPIAX
>
> This software (Skypiax) uses the Skype API but is not endorsed,
> certified or otherwise approved in any way by Skype.
>
> Skypiax is an endpoint (channel driver) that uses the Skype client as
> an interface to the Skype network, and allows incoming and outgoing
> Skype calls to/from FreeSWITCH (that can be bridged, originated,
> answered, etc. as in all other endpoints, e.g. sofia/SIP).
>
> Skypiax works in FreeSWITCH (FS) on both Linux and Windows, at both
> 8khz and 16khz (Skype client has 16khz audio I/O). Skypiax works on
> Asterisk too, at 8khz, on Linux and Windows (through CygWin).
>
> Think of Skypiax as similar to OpenZAP for analog lines. For each
> channel you need an interface (a Skype client). So, for example, two
> concurrent calls would need two channels, and therefor two Skype
> clients running on your FreeSWITCH server.
>
> If your Skype client(s) have Skype credits, then Skypiax works for
> SkypeOut calls as well.
>
> Sincerely,
>
> Giovanni Maruzzelli
> =========================================
> www.celliax.org
> via Pierlombardo 9, 20135 Milano
> Italy
> gmaruzz at celliax dot org
> Cell : +39-347-2665618
> Fax : +39-02-87390039
>
>
>
>
> On Thu, Jan 15, 2009 at 6:39 PM, Giovanni Maruzzelli
> <gmaruzz at celliax.org> wrote:
>> Hi FreeSWITCH developers
>>
>> I would like to propose to the community my plans, so we can discuss
>> and coordinate efforts.
>>
>> I developed a couple of channel drivers for Asterisk in the past
>> (works on both Linux and Windows), and I would like to port them to  
>> FS
>> and further enhance them.
>>
>> The two endpoints are:
>> - Skypiax, Skype compatible, makes and receives calls to/from Skype
>> network and Skypeout service, using the Skype client as interface.
>> - Celliax, GSM and SMS endpoint, makes and receives voice calls and
>> SMSs to/from the GSM/CDMA network, using second hand cellphones and/ 
>> or
>> embedded professional devices as interfaces
>>
>> My aims are:
>>
>> a) port both endpoints from Asterisk to FreeSWITCH
>> b) have both endpoints continue to support at least Linux and  
>> Windows on FS
>> c) I would like better having most of the endpoints code working for
>> both FreeSWITCH and Asterisk, maintaining separated the code that
>> interface with the GSM and Skype network, from the code that  
>> interface
>> with the core.
>>
>> Skypiax, the skype compatible endpoint, is a fork of celliax, the GSM
>> endpoint, and they share the same skeleton and logic, so porting
>> celliax after having ported skypiax will be easier and faster :-).
>>
>> Current situation and next steps:
>> 1) skypiax (http://wiki.freeswitch.org/wiki/Skypiax) is now available
>> for testing and debugging, needs to be polished and cleaned
>> 2) starting mid next week (I'll be back in office), I want to
>> integrate into skypiax the code and ideas from mod_airpe of Massimo
>> (ctrix), that has developed an alternative Skype compatible module,
>> and coordinate any future development with him and any other
>> interested developer
>> 3) begin the porting of celliax to FS, aiming at a pre-beta release
>> for Linux and Windows during February.
>> 4) coordinate further development of celliax with any other developer
>> interested in GSM, SMSs, CDMA, IDEN, AT commands, FBUS commands,
>> embedded devices, audio sampling
>>
>> I am gmaruzz on #freeswitch and #freeswitch-dev, you can find more
>> info at www.celliax.org.
>>
>> Sincerely,
>>
>> Giovanni Maruzzelli
>> =========================================
>> www.celliax.org
>> via Pierlombardo 9, 20135 Milano
>> Italy
>> gmaruzz at celliax dot org
>> Cell : +39-347-2665618
>> Fax : +39-02-87390039
>>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org


From gmaruzz at celliax.org  Fri Feb 13 11:09:01 2009
From: gmaruzz at celliax.org (Giovanni Maruzzelli)
Date: Fri, 13 Feb 2009 20:09:01 +0100
Subject: [Freeswitch-dev] Skypiax (Skype Network endpoint) for FreeSWITCH
In-Reply-To: <899B0770-C0BD-4077-BA91-D6EA51B11DDB@enterux.com>
References: <7b197bef0902131015k456dee87x8f0f1b7059f1b49c@mail.gmail.com>
	<899B0770-C0BD-4077-BA91-D6EA51B11DDB@enterux.com>
Message-ID: <7b197bef0902131109j223f98ecx5a41a9754a7f8621@mail.gmail.com>

Mitul,

you're always the faster one! :-)

A big hug from Milano!

Sincerely,

Giovanni Maruzzelli
=========================================
www.celliax.org
via Pierlombardo 9, 20135 Milano
Italy
gmaruzz at celliax dot org
Cell : +39-347-2665618
Fax : +39-02-87390039




On Fri, Feb 13, 2009 at 7:55 PM, Mitul Limbani <mitul at enterux.com> wrote:
> Giovanni,
>
> Nice stuff I shall test this out.
>
> Regards,
> Mitul Limbani,
> Founder & CEO,
> Enterux Solutions Pvt Ltd,
> The Enterprise Linux Company(r),
> http://www.enterux.com/
>
>
> On 13-Feb-09, at 23:45, Giovanni Maruzzelli <gmaruzz at celliax.org> wrote:
>
>> Hello FreeSWITCHers,
>>
>> mod_skypiax is available for testing, feature requests, bug hunting.
>>
>> I would like to ask the help of you all to make Skypiax robust and
>> feature full on FreeSWITCH, and particularly of Massimo Cetra (CtRiX
>> on IRC), that has developed mod_airpe (another Skype endpoint).
>>
>> I've written a first documentation on Skypiax installation and usage
>> at: http://wiki.freeswitch.org/wiki/Skypiax
>> and there is a Jira module at:
>> http://jira.freeswitch.org/browse/MODSKYPIAX
>>
>> So, please, test the software, edit the wiki page both for style and
>> content, file bug reports and feature requests.
>>
>> FreeSWITCH is now the platform of first development for me, so the
>> FreeSWITCH part of Skypiax is more tested (if any) and the code is
>> more readable compared to the Asterisk part where lot of legacy from
>> my other projects clutter the code.
>>
>> But Skypiax strive to be available as a Skype compatible endpoint for
>> all the opensource telephony community, and in the near time the
>> Asterisk part will be cleaned much more, and documented.
>>
>> As you will see, the code is made by skypiax_protocol.c (the
>> interaction with Skype client), mod_skypiax.c (the interaction with
>> FreeSWITCH), chan_skypiax.c (the interaction with Asterisk).
>>
>> Please consider me available for all infos, clarifications,
>> discussions, etc.
>>
>> I would like to thanks all the peoples that helped me via mail and IRC
>> (so bad to have different timezones, isn't?), the *very early
>> adopters*, the testers, the patchers, and you all.
>> Particularly Anthony Minessale, Michael Jerris, Brian West, Michael
>> Collins, Ken Rice, Seven Du, Clif Cox, Hristo Trendev, Rehan Allah
>> Wala, Jason Garland and Antonio Gallo.
>>
>>> From the wiki page (http://wiki.freeswitch.org/wiki/Skypiax):
>>
>> WHAT IS SKYPIAX
>>
>> This software (Skypiax) uses the Skype API but is not endorsed,
>> certified or otherwise approved in any way by Skype.
>>
>> Skypiax is an endpoint (channel driver) that uses the Skype client as
>> an interface to the Skype network, and allows incoming and outgoing
>> Skype calls to/from FreeSWITCH (that can be bridged, originated,
>> answered, etc. as in all other endpoints, e.g. sofia/SIP).
>>
>> Skypiax works in FreeSWITCH (FS) on both Linux and Windows, at both
>> 8khz and 16khz (Skype client has 16khz audio I/O). Skypiax works on
>> Asterisk too, at 8khz, on Linux and Windows (through CygWin).
>>
>> Think of Skypiax as similar to OpenZAP for analog lines. For each
>> channel you need an interface (a Skype client). So, for example, two
>> concurrent calls would need two channels, and therefor two Skype
>> clients running on your FreeSWITCH server.
>>
>> If your Skype client(s) have Skype credits, then Skypiax works for
>> SkypeOut calls as well.
>>
>> Sincerely,
>>
>> Giovanni Maruzzelli
>> =========================================
>> www.celliax.org
>> via Pierlombardo 9, 20135 Milano
>> Italy
>> gmaruzz at celliax dot org
>> Cell : +39-347-2665618
>> Fax : +39-02-87390039
>>
>>
>>
>>
>> On Thu, Jan 15, 2009 at 6:39 PM, Giovanni Maruzzelli
>> <gmaruzz at celliax.org> wrote:
>>> Hi FreeSWITCH developers
>>>
>>> I would like to propose to the community my plans, so we can discuss
>>> and coordinate efforts.
>>>
>>> I developed a couple of channel drivers for Asterisk in the past
>>> (works on both Linux and Windows), and I would like to port them to
>>> FS
>>> and further enhance them.
>>>
>>> The two endpoints are:
>>> - Skypiax, Skype compatible, makes and receives calls to/from Skype
>>> network and Skypeout service, using the Skype client as interface.
>>> - Celliax, GSM and SMS endpoint, makes and receives voice calls and
>>> SMSs to/from the GSM/CDMA network, using second hand cellphones and/
>>> or
>>> embedded professional devices as interfaces
>>>
>>> My aims are:
>>>
>>> a) port both endpoints from Asterisk to FreeSWITCH
>>> b) have both endpoints continue to support at least Linux and
>>> Windows on FS
>>> c) I would like better having most of the endpoints code working for
>>> both FreeSWITCH and Asterisk, maintaining separated the code that
>>> interface with the GSM and Skype network, from the code that
>>> interface
>>> with the core.
>>>
>>> Skypiax, the skype compatible endpoint, is a fork of celliax, the GSM
>>> endpoint, and they share the same skeleton and logic, so porting
>>> celliax after having ported skypiax will be easier and faster :-).
>>>
>>> Current situation and next steps:
>>> 1) skypiax (http://wiki.freeswitch.org/wiki/Skypiax) is now available
>>> for testing and debugging, needs to be polished and cleaned
>>> 2) starting mid next week (I'll be back in office), I want to
>>> integrate into skypiax the code and ideas from mod_airpe of Massimo
>>> (ctrix), that has developed an alternative Skype compatible module,
>>> and coordinate any future development with him and any other
>>> interested developer
>>> 3) begin the porting of celliax to FS, aiming at a pre-beta release
>>> for Linux and Windows during February.
>>> 4) coordinate further development of celliax with any other developer
>>> interested in GSM, SMSs, CDMA, IDEN, AT commands, FBUS commands,
>>> embedded devices, audio sampling
>>>
>>> I am gmaruzz on #freeswitch and #freeswitch-dev, you can find more
>>> info at www.celliax.org.
>>>
>>> Sincerely,
>>>
>>> Giovanni Maruzzelli
>>> =========================================
>>> www.celliax.org
>>> via Pierlombardo 9, 20135 Milano
>>> Italy
>>> gmaruzz at celliax dot org
>>> Cell : +39-347-2665618
>>> Fax : +39-02-87390039
>>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>


From kristian.kielhofner at gmail.com  Fri Feb 13 11:31:31 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Fri, 13 Feb 2009 14:31:31 -0500
Subject: [Freeswitch-dev] Ecasound support in FreeSWITCH?
In-Reply-To: <4995B020.2080402@coppice.org>
References: <2d9149cd0902090002h1ad34147vad63ea88f8d9b0a6@mail.gmail.com>
	<6AE69884-B2BA-41F4-A5ED-03E8A72224D6@freeswitch.org>
	<6b65470d0902090635l57ebb9f1i8aa3436cb8e15b1a@mail.gmail.com>
	<2d9149cd0902090819nfae6d60xb3497d3940faaf@mail.gmail.com>
	<49955FED.70209@coppice.org>
	<2d9149cd0902130809s63ef5a31y4155371428eda6fc@mail.gmail.com>
	<4995B020.2080402@coppice.org>
Message-ID: <2d9149cd0902131131v5f5e93ep71370dea7ff48da6@mail.gmail.com>

On Fri, Feb 13, 2009 at 12:38 PM, Steve Underwood <steveu at coppice.org> wrote:
> Well, I had a look through ecasound, and it looks pretty useful for
> someone doing recording. It looks pretty useless for call analysis, though.
>
> As for mod_soundtouch, the current version is largely a toy, as it takes
> too much compute time for serious application. There will probably be a
> more telephony oriented version of the same concept available in the not
> too distant future.
>
> Steve
>

Steve,

  It proved to be quite useful for my application (analyzing recorded
calls from Asterisk).  I don't understand how it is useless for call
analysis.  Calls are just audio after all, right?

  I'm looking to build on this with FreeSWITCH.  I can continue to
analyze recorded files but it would be much cooler to do it in FS with
a mod.  I was just comparing functionality (manipulating the audio
stream) with mod_soundtouch.

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From gmaruzz at celliax.org  Sun Feb 15 06:56:33 2009
From: gmaruzz at celliax.org (Giovanni Maruzzelli)
Date: Sun, 15 Feb 2009 15:56:33 +0100
Subject: [Freeswitch-dev] [Freeswitch-users] Skypiax (Skype Network
	endpoint) for FreeSWITCH
In-Reply-To: <60d395660902150545n5ea158bbxc47f0634a6c19c0f@mail.gmail.com>
References: <7b197bef0902131015k456dee87x8f0f1b7059f1b49c@mail.gmail.com>
	<60d395660902150545n5ea158bbxc47f0634a6c19c0f@mail.gmail.com>
Message-ID: <7b197bef0902150656o7162b90ate1464da614f26cde@mail.gmail.com>

On Sun, Feb 15, 2009 at 2:45 PM, Gourav Shah <freedomyug at gmail.com> wrote:

> I have been testing it for a couple of days now, and its been working fine
> in my environment for making outgoing calls through skypeout etc.  Have
> filed a ticket for you regarding incoming call transfer to regular
> extensions. (http://jira.freeswitch.org/browse/MODSKYPIAX-4)

I tested and it worked for me. Maybe was the xml bug fixed by anthm?
Please "make current" FS, or reinstall from scratch, and check
again... If the problem show up again, reopen the issue.

>
> I see you have been planning to release a Live CD for Celliax for some time
> now, and would like to offer my help with this. If you need a resource to
> create a Live CD, please let me know, I would be glad to help.

I would be glad to collaborate on this.

The livecd has been neglected until now, and Celliax too, because of
Skypiax ;-).
Starting monday I'll begin to port Celliax to FS.

Would be nice to have the livecd with both Celliax and Skypiax, on
both FS and *.

In the past I used Knoppix as a base for the livecds, maybe today we
can start from Ubuntu live cd? What do you think?


Sincerely,

Giovanni Maruzzelli
=========================================
www.celliax.org
via Pierlombardo 9, 20135 Milano
Italy
gmaruzz at celliax dot org
Cell : +39-347-2665618
Fax : +39-02-87390039




On Sun, Feb 15, 2009 at 2:45 PM, Gourav Shah <freedomyug at gmail.com> wrote:
> Thank You !
>
> I have been waiting for mod_skypiax  to be released on FreeSwitch.
>
> I have been testing it for a couple of days now, and its been working fine
> in my environment for making outgoing calls through skypeout etc.  Have
> filed a ticket for you regarding incoming call transfer to regular
> extensions. (http://jira.freeswitch.org/browse/MODSKYPIAX-4)
>
> I see you have been planning to release a Live CD for Celliax for some time
> now, and would like to offer my help with this. If you need a resource to
> create a Live CD, please let me know, I would be glad to help.
>
> Thanks
> Gourav
>
> On Fri, Feb 13, 2009 at 11:45 PM, Giovanni Maruzzelli <gmaruzz at celliax.org>
> wrote:
>>
>> Hello FreeSWITCHers,
>>
>> mod_skypiax is available for testing, feature requests, bug hunting.
>>
>> I would like to ask the help of you all to make Skypiax robust and
>> feature full on FreeSWITCH, and particularly of Massimo Cetra (CtRiX
>> on IRC), that has developed mod_airpe (another Skype endpoint).
>>
>> I've written a first documentation on Skypiax installation and usage
>> at: http://wiki.freeswitch.org/wiki/Skypiax
>> and there is a Jira module at:
>> http://jira.freeswitch.org/browse/MODSKYPIAX
>>
>> So, please, test the software, edit the wiki page both for style and
>> content, file bug reports and feature requests.
>>
>> FreeSWITCH is now the platform of first development for me, so the
>> FreeSWITCH part of Skypiax is more tested (if any) and the code is
>> more readable compared to the Asterisk part where lot of legacy from
>> my other projects clutter the code.
>>
>> But Skypiax strive to be available as a Skype compatible endpoint for
>> all the opensource telephony community, and in the near time the
>> Asterisk part will be cleaned much more, and documented.
>>
>> As you will see, the code is made by skypiax_protocol.c (the
>> interaction with Skype client), mod_skypiax.c (the interaction with
>> FreeSWITCH), chan_skypiax.c (the interaction with Asterisk).
>>
>> Please consider me available for all infos, clarifications, discussions,
>> etc.
>>
>> I would like to thanks all the peoples that helped me via mail and IRC
>> (so bad to have different timezones, isn't?), the *very early
>> adopters*, the testers, the patchers, and you all.
>> Particularly Anthony Minessale, Michael Jerris, Brian West, Michael
>> Collins, Ken Rice, Seven Du, Clif Cox, Hristo Trendev, Rehan Allah
>> Wala, Jason Garland and Antonio Gallo.
>>
>> >From the wiki page (http://wiki.freeswitch.org/wiki/Skypiax):
>>
>>  WHAT IS SKYPIAX
>>
>> This software (Skypiax) uses the Skype API but is not endorsed,
>> certified or otherwise approved in any way by Skype.
>>
>> Skypiax is an endpoint (channel driver) that uses the Skype client as
>> an interface to the Skype network, and allows incoming and outgoing
>> Skype calls to/from FreeSWITCH (that can be bridged, originated,
>> answered, etc. as in all other endpoints, e.g. sofia/SIP).
>>
>> Skypiax works in FreeSWITCH (FS) on both Linux and Windows, at both
>> 8khz and 16khz (Skype client has 16khz audio I/O). Skypiax works on
>> Asterisk too, at 8khz, on Linux and Windows (through CygWin).
>>
>> Think of Skypiax as similar to OpenZAP for analog lines. For each
>> channel you need an interface (a Skype client). So, for example, two
>> concurrent calls would need two channels, and therefor two Skype
>> clients running on your FreeSWITCH server.
>>
>> If your Skype client(s) have Skype credits, then Skypiax works for
>> SkypeOut calls as well.
>>
>> Sincerely,
>>
>> Giovanni Maruzzelli
>> =========================================
>> www.celliax.org
>> via Pierlombardo 9, 20135 Milano
>> Italy
>> gmaruzz at celliax dot org
>> Cell : +39-347-2665618
>> Fax : +39-02-87390039
>>
>>
>>
>>
>> On Thu, Jan 15, 2009 at 6:39 PM, Giovanni Maruzzelli
>> <gmaruzz at celliax.org> wrote:
>> > Hi FreeSWITCH developers
>> >
>> > I would like to propose to the community my plans, so we can discuss
>> > and coordinate efforts.
>> >
>> > I developed a couple of channel drivers for Asterisk in the past
>> > (works on both Linux and Windows), and I would like to port them to FS
>> > and further enhance them.
>> >
>> > The two endpoints are:
>> > - Skypiax, Skype compatible, makes and receives calls to/from Skype
>> > network and Skypeout service, using the Skype client as interface.
>> > - Celliax, GSM and SMS endpoint, makes and receives voice calls and
>> > SMSs to/from the GSM/CDMA network, using second hand cellphones and/or
>> > embedded professional devices as interfaces
>> >
>> > My aims are:
>> >
>> > a) port both endpoints from Asterisk to FreeSWITCH
>> > b) have both endpoints continue to support at least Linux and Windows on
>> > FS
>> > c) I would like better having most of the endpoints code working for
>> > both FreeSWITCH and Asterisk, maintaining separated the code that
>> > interface with the GSM and Skype network, from the code that interface
>> > with the core.
>> >
>> > Skypiax, the skype compatible endpoint, is a fork of celliax, the GSM
>> > endpoint, and they share the same skeleton and logic, so porting
>> > celliax after having ported skypiax will be easier and faster :-).
>> >
>> > Current situation and next steps:
>> > 1) skypiax (http://wiki.freeswitch.org/wiki/Skypiax) is now available
>> > for testing and debugging, needs to be polished and cleaned
>> > 2) starting mid next week (I'll be back in office), I want to
>> > integrate into skypiax the code and ideas from mod_airpe of Massimo
>> > (ctrix), that has developed an alternative Skype compatible module,
>> > and coordinate any future development with him and any other
>> > interested developer
>> > 3) begin the porting of celliax to FS, aiming at a pre-beta release
>> > for Linux and Windows during February.
>> > 4) coordinate further development of celliax with any other developer
>> > interested in GSM, SMSs, CDMA, IDEN, AT commands, FBUS commands,
>> > embedded devices, audio sampling
>> >
>> > I am gmaruzz on #freeswitch and #freeswitch-dev, you can find more
>> > info at www.celliax.org.
>> >
>> > Sincerely,
>> >
>> > Giovanni Maruzzelli
>> > =========================================
>> > www.celliax.org
>> > via Pierlombardo 9, 20135 Milano
>> > Italy
>> > gmaruzz at celliax dot org
>> > Cell : +39-347-2665618
>> > Fax : +39-02-87390039
>> >
>>
>> _______________________________________________
>> Freeswitch-users mailing list
>> Freeswitch-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>
>


From ravriel_1 at yahoo.com  Sun Feb 15 06:49:38 2009
From: ravriel_1 at yahoo.com (Ron Avriel)
Date: Sun, 15 Feb 2009 06:49:38 -0800 (PST)
Subject: [Freeswitch-dev] FreeSWITCH Windows Crash due to Detached Threads
	(and solution)
Message-ID: <230264.2936.qm@web45215.mail.sp1.yahoo.com>

Hi,

Under Windows, FreeSWITCH consistently crashes with all default install setting after issuing the ?shutdown? 
command from console immediately after startup, without a single call handled. 
Note that on my servers, this only happens in ?Release? version, not in ?Debug?.

The problem is due to ?problematic? Windows thread handling.
I noticed that all FS threads are ?detachable? and not ?joinable?. When an application with active detached threads terminates, a race condition can lead to the application crash, as shown in the sample application 
at http://pastebin.freeswitch.org/7225 . 

This is exactly what causes FS to crash as a result of the mod_event_socket detached runtime thread.

A temporary workaround is to change in switch_loadable_module_exec() the call to 
switch_yield(1000000) with switch_thread_exit(thread, 0).

In my case it solved the crash, but theoretically it does not always solve the problem, because there is no 
guarantee that it will get called before the main thread reaches its termination code.

I think the only safe solution is to use ?joinable? threads. Is there a good reason they?re not used? 

Note ? this problem was reported to jira about a month ago http://jira.freeswitch.org/browse/MODEVENT-37 but it seems it was ignored.

Thanks,
Ron


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090215/62dee9a4/attachment.html 

From mike at jerris.com  Sun Feb 15 09:27:54 2009
From: mike at jerris.com (Michael Jerris)
Date: Sun, 15 Feb 2009 12:27:54 -0500
Subject: [Freeswitch-dev] FreeSWITCH Windows Crash due to Detached
	Threads (and solution)
In-Reply-To: <230264.2936.qm@web45215.mail.sp1.yahoo.com>
References: <230264.2936.qm@web45215.mail.sp1.yahoo.com>
Message-ID: <2B0BFA11-0D82-4523-8690-D9BE484C8F2A@jerris.com>


On Feb 15, 2009, at 9:49 AM, Ron Avriel wrote:

> Hi,
>
> Under Windows, FreeSWITCH consistently crashes with all default  
> install setting after issuing the ?shutdown?
> command from console immediately after startup, without a single  
> call handled.
> Note that on my servers, this only happens in ?Release? version, not  
> in ?Debug?.
>
> The problem is due to ?problematic? Windows thread handling.
> I noticed that all FS threads are ?detachable? and not ?joinable?.  
> When an application with active detached threads terminates, a race  
> condition can lead to the application crash, as shown in the sample  
> application
> at http://pastebin.freeswitch.org/7225 .
>
> This is exactly what causes FS to crash as a result of the  
> mod_event_socket detached runtime thread.
>
> A temporary workaround is to change in switch_loadable_module_exec()  
> the call to
> switch_yield(1000000) with switch_thread_exit(thread, 0).
>
> In my case it solved the crash, but theoretically it does not always  
> solve the problem, because there is no
> guarantee that it will get called before the main thread reaches its  
> termination code.
>
> I think the only safe solution is to use ?joinable? threads. Is  
> there a good reason they?re not used?
>
> Note ? this problem was reported to jira about a month ago http://jira.freeswitch.org/browse/MODEVENT-37 
>  but it seems it was ignored.
>

The issue has not been ignored, it just has not been resolved yet.   
Please put these details on that bug, I'll take a look.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090215/33694184/attachment.html 

From gmaruzz at celliax.org  Sun Feb 15 09:30:36 2009
From: gmaruzz at celliax.org (Giovanni Maruzzelli)
Date: Sun, 15 Feb 2009 18:30:36 +0100
Subject: [Freeswitch-dev] FreeSWITCH Windows Crash due to Detached
	Threads (and solution)
In-Reply-To: <230264.2936.qm@web45215.mail.sp1.yahoo.com>
References: <230264.2936.qm@web45215.mail.sp1.yahoo.com>
Message-ID: <7b197bef0902150930j3cca034ctc05640160a1e59a0@mail.gmail.com>

Hi Ron,

don't know if it's always like that, but I can confirm I had to use
joinable thread for Skypiax to have a reliable "killability" without
crashes on Windows (on the Debug build, not cheked on Release).

Sincerely,

Giovanni Maruzzelli
=========================================
www.celliax.org
via Pierlombardo 9, 20135 Milano
Italy
gmaruzz at celliax dot org
Cell : +39-347-2665618
Fax : +39-02-87390039




On Sun, Feb 15, 2009 at 3:49 PM, Ron Avriel <ravriel_1 at yahoo.com> wrote:
> Hi,
>
> Under Windows, FreeSWITCH consistently crashes with all default install
> setting after issuing the 'shutdown'
> command from console immediately after startup, without a single call
> handled.
> Note that on my servers, this only happens in 'Release' version, not in
> 'Debug'.
>
> The problem is due to "problematic" Windows thread handling.
> I noticed that all FS threads are 'detachable' and not 'joinable'. When an
> application with active detached threads terminates, a race condition can
> lead to the application crash, as shown in the sample application
> at http://pastebin.freeswitch.org/7225 .
>
> This is exactly what causes FS to crash as a result of the mod_event_socket
> detached runtime thread.
>
> A temporary workaround is to change in switch_loadable_module_exec() the
> call to
> switch_yield(1000000) with switch_thread_exit(thread, 0).
>
> In my case it solved the crash, but theoretically it does not always solve
> the problem, because there is no
> guarantee that it will get called before the main thread reaches its
> termination code.
>
> I think the only safe solution is to use 'joinable' threads. Is there a good
> reason they're not used?
>
> Note ? this problem was reported to jira about a month ago
> http://jira.freeswitch.org/browse/MODEVENT-37 but it seems it was ignored.
>
> Thanks,
> Ron
>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>


From freedomyug at gmail.com  Sun Feb 15 10:29:33 2009
From: freedomyug at gmail.com (Gourav Shah)
Date: Sun, 15 Feb 2009 23:59:33 +0530
Subject: [Freeswitch-dev] [Freeswitch-users] Skypiax (Skype Network
	endpoint) for FreeSWITCH
In-Reply-To: <7b197bef0902150656o7162b90ate1464da614f26cde@mail.gmail.com>
References: <7b197bef0902131015k456dee87x8f0f1b7059f1b49c@mail.gmail.com>
	<60d395660902150545n5ea158bbxc47f0634a6c19c0f@mail.gmail.com>
	<7b197bef0902150656o7162b90ate1464da614f26cde@mail.gmail.com>
Message-ID: <60d395660902151029s4c1b62e8wf56251c534d749f5@mail.gmail.com>

>
>
> The livecd has been neglected until now, and Celliax too, because of
> Skypiax ;-).
> Starting monday I'll begin to port Celliax to FS.

really grateful that skypiax was given  priority though :) its really very
useful.

>
>
> Would be nice to have the livecd with both Celliax and Skypiax, on
> both FS and *.
>
> In the past I used Knoppix as a base for the livecds, maybe today we
> can start from Ubuntu live cd? What do you think?
>
> Certainly. I second on using  Ubuntu live cd platform for this.

here are a few links to the relevant documents
https://help.ubuntu.com/community/InstallCDCustomization
https://help.ubuntu.com/community/LiveCDCustomization
https://help.ubuntu.com/community/LiveCDCustomizationFromScratch


Thanks
Gourav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090215/5ca096db/attachment-0001.html 

From anthony.minessale at gmail.com  Sun Feb 15 17:18:48 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Sun, 15 Feb 2009 19:18:48 -0600
Subject: [Freeswitch-dev] FreeSWITCH Windows Crash due to Detached
	Threads (and solution)
In-Reply-To: <7b197bef0902150930j3cca034ctc05640160a1e59a0@mail.gmail.com>
References: <230264.2936.qm@web45215.mail.sp1.yahoo.com>
	<7b197bef0902150930j3cca034ctc05640160a1e59a0@mail.gmail.com>
Message-ID: <191c3a030902151718k4d1677faid08d1ffb851ca3ad@mail.gmail.com>

Saying that we are ignoring an issue, considering the workload we have, is
not the best way to open a conversation.
If you are willing to work on this issue and volunteer your time and efforts
to get a more long term solution. please contact us.


On Sun, Feb 15, 2009 at 11:30 AM, Giovanni Maruzzelli
<gmaruzz at celliax.org>wrote:

> Hi Ron,
>
> don't know if it's always like that, but I can confirm I had to use
> joinable thread for Skypiax to have a reliable "killability" without
> crashes on Windows (on the Debug build, not cheked on Release).
>
> Sincerely,
>
> Giovanni Maruzzelli
> =========================================
> www.celliax.org
> via Pierlombardo 9, 20135 Milano
> Italy
> gmaruzz at celliax dot org
> Cell : +39-347-2665618
> Fax : +39-02-87390039
>
>
>
>
> On Sun, Feb 15, 2009 at 3:49 PM, Ron Avriel <ravriel_1 at yahoo.com> wrote:
> > Hi,
> >
> > Under Windows, FreeSWITCH consistently crashes with all default install
> > setting after issuing the 'shutdown'
> > command from console immediately after startup, without a single call
> > handled.
> > Note that on my servers, this only happens in 'Release' version, not in
> > 'Debug'.
> >
> > The problem is due to "problematic" Windows thread handling.
> > I noticed that all FS threads are 'detachable' and not 'joinable'. When
> an
> > application with active detached threads terminates, a race condition can
> > lead to the application crash, as shown in the sample application
> > at http://pastebin.freeswitch.org/7225 .
> >
> > This is exactly what causes FS to crash as a result of the
> mod_event_socket
> > detached runtime thread.
> >
> > A temporary workaround is to change in switch_loadable_module_exec() the
> > call to
> > switch_yield(1000000) with switch_thread_exit(thread, 0).
> >
> > In my case it solved the crash, but theoretically it does not always
> solve
> > the problem, because there is no
> > guarantee that it will get called before the main thread reaches its
> > termination code.
> >
> > I think the only safe solution is to use 'joinable' threads. Is there a
> good
> > reason they're not used?
> >
> > Note ? this problem was reported to jira about a month ago
> > http://jira.freeswitch.org/browse/MODEVENT-37 but it seems it was
> ignored.
> >
> > Thanks,
> > Ron
> >
> >
> >
> > _______________________________________________
> > Freeswitch-dev mailing list
> > Freeswitch-dev at 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 at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090215/8165b65a/attachment.html 

From gmaruzz at celliax.org  Mon Feb 16 04:31:19 2009
From: gmaruzz at celliax.org (Giovanni Maruzzelli)
Date: Mon, 16 Feb 2009 13:31:19 +0100
Subject: [Freeswitch-dev] [Freeswitch-users] Skypiax (Skype Network
	endpoint) for FreeSWITCH
In-Reply-To: <60d395660902151029s4c1b62e8wf56251c534d749f5@mail.gmail.com>
References: <7b197bef0902131015k456dee87x8f0f1b7059f1b49c@mail.gmail.com>
	<60d395660902150545n5ea158bbxc47f0634a6c19c0f@mail.gmail.com>
	<7b197bef0902150656o7162b90ate1464da614f26cde@mail.gmail.com>
	<60d395660902151029s4c1b62e8wf56251c534d749f5@mail.gmail.com>
Message-ID: <7b197bef0902160431p519478f9i87deb6b7289e79d5@mail.gmail.com>

Thanks for the links Gourav. We'll give it a shot as soon as the
Celliax port to FS will be over :-)

btw, the "calling 1000" problem with skypiax is fixed:
http://wiki.freeswitch.org/wiki/Skypiax#Dialplan.2C_what_to_add_to_default.xml_for_use_with_Skypiax

Sincerely,

Giovanni Maruzzelli
=========================================
www.celliax.org
via Pierlombardo 9, 20135 Milano
Italy
gmaruzz at celliax dot org
Cell : +39-347-2665618
Fax : +39-02-87390039




On Sun, Feb 15, 2009 at 7:29 PM, Gourav Shah <freedomyug at gmail.com> wrote:
>>
>> The livecd has been neglected until now, and Celliax too, because of
>> Skypiax ;-).
>> Starting monday I'll begin to port Celliax to FS.
>
> really grateful that skypiax was given  priority though :) its really very
> useful.
>>
>>
>> Would be nice to have the livecd with both Celliax and Skypiax, on
>> both FS and *.
>>
>> In the past I used Knoppix as a base for the livecds, maybe today we
>> can start from Ubuntu live cd? What do you think?
>>
> Certainly. I second on using  Ubuntu live cd platform for this.
>
> here are a few links to the relevant documents
> https://help.ubuntu.com/community/InstallCDCustomization
> https://help.ubuntu.com/community/LiveCDCustomization
> https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
>
>
> Thanks
> Gourav
>


From freedomyug at gmail.com  Mon Feb 16 04:52:00 2009
From: freedomyug at gmail.com (Gourav Shah)
Date: Mon, 16 Feb 2009 18:22:00 +0530
Subject: [Freeswitch-dev] [Freeswitch-users] Skypiax (Skype Network
	endpoint) for FreeSWITCH
In-Reply-To: <7b197bef0902160431p519478f9i87deb6b7289e79d5@mail.gmail.com>
References: <7b197bef0902131015k456dee87x8f0f1b7059f1b49c@mail.gmail.com>
	<60d395660902150545n5ea158bbxc47f0634a6c19c0f@mail.gmail.com>
	<7b197bef0902150656o7162b90ate1464da614f26cde@mail.gmail.com>
	<60d395660902151029s4c1b62e8wf56251c534d749f5@mail.gmail.com>
	<7b197bef0902160431p519478f9i87deb6b7289e79d5@mail.gmail.com>
Message-ID: <60d395660902160452g28a6e4c5h58439eb70108532@mail.gmail.com>

On Mon, Feb 16, 2009 at 6:01 PM, Giovanni Maruzzelli <gmaruzz at celliax.org>wrote:

> Thanks for the links Gourav. We'll give it a shot as soon as the
> Celliax port to FS will be over :-)


sure. sounds good to me.

>
>
> btw, the "calling 1000" problem with skypiax is fixed:
>
> http://wiki.freeswitch.org/wiki/Skypiax#Dialplan.2C_what_to_add_to_default.xml_for_use_with_Skypiax


Excellent.I tested it and it just  works.  Thank you.

Gourav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090216/1d2e6cf4/attachment.html 

From gmaruzz at celliax.org  Mon Feb 16 11:41:13 2009
From: gmaruzz at celliax.org (Giovanni Maruzzelli)
Date: Mon, 16 Feb 2009 20:41:13 +0100
Subject: [Freeswitch-dev] [Freeswitch-users] Skypiax (Skype Network
	endpoint) for FreeSWITCH
In-Reply-To: <60d395660902160452g28a6e4c5h58439eb70108532@mail.gmail.com>
References: <7b197bef0902131015k456dee87x8f0f1b7059f1b49c@mail.gmail.com>
	<60d395660902150545n5ea158bbxc47f0634a6c19c0f@mail.gmail.com>
	<7b197bef0902150656o7162b90ate1464da614f26cde@mail.gmail.com>
	<60d395660902151029s4c1b62e8wf56251c534d749f5@mail.gmail.com>
	<7b197bef0902160431p519478f9i87deb6b7289e79d5@mail.gmail.com>
	<60d395660902160452g28a6e4c5h58439eb70108532@mail.gmail.com>
Message-ID: <7b197bef0902161141x77a775e0p7b669fcf7e3f3832@mail.gmail.com>

>> btw, the "calling 1000" problem with skypiax is fixed:
>>
>>http://wiki.freeswitch.org/wiki/Skypiax#Dialplan.2C_what_to_add_to_default.xml_for_use_with_Skypiax

No more needed since now on, for svn rev after 12064 or for upcoming
1.0.3RC2 and following.


From sshen at oa.com.au  Mon Feb 16 15:46:32 2009
From: sshen at oa.com.au (Scott Shen)
Date: Tue, 17 Feb 2009 10:46:32 +1100
Subject: [Freeswitch-dev] Conference Hangup
Message-ID: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>

Is there a way to configure the dialplan so that the FS could terminate the conference session upon certain condition?

The scenario is:

1.      User A dials a number
2.      FS starts a conference session by ringing User B and User C ( and User D or any number of other Users )
3.      User B joins the conference ( along with other invited Users )
4.      After talking a while, User B leaves the conference
5.      At here, could FS be triggered to terminate the conference?


Regards
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090217/7839455d/attachment.html 

From regs at kinetix.gr  Tue Feb 17 02:08:25 2009
From: regs at kinetix.gr (Apostolos Pantsiopoulos)
Date: Tue, 17 Feb 2009 12:08:25 +0200
Subject: [Freeswitch-dev] jira question
Message-ID: <499A8C99.5060406@kinetix.gr>

Hi,

I have just created a second patch for module mod_radius_cdr
which is a better version of my previous patch :

http://jira.freeswitch.org/browse/MODEVENT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

What I would like to know is the procedure that is used
by the maintainers to test (and hopefully approve) the
submitted patches. I cloned MODEVENT-30 because it was
relevant to the issue that I tried to solve. The system
automatically set Chris Parker as the assignee. So, where does
it go from here?

Do I wait for the patch to be reviewed by the assignee or the project 
leader? I am not in any specific hurry about it, I am just wondering how
the procedure goes...


-- 
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs at kinetix.gr
-------------------------------------------


From gmaruzz at celliax.org  Tue Feb 17 02:15:07 2009
From: gmaruzz at celliax.org (Giovanni Maruzzelli)
Date: Tue, 17 Feb 2009 11:15:07 +0100
Subject: [Freeswitch-dev] jira question
In-Reply-To: <499A8C99.5060406@kinetix.gr>
References: <499A8C99.5060406@kinetix.gr>
Message-ID: <7b197bef0902170215s57d11b2dh7e6ef5f8102ffe49@mail.gmail.com>

On Tue, Feb 17, 2009 at 11:08 AM, Apostolos Pantsiopoulos
<regs at kinetix.gr> wrote:

> Do I wait for the patch to be reviewed by the assignee or the project
> leader? I am not in any specific hurry about it, I am just wondering how
> the procedure goes...


Ciao Apostolos,

yes, you do wait, and usually you'll get an answer to the issue you
put in Jira in little time (allowing for the different timezones, and
for the "climaxing" RC release moment).


Sincerely,

Giovanni Maruzzelli
=========================================
www.celliax.org
via Pierlombardo 9, 20135 Milano
Italy
gmaruzz at celliax dot org
Cell : +39-347-2665618
Fax : +39-02-87390039


From jkr888 at gmail.com  Tue Feb 17 15:25:09 2009
From: jkr888 at gmail.com (Johny Kadarisman)
Date: Tue, 17 Feb 2009 18:25:09 -0500
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
References: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
Message-ID: <b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>

The question is why user B? how do you determine which user that that
leave that need to trigger conference termination.

FS is very flexible, It definitely can support your scenario. It may
not be from dialplan alone, You might want to take a look at
event_socket module for advance conference control.

On Mon, Feb 16, 2009 at 6:46 PM, Scott Shen <sshen at oa.com.au> wrote:
> Is there a way to configure the dialplan so that the FS could terminate the
> conference session upon certain condition?
>
>
>
> The scenario is:
>
>
>
> User A dials a number
> FS starts a conference session by ringing User B and User C ( and User D or
> any number of other Users )
> User B joins the conference ( along with other invited Users )
> After talking a while, User B leaves the conference
> At here, could FS be triggered to terminate the conference?
>
>
>
>
>
> Regards
>
> Scott
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>


From brian at freeswitch.org  Tue Feb 17 15:29:37 2009
From: brian at freeswitch.org (Brian West)
Date: Tue, 17 Feb 2009 17:29:37 -0600
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>
References: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
	<b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>
Message-ID: <5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>

You make sure you push the user into the conference with the endconf  
flag.  ie 1234 at default+flags{endconf}

/b

On Feb 17, 2009, at 5:25 PM, Johny Kadarisman wrote:

> The question is why user B? how do you determine which user that that
> leave that need to trigger conference termination.
>
> FS is very flexible, It definitely can support your scenario. It may
> not be from dialplan alone, You might want to take a look at
> event_socket module for advance conference control.



From msc at freeswitch.org  Tue Feb 17 15:38:09 2009
From: msc at freeswitch.org (Michael Collins)
Date: Tue, 17 Feb 2009 15:38:09 -0800
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
References: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
	<b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>
	<5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
Message-ID: <87f2f3b90902171538v3df7f68am68f3b77f82058f00@mail.gmail.com>

> You make sure you push the user into the conference with the endconf
> flag.  ie 1234 at default+flags{endconf}
>
> /b

FYI, it looks like many of the conference flags are missing from the
wiki. I will update the mod_conference page and make sure that all of
the flags are properly documented.

-MC


From jkr888 at gmail.com  Tue Feb 17 15:52:35 2009
From: jkr888 at gmail.com (Johny Kadarisman)
Date: Tue, 17 Feb 2009 18:52:35 -0500
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <87f2f3b90902171538v3df7f68am68f3b77f82058f00@mail.gmail.com>
References: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
	<b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>
	<5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
	<87f2f3b90902171538v3df7f68am68f3b77f82058f00@mail.gmail.com>
Message-ID: <b0a271780902171552g52f1cb5dwf75c1d48c05c0c2f@mail.gmail.com>

There you go, something to learn everytime i read a new post.
I feel event_socket kind of old fashion, now seems like tons of
dialplan flags that will do some magic trick :)

On Tue, Feb 17, 2009 at 6:38 PM, Michael Collins <msc at freeswitch.org> wrote:
>> You make sure you push the user into the conference with the endconf
>> flag.  ie 1234 at default+flags{endconf}
>>
>> /b
>
> FYI, it looks like many of the conference flags are missing from the
> wiki. I will update the mod_conference page and make sure that all of
> the flags are properly documented.
>
> -MC
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>


From msc at freeswitch.org  Tue Feb 17 16:09:15 2009
From: msc at freeswitch.org (Michael Collins)
Date: Tue, 17 Feb 2009 16:09:15 -0800
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <b0a271780902171552g52f1cb5dwf75c1d48c05c0c2f@mail.gmail.com>
References: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
	<b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>
	<5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
	<87f2f3b90902171538v3df7f68am68f3b77f82058f00@mail.gmail.com>
	<b0a271780902171552g52f1cb5dwf75c1d48c05c0c2f@mail.gmail.com>
Message-ID: <87f2f3b90902171609y2c37a0d6n6cb80a3e9dbea0d7@mail.gmail.com>

On Tue, Feb 17, 2009 at 3:52 PM, Johny Kadarisman <jkr888 at gmail.com> wrote:
> There you go, something to learn everytime i read a new post.
> I feel event_socket kind of old fashion, now seems like tons of
> dialplan flags that will do some magic trick :)

FYI, I am working on the documentation for all of this. I will keep
updating things as I learn them also. This item wasn't anywhere on the
wiki. I will have it and the rest of the member flags documented
shortly.

-MC


From sshen at oa.com.au  Tue Feb 17 16:36:33 2009
From: sshen at oa.com.au (Scott Shen)
Date: Wed, 18 Feb 2009 11:36:33 +1100
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
Message-ID: <4462DF002246D44CB823FA4F985539940D21951D2B@oa-exchange1.oa.com.au>

Can this flag be used in a group_call? How? If yes, is it means anyone in the group who joined the conference will be able to terminate the conference upon leaving?



-----Original Message-----
From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Brian West
Sent: Wednesday, 18 February 2009 10:30 AM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Conference Hangup

You make sure you push the user into the conference with the endconf
flag.  ie 1234 at default+flags{endconf}

/b

On Feb 17, 2009, at 5:25 PM, Johny Kadarisman wrote:

> The question is why user B? how do you determine which user that that
> leave that need to trigger conference termination.
>
> FS is very flexible, It definitely can support your scenario. It may
> not be from dialplan alone, You might want to take a look at
> event_socket module for advance conference control.


_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org


From jkr888 at gmail.com  Tue Feb 17 16:53:18 2009
From: jkr888 at gmail.com (Johny Kadarisman)
Date: Tue, 17 Feb 2009 19:53:18 -0500
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <4462DF002246D44CB823FA4F985539940D21951D2B@oa-exchange1.oa.com.au>
References: <5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
	<4462DF002246D44CB823FA4F985539940D21951D2B@oa-exchange1.oa.com.au>
Message-ID: <b0a271780902171653u2353413do9d3eb2b6fa43ece4@mail.gmail.com>

If everyone trigger the termination, then I think it should even
easier to accomplish. When you put the new participant into
conference, per Brian recommendation, just initiate conference with
that flags. ie.  "3000 at default+flags{endconf}"

On Tue, Feb 17, 2009 at 7:36 PM, Scott Shen <sshen at oa.com.au> wrote:
> Can this flag be used in a group_call? How? If yes, is it means anyone in the group who joined the conference will be able to terminate the conference upon leaving?
>
>
>
> -----Original Message-----
> From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Brian West
> Sent: Wednesday, 18 February 2009 10:30 AM
> To: freeswitch-dev at lists.freeswitch.org
> Subject: Re: [Freeswitch-dev] Conference Hangup
>
> You make sure you push the user into the conference with the endconf
> flag.  ie 1234 at default+flags{endconf}
>
> /b
>
> On Feb 17, 2009, at 5:25 PM, Johny Kadarisman wrote:
>
>> The question is why user B? how do you determine which user that that
>> leave that need to trigger conference termination.
>>
>> FS is very flexible, It definitely can support your scenario. It may
>> not be from dialplan alone, You might want to take a look at
>> event_socket module for advance conference control.
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>


From jkr888 at gmail.com  Tue Feb 17 17:12:10 2009
From: jkr888 at gmail.com (Johny Kadarisman)
Date: Tue, 17 Feb 2009 20:12:10 -0500
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <87f2f3b90902171609y2c37a0d6n6cb80a3e9dbea0d7@mail.gmail.com>
References: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
	<b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>
	<5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
	<87f2f3b90902171538v3df7f68am68f3b77f82058f00@mail.gmail.com>
	<b0a271780902171552g52f1cb5dwf75c1d48c05c0c2f@mail.gmail.com>
	<87f2f3b90902171609y2c37a0d6n6cb80a3e9dbea0d7@mail.gmail.com>
Message-ID: <b0a271780902171712if9c0b0bk34620c99d454938@mail.gmail.com>

Thanks MC, i dont meant to complain, just saying that FS evolve so
quickly, that none of us (pointing to me) can keep up with all the
nice trick with dialplan flags/var. Should we have some central
location in wiki to track this? or even better, maybe we should do
something at code level that automatically track this kind of flags.
Something like a core api to registers the flags + some description.
Then, we can issus something like "show flags" or similar. This at
least show us what kind of flags that available in the system.


On Tue, Feb 17, 2009 at 7:09 PM, Michael Collins <msc at freeswitch.org> wrote:
> On Tue, Feb 17, 2009 at 3:52 PM, Johny Kadarisman <jkr888 at gmail.com> wrote:
>> There you go, something to learn everytime i read a new post.
>> I feel event_socket kind of old fashion, now seems like tons of
>> dialplan flags that will do some magic trick :)
>
> FYI, I am working on the documentation for all of this. I will keep
> updating things as I learn them also. This item wasn't anywhere on the
> wiki. I will have it and the rest of the member flags documented
> shortly.
>
> -MC
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>


From msc at freeswitch.org  Tue Feb 17 17:26:38 2009
From: msc at freeswitch.org (Michael Collins)
Date: Tue, 17 Feb 2009 17:26:38 -0800
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <b0a271780902171712if9c0b0bk34620c99d454938@mail.gmail.com>
References: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
	<b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>
	<5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
	<87f2f3b90902171538v3df7f68am68f3b77f82058f00@mail.gmail.com>
	<b0a271780902171552g52f1cb5dwf75c1d48c05c0c2f@mail.gmail.com>
	<87f2f3b90902171609y2c37a0d6n6cb80a3e9dbea0d7@mail.gmail.com>
	<b0a271780902171712if9c0b0bk34620c99d454938@mail.gmail.com>
Message-ID: <87f2f3b90902171726n69535901kbafb6a962579cac4@mail.gmail.com>

On Tue, Feb 17, 2009 at 5:12 PM, Johny Kadarisman <jkr888 at gmail.com> wrote:
> Thanks MC, i dont meant to complain, just saying that FS evolve so
> quickly, that none of us (pointing to me) can keep up with all the
> nice trick with dialplan flags/var.
Yeah, now try to document all that stuff! ;) It's okay, everyone knows
that Tony and company can write software much faster than we can
document it.

> Should we have some central
> location in wiki to track this? or even better, maybe we should do
> something at code level that automatically track this kind of flags.
> Something like a core api to registers the flags + some description.

There is merit to this idea. I would be willing to discuss it further.
Please contact me off list if you have ideas. It's something that I've
been wanting to do for a while.

-MC

> Then, we can issus something like "show flags" or similar. This at
> least show us what kind of flags that available in the system.


From brian at freeswitch.org  Tue Feb 17 17:27:29 2009
From: brian at freeswitch.org (Brian West)
Date: Tue, 17 Feb 2009 19:27:29 -0600
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <b0a271780902171712if9c0b0bk34620c99d454938@mail.gmail.com>
References: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
	<b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>
	<5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
	<87f2f3b90902171538v3df7f68am68f3b77f82058f00@mail.gmail.com>
	<b0a271780902171552g52f1cb5dwf75c1d48c05c0c2f@mail.gmail.com>
	<87f2f3b90902171609y2c37a0d6n6cb80a3e9dbea0d7@mail.gmail.com>
	<b0a271780902171712if9c0b0bk34620c99d454938@mail.gmail.com>
Message-ID: <E43010BA-64E4-418C-BAA7-098FCFE22B5C@freeswitch.org>

How about we bring back our weekly meetings and start writing docs in  
a more collaborative method?

/b

On Feb 17, 2009, at 7:12 PM, Johny Kadarisman wrote:

> Thanks MC, i dont meant to complain, just saying that FS evolve so
> quickly, that none of us (pointing to me) can keep up with all the
> nice trick with dialplan flags/var. Should we have some central
> location in wiki to track this? or even better, maybe we should do
> something at code level that automatically track this kind of flags.
> Something like a core api to registers the flags + some description.
> Then, we can issus something like "show flags" or similar. This at
> least show us what kind of flags that available in the system.



From msc at freeswitch.org  Tue Feb 17 17:29:58 2009
From: msc at freeswitch.org (Michael Collins)
Date: Tue, 17 Feb 2009 17:29:58 -0800
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <E43010BA-64E4-418C-BAA7-098FCFE22B5C@freeswitch.org>
References: <4462DF002246D44CB823FA4F985539940D0FB868A4@oa-exchange1.oa.com.au>
	<b0a271780902171525p4c4cd688qd3c54d9c2b2c74a3@mail.gmail.com>
	<5018FBE2-6B83-498F-B3C3-42B99AE6445D@freeswitch.org>
	<87f2f3b90902171538v3df7f68am68f3b77f82058f00@mail.gmail.com>
	<b0a271780902171552g52f1cb5dwf75c1d48c05c0c2f@mail.gmail.com>
	<87f2f3b90902171609y2c37a0d6n6cb80a3e9dbea0d7@mail.gmail.com>
	<b0a271780902171712if9c0b0bk34620c99d454938@mail.gmail.com>
	<E43010BA-64E4-418C-BAA7-098FCFE22B5C@freeswitch.org>
Message-ID: <87f2f3b90902171729gd60782bhbbbec73cb91d8d7d@mail.gmail.com>

On Tue, Feb 17, 2009 at 5:27 PM, Brian West <brian at freeswitch.org> wrote:
> How about we bring back our weekly meetings and start writing docs in
> a more collaborative method?
>
> /b
Count me in. :)
-MC


From sshen at oa.com.au  Tue Feb 17 21:07:21 2009
From: sshen at oa.com.au (Scott Shen)
Date: Wed, 18 Feb 2009 16:07:21 +1100
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <b0a271780902171653u2353413do9d3eb2b6fa43ece4@mail.gmail.com>
Message-ID: <4462DF002246D44CB823FA4F985539940D21951D33@oa-exchange1.oa.com.au>

Thanks for the quick response, however, I meant "group call", something like

<action application="conference_set_auto_outcall" data="${group_call(sales)}"/>

could I do something like

<action application="conference_set_auto_outcall" data="${group_call(sales)}+flag(endconf)"/>

In this case, I would assume anyone in the group could terminate the conference upon leaving, is that right?




-----Original Message-----
From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Johny Kadarisman
Sent: Wednesday, 18 February 2009 11:53 AM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Conference Hangup

If everyone trigger the termination, then I think it should even
easier to accomplish. When you put the new participant into
conference, per Brian recommendation, just initiate conference with
that flags. ie.  "3000 at default+flags{endconf}"

On Tue, Feb 17, 2009 at 7:36 PM, Scott Shen <sshen at oa.com.au> wrote:
> Can this flag be used in a group_call? How? If yes, is it means anyone in the group who joined the conference will be able to terminate the conference upon leaving?
>
>
>
> -----Original Message-----
> From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Brian West
> Sent: Wednesday, 18 February 2009 10:30 AM
> To: freeswitch-dev at lists.freeswitch.org
> Subject: Re: [Freeswitch-dev] Conference Hangup
>
> You make sure you push the user into the conference with the endconf
> flag.  ie 1234 at default+flags{endconf}
>
> /b
>
> On Feb 17, 2009, at 5:25 PM, Johny Kadarisman wrote:
>
>> The question is why user B? how do you determine which user that that
>> leave that need to trigger conference termination.
>>
>> FS is very flexible, It definitely can support your scenario. It may
>> not be from dialplan alone, You might want to take a look at
>> event_socket module for advance conference control.
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at 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 at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org


From msc at freeswitch.org  Tue Feb 17 22:25:51 2009
From: msc at freeswitch.org (Michael S Collins)
Date: Tue, 17 Feb 2009 22:25:51 -0800
Subject: [Freeswitch-dev] Conference Hangup
Message-ID: <CC786AE1-7F6D-44AB-835C-279C6821D99B@freeswitch.org>


On Feb 17, 2009, at 9:07 PM, Scott Shen <sshen at oa.com.au> wrote:

> Thanks for the quick response, however, I meant "group call",  
> something like
>
> <action application="conference_set_auto_outcall" data="$ 
> {group_call(sales)}"/>
>
> could I do something like
>
> <action application="conference_set_auto_outcall" data="$ 
> {group_call(sales)}+flag(endconf)"/>
>
> In this case, I would assume anyone in the group could terminate the  
> conference upon leaving, is that right?

IIRC, group_call connects to a single endpoint. That is, it dials a  
group but whoever answers "wins" and the other phones stop ringing. Is  
that what you are thinking?

-MC
>>
>>
>>
>>
>>
>>
>>>
>>
>>
>>
>>



From sshen at oa.com.au  Tue Feb 17 22:52:01 2009
From: sshen at oa.com.au (Scott Shen)
Date: Wed, 18 Feb 2009 17:52:01 +1100
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <CC786AE1-7F6D-44AB-835C-279C6821D99B@freeswitch.org>
Message-ID: <4462DF002246D44CB823FA4F985539940D21951D36@oa-exchange1.oa.com.au>

No. I would expect FS to accept any number of endpoints defined in that group, and any of those endpoints leaves the conference will terminate the conference.


-----Original Message-----
From: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Michael S Collins
Sent: Wednesday, 18 February 2009 5:26 PM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Conference Hangup


On Feb 17, 2009, at 9:07 PM, Scott Shen <sshen at oa.com.au> wrote:

> Thanks for the quick response, however, I meant "group call",
> something like
>
> <action application="conference_set_auto_outcall" data="$
> {group_call(sales)}"/>
>
> could I do something like
>
> <action application="conference_set_auto_outcall" data="$
> {group_call(sales)}+flag(endconf)"/>
>
> In this case, I would assume anyone in the group could terminate the
> conference upon leaving, is that right?

IIRC, group_call connects to a single endpoint. That is, it dials a
group but whoever answers "wins" and the other phones stop ringing. Is
that what you are thinking?

-MC
>>
>>
>>
>>
>>
>>
>>>
>>
>>
>>
>>


_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org


From msc at freeswitch.org  Tue Feb 17 23:39:17 2009
From: msc at freeswitch.org (Michael Collins)
Date: Tue, 17 Feb 2009 23:39:17 -0800
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <4462DF002246D44CB823FA4F985539940D21951D36@oa-exchange1.oa.com.au>
References: <CC786AE1-7F6D-44AB-835C-279C6821D99B@freeswitch.org>
	<4462DF002246D44CB823FA4F985539940D21951D36@oa-exchange1.oa.com.au>
Message-ID: <87f2f3b90902172339v3af1dd23s6bc4a50da0a0b463@mail.gmail.com>

On Tue, Feb 17, 2009 at 10:52 PM, Scott Shen <sshen at oa.com.au> wrote:
> No. I would expect FS to accept any number of endpoints defined in that group, and any of those endpoints leaves the conference will terminate the conference.

In other words, whichever endpoint "won" the call would be put into
the conference with the "endconf" flag set?
-MC


From brian at freeswitch.org  Wed Feb 18 01:04:11 2009
From: brian at freeswitch.org (Brian West)
Date: Wed, 18 Feb 2009 03:04:11 -0600
Subject: [Freeswitch-dev] Conference Hangup
In-Reply-To: <87f2f3b90902172339v3af1dd23s6bc4a50da0a0b463@mail.gmail.com>
References: <CC786AE1-7F6D-44AB-835C-279C6821D99B@freeswitch.org>
	<4462DF002246D44CB823FA4F985539940D21951D36@oa-exchange1.oa.com.au>
	<87f2f3b90902172339v3af1dd23s6bc4a50da0a0b463@mail.gmail.com>
Message-ID: <8AB1A399-3849-4A6D-849A-B06C27570D08@freeswitch.org>

Actually check the mad boss extension examples in the default  
config... it does this and all parties win and the one that enters  
first ie the boss gets the endconf flag

/b

On Feb 18, 2009, at 1:39 AM, Michael Collins wrote:

>
> In other words, whichever endpoint "won" the call would be put into
> the conference with the "endconf" flag set?
> -MC



From sergio.alecha at gmail.com  Tue Feb 24 08:38:47 2009
From: sergio.alecha at gmail.com (Sergio Alecha)
Date: Tue, 24 Feb 2009 13:38:47 -0300
Subject: [Freeswitch-dev] can't set caller id opal/h323
Message-ID: <47f9a0940902240838r6c77086bi775363f4db952c15@mail.gmail.com>

they can set caller id in module mod_opal (opal/h323) ?. If possible, as is
done?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090224/630933e5/attachment.html 

From brian at freeswitch.org  Tue Feb 24 08:47:48 2009
From: brian at freeswitch.org (Brian West)
Date: Tue, 24 Feb 2009 10:47:48 -0600
Subject: [Freeswitch-dev] can't set caller id opal/h323
In-Reply-To: <47f9a0940902240838r6c77086bi775363f4db952c15@mail.gmail.com>
References: <47f9a0940902240838r6c77086bi775363f4db952c15@mail.gmail.com>
Message-ID: <5D239F29-38B4-44D2-9707-4F9B5A76872E@freeswitch.org>

Yes, this is a known feature request.

/b

On Feb 24, 2009, at 10:38 AM, Sergio Alecha wrote:

> they can set caller id in module mod_opal (opal/h323) ?. If  
> possible, as is done?
>
> Thanks.
> ___________



From javieraristizabal at gmail.com  Tue Feb 24 09:36:16 2009
From: javieraristizabal at gmail.com (=?ISO-8859-1?Q?Javier_Aristiz=E1bal?=)
Date: Tue, 24 Feb 2009 12:36:16 -0500
Subject: [Freeswitch-dev] can't set caller id opal/h323
In-Reply-To: <5D239F29-38B4-44D2-9707-4F9B5A76872E@freeswitch.org>
References: <47f9a0940902240838r6c77086bi775363f4db952c15@mail.gmail.com>
	<5D239F29-38B4-44D2-9707-4F9B5A76872E@freeswitch.org>
Message-ID: <b6f11f300902240936x3981d3fcg5126ed9b63fa98f0@mail.gmail.com>

I compiled mod_opal without problems. And i did the change suggested on the
wiki about the delay. I testing h323 calls: exten ? FS (mod_opal) ? GW
(support h323) ? PSTN.
But i have echo & delay from the exten and from the PSTN only delay.

Any idea what can i do it?


Thanks in advance

-javar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090224/40a3a824/attachment.html 

From seven at idapted.com  Wed Feb 25 07:06:49 2009
From: seven at idapted.com (seven du)
Date: Wed, 25 Feb 2009 23:06:49 +0800
Subject: [Freeswitch-dev] What's the easiest way to get all the SIP messages
	in FS?
Message-ID: <BBEBF4B2-D732-47EC-A9B4-E5DDB429CCA2@idapted.com>

Hi,

I want to get all(or certain) SIP messages in FS(perhaps I want to  
write a module), What's the easiest or best way to get that? or where  
I can find it in code?

I know we can see SIP messages with TPORT_LOG enabled, It's in  
mod_sofia or sofia-lib?  Why it is only possible to set that on start  
time but can't change it lively?

If I can get them, I think it's possible to write to a file/db, or  
even send out from event_socket. I know it will hurt performance, but  
we don't do high volume calls and want to debug easily. Third party  
tools maybe work but also hurt performance right?

Thanks.

Seven




From anthony.minessale at gmail.com  Wed Feb 25 07:32:39 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Wed, 25 Feb 2009 09:32:39 -0600
Subject: [Freeswitch-dev] What's the easiest way to get all the SIP
	messages in FS?
In-Reply-To: <BBEBF4B2-D732-47EC-A9B4-E5DDB429CCA2@idapted.com>
References: <BBEBF4B2-D732-47EC-A9B4-E5DDB429CCA2@idapted.com>
Message-ID: <191c3a030902250732l433a1d1al7743560c4fab6d30@mail.gmail.com>

try tcpdump or tshark


On Wed, Feb 25, 2009 at 9:06 AM, seven du <seven at idapted.com> wrote:

> Hi,
>
> I want to get all(or certain) SIP messages in FS(perhaps I want to
> write a module), What's the easiest or best way to get that? or where
> I can find it in code?
>
> I know we can see SIP messages with TPORT_LOG enabled, It's in
> mod_sofia or sofia-lib?  Why it is only possible to set that on start
> time but can't change it lively?
>
> If I can get them, I think it's possible to write to a file/db, or
> even send out from event_socket. I know it will hurt performance, but
> we don't do high volume calls and want to debug easily. Third party
> tools maybe work but also hurt performance right?
>
> Thanks.
>
> Seven
>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090225/4a0ae22b/attachment-0001.html 

From kristian.kielhofner at gmail.com  Wed Feb 25 07:51:22 2009
From: kristian.kielhofner at gmail.com (Kristian Kielhofner)
Date: Wed, 25 Feb 2009 10:51:22 -0500
Subject: [Freeswitch-dev] What's the easiest way to get all the SIP
	messages in FS?
In-Reply-To: <191c3a030902250732l433a1d1al7743560c4fab6d30@mail.gmail.com>
References: <BBEBF4B2-D732-47EC-A9B4-E5DDB429CCA2@idapted.com>
	<191c3a030902250732l433a1d1al7743560c4fab6d30@mail.gmail.com>
Message-ID: <2d9149cd0902250751m3863fd4fv4b505bf57b9e4899@mail.gmail.com>

Or ngrep...

The nice things about such tools is that you can use them to monitor
several systems (if you have setup a port mirror/SPAN) from a separate
host without even potentially impacting anything on the FS hosts -
it's just passive monitoring anyway...

On Wed, Feb 25, 2009 at 10:32 AM, Anthony Minessale
<anthony.minessale at gmail.com> wrote:
> try tcpdump or tshark
>
>
> On Wed, Feb 25, 2009 at 9:06 AM, seven du <seven at idapted.com> wrote:
>>
>> Hi,
>>
>> I want to get all(or certain) SIP messages in FS(perhaps I want to
>> write a module), What's the easiest or best way to get that? or where
>> I can find it in code?
>>
>> I know we can see SIP messages with TPORT_LOG enabled, It's in
>> mod_sofia or sofia-lib? ?Why it is only possible to set that on start
>> time but can't change it lively?
>>
>> If I can get them, I think it's possible to write to a file/db, or
>> even send out from event_socket. I know it will hurt performance, but
>> we don't do high volume calls and want to debug easily. Third party
>> tools maybe work but also hurt performance right?
>>
>> Thanks.
>>
>> Seven
>>
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org
> pstn:213-799-1400
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>



-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com


From seven at idapted.com  Wed Feb 25 08:03:28 2009
From: seven at idapted.com (seven du)
Date: Thu, 26 Feb 2009 00:03:28 +0800
Subject: [Freeswitch-dev] What's the easiest way to get all the SIP
	messages in FS?
In-Reply-To: <191c3a030902250732l433a1d1al7743560c4fab6d30@mail.gmail.com>
References: <BBEBF4B2-D732-47EC-A9B4-E5DDB429CCA2@idapted.com>
	<191c3a030902250732l433a1d1al7743560c4fab6d30@mail.gmail.com>
Message-ID: <6BFD25CE-AE33-402D-8C84-4A781F903368@idapted.com>

Thank you Anthony. I'm using them. But I'm not debugging the current  
calls but want to check them later, if necessary. Like this:

post XML cdr to a web interface, store in db, and every time I list  
cdrs on web and click "View all related SIP" will list all the related  
sip messages on that cdr record.

I know wireshark even can display a graph, but hard to do that  
automatically and,  Even I can capture all the packets through tshark,  
I still need to parse all the SIP messages from a pcap file and  
perhaps store them into a database. So I think it maybe easy to  
implement something in FS like "record-sip-session" and record all the  
SIP messages related to a session. I'm not sure whether that works.


On Feb 25, 2009, at 11:32 PM, Anthony Minessale wrote:

> try tcpdump or tshark
>
>
> On Wed, Feb 25, 2009 at 9:06 AM, seven du <seven at idapted.com> wrote:
> Hi,
>
> I want to get all(or certain) SIP messages in FS(perhaps I want to
> write a module), What's the easiest or best way to get that? or where
> I can find it in code?
>
> I know we can see SIP messages with TPORT_LOG enabled, It's in
> mod_sofia or sofia-lib?  Why it is only possible to set that on start
> time but can't change it lively?
>
> If I can get them, I think it's possible to write to a file/db, or
> even send out from event_socket. I know it will hurt performance, but
> we don't do high volume calls and want to debug easily. Third party
> tools maybe work but also hurt performance right?
>
> Thanks.
>
> Seven
>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org
> pstn:213-799-1400
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090226/58d4edc1/attachment.html 

From anthony.minessale at gmail.com  Wed Feb 25 08:44:09 2009
From: anthony.minessale at gmail.com (Anthony Minessale)
Date: Wed, 25 Feb 2009 10:44:09 -0600
Subject: [Freeswitch-dev] What's the easiest way to get all the SIP
	messages in FS?
In-Reply-To: <6BFD25CE-AE33-402D-8C84-4A781F903368@idapted.com>
References: <BBEBF4B2-D732-47EC-A9B4-E5DDB429CCA2@idapted.com>
	<191c3a030902250732l433a1d1al7743560c4fab6d30@mail.gmail.com>
	<6BFD25CE-AE33-402D-8C84-4A781F903368@idapted.com>
Message-ID: <191c3a030902250844u1e4527feh93bb567e2352790b@mail.gmail.com>

there are 2 options you can enable in your sofia profile.

<param name="inbound-use-callid-as-uuid" value="true"/>
<param name="outbound-use-uuid-as-callid" value="true"/>

This will use the FS uuid of the call leg as the call-id in the sip dialogs
AND use the call-id from inbound sip calls as the uuid in FS.

This way the uuid of the channel from the cdr and the call-id in sip are
identical and you can cross reference them.

There is also a program called sippcapdump out there that puts each sip call
in it's own dedicated pcap file you may want to consider.

Doing what you want in FS is not going to happen in the near future as it's
a function of the sofia-sip lib that we are a partener project with and they
would have to make changes to their api to allow us to get the data.  What
you see in TPORT_LOG is being generated well before FS ever gets the data.




On Wed, Feb 25, 2009 at 10:03 AM, seven du <seven at idapted.com> wrote:

> Thank you Anthony. I'm using them. But I'm not debugging the current calls
> but want to check them later, if necessary. Like this:
> post XML cdr to a web interface, store in db, and every time I list cdrs on
> web and click "View all related SIP" will list all the related sip messages
> on that cdr record.
>
> I know wireshark even can display a graph, but hard to do that
> automatically and,  Even I can capture all the packets through tshark, I
> still need to parse all the SIP messages from a pcap file and perhaps store
> them into a database. So I think it maybe easy to implement something in FS
> like "record-sip-session" and record all the SIP messages related to a
> session. I'm not sure whether that works.
>
>
> On Feb 25, 2009, at 11:32 PM, Anthony Minessale wrote:
>
> try tcpdump or tshark
>
>
> On Wed, Feb 25, 2009 at 9:06 AM, seven du <seven at idapted.com> wrote:
>
>> Hi,
>>
>> I want to get all(or certain) SIP messages in FS(perhaps I want to
>> write a module), What's the easiest or best way to get that? or where
>> I can find it in code?
>>
>> I know we can see SIP messages with TPORT_LOG enabled, It's in
>> mod_sofia or sofia-lib?  Why it is only possible to set that on start
>> time but can't change it lively?
>>
>> If I can get them, I think it's possible to write to a file/db, or
>> even send out from event_socket. I know it will hurt performance, but
>> we don't do high volume calls and want to debug easily. Third party
>> tools maybe work but also hurt performance right?
>>
>> Thanks.
>>
>> Seven
>>
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at 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 at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090225/960f7b94/attachment.html 

From seven at idapted.com  Wed Feb 25 20:07:17 2009
From: seven at idapted.com (seven)
Date: Thu, 26 Feb 2009 12:07:17 +0800
Subject: [Freeswitch-dev] What's the easiest way to get all the SIP
	messages in FS?
In-Reply-To: <191c3a030902250844u1e4527feh93bb567e2352790b@mail.gmail.com>
References: <BBEBF4B2-D732-47EC-A9B4-E5DDB429CCA2@idapted.com>
	<191c3a030902250732l433a1d1al7743560c4fab6d30@mail.gmail.com>
	<6BFD25CE-AE33-402D-8C84-4A781F903368@idapted.com>
	<191c3a030902250844u1e4527feh93bb567e2352790b@mail.gmail.com>
Message-ID: <4B156960-47DF-4906-8C5E-D2B0A5F0B1FC@idapted.com>

Thanks, the two params helps a  lot.


On Feb 26, 2009, at 12:44 AM, Anthony Minessale wrote:

> there are 2 options you can enable in your sofia profile.
>
> <param name="inbound-use-callid-as-uuid" value="true"/>
> <param name="outbound-use-uuid-as-callid" value="true"/>
>
> This will use the FS uuid of the call leg as the call-id in the sip  
> dialogs AND use the call-id from inbound sip calls as the uuid in FS.
>
> This way the uuid of the channel from the cdr and the call-id in sip  
> are identical and you can cross reference them.
>
> There is also a program called sippcapdump out there that puts each  
> sip call in it's own dedicated pcap file you may want to consider.
>
> Doing what you want in FS is not going to happen in the near future  
> as it's a function of the sofia-sip lib that we are a partener  
> project with and they would have to make changes to their api to  
> allow us to get the data.  What you see in TPORT_LOG is being  
> generated well before FS ever gets the data.
>
>
>
>
> On Wed, Feb 25, 2009 at 10:03 AM, seven du <seven at idapted.com> wrote:
> Thank you Anthony. I'm using them. But I'm not debugging the current  
> calls but want to check them later, if necessary. Like this:
>
> post XML cdr to a web interface, store in db, and every time I list  
> cdrs on web and click "View all related SIP" will list all the  
> related sip messages on that cdr record.
>
> I know wireshark even can display a graph, but hard to do that  
> automatically and,  Even I can capture all the packets through  
> tshark, I still need to parse all the SIP messages from a pcap file  
> and perhaps store them into a database. So I think it maybe easy to  
> implement something in FS like "record-sip-session" and record all  
> the SIP messages related to a session. I'm not sure whether that  
> works.
>
>
> On Feb 25, 2009, at 11:32 PM, Anthony Minessale wrote:
>> try tcpdump or tshark
>>
>>
>> On Wed, Feb 25, 2009 at 9:06 AM, seven du <seven at idapted.com> wrote:
>> Hi,
>>
>> I want to get all(or certain) SIP messages in FS(perhaps I want to
>> write a module), What's the easiest or best way to get that? or where
>> I can find it in code?
>>
>> I know we can see SIP messages with TPORT_LOG enabled, It's in
>> mod_sofia or sofia-lib?  Why it is only possible to set that on start
>> time but can't change it lively?
>>
>> If I can get them, I think it's possible to write to a file/db, or
>> even send out from event_socket. I know it will hurt performance, but
>> we don't do high volume calls and want to debug easily. Third party
>> tools maybe work but also hurt performance right?
>>
>> Thanks.
>>
>> Seven
>>
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> iax:guest at conference.freeswitch.org/888
>> googletalk:conf+888 at conference.freeswitch.org
>> pstn:213-799-1400
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at 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 at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org
> pstn:213-799-1400
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090226/d6f2cfaa/attachment-0001.html 

From seven at idapted.com  Thu Feb 26 19:12:00 2009
From: seven at idapted.com (seven)
Date: Fri, 27 Feb 2009 11:12:00 +0800
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
Message-ID: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>

Hi,

The recent version of FS( I think I  had notice that also on 1.0.1  
stable version) seems sends out an INVITE msg every minute when I  
originate a call from a SIPUA(say X-Lite), then the SIPUA will respond  
200 OK with SDP msg. There's no problem with X-Lite but some bad SIPUA  
can send bad responding msg and will cause FS hangup the call said  
"Malformed Session Description".

I know it's not FS's problem, but I don't understand why it send the  
INVITE(a re-INVITE?) every minute? is there a way to disable it?

btw, it only happens when you originate a call from a SIPUA, I  
originate from FS(originate sofia/defaut/1000 &echo) doesn't get re- 
INVITE msg.




From mrene_lists at avgs.ca  Thu Feb 26 19:23:14 2009
From: mrene_lists at avgs.ca (Mathieu Rene)
Date: Thu, 26 Feb 2009 22:23:14 -0500
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
Message-ID: <8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>

Seven,

This is called session timers, its sent out to make sure the call is  
still active. Since SIP is UDP-based, if the UA is unplugged, the call  
would just stay active.

You can look in your UA's settings to see if you can make that longer  
or disable it.

If you do a SIP trace, look for the "Session-Expires" header. (Should  
be like: Session-Expires: <nbr of seconds>).

When FS performs an outbound call, this is controlled by the session- 
timeout parameter in the sip profile.
Eg: <param name="session-timeout" value="120"/>

~Math

On 26-Feb-09, at 10:12 PM, seven wrote:

> Hi,
>
> The recent version of FS( I think I  had notice that also on 1.0.1
> stable version) seems sends out an INVITE msg every minute when I
> originate a call from a SIPUA(say X-Lite), then the SIPUA will respond
> 200 OK with SDP msg. There's no problem with X-Lite but some bad SIPUA
> can send bad responding msg and will cause FS hangup the call said
> "Malformed Session Description".
>
> I know it's not FS's problem, but I don't understand why it send the
> INVITE(a re-INVITE?) every minute? is there a way to disable it?
>
> btw, it only happens when you originate a call from a SIPUA, I
> originate from FS(originate sofia/defaut/1000 &echo) doesn't get re-
> INVITE msg.
>
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org



From seven at idapted.com  Thu Feb 26 20:05:24 2009
From: seven at idapted.com (seven)
Date: Fri, 27 Feb 2009 12:05:24 +0800
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
Message-ID: <CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>

Thanks, but doesn't OPTION msg can make sure KEEP-ALIVE?

I have no way to edit the bad UA settings for Session-Expires. But I  
traced SIP and there is no Session-Expires in the UA's INVITE msg, I  
guess FS default that to 1 minute so it send out the re-INVITE. And  
INVITE sent by FS do has a Session-Expires:120 header .


Seven-

On Feb 27, 2009, at 11:23 AM, Mathieu Rene wrote:

> Seven,
>
> This is called session timers, its sent out to make sure the call is
> still active. Since SIP is UDP-based, if the UA is unplugged, the call
> would just stay active.
>
> You can look in your UA's settings to see if you can make that longer
> or disable it.
>
> If you do a SIP trace, look for the "Session-Expires" header. (Should
> be like: Session-Expires: <nbr of seconds>).
>
> When FS performs an outbound call, this is controlled by the session-
> timeout parameter in the sip profile.
> Eg: <param name="session-timeout" value="120"/>
>
> ~Math
>
> On 26-Feb-09, at 10:12 PM, seven wrote:
>
>> Hi,
>>
>> The recent version of FS( I think I  had notice that also on 1.0.1
>> stable version) seems sends out an INVITE msg every minute when I
>> originate a call from a SIPUA(say X-Lite), then the SIPUA will  
>> respond
>> 200 OK with SDP msg. There's no problem with X-Lite but some bad  
>> SIPUA
>> can send bad responding msg and will cause FS hangup the call said
>> "Malformed Session Description".
>>
>> I know it's not FS's problem, but I don't understand why it send the
>> INVITE(a re-INVITE?) every minute? is there a way to disable it?
>>
>> btw, it only happens when you originate a call from a SIPUA, I
>> originate from FS(originate sofia/defaut/1000 &echo) doesn't get re-
>> INVITE msg.
>>
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org



From mrene_lists at avgs.ca  Thu Feb 26 20:09:46 2009
From: mrene_lists at avgs.ca (Mathieu Rene)
Date: Thu, 26 Feb 2009 23:09:46 -0500
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
	<CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
Message-ID: <0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>

OPTIONS messages arent call-related, they can be used to check  
connectivity but is not relevant in the event of a call being proxied.

Could you attach a sip trace? and which UA are we talking about?

~Math

On 26-Feb-09, at 11:05 PM, seven wrote:

> Thanks, but doesn't OPTION msg can make sure KEEP-ALIVE?
>
> I have no way to edit the bad UA settings for Session-Expires. But I
> traced SIP and there is no Session-Expires in the UA's INVITE msg, I
> guess FS default that to 1 minute so it send out the re-INVITE. And
> INVITE sent by FS do has a Session-Expires:120 header .
>
>
> Seven-
>
> On Feb 27, 2009, at 11:23 AM, Mathieu Rene wrote:
>
>> Seven,
>>
>> This is called session timers, its sent out to make sure the call is
>> still active. Since SIP is UDP-based, if the UA is unplugged, the  
>> call
>> would just stay active.
>>
>> You can look in your UA's settings to see if you can make that longer
>> or disable it.
>>
>> If you do a SIP trace, look for the "Session-Expires" header. (Should
>> be like: Session-Expires: <nbr of seconds>).
>>
>> When FS performs an outbound call, this is controlled by the session-
>> timeout parameter in the sip profile.
>> Eg: <param name="session-timeout" value="120"/>
>>
>> ~Math
>>
>> On 26-Feb-09, at 10:12 PM, seven wrote:
>>
>>> Hi,
>>>
>>> The recent version of FS( I think I  had notice that also on 1.0.1
>>> stable version) seems sends out an INVITE msg every minute when I
>>> originate a call from a SIPUA(say X-Lite), then the SIPUA will
>>> respond
>>> 200 OK with SDP msg. There's no problem with X-Lite but some bad
>>> SIPUA
>>> can send bad responding msg and will cause FS hangup the call said
>>> "Malformed Session Description".
>>>
>>> I know it's not FS's problem, but I don't understand why it send the
>>> INVITE(a re-INVITE?) every minute? is there a way to disable it?
>>>
>>> btw, it only happens when you originate a call from a SIPUA, I
>>> originate from FS(originate sofia/defaut/1000 &echo) doesn't get re-
>>> INVITE msg.
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org



From seven at idapted.com  Thu Feb 26 22:25:09 2009
From: seven at idapted.com (seven)
Date: Fri, 27 Feb 2009 14:25:09 +0800
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
	<CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
	<0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>
Message-ID: <6BBDDE98-E7B4-41F8-9973-F3C889B0C7D3@idapted.com>

Thank you.

I first noticed this and posted on JIRA: http://jira.freeswitch.org/browse/SFSIP-110 
, however it's another problem(network problem I think).
The easiest way to make a sip trace is from our production system and  
I it's not good to post in public, hope email you off list is OK.

On Feb 27, 2009, at 12:09 PM, Mathieu Rene wrote:

> OPTIONS messages arent call-related, they can be used to check
> connectivity but is not relevant in the event of a call being proxied.
>
> Could you attach a sip trace? and which UA are we talking about?
>
> ~Math
>
> On 26-Feb-09, at 11:05 PM, seven wrote:
>
>> Thanks, but doesn't OPTION msg can make sure KEEP-ALIVE?
>>
>> I have no way to edit the bad UA settings for Session-Expires. But I
>> traced SIP and there is no Session-Expires in the UA's INVITE msg, I
>> guess FS default that to 1 minute so it send out the re-INVITE. And
>> INVITE sent by FS do has a Session-Expires:120 header .
>>
>>
>> Seven-
>>
>> On Feb 27, 2009, at 11:23 AM, Mathieu Rene wrote:
>>
>>> Seven,
>>>
>>> This is called session timers, its sent out to make sure the call is
>>> still active. Since SIP is UDP-based, if the UA is unplugged, the
>>> call
>>> would just stay active.
>>>
>>> You can look in your UA's settings to see if you can make that  
>>> longer
>>> or disable it.
>>>
>>> If you do a SIP trace, look for the "Session-Expires" header.  
>>> (Should
>>> be like: Session-Expires: <nbr of seconds>).
>>>
>>> When FS performs an outbound call, this is controlled by the  
>>> session-
>>> timeout parameter in the sip profile.
>>> Eg: <param name="session-timeout" value="120"/>
>>>
>>> ~Math
>>>
>>> On 26-Feb-09, at 10:12 PM, seven wrote:
>>>
>>>> Hi,
>>>>
>>>> The recent version of FS( I think I  had notice that also on 1.0.1
>>>> stable version) seems sends out an INVITE msg every minute when I
>>>> originate a call from a SIPUA(say X-Lite), then the SIPUA will
>>>> respond
>>>> 200 OK with SDP msg. There's no problem with X-Lite but some bad
>>>> SIPUA
>>>> can send bad responding msg and will cause FS hangup the call said
>>>> "Malformed Session Description".
>>>>
>>>> I know it's not FS's problem, but I don't understand why it send  
>>>> the
>>>> INVITE(a re-INVITE?) every minute? is there a way to disable it?
>>>>
>>>> btw, it only happens when you originate a call from a SIPUA, I
>>>> originate from FS(originate sofia/defaut/1000 &echo) doesn't get  
>>>> re-
>>>> INVITE msg.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeswitch-dev mailing list
>>>> Freeswitch-dev at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org



From mrene_lists at avgs.ca  Fri Feb 27 06:31:59 2009
From: mrene_lists at avgs.ca (Mathieu Rene)
Date: Fri, 27 Feb 2009 09:31:59 -0500
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <6BBDDE98-E7B4-41F8-9973-F3C889B0C7D3@idapted.com>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
	<CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
	<0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>
	<6BBDDE98-E7B4-41F8-9973-F3C889B0C7D3@idapted.com>
Message-ID: <F77477F7-CF7C-4654-8FAD-E2CFE389E80B@avgs.ca>

FS 200 OKs with a session-timeout header, add that to your sip profile

<param name="session-timeout" value="0"/>

It will disable them.

~Math

On 27-Feb-09, at 1:25 AM, seven wrote:

> Thank you.
>
> I first noticed this and posted on JIRA: http://jira.freeswitch.org/browse/SFSIP-110
> , however it's another problem(network problem I think).
> The easiest way to make a sip trace is from our production system and
> I it's not good to post in public, hope email you off list is OK.
>
> On Feb 27, 2009, at 12:09 PM, Mathieu Rene wrote:
>
>> OPTIONS messages arent call-related, they can be used to check
>> connectivity but is not relevant in the event of a call being  
>> proxied.
>>
>> Could you attach a sip trace? and which UA are we talking about?
>>
>> ~Math
>>
>> On 26-Feb-09, at 11:05 PM, seven wrote:
>>
>>> Thanks, but doesn't OPTION msg can make sure KEEP-ALIVE?
>>>
>>> I have no way to edit the bad UA settings for Session-Expires. But I
>>> traced SIP and there is no Session-Expires in the UA's INVITE msg, I
>>> guess FS default that to 1 minute so it send out the re-INVITE. And
>>> INVITE sent by FS do has a Session-Expires:120 header .
>>>
>>>
>>> Seven-
>>>
>>> On Feb 27, 2009, at 11:23 AM, Mathieu Rene wrote:
>>>
>>>> Seven,
>>>>
>>>> This is called session timers, its sent out to make sure the call  
>>>> is
>>>> still active. Since SIP is UDP-based, if the UA is unplugged, the
>>>> call
>>>> would just stay active.
>>>>
>>>> You can look in your UA's settings to see if you can make that
>>>> longer
>>>> or disable it.
>>>>
>>>> If you do a SIP trace, look for the "Session-Expires" header.
>>>> (Should
>>>> be like: Session-Expires: <nbr of seconds>).
>>>>
>>>> When FS performs an outbound call, this is controlled by the
>>>> session-
>>>> timeout parameter in the sip profile.
>>>> Eg: <param name="session-timeout" value="120"/>
>>>>
>>>> ~Math
>>>>
>>>> On 26-Feb-09, at 10:12 PM, seven wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The recent version of FS( I think I  had notice that also on 1.0.1
>>>>> stable version) seems sends out an INVITE msg every minute when I
>>>>> originate a call from a SIPUA(say X-Lite), then the SIPUA will
>>>>> respond
>>>>> 200 OK with SDP msg. There's no problem with X-Lite but some bad
>>>>> SIPUA
>>>>> can send bad responding msg and will cause FS hangup the call said
>>>>> "Malformed Session Description".
>>>>>
>>>>> I know it's not FS's problem, but I don't understand why it send
>>>>> the
>>>>> INVITE(a re-INVITE?) every minute? is there a way to disable it?
>>>>>
>>>>> btw, it only happens when you originate a call from a SIPUA, I
>>>>> originate from FS(originate sofia/defaut/1000 &echo) doesn't get
>>>>> re-
>>>>> INVITE msg.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Freeswitch-dev mailing list
>>>>> Freeswitch-dev at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org



From seven at idapted.com  Fri Feb 27 23:24:59 2009
From: seven at idapted.com (seven du)
Date: Sat, 28 Feb 2009 15:24:59 +0800
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <F77477F7-CF7C-4654-8FAD-E2CFE389E80B@avgs.ca>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
	<CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
	<0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>
	<6BBDDE98-E7B4-41F8-9973-F3C889B0C7D3@idapted.com>
	<F77477F7-CF7C-4654-8FAD-E2CFE389E80B@avgs.ca>
Message-ID: <725869A8-102B-4EE4-9095-A751B9CABF12@idapted.com>

Hi Math,

in 200 OK session-timeout, do you mean this?

Session-Expires: 120;refresher=uas

I added the session-timeout to my sip profile and I can see

SESSION_TO           0

in console when I typed in " sofia status profile default " , however  
the Session-Expires will be always 120 in the 200OK msg.

Oh, I'm behind a NAT, so I think the timeout always equals 20  
(mod_sofia.c around line 519: session_timeout =  
SOFIA_NAT_SESSION_TIMEOUT; )

I tried change

<param name="minimum-session-expires" value="0"/>

and I can get

Session-Expires: 90;refresher=uas
Min-SE: 90

However, I still get the re-INVITE message after 60 seconds.

On Feb 27, 2009, at 10:31 PM, Mathieu Rene wrote:

> FS 200 OKs with a session-timeout header, add that to your sip profile
>
> <param name="session-timeout" value="0"/>
>
> It will disable them.
>
> ~Math
>
> On 27-Feb-09, at 1:25 AM, seven wrote:
>
>> Thank you.
>>
>> I first noticed this and posted on JIRA: http://jira.freeswitch.org/browse/SFSIP-110
>> , however it's another problem(network problem I think).
>> The easiest way to make a sip trace is from our production system and
>> I it's not good to post in public, hope email you off list is OK.
>>
>> On Feb 27, 2009, at 12:09 PM, Mathieu Rene wrote:
>>
>>> OPTIONS messages arent call-related, they can be used to check
>>> connectivity but is not relevant in the event of a call being
>>> proxied.
>>>
>>> Could you attach a sip trace? and which UA are we talking about?
>>>
>>> ~Math
>>>
>>> On 26-Feb-09, at 11:05 PM, seven wrote:
>>>
>>>> Thanks, but doesn't OPTION msg can make sure KEEP-ALIVE?
>>>>
>>>> I have no way to edit the bad UA settings for Session-Expires.  
>>>> But I
>>>> traced SIP and there is no Session-Expires in the UA's INVITE  
>>>> msg, I
>>>> guess FS default that to 1 minute so it send out the re-INVITE. And
>>>> INVITE sent by FS do has a Session-Expires:120 header .
>>>>
>>>>
>>>> Seven-
>>>>
>>>> On Feb 27, 2009, at 11:23 AM, Mathieu Rene wrote:
>>>>
>>>>> Seven,
>>>>>
>>>>> This is called session timers, its sent out to make sure the call
>>>>> is
>>>>> still active. Since SIP is UDP-based, if the UA is unplugged, the
>>>>> call
>>>>> would just stay active.
>>>>>
>>>>> You can look in your UA's settings to see if you can make that
>>>>> longer
>>>>> or disable it.
>>>>>
>>>>> If you do a SIP trace, look for the "Session-Expires" header.
>>>>> (Should
>>>>> be like: Session-Expires: <nbr of seconds>).
>>>>>
>>>>> When FS performs an outbound call, this is controlled by the
>>>>> session-
>>>>> timeout parameter in the sip profile.
>>>>> Eg: <param name="session-timeout" value="120"/>
>>>>>
>>>>> ~Math
>>>>>
>>>>> On 26-Feb-09, at 10:12 PM, seven wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The recent version of FS( I think I  had notice that also on  
>>>>>> 1.0.1
>>>>>> stable version) seems sends out an INVITE msg every minute when I
>>>>>> originate a call from a SIPUA(say X-Lite), then the SIPUA will
>>>>>> respond
>>>>>> 200 OK with SDP msg. There's no problem with X-Lite but some bad
>>>>>> SIPUA
>>>>>> can send bad responding msg and will cause FS hangup the call  
>>>>>> said
>>>>>> "Malformed Session Description".
>>>>>>
>>>>>> I know it's not FS's problem, but I don't understand why it send
>>>>>> the
>>>>>> INVITE(a re-INVITE?) every minute? is there a way to disable it?
>>>>>>
>>>>>> btw, it only happens when you originate a call from a SIPUA, I
>>>>>> originate from FS(originate sofia/defaut/1000 &echo) doesn't get
>>>>>> re-
>>>>>> INVITE msg.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeswitch-dev mailing list
>>>>>> Freeswitch-dev at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org



From brian at freeswitch.org  Sat Feb 28 08:40:15 2009
From: brian at freeswitch.org (Brian West)
Date: Sat, 28 Feb 2009 10:40:15 -0600
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <725869A8-102B-4EE4-9095-A751B9CABF12@idapted.com>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
	<CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
	<0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>
	<6BBDDE98-E7B4-41F8-9973-F3C889B0C7D3@idapted.com>
	<F77477F7-CF7C-4654-8FAD-E2CFE389E80B@avgs.ca>
	<725869A8-102B-4EE4-9095-A751B9CABF12@idapted.com>
Message-ID: <24981C76-8D10-48BA-B9D4-BC64A91A73FF@freeswitch.org>

Seven,
	Do you know how Session timers work?  If for example a session timer  
is setup at 120 seconds you'll get an invite about every 60 seconds.

/b


On Feb 28, 2009, at 1:24 AM, seven du wrote:

> Hi Math,
>
> in 200 OK session-timeout, do you mean this?
>
> Session-Expires: 120;refresher=uas
>
> I added the session-timeout to my sip profile and I can see
>
> SESSION_TO           0
>
> in console when I typed in " sofia status profile default " , however
> the Session-Expires will be always 120 in the 200OK msg.
>
> Oh, I'm behind a NAT, so I think the timeout always equals 20
> (mod_sofia.c around line 519: session_timeout =
> SOFIA_NAT_SESSION_TIMEOUT; )
>
> I tried change
>
> <param name="minimum-session-expires" value="0"/>
>
> and I can get
>
> Session-Expires: 90;refresher=uas
> Min-SE: 90
>
> However, I still get the re-INVITE message after 60 seconds.



From seven at idapted.com  Sat Feb 28 10:32:05 2009
From: seven at idapted.com (seven du)
Date: Sun, 1 Mar 2009 02:32:05 +0800
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <24981C76-8D10-48BA-B9D4-BC64A91A73FF@freeswitch.org>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
	<CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
	<0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>
	<6BBDDE98-E7B4-41F8-9973-F3C889B0C7D3@idapted.com>
	<F77477F7-CF7C-4654-8FAD-E2CFE389E80B@avgs.ca>
	<725869A8-102B-4EE4-9095-A751B9CABF12@idapted.com>
	<24981C76-8D10-48BA-B9D4-BC64A91A73FF@freeswitch.org>
Message-ID: <2FE5B8E2-4291-465D-832B-0E5A9E888F70@idapted.com>

Thanks Brian. I didn't know that before. But doesn't set the timer to  
0 disable it? Or can I set to a very large value say 9999999?

Anyway, if I change session-timeout, should I see the difference at  
the sip response header "Session-Expires: 120;refresher=uas" right?

Do you think it related to this?
http://www.nabble.com/change-session-timer-value-td22239490.html


On Mar 1, 2009, at 12:40 AM, Brian West wrote:

> Seven,
> 	Do you know how Session timers work?  If for example a session timer
> is setup at 120 seconds you'll get an invite about every 60 seconds.
>
> /b
>
>
> On Feb 28, 2009, at 1:24 AM, seven du wrote:
>
>> Hi Math,
>>
>> in 200 OK session-timeout, do you mean this?
>>
>> Session-Expires: 120;refresher=uas
>>
>> I added the session-timeout to my sip profile and I can see
>>
>> SESSION_TO           0
>>
>> in console when I typed in " sofia status profile default " , however
>> the Session-Expires will be always 120 in the 200OK msg.
>>
>> Oh, I'm behind a NAT, so I think the timeout always equals 20
>> (mod_sofia.c around line 519: session_timeout =
>> SOFIA_NAT_SESSION_TIMEOUT; )
>>
>> I tried change
>>
>> <param name="minimum-session-expires" value="0"/>
>>
>> and I can get
>>
>> Session-Expires: 90;refresher=uas
>> Min-SE: 90
>>
>> However, I still get the re-INVITE message after 60 seconds.
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org



From brian at freeswitch.org  Sat Feb 28 10:40:49 2009
From: brian at freeswitch.org (Brian West)
Date: Sat, 28 Feb 2009 12:40:49 -0600
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <2FE5B8E2-4291-465D-832B-0E5A9E888F70@idapted.com>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
	<CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
	<0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>
	<6BBDDE98-E7B4-41F8-9973-F3C889B0C7D3@idapted.com>
	<F77477F7-CF7C-4654-8FAD-E2CFE389E80B@avgs.ca>
	<725869A8-102B-4EE4-9095-A751B9CABF12@idapted.com>
	<24981C76-8D10-48BA-B9D4-BC64A91A73FF@freeswitch.org>
	<2FE5B8E2-4291-465D-832B-0E5A9E888F70@idapted.com>
Message-ID: <720DC4E9-093C-4B51-9EDD-C852378EA979@freeswitch.org>

That depends on if its inbound or outbound.. you have to pay close  
attention to the direction and uas vs uac.

/b

On Feb 28, 2009, at 12:32 PM, seven du wrote:

> Thanks Brian. I didn't know that before. But doesn't set the timer to
> 0 disable it? Or can I set to a very large value say 9999999?
>
> Anyway, if I change session-timeout, should I see the difference at
> the sip response header "Session-Expires: 120;refresher=uas" right?
>
> Do you think it related to this?
> http://www.nabble.com/change-session-timer-value-td22239490.html
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090228/3c51a56a/attachment.html 

From brian at freeswitch.org  Sat Feb 28 12:19:44 2009
From: brian at freeswitch.org (Brian West)
Date: Sat, 28 Feb 2009 14:19:44 -0600
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <2FE5B8E2-4291-465D-832B-0E5A9E888F70@idapted.com>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
	<CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
	<0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>
	<6BBDDE98-E7B4-41F8-9973-F3C889B0C7D3@idapted.com>
	<F77477F7-CF7C-4654-8FAD-E2CFE389E80B@avgs.ca>
	<725869A8-102B-4EE4-9095-A751B9CABF12@idapted.com>
	<24981C76-8D10-48BA-B9D4-BC64A91A73FF@freeswitch.org>
	<2FE5B8E2-4291-465D-832B-0E5A9E888F70@idapted.com>
Message-ID: <FE447906-9BD0-4B68-BD31-8528FE07BDA3@freeswitch.org>

If you go look in sofia's code you see something like this:

/* refresh 30..60 seconds before deadline */

/* By default, refresh around half time before deadline */

/b



On Feb 28, 2009, at 12:32 PM, seven du wrote:

> Thanks Brian. I didn't know that before. But doesn't set the timer to
> 0 disable it? Or can I set to a very large value say 9999999?
>
> Anyway, if I change session-timeout, should I see the difference at
> the sip response header "Session-Expires: 120;refresher=uas" right?
>
> Do you think it related to this?



From seven at idapted.com  Sat Feb 28 22:48:58 2009
From: seven at idapted.com (seven du)
Date: Sun, 1 Mar 2009 14:48:58 +0800
Subject: [Freeswitch-dev] FS send re-invite about every minutes,
	is there a way to disable it?
In-Reply-To: <FE447906-9BD0-4B68-BD31-8528FE07BDA3@freeswitch.org>
References: <3A8ABF89-1DA0-4705-A674-B1C1047EAF71@idapted.com>
	<8A5E3C9B-CE3A-45F7-A44E-17550EB781B7@avgs.ca>
	<CDB299A0-D8AF-4A02-98D6-ED397576857A@idapted.com>
	<0F27C17D-DEF9-4135-9118-0ED59F9AF5BA@avgs.ca>
	<6BBDDE98-E7B4-41F8-9973-F3C889B0C7D3@idapted.com>
	<F77477F7-CF7C-4654-8FAD-E2CFE389E80B@avgs.ca>
	<725869A8-102B-4EE4-9095-A751B9CABF12@idapted.com>
	<24981C76-8D10-48BA-B9D4-BC64A91A73FF@freeswitch.org>
	<2FE5B8E2-4291-465D-832B-0E5A9E888F70@idapted.com>
	<FE447906-9BD0-4B68-BD31-8528FE07BDA3@freeswitch.org>
Message-ID: <7C225EE0-B1EB-4C5C-94F8-FE4B5FD7BC4A@idapted.com>

Got it.

because I'm behind an NAT and

#define SOFIA_NAT_SESSION_TIMEOUT 20


  515     if (switch_test_flag(tech_pvt, TFLAG_NAT) ||
  516         (val = switch_channel_get_variable(channel, "sip-force- 
contact")) ||
  517         ((val = switch_channel_get_variable(channel,  
"sip_sticky_contact")) && switch_true(val))) {
  518         sticky = tech_pvt->record_route;
  519         session_timeout = SOFIA_NAT_SESSION_TIMEOUT;

so, session_timeout would always be 20 and I always get a Session- 
Expires header with value 120(the default value maybe).

Based on http://tools.ietf.org/html/draft-ietf-sip-session-timer-15, I  
think #define SOFIA_NAT_SESSION_TIMEOUT 20 maybe not followed the  
standard. Anyway, OPTION packets works well for NAT KEEP-ALIVE right?

Do we really need line 519(as the above code)? or should we make  
another setting parameter say "nat_session_timeout" in sofia profile?  
Do I need to post this on jira?




On Mar 1, 2009, at 4:19 AM, Brian West wrote:

> If you go look in sofia's code you see something like this:
>
> /* refresh 30..60 seconds before deadline */
>
> /* By default, refresh around half time before deadline */
>
> /b
>
>
>
> On Feb 28, 2009, at 12:32 PM, seven du wrote:
>
>> Thanks Brian. I didn't know that before. But doesn't set the timer to
>> 0 disable it? Or can I set to a very large value say 9999999?
>>
>> Anyway, if I change session-timeout, should I see the difference at
>> the sip response header "Session-Expires: 120;refresher=uas" right?
>>
>> Do you think it related to this?
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org