I'm having some difficulty with Freeswitch/Erlang processing. An operator dials in and registers by entering a PIN code, which triggers an Erlang event handler callback and puts the call into park. This works. A customer calls in, which triggers another Erlang event handler callback and puts the call into park. That works, too. Another thread of Erlang checks the operator and customer queues, and uses uuid_bridge to join the two calls together. That also works. What _doesn't_ work is that when the customer hangs up, I want the operator A leg to go back into a park state, and it's hanging up instead. One suspicion I have is that because there is no dialplan associated with the call (it's controlled by Erlang), there is no dialplan to "continue" by setting hangup_after_bridge=false. Either that or maybe I need to set the variables on the new UUID returned by the uuid_bridge command (though I thought that UUID was just the UUID assigned to the command, not a new call identifier.) BTW, "pbx" is just an OTP rewrite of pieces of the standard "freeswitch.erl" code. pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid ++ " hangup_after_bridge false" ), pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid ++ " park_after_bridge true" ), BridgeResult = pbx:api( uuid_bridge, Operator#pbx_operator_registry.operator_uuid ++ " " ++ Customer#pbx_cust_queue.uuid ), -- Mark Sobkow Senior Developer MarkeTel Multi-Line Dialing Systems LTD. 428 Victoria Ave Regina, SK S4N-0P6 Toll-Free: 800-289-8616-X533 Local: 306-359-6893-X533 Fax: 306-359-6879 Email: m.sobkow@marketelsystems.com Web: http://www.marketelsystems.com
On Thu, Mar 04, 2010 at 12:36:23PM -0600, Mark Sobkow wrote:
I'm having some difficulty with Freeswitch/Erlang processing. An operator dials in and registers by entering a PIN code, which triggers an Erlang event handler callback and puts the call into park. This works.
A customer calls in, which triggers another Erlang event handler callback and puts the call into park. That works, too.
Another thread of Erlang checks the operator and customer queues, and uses uuid_bridge to join the two calls together. That also works.
What _doesn't_ work is that when the customer hangs up, I want the operator A leg to go back into a park state, and it's hanging up instead. One suspicion I have is that because there is no dialplan associated with the call (it's controlled by Erlang), there is no dialplan to "continue" by setting hangup_after_bridge=false. Either that or maybe I need to set the variables on the new UUID returned by the uuid_bridge command (though I thought that UUID was just the UUID assigned to the command, not a new call identifier.)
BTW, "pbx" is just an OTP rewrite of pieces of the standard "freeswitch.erl" code.
pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid ++ " hangup_after_bridge false" ), pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid ++ " park_after_bridge true" ),
Try using park_after_bridge and catch the park event or transfer_after_bridge and set the dialplan location to transfer the call to. Andrew
"Hello this is the United States Calling are we reaching... *click* See!, he keeps hanging up, is there supposed to be someone there besides your wife sir?" On Thu, Mar 4, 2010 at 12:47 PM, Andrew Thompson <andrew@hijacked.us> wrote:
On Thu, Mar 04, 2010 at 12:36:23PM -0600, Mark Sobkow wrote:
I'm having some difficulty with Freeswitch/Erlang processing. An operator dials in and registers by entering a PIN code, which triggers an Erlang event handler callback and puts the call into park. This works.
A customer calls in, which triggers another Erlang event handler callback and puts the call into park. That works, too.
Another thread of Erlang checks the operator and customer queues, and uses uuid_bridge to join the two calls together. That also works.
What _doesn't_ work is that when the customer hangs up, I want the operator A leg to go back into a park state, and it's hanging up instead. One suspicion I have is that because there is no dialplan associated with the call (it's controlled by Erlang), there is no dialplan to "continue" by setting hangup_after_bridge=false. Either that or maybe I need to set the variables on the new UUID returned by the uuid_bridge command (though I thought that UUID was just the UUID assigned to the command, not a new call identifier.)
BTW, "pbx" is just an OTP rewrite of pieces of the standard "freeswitch.erl" code.
pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid ++ " hangup_after_bridge false" ), pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid ++ " park_after_bridge true" ),
Try using park_after_bridge and catch the park event or transfer_after_bridge and set the dialplan location to transfer the call to.
Andrew
_______________________________________________ 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> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
On Thu, Mar 4, 2010 at 2:35 PM, Mark Sobkow <m.sobkow@marketelsystems.com>wrote:
Andrew Thompson wrote:
On Thu, Mar 04, 2010 at 12:36:23PM -0600, Mark Sobkow wrote:
I'm having some difficulty with Freeswitch/Erlang processing. An operator dials in and registers by entering a PIN code, which triggers an Erlang event handler callback and puts the call into park. This works.
A customer calls in, which triggers another Erlang event handler callback and puts the call into park. That works, too.
Another thread of Erlang checks the operator and customer queues, and uses uuid_bridge to join the two calls together. That also works.
What _doesn't_ work is that when the customer hangs up, I want the operator A leg to go back into a park state, and it's hanging up instead. One suspicion I have is that because there is no dialplan associated with the call (it's controlled by Erlang), there is no dialplan to "continue" by setting hangup_after_bridge=false. Either that or maybe I need to set the variables on the new UUID returned by the uuid_bridge command (though I thought that UUID was just the UUID assigned to the command, not a new call identifier.)
BTW, "pbx" is just an OTP rewrite of pieces of the standard "freeswitch.erl" code.
pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid ++ " hangup_after_bridge false" ), pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid ++ " park_after_bridge true" ),
Try using park_after_bridge and catch the park event or transfer_after_bridge and set the dialplan location to transfer the call to.
Andrew
What a relief. "transfer_after_bridge" worked! Plus it provided an obvious way for me to collect the call result code, fire it back to Erlang, and leave the operator waiting for the next incoming call. :)
"Another satisfied customer!" :D Now it's time to throw some of that Canadian colored money at Tony's paypal account. ;) BTW, what kind of solution are you developing? -MC
On Thu, Mar 4, 2010 at 3:40 PM, Andrew Thompson <andrew@hijacked.us> wrote:
On Thu, Mar 04, 2010 at 03:00:12PM -0800, Michael Collins wrote:
"Another satisfied customer!" :D Now it's time to throw some of that Canadian colored money at Tony's paypal account. ;)
Hey! I wrote the erlang module and provided the solution to the problem ;)
ok ok. what's your paypal account? We'll give you some love too. :) -MC
I spoke with "the boss" today, and he's hoping to do a donation at month end if our accountant can confirm that it can be taken as a tax writeoff (I suggested it's an alternative way of paying for software, so it should be write-offable.) Andrew Thompson wrote:
On Thu, Mar 04, 2010 at 03:00:12PM -0800, Michael Collins wrote:
"Another satisfied customer!" :D Now it's time to throw some of that
Canadian colored money at Tony's paypal account. ;)
Hey! I wrote the erlang module and provided the solution to the problem ;)
Andrew
_______________________________________________ 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
-- Mark Sobkow Senior Developer MarkeTel Multi-Line Dialing Systems LTD. 428 Victoria Ave Regina, SK S4N-0P6 Toll-Free: 800-289-8616-X533 Local: 306-359-6893-X533 Fax: 306-359-6879 Email: m.sobkow@marketelsystems.com Web: http://www.marketelsystems.com
Try using park_after_bridge and catch the park event or transfer_after_bridge and set the dialplan location to transfer the call to.
Andrew
What a relief. "transfer_after_bridge" worked! Plus it provided an obvious way for me to collect the call result code, fire it back to Erlang, and leave the operator waiting for the next incoming call. :)
"Another satisfied customer!" :D Now it's time to throw some of that Canadian colored money at Tony's paypal account. ;) BTW, what kind of solution are you developing? -MC Tech support call center solution right now, with bidirectional calling. If a customer calls in and no one is available, they have the option of requesting a callback instead of waiting online, so both inbound and outbound calls have to be handled. I'm also having fun with skill-based routing of calls (which is more complex than mod_fifo can handle.)
"Another satisfied customer!" :D Now it's time to throw some of that Canadian colored money at Tony's paypal account. ;) BTW, what kind of solution are you developing? -MC Tech support call center solution right now, with bidirectional calling. If a customer calls in and no one is available, they have the option of requesting a callback instead of waiting online, so both inbound and outbound calls have to be handled. I'm also having fun with skill-based routing of calls (which is more complex than mod_fifo can handle.)
Very interesting. Okay, keep us posted on how your setup is coming along. You might also want to join the Wednesday morning conference calls and talk to some of the other users as well as listen to some of the presentations. Next week Math will be discussing mod_sofia in excruciating detail. :) -MC
Better clear your schedule for a few days for that talk :P /b On Mar 5, 2010, at 11:24 AM, Michael Collins wrote:
Very interesting. Okay, keep us posted on how your setup is coming along. You might also want to join the Wednesday morning conference calls and talk to some of the other users as well as listen to some of the presentations. Next week Math will be discussing mod_sofia in excruciating detail. :)
-MC
participants (6)
-
Andrew Thompson
-
Anthony Minessale
-
Brian West
-
Mark Sobkow
-
Michael Collins
-
Yossi Neiman