When leg on hold hangs up, another leg is hanged up too
Hello, it's me again, I noticed then these steps: 1) dial 2 calls bgapi originate {ignore_early_media=true}sofia/gateway/agent_gateway/2500 &park() bgapi originate {ignore_early_media=true}sofia/gateway/g2/2501 &park() 2) bridge them bgapi uuid_transfer f0c0db16-f00f-4b0b-8a00-d3b108d121b2 intercept:a85fd47e-051f-42ea-987e-f4e090c7ae78,park inline 3) put the 2nd call on hold: uuid_hold a85fd47e-051f-42ea-987e-f4e090c7ae78 4) hangup the 2nd call uuid_kill a85fd47e-051f-42ea-987e-f4e090c7ae78 cause the 1st call to be hanged up as well. I want it to be parked in this situation. When I set the [park_after_bridge=true] var in dialstring, it works just like I want it to. Is setting this variable the proper way of accomplishing it - keeping channel alive when the other leg put on hold hangs up? Thanks, Maciej Aniserowicz -- View this message in context: http://n2.nabble.com/When-leg-on-hold-hangs-up-another-leg-is-hanged-up-too-... Sent from the freeswitch-users mailing list archive at Nabble.com.
since you are controlling the call process, why not just use uuid_park? http://wiki.freeswitch.org/wiki/Mod_commands#uuid_park On Wed, Mar 24, 2010 at 8:14 AM, Maciej Aniserowicz < maciej.aniserowicz@gmail.com> wrote:
Hello, it's me again,
I noticed then these steps:
1) dial 2 calls
bgapi originate {ignore_early_media=true}sofia/gateway/agent_gateway/2500 &park() bgapi originate {ignore_early_media=true}sofia/gateway/g2/2501 &park()
2) bridge them
bgapi uuid_transfer f0c0db16-f00f-4b0b-8a00-d3b108d121b2 intercept:a85fd47e-051f-42ea-987e-f4e090c7ae78,park inline
3) put the 2nd call on hold:
uuid_hold a85fd47e-051f-42ea-987e-f4e090c7ae78
4) hangup the 2nd call
uuid_kill a85fd47e-051f-42ea-987e-f4e090c7ae78
cause the 1st call to be hanged up as well.
I want it to be parked in this situation.
When I set the [park_after_bridge=true] var in dialstring, it works just like I want it to. Is setting this variable the proper way of accomplishing it - keeping channel alive when the other leg put on hold hangs up?
Thanks, Maciej Aniserowicz -- View this message in context: http://n2.nabble.com/When-leg-on-hold-hangs-up-another-leg-is-hanged-up-too-... Sent from the freeswitch-users mailing list archive at Nabble.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
-- -Rupa
The 2nd call can be hanged up manually too, not only from my app by uuid_kill. I use the uuid_kill scenario just for tests, to see how it behaves. -- View this message in context: http://n2.nabble.com/When-leg-on-hold-hangs-up-another-leg-is-hanged-up-too-... Sent from the freeswitch-users mailing list archive at Nabble.com.
either way is fine. when you hangup up a bridged call the A leg returns to the execute state and since there are no more apps to execute it hangs up (desired default behavior) setting park_after_bridge was designed for your desired result of the call returning to a park state to await further instructions. On Wed, Mar 24, 2010 at 10:25 AM, Maciej Aniserowicz < maciej.aniserowicz@gmail.com> wrote:
The 2nd call can be hanged up manually too, not only from my app by uuid_kill. I use the uuid_kill scenario just for tests, to see how it behaves. -- View this message in context: http://n2.nabble.com/When-leg-on-hold-hangs-up-another-leg-is-hanged-up-too-... Sent from the freeswitch-users mailing list archive at Nabble.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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
participants (3)
-
Anthony Minessale
-
Maciej Aniserowicz
-
Rupa Schomaker