I don't think there is a very elegant way to do this and even if I find one i can live with it would be at least 2k worth of work to add it.
Why do you need the loopback channel at all? Can't you just originate the sofia channel directly instead of bridging it to loopback and adding 2 more channels per call? On Thu, Jan 29, 2009 at 7:20 AM, Tamas Cseke <[email protected]>wrote: > Hello, > > I'm sorry for still bothering you with this issue. > but thanks to somewhat missunderstanding/misleading by us, it shows up that > our customers need this feature for the complicated > predictive calls too. > > There is an idea, could you let me know if it is achiveable. and if it's > how? > So we record sofia channel, but the media pause/resume is happening on > loopback channel. > the idea is to have a switch_set_flag_recursive function, which set the > flag not only to the current channel, but to all connected channels. > we need to push CS_PAUSE_MEDIA flag to the sofia channel. > > Thanks in advance, > Tamas > > Here is the callflow again: > 1, originate a loopback channel via event socket > 2, loopback-b channel is hunting the dialplan, wich decide routing, > caller_id, the need for recordings and so forth, and bridge a sofia call > 3. the record_session is running on the sofia channel with > bridge_pre_execute magic vars > 4 loopback-a channel is pushed into the fifo > 5 a script get the fifo::info via event socket > 6 originate a call to the consumer with the proper strategy with &fifo > out application > 7 sofia channel is bridged to the consumer > 8 loopback channels die > > > > Anthony Minessale írta: > > yes some code was missing for some reason, try again > > > > > > On Mon, Jan 26, 2009 at 10:11 AM, Tamas Cseke <[email protected] > >wrote: > > > > > >> Hello, > >> > >> I tested with the attached patch. > >> It is working fine in a normal case. > >> > >> I have only problems with the automatic calls, because in this case the > >> loopback channel is in the fifo, but the record_session is running on > the > >> sofia channel. > >> Maybe it could be sort out with putting the bug pause/resume functions > into > >> api function, what I should turn on and off on demand? > >> Anyway, I quess this is a bit extreme circumstance, and it isn't so > >> important to us now. > >> > >> Thanks, > >> Tamas > >> > >> Tamas Cseke írta: > >> > >> Hello, > >> > >>> Thank you your help. > >>> > >>> I tested with r11489, but moh is still recorded in fifo. > >>> > >>> I quess you I should test the CF_PAUSE_BUGS in r11466. But I didn't > find > >>> where you check this flag. > >>> Is it maybe possible you forget to commit something? > >>> > >>> Thanks, > >>> Tamas > >>> > >>> > >>> I didn't find where you > >>> Anthony Minessale írta: > >>> > >>> > >>> > >>>> please test latest trunk. > >>>> Patch added to pause media bugs while not in a bridge which should > pause > >>>> recordings and cut out the moh. > >>>> > >>>> > >>>> On Fri, Jan 23, 2009 at 10:45 AM, Tamas Cseke < > [email protected] > >>>> > >>>>> wrote: > >>>>> > >>>> > >>>> > >>>>> Hello, > >>>>> > >>>>> we would like to distribute calls with fifo and record these sessions > >>>>> but we'd like to skip the recording while the caller is waiting. > >>>>> (we don't need to record the hold music, just the speech with the > fifo > >>>>> consumer.) > >>>>> > >>>>> I tried > >>>>> <action application="set" data="RECORD_ANSWER_REQ=true"/> > >>>>> <action application="record_session" data="${callfilename}"/> > >>>>> <action application="fifo" data="myfifo in"/> > >>>>> > >>>>> but it doesn't work because the channel is answered immediately when > the > >>>>> caller is pushed into the fifo. > >>>>> (I don't know if there exists any other channel flag that could be > use > >>>>> here) > >>>>> > >>>>> I also tried fifo_record_template. > >>>>> but it records the session from the point of view of the consumer's > >>>>> session, and after the bridge the recording is stopped. > >>>>> we would like to record the whole session into a single file even > after > >>>>> calltransfers > >>>>> > >>>>> moreover we'd like to use some kind of predcitive dialing > >>>>> which > >>>>> 1, originate a loopback channel via event socket > >>>>> 2, loopback-b channel is hunting the dialplan, wich decide routing, > >>>>> caller_id, the need for recordings and so forth, and bridge a sofia > call > >>>>> 3. the record_session is running on the sofia channel with > >>>>> bridge_pre_execute magic vars > >>>>> 4 loopback-a channel is pushed into the fifo > >>>>> 5 a script get the fifo::info via event socket > >>>>> 6 originate a call to the consumer with the proper strategy with > &fifo > >>>>> out application > >>>>> 7 sofia channel is bridged to the consumer > >>>>> 8 loopback channels die > >>>>> > >>>>> after transfers everything is recorded into one file. > >>>>> but the problem here is again the unwanted recording in the fifo > while > >>>>> the caller is waiting > >>>>> > >>>>> Could you please advise me any solution, if there is? > >>>>> > >>>>> > >>>>> Thank you, > >>>>> Tamas > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Freeswitch-users mailing list > >>>>> [email protected] > >>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > >>>>> UNSUBSCRIBE: > >>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users > >>>>> http://www.freeswitch.org > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > ------------------------------------------------------------------------ > >>>> > >>>> _______________________________________________ > >>>> Freeswitch-users mailing list > >>>> [email protected] > >>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > >>>> UNSUBSCRIBE: > http://lists.freeswitch.org/mailman/options/freeswitch-users > >>>> http://www.freeswitch.org > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> Freeswitch-users mailing list > >>> [email protected] > >>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > >>> UNSUBSCRIBE: > http://lists.freeswitch.org/mailman/options/freeswitch-users > >>> http://www.freeswitch.org > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> Freeswitch-users mailing list > >> [email protected] > >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > >> UNSUBSCRIBE: > http://lists.freeswitch.org/mailman/options/freeswitch-users > >> http://www.freeswitch.org > >> > >> > >> > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeswitch-users mailing list > > [email protected] > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > > http://www.freeswitch.org > > > > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:[email protected] <msn%[email protected]> GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[email protected] <sip%[email protected]> iax:[email protected]/888 googletalk:[email protected]<googletalk%3aconf%[email protected]> pstn:213-799-1400
_______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
