On Thu, Feb 4, 2010 at 10:41 PM, Nagalenoj H.
<nagalenoj@gmail.com> wrote:
Sorry., I couldn't understand its behavior.
Let me ask the same question in this way.
* hangup_after_bridge is set to false.
* In outbound socket, first I answer the call.
* When I do a bridge to a extension (1001), after 1001 disconnects the call. I am able to make another call.
sendmsg
call-command: execute
execute-app-name: bridge
execute-app-arg: user/1001
* When I originate a call to extension (1001), after 1001 disconnects the call. I'm unable to make another call, because my session is also getting closed.
api originate user/1001 &park
Content-Type: api/response
Content-Length: 41
+OK 1fac17ce-120b-11df-a878-d9c7fbcf71c4
sendmsg
call-command: execute
execute-app-name: intercept
execute-app-arg: 1fac17ce-120b-11df-a878-d9c7fbcf71c4
* In both the case, the call is getting bridged to an extension and hangup_after_bridge is false.
* When bridge doesn't need any other variables to set to continue, why intercept needs a explicit park after bridge.?
Hope, this has some clarity.,On Thu, Feb 4, 2010 at 9:24 PM, Anthony Minessale
<anthony.minessale@gmail.com> wrote:
2010-02-04 14:30:09.574084 [DEBUG] switch_core_state_machine.c:354 (sofia/internal/1010@192.168.1.222) State SOFT_EXECUTE going to sleep
2010-02-04 14:30:09.574084 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/1010@192.168.1.222) Running State Change CS_EXECUTE
2010-02-04 14:30:09.574084 [DEBUG] switch_core_state_machine.c:348 (sofia/internal/1010@192.168.1.222) State EXECUTE
2010-02-04 14:30:09.574084 [DEBUG] mod_sofia.c:181 sofia/internal/1010@192.168.1.222 SOFIA EXECUTE
2010-02-04 14:30:09.574084 [DEBUG] switch_core_state_machine.c:159 sofia/internal/1010@192.168.1.222 Standard EXECUTE
2010-02-04 14:30:09.574084 [NOTICE] switch_core_state_machine.c:187 Hangup sofia/internal/1010@192.168.1.222 [CS_EXECUTE] [NORMAL_CLEARING]
Your channel went back to EXECUTE as expected then it hungup because there were no more instructions in your dial plan for it to execute. So it is working as expected.
Consider using transfer_after_bridge variable or park_after bridge to make it stay around when the call is over.
On Thu, Feb 4, 2010 at 6:52 AM, Nagalenoj H.
<nagalenoj@gmail.com> wrote:
By using create_uuid. I've also tried without giving origination_uuid. But, the result is same.--
Regards,
Nagalenoj H.
On Thu, Feb 4, 2010 at 5:42 PM, Brian West
<brian@freeswitch.org> wrote:
Where are you getting this UUID?
/b
On Feb 4, 2010, at 3:32 AM, Nagalenoj H. wrote:
> api originate {origination_uuid=c6d2e0e2-0b2f-11df-9e84-fb15c3cd8565}user/1001 &park
_______________________________________________
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
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900
_______________________________________________
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
Regards,
Nagalenoj H.
_______________________________________________
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