I would try to get this working w/ just raw XML dialplan and take Lua out of the equation. Once you get it working then migrate into a Lua script, assuming you even need to use it. Personally, I try not to overuse Lua (or any other dp scripting language) and keep as much in the XML dialplan as possible. Lab it up just with the dialplan using as simple a config as possible. Capture logs and post to pastebin.freeswitch.org along with your relevant configs (dialplan, conference) and some of the gang here will see if they can help analyze what's going on. -MC On Thu, Aug 30, 2012 at 5:44 AM, Dave Horton <daveh@beachdognet.com> wrote:
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
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org