Hi again, I don't quite understand why both of them would not be parked... in logs (from http://pastebin.freeswitch.org/12432) I can see this: dialing 1st call [5] 2010-03-15 08:52:45.191854 [NOTICE] switch_channel.c:666 New Channel sofia/external/2500 [b278ec65-6d83-4454-b885-7ee66f414230] then...: [55] 2010-03-15 08:52:45.332056 [DEBUG] switch_core_state_machine.c:157 sofia/external/2500 Standard EXECUTE [56] EXECUTE sofia/external/2500 park() then...: [57] 2010-03-15 08:52:45.332056 [DEBUG] switch_ivr.c:1426 (sofia/external/2500) State Change CS_EXECUTE -> CS_ROUTING [58] 2010-03-15 08:52:45.332056 [DEBUG] switch_core_session.c:1018 Send signal sofia/external/2500 [BREAK] [59] 2010-03-15 08:52:45.332056 [DEBUG] switch_core_session.c:638 Send signal sofia/external/2500 [BREAK] [60] 2010-03-15 08:52:45.332056 [NOTICE] switch_ivr.c:1432 Transfer sofia/external/2500 to inline[park@default] then PARK again...: [72] 2010-03-15 08:52:45.342070 [DEBUG] switch_core_state_machine.c:157 sofia/external/2500 Standard EXECUTE [73] EXECUTE sofia/external/2500 park() [74] 2010-03-15 08:52:45.402157 [DEBUG] switch_rtp.c:2055 Correct ip/port confirmed. [75] 2010-03-15 08:52:50.709789 [DEBUG] switch_ivr.c:1426 (sofia/external/2500) State Change CS_EXECUTE -> CS_ROUTING then TRANSFER again...: [78] 2010-03-15 08:52:50.709789 [NOTICE] switch_ivr.c:1432 Transfer sofia/external/2500 to inline[park@default] and PARK again...: [90] 2010-03-15 08:52:50.719803 [DEBUG] switch_core_state_machine.c:157 sofia/external/2500 Standard EXECUTE [91] EXECUTE sofia/external/2500 park() And the same goes for the 2nd channel. The Transfer/Park instructions are repeated several times. Is this normal? My command is fine according to WIKI I guess: bgapi originate {originate_timeout=15}[24cc_session_id=76dfb907-a0c3-4357-b1f9-ede89caf8a7e,ignore_early_media=true,max_forwards=999999,origination_uuid=d4f4e460-43c7-4e53-af18-46fa5226227d]sofia/gateway/agent_gateway/2500 &park() Or maybe the &park() is not necessary there? This mechanism worked mostly OK for several months with previous builds of freeswitch, the problems showed up after upgrading to trunk recently. Sometimes it works though, i'd say that ~30% of the calls end up being hanged up, but most of them are just fine. Anyway, I'll try to wait for CHANNEL_PARK event as you suggested and only then assume that the call is really "answered" and ready for processing. -- View this message in context: http://n2.nabble.com/Call-gets-hanged-up-with-ORIGINATOR-CANCEL-cause-tp4735... Sent from the freeswitch-users mailing list archive at Nabble.com.