From a quick peek at the code, I can state the obvious: process(peer_event) is only called when process(event) has failed. So, process_event will be called for event or peer_event (not both). I can think of a scenario where this might happen (this is an educated guess, though): If channels A and B bridged and A hangs up. A receives a CHANNEL_HANGUP and channel B must receive a CHANNEL_UNBRIDGE (from channel A) event, so that it can take appropriate actions (like hang up too or go back to an IVR menu). Regards, Paulo. On 21/11/10 01:48, jesse wrote:
hi,
Any expert can shed me some light on quick code understanding? thanks in advance!
suppose I dial 88<1001> to spy on extension user 1001. and 5 minutes later 1001 calls 1002.
<extension name="userspy"> <condition field="destination_number" expression="^88(.*)$|^\*0(.*)$"> <action application="answer"/> <action application="userspy" data="$1@192.168.1.1"/> </condition> </extension>
in event_handle(...) of mod_spy.c. -- Whats is the reason that we need to call process_event for both event and peer_event? is not processing event for call leg-a 's bridge enough? it seems mod_spy.c in 1.0.6 version doesn't process peer_event.
static void event_handler(switch_event_t *event) { if (process_event(event) != SWITCH_STATUS_SUCCESS) { const char *peer_uuid = switch_event_get_header(event, "variable_signal_bond"); ... if (peer_event) { process_event(peer_event); } } }
http://svn.freeswitch.org/svn/freeswitch/trunk/src/mod/applications/mod_spy/...
_______________________________________________ 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