Srikant Posted November 1, 2019 Report Share Posted November 1, 2019 Hi , I am trying to hangup during a call through a meta flow , When the post is issued i am able to see the message as "recv metaflow exe request for " but the call want hangup , below is the post request { "data": { "numbers": { "123": { "module": "hangup", "data": { "id": "ec31008f274d9e5e27b7d90b79563689" } } }, "binding_digit": "*", "listen_on": "both" } } and the invocation post request { "data": { "action": "hangup" } } The logging are as below ===================================================== Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|cb_channels:479(<0.32330.0>) attempting to hangup 2713-0-1174759168@172.31.1.138 Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|kz_amqp_worker:252(<0.32330.0>) application ranch checked out worker <0.3379.0> from pool kz_amqp_pool Nov 1 14:40:25 sandbox 2600hz[16081]: |2713-0-1174759168@172.31.1.138|kz_amqp_channel:245(<0.3379.0>) published to metaflow(direct 236B) exchange (routing key metaflow.action.2713-0-1174759168%40172%2E31%2E1%2E138.hangup) via <0.3747.0> Nov 1 14:40:25 sandbox 2600hz[16081]: |2713-0-1174759168@172.31.1.138|kz_amqp_worker:737(<0.3379.0>) published message beba9b576c33dd7a for <0.32330.0> Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|crossbar_bindings:90(<0.32330.0>) folding v2_resource.billing Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_util:1098(<0.32330.0>) billing returned accepted Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_resource:689(<0.32330.0>) requested resource update validated Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_resource:546(<0.32330.0>) run: content_types_accepted Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|crossbar_bindings:90(<0.32330.0>) folding v2_resource.content_types_accepted.channels Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_resource:560(<0.32330.0>) checking content type '{<<"application">>,<<"json">>,[]}' against accepted Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_resource:608(<0.32330.0>) no content-types accepted, using defaults Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_resource:617(<0.32330.0>) cta: [{{<<"application">>,<<"json">>,[]},from_json}] Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_resource:776(<0.32330.0>) run: from_json Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|crossbar_bindings:90(<0.32330.0>) folding v2_resource.execute.post.channels Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_resource:804(<0.32330.0>) content-type provided is to_json Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_util:1707(<0.32330.0>) adding resp header content-type: <<"application/json">> Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_resource:255(<0.32330.0>) session finished: normal Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|api_resource:268(<0.32330.0>) POST request fulfilled in 19 ms 211K664B mem 5K641B bin Nov 1 14:40:25 sandbox 2600hz[16081]: |a05adfc5a177e2b61e1ef70c12827d70|crossbar_bindings:78(<0.32340.0>) pmapping v2_resource.finish_request.POST.channels Nov 1 14:40:25 sandbox 2600hz[16081]: |2713-0-1174759168@172.31.1.138|konami_code_statem:224(<0.32307.0>) recv metaflow exe request for 2713-0-1174759168@172.31.1.138, processing in <0.32343.0> Nov 1 14:40:25 sandbox 2600hz[16081]: |2713-0-1174759168@172.31.1.138|konami_hangup:22(<0.32343.0>) attempting to hangup 2713-0-1174759168@172.31.1.138 Nov 1 14:40:25 sandbox 2600hz[16081]: |2713-0-1174759168@172.31.1.138|konami_code_exe:26(<0.32343.0>) continuing to default child from konami_hangup Nov 1 14:40:25 sandbox 2600hz[16081]: |2713-0-1174759168@172.31.1.138|konami_code_exe:15(<0.32343.0>) no metaflow to execute Nov 1 14:40:26 sandbox 2600hz[16081]: |a090680a8a7e149a17f28bb13acafb9e|kz_amqp_channel:221(<0.4105.0>) published(78942f7967ccba62552d9926a5165b0b 1K) to nodes(amqp://guest:guest@127.0.0.1:5672) exchange (routing key ) via <0.4061.0> Nov 1 14:40:34 sandbox 2600hz[16081]: |bdd47095-db7f-42c1-a8c1-e1f0abea85e0|kz_amqp_channel:221(<0.4105.0>) published(ea1cc1050e6320a9f9e33698ced0b66b 1K) to nodes(amqp://guest:guest@127.0.0.1:5672) exchange (routing key ) via <0.4061.0> Nov 1 14:40:34 sandbox 2600hz[16081]: |knm_port_request_crawler|knm_port_request_crawler:132(<0.32367.0>) port_request crawler completed a full crawl in 3ms Thanks Srikant v Quote Link to comment Share on other sites More sharing options...
2600Hz Employees mc_ Posted November 1, 2019 2600Hz Employees Report Share Posted November 1, 2019 You will need to get the ecallmgr logs to see if the hangup was received or check the FreeSWITCH logs to see if uuid_kill was issued. Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 4, 2019 Author Report Share Posted November 4, 2019 (edited) Hi MC_, We have checked Freeswitch logs to check for "uuid_kill" , the command is getting received but still the ongoing call is continuing , don't know why this is happening , we have tried to invoke the metaflow from both PUT and POST , from put request it is not working but from post we are able to send the metaflow using crossbar API, we can see from the logs that the control is going to the "kapi-dialplan.erl" class Also we have observed from the logs that the command "uuid_kill" is received earlier then we are seeing "Hangup" messages , this is bit confusing for us to understand For your reference i am attaching both the kazoo and free switch logs Edited November 13, 2019 by Srikant (see edit history) Quote Link to comment Share on other sites More sharing options...
Vijay Posted November 4, 2019 Report Share Posted November 4, 2019 Hi mc_, Could you please confirm If a metaflow can be Invoked through only PUT or POST can also be used. And any documentation with sample metaflow to understand the workings of metaflow through Kazoo. Regards, Vijay Quote Link to comment Share on other sites More sharing options...
2600Hz Employees mc_ Posted November 4, 2019 2600Hz Employees Report Share Posted November 4, 2019 @Srikant sorry, I'm not seeing KAZOO debug logs in your attachments. Can you increase logging to debug and make another attempt. Grab the call-id and use that when grepping the logs. @Vijay https://docs.2600hz.com/dev/applications/crossbar/doc/metaflows/ Do note that Konami is the community-supported version at the moment. Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 6, 2019 Author Report Share Posted November 6, 2019 (edited) Hi MC , Thanks for your prompt response After doing some more testing on the metaflow we are now in a position where we can see that the request is posted to the ecall manager control queue , and we are lost here when the message for the metaflow execution has gone after published to callctl and is terminating after that and what could be reason Nov 6 12:45:29 sandbox 2600hz[20724]: |2820-0-1599794758@172.31.1.138|kz_amqp_channel:245(<0.3339.0>) published to callctl(direct 252B) exchange (routing key ecallmgr@sandbox.testcomp.com-ecallmgr_call_control-<0.363.4>-35669c98) via <0.3537.0> Nov 6 12:45:29 sandbox 2600hz[20724]: |2820-0-1599794758@172.31.1.138|kz_amqp_worker:737(<0.3339.0>) published message d7feeebf951593da for <0.13241.8> Nov 6 12:45:29 sandbox 2600hz[20724]: |2820-0-1599794758@172.31.1.138|cf_exe:676(<0.13241.8>) callflow execution has been stopped: normal Nov 6 12:45:29 sandbox 2600hz[20724]: |2820-0-1599794758@172.31.1.138|kz_amqp_channel:135(<0.13241.8>) release consumer <0.13241.8> channel assignment Nov 6 12:45:29 sandbox 2600hz[20724]: |kz_amqp_assignments|kz_amqp_assignments:914(<0.3132.0>) unregistered handlers for channel <0.23322.7> Nov 6 12:45:29 sandbox 2600hz[20724]: |2820-0-1599794758@172.31.1.138|gen_listener:803(<0.13241.8>) cf_exe terminated cleanly, going down Nov 6 12:45:29 sandbox 2600hz[20724]: |kz_amqp_assignments|kz_amqp_channel:144(<0.3132.0>) closed amqp channel <0.23322.7> Nov 6 12:45:29 sandbox 2600hz[20724]: |kz_amqp_assignments|kz_amqp_assignments:291(<0.3132.0>) removed assignment for consumer <0.13241.8> Nov 6 12:45:29 sandbox 2600hz[20724]: |2820-0-1599794758@172.31.1.138|webhooks_channel_util:32(<0.13370.8>) evt CHANNEL_DESTROY for 1721424dfecd2fb219e366370ca9ab36 Can you show us some pointers in resolving our current situation , Currently we are using the basic metaflow of break as through POST request { "data": { "action":"break" } } Below is what we have posted on accounts { "data": { "module": "break" } } Let us know if we are doing any mistakes in the posted events Also for your reference i have added the entire kazoo log and freeswitch log Thanks Srikant V Edited November 13, 2019 by Srikant (see edit history) Quote Link to comment Share on other sites More sharing options...
2600Hz Employees mc_ Posted November 6, 2019 2600Hz Employees Report Share Posted November 6, 2019 The control queue is "ecallmgr@sandbox.testcomp.com-ecallmgr_call_control-<0.363.4>-35669c98". This tells you that the control queue is on the "ecallmgr@sandbox.testcomp.com" Erlang VM, an "ecallmgr_call_control" process at PID "0.363.4". Your logs, afaict, don't include the logs for that PID. You may need to increase ecallmgr's log level. sup, by default, talks to kazoo_apps@{hostname}. You can include "-necallmgr" to run commands against the ecallmgr VM: "sup -necallmgr kazoo_maintenance syslog_level debug" for instance. Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 7, 2019 Author Report Share Posted November 7, 2019 (edited) Hi MC , Thank you for the quick suggestion , now we are able to see the debug logs for ecallmgr When checked in the logs we found that the metaflow POST "break " which we posted is been published to "metaflow(direct 235B) exchange (routing key metaflow.action.2841-0-1676611348%40172%2E31%2E1%2E138.break) via <0.3947.0>" , but after that we dint see any receive message , we are lost here as we don't know why the "metaflow" exchange is not accepting and processing the message with the routing key , Also we checked in the rabbitmq that no queue or the exchange metaflow is receiving the message with the above mentioned routing key , we have configured the following queues are configured in rabbitmq for metaflow exchnage , and we are not sure if the queue will be konami_listener or some thing else , please show us some light on this To Routing key Arguments konami_listener metaflow.action.* konami_listener metaflow.bind.* konami_listener metaflow.flow.* konami_listener metaflow.flow.*.* Error Log (Kazoo.log) ------------------------------------------------------ Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|cb_channels:490(<0.11815.15>) attempting to break 2841-0-1676611348@172.31.1.138 Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|kz_amqp_worker:252(<0.11815.15>) application ranch checked out worker <0.3470.0> from pool kz_amqp_pool Nov 7 10:05:44 sandbox 2600hz[20724]: |2841-0-1676611348@172.31.1.138|kz_api:246(<0.3470.0>) inside kzapi setmissingvalues is prop is Nov 7 10:05:44 sandbox 2600hz[20724]: |2841-0-1676611348@172.31.1.138|kz_api:246(<0.3470.0>) inside kzapi setmissingvalues is prop is Nov 7 10:05:44 sandbox 2600hz[20724]: |2841-0-1676611348@172.31.1.138|kz_amqp_channel:245(<0.3470.0>) published to metaflow(direct 235B) exchange (routing key metaflow.action.2841-0-1676611348%40172%2E31%2E1%2E138.break) via <0.3947.0> Nov 7 10:05:44 sandbox 2600hz[20724]: |2841-0-1676611348@172.31.1.138|kz_amqp_worker:737(<0.3470.0>) published message d08a3ae4619f46d2 for <0.11815.15> Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|crossbar_bindings:90(<0.11815.15>) folding v2_resource.billing Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_util:1098(<0.11815.15>) billing returned accepted Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_resource:689(<0.11815.15>) requested resource update validated Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_resource:546(<0.11815.15>) run: content_types_accepted Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|crossbar_bindings:90(<0.11815.15>) folding v2_resource.content_types_accepted.channels Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_resource:560(<0.11815.15>) checking content type '{<<"application">>,<<"json">>,[]}' against accepted Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_resource:608(<0.11815.15>) no content-types accepted, using defaults Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_resource:617(<0.11815.15>) cta: [{{<<"application">>,<<"json">>,[]},from_json}] Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_resource:776(<0.11815.15>) run: from_json Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|crossbar_bindings:90(<0.11815.15>) folding v2_resource.execute.post.channels Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_resource:804(<0.11815.15>) content-type provided is to_json Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_util:1707(<0.11815.15>) adding resp header content-type: <<"application/json">> Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_resource:255(<0.11815.15>) session finished: normal Nov 7 10:05:44 sandbox 2600hz[20724]: |47737045e6aef03be5bee2bf4149ab1d|api_resource:268(<0.11815.15>) POST request fulfilled in 20 ms 32K720B mem 4K819B bin Edited November 13, 2019 by Srikant (see edit history) Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 8, 2019 Author Report Share Posted November 8, 2019 (edited) Hi Mc_, We are also trying to post a metaflow using the DTMF there also we were not successful and the metaflow is not invoked , for invoking the metaflows we are posting the metaflow as below on channels { "data":{ "numbers":{ "234":{ "module":"play", "data":{ } } }, "binding_digit":"*", "listen_on":"both" } } But after calling the number when ever we are trying to press '*' the call is getting hangup and we can see in the logs that the metaflow is not invoked , Please show us a path if we are doing anything wrong For your reference Kazoo.log and free switch logs are attached Please let us know your feedback on both the above posts as we are eagerly waiting for some response published(9ea0e86ffee8b37f87f91e96a3975328 1K) to nodes(amqp://guest:guest@127.0.0.1:5672) exchange (routing key ) via <0.4062.0> Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|ecallmgr_call_events:620(<0.7331.0>) publishing received DTMF digit * Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|kz_amqp_worker:252(<0.7331.0>) application ecallmgr checked out worker <0.3682.0> from pool kz_amqp_pool Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|kz_api:246(<0.3682.0>) inside kzapi setmissingvalues is prop is Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|kz_api:246(<0.3682.0>) inside kzapi setmissingvalues is prop is Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|kz_amqp_channel:245(<0.3682.0>) published to callevt(direct 867B) exchange (routing key call.DTMF.2891-0-1768239268%40172%2E31%2E1%2E138) via <0.3906.0> Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|kz_amqp_worker:737(<0.3682.0>) published message 1573212789517658 for <0.7331.0> Nov 8 11:33:09 sandbox 2600hz[7360]: |2891-0-1768239268@172.31.1.138|cf_util:677(<0.9927.0>) recv DTMF *, adding to default Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|ecallmgr_call_events:632(<0.7331.0>) publishing call event channel_execute_complete 'play(silence_stream://60000)' result: file played Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|ecallmgr_call_control:579(<0.7332.0>) play finished, checking for group-id/DTMF termination Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|ecallmgr_call_control:584(<0.7332.0>) DTMF * terminated playback, flushing all with group id undefined Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|ecallmgr_call_control:1056(<0.7332.0>) executing call command 'noop' ccf318c4e12e8731f52605b89b3a10cf Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|kz_amqp_worker:252(<0.7331.0>) application ecallmgr checked out worker <0.3683.0> from pool kz_amqp_pool Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|kz_api:246(<0.3683.0>) inside kzapi setmissingvalues is prop is Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|kz_api:246(<0.3683.0>) inside kzapi setmissingvalues is prop is Nov 8 11:33:09 sandbox 2600hz[7641]: |2891-0-1768239268@172.31.1.138|kz_amqp_channel:245(<0.3683.0>) published to callevt(direct 1K) exchange (routing key call.CHANNEL_EXECUTE_COMPLETE.2891-0-1768239268%40172%2E31%2E1%2E138) via <0.3910.0> Edited November 13, 2019 by Srikant (see edit history) Quote Link to comment Share on other sites More sharing options...
2600Hz Employees mc_ Posted November 8, 2019 2600Hz Employees Report Share Posted November 8, 2019 Your pivot response is to play silence for 60s but you don't specify DTMF terminators so when you press '*' the playback of silence is cancelled. Then because you have no more callflow actions, the call is hung up. Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 11, 2019 Author Report Share Posted November 11, 2019 Hi MC_ , Thanks for the suggestion , but as you said i also tried adding terminators to the metaflow on accounts but still facing the same issue , the call is getting disconnected on pressing * , Below is the metaflow posted on accounts { "data":{ "numbers":{ "234":{ "module":"play", "data":{ } } }, "binding_digit":"*", "listen_on":"both", "terminators": ["5","6"] } } Please let me know if any thing i need to change in the metaflow , or if you have some sample basic metaflow it would be a great help below are the kazoo logs, Where i can see the catched terminators are printing as "[<<"#">>,<<"*">>,<<"0">>,<<"1">>,<<"2">>,<<"3">>,<<"4">>,<<"5">>,<<"6">>,<<"7">>,<<"8">>,<<"9">>]" is this an issue --------------------------------------------- LOGS --------------------------------------------- Nov 11 10:14:21 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|cf_route_req:212(<0.13348.0>) callflow up & running Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_util:169(<0.8730.0>) execute on node freeswitch@sandbox.servenova.com(2927-0-2022706288@172.31.1.138) answer(): ok Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:903(<0.8730.0>) received control queue flush command, clearing all waiting commands Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:957(<0.8730.0>) inserting at the tail of the control queue call command noop(0edcb5a2540f955258080867b3c1bffe) Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:960(<0.8730.0>) inserting at the tail of the control queue call command play Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:957(<0.8730.0>) inserting at the tail of the control queue call command noop(8d3aaa28d5b05217367adc2e30b9cb34) Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:566(<0.8730.0>) answer execute complete, advancing control queue Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:1056(<0.8730.0>) executing call command 'noop' 0edcb5a2540f955258080867b3c1bffe Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_events:632(<0.8729.0>) publishing call event channel_execute_complete 'noop()' result: 0edcb5a2540f955258080867b3c1bffe Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_worker:252(<0.8729.0>) application ecallmgr checked out worker <0.3321.0> from pool kz_amqp_pool Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_channel:245(<0.3321.0>) published to callevt(direct 1K) exchange (routing key call.CHANNEL_EXECUTE_COMPLETE.2927-0-2022706288%40172%2E31%2E1%2E138) via <0.3459.0> Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_worker:737(<0.3321.0>) published message 1573467261457633 for <0.8729.0> Nov 11 10:14:21 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|cf_util:672(<0.13374.0>) ignoring noop 1573467261457633(0edcb5a2540f955258080867b3c1bffe) (waiting for 8d3aaa28d5b05217367adc2e30b9cb34) Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_util:169(<0.8730.0>) execute on node freeswitch@sandbox.servenova.com(2927-0-2022706288@172.31.1.138) event(Event-Subclass=kazoo::noop,Event-Name=CUSTOM,kazoo_event_name=CHANNEL_EXECUTE_COMPLETE,kazoo_application_name=noop,kazoo_application_response=0edcb5a2540f955258080867b3c1bffe): ok Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:508(<0.8730.0>) received control queue unconditional advance, skipping wait for command completion of 'noop' Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:1056(<0.8730.0>) executing call command 'play' 92e69eaafc69c1ad53c5730935747617 Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_command:1428(<0.8730.0>) cached terminators: [<<"#">>,<<"*">>,<<"0">>,<<"1">>,<<"2">>,<<"3">>,<<"4">>,<<"5">>,<<"6">>,<<"7">>,<<"8">>,<<"9">>] Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_fs_channel:163(<0.8730.0>) channel is not bridged Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_fs_channel:735(<0.8752.0>) channel has ecallmgr ecallmgr@sandbox.servenova.com (we are ecallmgr@sandbox.servenova.com) Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_fs_channel:767(<0.8752.0>) no 'Realm' in CCVs, checking FS props Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_fs_channel:777(<0.8752.0>) no realm found in 'variable_domain_name' in FS props Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_fs_channel:757(<0.8752.0>) no username in CCVs or variable_user_name Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_fs_channels:208(<0.8752.0>) updating channel properties: [{5,<<"1721424dfecd2fb219e366370ca9ab36">>},{20,true},{8,<<"resource">>},{14,<<"2927-0-2022706288@172.31.1.138">>},{40,<<"2b596bcb02a0055a8931f2cf344f03f2">>},{42,[]},{26,<<"context_2">>},{3,<<"+17073066285">>},{27,<<"XML">>},{4,<<"inbound">>},{13,<<"06eeb436-046c-11ea-bad9-ad2fc91653de">>},{31,<<"sansay4775rdb21">>},{29,true},{19,true},{32,<<"63740686460-155064c8">>},{9,<<"true">>},{37,false},{28,5},{12,<<"+914067667300@172.31.1.139">>},{25,<<"sipinterface_1">>},{11,<<"384efa0ba3d0447d6be0a9b4439dd746">>},{30,<<"aZU4jaZKtra5S">>},{35,<<"+914067667300">>},{36,<<"+914067667300">>}] Nov 11 10:14:21 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_util:169(<0.8730.0>) execute on node freeswitch@sandbox.servenova.com(2927-0-2022706288@172.31.1.138) kz_multiset(playback_terminators=#*0123456789): ok Nov 11 10:14:22 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_util:169(<0.8730.0>) execute on node freeswitch@sandbox.servenova.com(2927-0-2022706288@172.31.1.138) playback(silence_stream://60000): ok Nov 11 10:14:22 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:554(<0.8730.0>) received noop execute complete with incorrect id 0edcb5a2540f955258080867b3c1bffe (expecting 92e69eaafc69c1ad53c5730935747617) Nov 11 10:14:22 sandbox 2600hz[26044]: |kz_account_crawler|kz_account_crawler:181(<0.5192.0>) crawling account 1721424dfecd2fb219e366370ca9ab36 Nov 11 10:14:22 sandbox 2600hz[26044]: |kz_account_crawler|kz_account_crawler:201(<0.5192.0>) account crawler processing account 1721424dfecd2fb219e366370ca9ab36 Nov 11 10:14:22 sandbox 2600hz[26044]: |kz_account_crawler|kazoo_bindings:765(<0.5192.0>) exact match for tasks.account_crawler Nov 11 10:14:22 sandbox 2600hz[26044]: |0000000000|kt_initial_occurrence:110(<0.13380.0>) looking for initial call in account 1721424dfecd2fb219e366370ca9ab36 Nov 11 10:14:22 sandbox 2600hz[26044]: |0000000000|kt_low_balance:77(<0.13379.0>) checking topup for account 1721424dfecd2fb219e366370ca9ab36 with balance $0.0 Nov 11 10:14:22 sandbox 2600hz[26044]: |0000000000|kt_low_balance:83(<0.13379.0>) topup failed for 1721424dfecd2fb219e366370ca9ab36: topup_disabled Nov 11 10:14:22 sandbox 2600hz[26044]: |0000000000|kt_low_balance:91(<0.13379.0>) checking if account 1721424dfecd2fb219e366370ca9ab36 balance $0.0 is below notification threshold $5.0 Nov 11 10:14:22 sandbox 2600hz[26044]: |0000000000|kt_low_balance:126(<0.13379.0>) low balance notification enabled key not present, using deprecated check Nov 11 10:14:22 sandbox 2600hz[26044]: |0000000000|kt_low_balance:152(<0.13379.0>) low balance alert already sent Nov 11 10:14:22 sandbox 2600hz[26044]: |kz_account_crawler|kz_account_crawler:127(<0.5192.0>) account crawler completed a full crawl Nov 11 10:14:23 sandbox 2600hz[26322]: |784b8088-9d5c-4989-8c96-a5fff1656ab7|kz_amqp_channel:221(<0.4105.0>) published(c9213d256b3df4c5fb32c44899e9b39a 1K) to nodes(amqp://guest:guest@127.0.0.1:5672) exchange (routing key ) via <0.4044.0> Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_events:620(<0.8729.0>) publishing received DTMF digit * Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_worker:252(<0.8729.0>) application ecallmgr checked out worker <0.3327.0> from pool kz_amqp_pool Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_channel:245(<0.3327.0>) published to callevt(direct 867B) exchange (routing key call.DTMF.2927-0-2022706288%40172%2E31%2E1%2E138) via <0.3464.0> Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_worker:737(<0.3327.0>) published message 1573467268877634 for <0.8729.0> Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_events:632(<0.8729.0>) publishing call event channel_execute_complete 'play(silence_stream://60000)' result: file played Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:579(<0.8730.0>) play finished, checking for group-id/DTMF termination Nov 11 10:14:28 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|cf_util:677(<0.13374.0>) recv DTMF *, adding to default Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:584(<0.8730.0>) DTMF * terminated playback, flushing all with group id undefined Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_control:1056(<0.8730.0>) executing call command 'noop' 8d3aaa28d5b05217367adc2e30b9cb34 Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_worker:252(<0.8729.0>) application ecallmgr checked out worker <0.3328.0> from pool kz_amqp_pool Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_channel:245(<0.3328.0>) published to callevt(direct 1K) exchange (routing key call.CHANNEL_EXECUTE_COMPLETE.2927-0-2022706288%40172%2E31%2E1%2E138) via <0.3469.0> Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_worker:737(<0.3328.0>) published message 1573467268877634 for <0.8729.0> Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|ecallmgr_call_events:632(<0.8729.0>) publishing call event channel_execute_complete 'noop()' result: 8d3aaa28d5b05217367adc2e30b9cb34 Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_worker:252(<0.8729.0>) application ecallmgr checked out worker <0.3329.0> from pool kz_amqp_pool Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_channel:245(<0.3329.0>) published to callevt(direct 1K) exchange (routing key call.CHANNEL_EXECUTE_COMPLETE.2927-0-2022706288%40172%2E31%2E1%2E138) via <0.3474.0> Nov 11 10:14:28 sandbox 2600hz[26322]: |2927-0-2022706288@172.31.1.138|kz_amqp_worker:737(<0.3329.0>) published message 1573467268897664 for <0.8729.0> Nov 11 10:14:28 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|cf_util:669(<0.13374.0>) noop 8d3aaa28d5b05217367adc2e30b9cb34 received Nov 11 10:14:28 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|cf_exe:428(<0.13356.0>) continuing to child '_' Nov 11 10:14:28 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|cf_exe:432(<0.13356.0>) wildcard child does not exist, we are lost...hanging up Nov 11 10:14:28 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|cf_exe:573(<0.13356.0>) cf module cf_pivot down normally Nov 11 10:14:28 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|cf_exe:448(<0.13356.0>) instructed to stop and no flows left Nov 11 10:14:28 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|kz_amqp_channel:507(<0.13356.0>) sending cancel for consumer amq.ctag-9YhsHJTbTsND_H_qrxW8bg to <0.5259.0> Nov 11 10:14:28 sandbox 2600hz[26044]: |2927-0-2022706288@172.31.1.138|kz_amqp_channel:509(<0.13356.0>) canceled consumer amq.ctag-9YhsHJTbTsND_H_qrxW8bg via channel <0.5259.0> Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 12, 2019 Author Report Share Posted November 12, 2019 (edited) Hi MC_ Today we have tried posting the terminators on pivot and we have observed that wen pressing on the given number for terminate the flow is terminating and child is playing Thanks for the help , it was very helpful But when trying to invoke the metaflow with the Binding Digit * and 2 the metaflow is not invoking and no any further actions are happenning Below is the meta flow which we posted on account {"action":"metaflow", "data": { "numbers":{ "2":{ "module":"break" } }, "binding_digit":"*", "listen_on":"self" } } According to this when the DTMF action happens * is the binding digit and when the number 2 is pressed the ongoing call / media should break which is not happening currently , can you please let us know if we are doing anything wrong or are there any more setting which need to be done For your reference the kazoo and kazoo-debug logs are attached it would be a great help if you can show us any pointers to it Thanks Srikant Edited November 19, 2019 by Srikant (see edit history) Quote Link to comment Share on other sites More sharing options...
2600Hz Employees mc_ Posted November 12, 2019 2600Hz Employees Report Share Posted November 12, 2019 Yeah no metaflow is being sent to Konami during call setup. Take a look in cf_route_win maybe_start_metaflow to see what it is looking for and what you've configured. Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 13, 2019 Author Report Share Posted November 13, 2019 (edited) Hi mc_ Thanks for your valuable suggestions, as suggested i tried looking in the code cf_route_win (maybe_start_metaflow) , Placed some loggers and checked , we found that in the below lines of code , the code flow is executing "maybe_start_endpoint_metaflow(_Call, 'undefined') -> 'ok';" but it never hit the method "maybe_start_endpoint_metaflow(Call, EndpointId) ->" as the EndpointId is undefined maybe_start_endpoint_metaflow(_Call, 'undefined') -> 'ok'; maybe_start_endpoint_metaflow(Call, EndpointId) -> Can you please suggest how that could be set or is there a way to pass the variable through metaflow We have checked printing the '_Call' variable where we didnt see our metaflow is a part of it Nov 13 10:44:22 sandbox 2600hz[27839]: |3055-0-2197286698@172.31.1.138|cf_route_win:277(<0.12663.0>) inside cfroutewin and maybestartmetaflow undefined and call is {kapps_call,<<"3055-0-2197286698@172.31.1.138">>,#Fun<kapps_call.3.25225864>,undefined,<<"context_2">>,<<"ecallmgr@sandbox.testcomp.com-ecallmgr_call_control-<0.8409.0>-dd6116b1">>,#Fun<kapps_call.4.25225864>,<<"kazoo_apps@sandbox.testcomp.com-cf_listener-<0.4588.0>-3f9a8fec">>,<<"+914067667300">>,<<"+914067667300">>,<<>>,<<"+17073066285">>,<<"freeswitch@sandbox.testcomp.com">>,<<"sandbox.testcomp.com">>,<<"sip:mod_sofia@13.235.10.123:11000">>,<<"sip:13.235.10.123:11000">>,<<"+17073066285@172.31.15.105">>,<<"+17073066285">>,<<"172.31.15.105">>,<<"+914067667300@172.31.1.139">>,<<"+914067667300">>,<<"172.31.1.139">>,<<"+17073066285@172.31.15.105">>,<<"+17073066285">>,<<"172.31.15.105">>,<<"+17073066285@172.31.15.105">>,<<"account%2F17%2F21%2F424dfecd2fb219e366370ca9ab36">>,<<"1721424dfecd2fb219e366370ca9ab36">>,undefined,<<"resource">>,undefined,<<"8d622c18-0602-11ea-a70b-1fbc19c4c967">>,undefined,<<"en-us">>,<<"callflow">>,<<"4.0.0">>,undefined,{[{<<"Resource-Type">>,<<"offnet-origination">>},{<<"Resource-ID">>,<<"384efa0ba3d0447d6be0a9b4439dd746">>},{<<"Privacy-Hide-Number">>,false},{<<"Privacy-Hide-Name">>,false},{<<"Inception">>,<<"+17073066285@172.31.15.105">>},{<<"Ignore-Display-Updates">>,<<"true">>},{<<"Global-Resource">>,false},{<<"Fetch-ID">>,<<"8d622c18-0602-11ea-a70b-1fbc19c4c967">>},{<<"Channel-Authorized">>,<<"true">>},{<<"CallFlow-ID">>,<<"2b596bcb02a0055a8931f2cf344f03f2">>},{<<"Call-Interaction-ID">>,<<"63740861062-59897cdc">>},{<<"Authorizing-Type">>,<<"resource">>},{<<"Application-Node">>,<<"kazoo_apps@sandbox.testcomp.com">>},{<<"Application-Name">>,<<"callflow">>},{<<"Account-ID">>,<<"1721424dfecd2fb219e366370ca9ab36">>},{<<"Caller-ID-Number">>,<<"+914067667300">>},{<<"Caller-ID-Name">>,<<"+914067667300">>}]},{[]},{[{<<"X-AUTH-PORT">>,<<"5060">>},{<<"X-AUTH-IP">>,<<"172.31.1.139">>}]},[{<<"cf_capture_group">>,undefined},{<<"cf_capture_groups">>,{[]}},{<<"cf_flow">>,{[{<<"data">>,{[{<<"method">>,<<"GET">>},{<<"req_timeout">>,<<"5">>},{<<"req_format">>,<<"kazoo">>},{<<"voice_url">>,<<"http://13.234.100.152:8090/testcomp/pivot/play2PivotCallTerminate2AWS152">>},{<<"debug">>,false},{<<"req_body_format">>,<<"form">>}]}},{<<"module">>,<<"pivot">>},{<<"children">>,{[]}}]}},{<<"cf_flow_id">>,<<"2b596bcb02a0055a8931f2cf344f03f2">>},{<<"cf_flow_name">>,<<"+17073066285">>},{<<"cf_metaflow">>,false},{<<"cf_no_match">>,false},{<<"consumer_pid">>,<0.12671.0>},{<<"owner_id">>,undefined}],undefined,<<"audio">>,undefined,<<"sansay5032rdb5">>,<<"inbound">>,false,false,false,false} Let me know if anything could be done in metaflow configurations or we are missing some thing , Thanks in advance and awaiting for your inputs Srikant V Edited November 19, 2019 by Srikant (see edit history) Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 18, 2019 Author Report Share Posted November 18, 2019 Hi Mc_ , I have tried testing the metaflow through PIVOT and through DEVICE( from monster) we found that through PIVOT the Device Id is not being passed and the process of the hangup / break is not invoked , But When tried through DEVICE I am able to see the Device_id / End Point which is required and posting the metaflow on the channels seems working but here we have tried the below scenarios and we are not sure if it works properly 1) When calling a phone number using the Device configured from monster , after we pickup the call at that point when we send the POST request then i can see that the log as below Nov 18 07:50:15 sandbox 2600hz[8709]: |3535-0-2618768508@172.31.1.138|ecallmgr_call_control:960(<0.4875.0>) inserting at the tail of the control queue call command hangup Nov 18 07:50:15 sandbox 2600hz[8709]: |3535-0-2618768508@172.31.1.138|ecallmgr_call_control:1056(<0.4875.0>) executing call command 'hangup' c6fe21ec50bd0345 Nov 18 07:50:15 sandbox 2600hz[8709]: |3535-0-2618768508@172.31.1.138|ecallmgr_util:137(<0.4875.0>) terminate call on node freeswitch@sandbox.testcomp.com Nov 18 07:50:15 sandbox 2600hz[8426]: |03caccd8-09d8-11ea-bec5-b14de2786d65|webhooks_channel_util:34(<0.5990.0>) no hooks to handle CHANNEL_DESTROY for 1721424dfecd2fb219e366370ca9ab36 Nov 18 07:50:15 sandbox 2600hz[8426]: |kz_amqp_assignments|kz_amqp_channel:144(<0.3124.0>) closed amqp channel <0.5508.0> 2) When calling a phone number using the Device configured from monster , after we pickup the call and bridging the call by pressing 1 , we are not able to see the above log and the hangup is not happened properly , for your reference the log file is attached Please help us as we are stuck in this process and really in a bad situation Also please let us know how to pass the device_id in the pivot call so that we can also check the process , or can we pass the device id manually through dynamic flags in the post request Thanks Srikant V test_after_connectingcall_by_1.log Quote Link to comment Share on other sites More sharing options...
2600Hz Employees mc_ Posted November 18, 2019 2600Hz Employees Report Share Posted November 18, 2019 I think there's some confusion on terminology here; let's clarify a bit Pivot is an app that, on a per-call basis, sends an HTTP request to your server and receives callflow instructions (versus configuring the callflow statically). It has nothing to do with metaflows directly. So when you say "testing the metaflow through PIVOT" I'm not sure what that means. How are you initiating calls? What are the steps to recreate the issue you see? Basically, what are the steps in your two scenarios, from start to finish, for how the initial phone call is placed up until the call ends? Another thought, device ID is typically sent as 'Authorizing-ID' when the call is started by a known device, perhaps that is present for you to use? Finally, if you're in a bad spot, you might consider contracting with us for support, officially, and get dedicated engineering time to help you move forward. Obviously that's a business decision on your end but figured I'd mention it. Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 19, 2019 Author Report Share Posted November 19, 2019 (edited) Hi mc_ , Thanks for your response When issuing the pivot through Monster and dialing the number i am supposed to play call a number and then invoke a metaflow on the ongoing pivot call that's what i meant by "testing the metaflow through PIVOT" When i dialed a number to a hotline number configured in SBC , then it will invoke the pivot which contains the instruction to redirect the call to other number and that number should be called / start ringing , once after picking up the call , using metaflow i want to hangup the call flow by giving the "hangup command" , this is the current scenario which i am trying to execute but when pivot is used to call the number there is no device_id , so when trying to pass the device_id using dynamic flags facing issues Please let me know if i am doing it properly or is there something which i am missing Below is my pivot request configured { "module": "resources", "data":{ "to_did": "+919160680999", "use_local_resources":"true"} } post request is { "data": { "action":"hangup" } } Also i found that in logs that meta flow is published on this "published to metaflow(direct 236B) exchange (routing key metaflow.action.3639-0-2717322298%40172%2E31%2E1%2E138.hangup) via <0.3616.0> " But the konami didnt handled the metaflow.action , when cheked in the konami_listener.erl we found that the responders are only defined as "define(RESPONDERS, [{{?MODULE, 'handle_metaflow'} ,[{<<"metaflow">>, <<"bind">>}]" does this have any impact on the test , if so please tell me if there anything which need to changed or added //Logging after the post is done Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|cb_channels:479(<0.1400.3>) attempting to hangup 3639-0-2717322298@172.31.1.138 Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|kz_amqp_worker:252(<0.1400.3>) application ranch checked out worker <0.3308.0> from pool kz_amqp_pool Nov 19 11:13:06 sandbox 2600hz[6796]: |3639-0-2717322298@172.31.1.138|kz_amqp_channel:245(<0.3308.0>) published to metaflow(direct 236B) exchange (routing key metaflow.action.3639-0-2717322298%40172%2E31%2E1%2E138.hangup) via <0.3616.0> Nov 19 11:13:06 sandbox 2600hz[6796]: |3639-0-2717322298@172.31.1.138|kz_amqp_worker:737(<0.3308.0>) published message 10dc8f40a00a1be0 for <0.1400.3> Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|crossbar_bindings:90(<0.1400.3>) folding v2_resource.billing Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_util:1098(<0.1400.3>) billing returned accepted Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_resource:689(<0.1400.3>) requested resource update validated Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_resource:546(<0.1400.3>) run: content_types_accepted Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|crossbar_bindings:90(<0.1400.3>) folding v2_resource.content_types_accepted.channels Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_resource:560(<0.1400.3>) checking content type '{<<"application">>,<<"json">>,[]}' against accepted Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_resource:608(<0.1400.3>) no content-types accepted, using defaults Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_resource:617(<0.1400.3>) cta: [{{<<"application">>,<<"json">>,[]},from_json}] Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_resource:776(<0.1400.3>) run: from_json Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|crossbar_bindings:90(<0.1400.3>) folding v2_resource.execute.post.channels Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_resource:804(<0.1400.3>) content-type provided is to_json Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_util:1707(<0.1400.3>) adding resp header content-type: <<"application/json">> Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_resource:255(<0.1400.3>) session finished: normal Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|api_resource:268(<0.1400.3>) POST request fulfilled in 144 ms 146K248B mem 3K895B bin Nov 19 11:13:06 sandbox 2600hz[6796]: |10f3cbfa7e849af4866f831258b3d0fe|crossbar_bindings:78(<0.1410.3>) pmapping v2_resource.finish_request.POST.channels Nov 19 11:13:06 sandbox 2600hz[7072]: |c900fafd-5270-444c-b5d5-2664d99800c3|kz_amqp_channel:221(<0.4105.0>) published(e039859c912e98b0deb3d65a1fe5691f 1K) to nodes(amqp://guest:guest@127.0.0.1:5672) exchange (routing key ) via <0.4046.0> Nov 19 11:13:12 sandbox 2600hz[6796]: |e039859c912e98b0deb3d65a1fe5691f|kz_amqp_channel:221(<0.4105.0>) published(ef176a3b8748dbe1192c7b63c4b27af0 1K) to nodes(amqp://guest:guest@127.0.0.1:5672) exchange (routing key ) via <0.4058.0> Nov 19 11:13:16 sandbox 2600hz[7072]: |fd3ae2da-aff8-4365-a701-8b824af08765|kz_amqp_channel:221(<0.4105.0>) published(946d178416786fda07466cb0139379ee 1K) to nodes(amqp://guest:guest@127.0.0.1:5672) exchange (routing key ) via <0.4046.0> Nov 19 11:13:24 sandbox 2600hz[6796]: |44f78b47-fb91-46b3-998b-f17a3810430b|kz_amqp_channel:221(<0.4105.0>) published(6a4bd6b74fd6cfa7ca06e17318c77c51 1K) to nodes(amqp://guest:guest@127.0.0.1:5672) exchange (routing key ) via <0.4058.0> Nov 19 11:13:28 sandbox 2600hz[7072]: |6a4bd6b74fd6cfa7ca06e17318c77c51|kz_amqp_channel:221(<0.4105.0>) published(eabcd87b014b1051d677ac34cb357b10 1K) to nodes(amqp://guest:guest@127.0.0.1:5672) exchange (routing key ) via <0.4046.0> Please let me know if any changes need to be done Thanks Srikant V Edited November 19, 2019 by Srikant (see edit history) Quote Link to comment Share on other sites More sharing options...
2600Hz Employees mc_ Posted November 19, 2019 2600Hz Employees Report Share Posted November 19, 2019 See konami_event_listener, you should also see konami_code_statem started when the call begins if the initial metaflow is configured properly. Quote Link to comment Share on other sites More sharing options...
Srikant Posted November 23, 2019 Author Report Share Posted November 23, 2019 Hi Mc_ , Currently we are using Konami application which comes with Kazoo version 4.3 free version , And from past one month we are trying to invoke a simple meta flow "hangup" which is still not successful ( steps which we follow are discussed in the above thread) . Can you please suggest if the metaflow invocation is possible in the open source version or not, or are we doing any steps incorrect. can you please send some references of Hangup so that we can try it out and validate for some conclusion Thanks Srikant V Quote Link to comment Share on other sites More sharing options...
2600Hz Employees mc_ Posted November 25, 2019 2600Hz Employees Report Share Posted November 25, 2019 I can only point you to the docs and source code, unfortunately, since konami is a community-maintained application in KAZOO. I haven't worked with konami directly for some time. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.