I did try that suggestion (api_on_answer uuidbroadcast) and it worked fine if I played it to the a leg, but when I tried playing to the b leg the prompt was incredibly choppy and slow, and delayed the cutthru of a and b legs by a long time. Interestingly, the prompt doesn't even start playing to the b party until some RTP is received from b for some reason, and then it sort of slowly chuffs out the prompt in small choppy chunks. I then tried Michael's follow on suggestion of using bridge_pre_execute_bleg_app, but that didn't work at all -- no prompt heard. I then decided to try the outdial as a bridged conference, and then play a prompt to the conference after the b party picks up. This may actually be the best option for me as I need the prompt to be saved in the recording of the call, and I am guessing when I stream it out on a bridged call it may not show up in the recording. However, I had no luck getting a bridged conference outdial to work at all -- the outdial does work successfully, but a and b parties don't hear each other so one must not be in the conference. And then when the b party hangs up the a party is not automatically hung up, which should happen in a bridged conference if I understand things correctly. So, while I am still interested in what is causing the prompt on the bridge call to sound so bad when played to the b leg, perhaps what is more important to me now is getting the bridged conference to work. Here is what I am doing, in case anyone can point out the problem: session:execute("set","progress_timeout=60") ; session:execute("set","call_timeout=120") ; session:setVariable("hangup_after_bridge","true") ; session:execute("conference","bridge:_uuid_@simple:sofia/normal_customer/${outdial}@${egress_gateway}") ; session:setVariable("conference_enter_sound",this_call_is_being_recorded) ; (I created a conference profile called 'simple' that turns off caller controls; interestingly, that doesn't seem to be picked up either as the debug logging shows it attaching the default caller controls) Dave On 2012-08-29 11:24:00 +0000, Dave Horton said:
Set api_on_answer to execute uuid_broadcast< http://wiki.freeswitch.org/wiki/Mod_commands#uuid_broadcast
which will let you pick which legs to play the recording to. You can pass in the UUID with ${uuid}
-Avi
I tried this, and it worked.....sort of. If I play the prompt the A leg it is fine -- caller hears the prompt, then is connected to called party. If I play it to the B leg, however, the prompt does not seem to start playing at all until the B party actually starts talking, and then the prompt is played extremely choppy and slow.....it takes about 10 seconds to play a 4 second prompt. Meanwhile, the caller and called party can't hear each other. Any idea what is going on and how to fix it? I am doing it in lua as follows:
session:execute("export","nolocal:jitterbuffer_msec=100") ; session:setVariable("RECORD_STEREO","true") ; session:setVariable("aleg_uuid",uuid) ; session:execute("record_session", outfile) ; session:execute("set","progress_timeout=60") ; session:execute("set","call_timeout=120") ; session:setVariable("hangup_after_bridge","true") ; session:execute("bridge","sofia/normal_customer/${outdial}@${egress_gateway}") ; --session:execute("bridge","{api_on_answer='uuid_broadcast " .. uuid .. " " .. this_call_is_being_recorded .. " " .. "bleg'}sofia/normal_customer/${outdial}@${egress_gateway}") ;
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org