For good measure, this is with tr...@14973 2009/9/25 Harry Vangberg <ha...@vangberg.name>: > Just tried that, but that simply results in *nothing* happening. It > processes the meta digit, but then it just goes on, without > transfering at all, nor if the original B-leg hangs up - that just > results in the A-leg hanging up as well. > > 2009/9/25 Anthony Minessale <anthony.miness...@gmail.com>: >> in that case, it's probably a delay in the media stream where the app is >> queued when you press the key >> >> try updating to trunk and add the new i flag to the flags param i.e. 1 b ai >> transfer::ff-transfer XML public >> >> >> On Thu, Sep 24, 2009 at 2:04 PM, Harry Vangberg <ha...@vangberg.name> wrote: >>> >>> Not exactly, as I said, if the original B-leg doesn't hang up, it will >>> wait 20 second before transfering to the new extension (check the >>> timestamps!) - but if the original B leg hangs up, it gets transfered >>> to the extension immediately. >>> >>> Look at this: >>> >>> 2009-09-24 18:29:48.138326 [DEBUG] switch_ivr_async.c:2042 >>> sofia/external/hemmel...@129.142.224.250 Processing meta digit '1' >>> [transfer::ff-transfer XML public] >>> 2009-09-24 18:29:48.138326 [DEBUG] switch_core_session.c:813 Send >>> signal sofia/external/hemmel...@129.142.224.250 [BREAK] >>> 2009-09-24 18:29:48.138326 [DEBUG] switch_ivr_bridge.c:228 >>> sofia/external/hemmel...@129.142.224.250 receive message [UNBRIDGE] >>> 2009-09-24 18:29:48.138326 [DEBUG] switch_core_session.c:630 Send >>> signal sofia/external/hemmel...@129.142.224.250 [BREAK] >>> 2009-09-24 18:29:48.278342 [DEBUG] switch_core_session.c:813 Send >>> signal sofia/external/46934488 [BREAK] >>> 2009-09-24 18:29:48.298341 [DEBUG] switch_ivr_bridge.c:228 >>> sofia/external/46934488 receive message [UNBRIDGE] >>> 2009-09-24 18:29:48.298341 [DEBUG] switch_core_session.c:630 Send >>> signal sofia/external/46934488 [BREAK] >>> 2009-09-24 18:29:48.438320 [DEBUG] switch_ivr.c:540 >>> sofia/external/46934488 Command Execute playback(local_stream://moh) >>> EXECUTE sofia/external/46934488 playback(local_stream://moh) >>> 2009-09-24 18:29:48.438320 [WARNING] mod_local_stream.c:318 Unknown >>> source moh, trying 'default' >>> 2009-09-24 18:29:48.438320 [ERR] mod_local_stream.c:327 Unknown source >>> default >>> 2009-09-24 18:29:48.438320 [DEBUG] switch_ivr_bridge.c:231 >>> sofia/external/46934488 receive message [BRIDGE] >>> 2009-09-24 18:29:48.438320 [DEBUG] switch_core_session.c:630 Send >>> signal sofia/external/46934488 [BREAK] >>> 2009-09-24 18:29:48.438320 [DEBUG] switch_ivr_bridge.c:233 Send signal >>> sofia/external/hemmel...@129.142.224.250 [BREAK] >>> 2009-09-24 18:30:09.111448 [DEBUG] switch_ivr.c:540 >>> sofia/external/hemmel...@129.142.224.250 Command Execute >>> transfer(ff-transfer XML public) >>> EXECUTE sofia/external/hemmel...@129.142.224.250 transfer(ff-transfer >>> XML public) >>> >>> >From 18:29:48 to 19:30:09 nothing happens - it's first then it's >>> transferred to the new extension, and first after that that the new >>> B-leg will even get called. >>> >>> 2009/9/24 Anthony Minessale <anthony.miness...@gmail.com>: >>> > because it's waiting for the other party to answer >>> > >>> > if you want to hear ringback or music while you are waiting >>> > see: >>> > http://wiki.freeswitch.org/wiki/Custom_Ring_Back_Tones >>> > >>> > specifically transfer_ringback >>> > >>> > >>> > On Thu, Sep 24, 2009 at 1:35 PM, Harry Vangberg <ha...@vangberg.name> >>> > wrote: >>> >> >>> >> Hello >>> >> >>> >> My setup is this (I've simplified everything, because a lot of my >>> >> logic isn't necesarry for showcasing this): A calls in, transfer is >>> >> bound as meta app, B is bridged. When the meta app is processed, the >>> >> call is transfered to a new extension, which rebridges A. But! After >>> >> triggering the meta app, it hangs 20 seconds, until transfering to the >>> >> new extension, unless the B-leg hangs up manually. >>> >> >>> >> It should be noted that I've set dtmf-type=sip-info, as I would like >>> >> to bypass media–if there's a better solution to get DTMF events while >>> >> bypassing media, please say so, as I know the SIP INFO solution is >>> >> kinda havoced. >>> >> >>> >> This is my dialplan: >>> >> >>> >> <include> >>> >> <context name="public"> >>> >> >>> >> <extension name="ff-ivr"> >>> >> <condition field="destination_number" expression="^(\d+)$"> >>> >> <action application="answer" /> >>> >> <action application="bind_meta_app" data="1 b a >>> >> transfer::ff-transfer XML public" /> >>> >> <action application="bridge" >>> >> data="sofia/gateway/gw1.fonet.dk/46934488" /> >>> >> </condition> >>> >> </extension> >>> >> >>> >> <extension name="ff-transfer"> >>> >> <condition field="destination_number" expression="^ff-transfer$"> >>> >> <action application="bridge" >>> >> data="sofia/gateway/gw1.fonet.dk/31354228" /> >>> >> </condition> >>> >> </extension> >>> >> ... >>> >> </context> >>> >> </include> >>> >> >>> >> A full trace of a session with A calling in, B answering, B triggering >>> >> meta app, waiting for transfer, and finally bridge to C is attached. >>> >> >>> >> This is using freeswitch-tr...@14962 >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >> >>> > >>> > >>> > >>> > -- >>> > Anthony Minessale II >>> > >>> > FreeSWITCH http://www.freeswitch.org/ >>> > ClueCon http://www.cluecon.com/ >>> > Twitter: http://twitter.com/FreeSWITCH_wire >>> > >>> > AIM: anthm >>> > MSN:anthony_miness...@hotmail.com >>> > GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com >>> > IRC: irc.freenode.net #freeswitch >>> > >>> > FreeSWITCH Developer Conference >>> > sip:8...@conference.freeswitch.org >>> > iax:gu...@conference.freeswitch.org/888 >>> > googletalk:conf+...@conference.freeswitch.org >>> > pstn:213-799-1400 >>> > >>> > _______________________________________________ >>> > 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 >>> > >>> > >>> >>> _______________________________________________ >>> 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 >> >> >> >> -- >> Anthony Minessale II >> >> FreeSWITCH http://www.freeswitch.org/ >> ClueCon http://www.cluecon.com/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_miness...@hotmail.com >> GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:8...@conference.freeswitch.org >> iax:gu...@conference.freeswitch.org/888 >> googletalk:conf+...@conference.freeswitch.org >> pstn:213-799-1400 >> >> _______________________________________________ >> 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 >> >> >
_______________________________________________ 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