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