Jump to content

Search the Community

Showing results for tags 'channel_destroy'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Welcome to the 2600Hz Forum!
    • Forum Rules & Announcements
    • Upcoming Events: Come Meet Us!
    • 2600Hz News
  • Platform Basics
    • Product Guidance
    • Tips & Tricks
    • Product Feedback
    • Product Focus Group & Surveys
    • Pre-Flight Questions
    • Platform Releases & Announcements
    • 2600Hz Training
  • 2600Hz Mobile
    • General Discussion
    • Network
    • Mobile Devices
  • 2600Hz Open Source Developers
    • General OS Kazoo Questions


  • Open Source Calendar
  • General Announcements
  • Industry Events

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Full Name

About Me

Company Name

Job Role

Company Website

I am using Kazoo via:

I use Kazoo:

Found 3 results

  1. I am using clicktocall for originating outbound calls from my client's web app.I am also using webhook for channel destroy event. I want to send a client's application specific custom parameter with chnnel destroy webhook event whose value will be dynamic even if call is not answered by user. I have tried to use "set_variables" in callflow action as like below "data": { "numbers": [cf_number], "flow": { "data": { "custom_application_vars": { "Jazzware-Request": base64_string }, "export": True }, "module": "set_variables", "children": { "_": { "data": { "method": "GET", "req_timeout": "60", "req_format": "kazoo", "voice_url": voice_url }, "module": "pivot", "children": {} } } } } If call is answered or declined, then i am getting the custom_application_vars in Channel_Destroy event. But If call is not answered, then i am not getting the custom_application_vars in Channel_Destroy event. Can you give any suggestion for this so that i can be able to receive that custom_application_vars in Channel_Destroy event even though call is not answered which is very crucial for our application. Thanks
  2. Dear all, My kazoo release version: v3.21.34 , and I faced the following issues: Step 1 : set up callflow 19006612: + First set up play media about 12s + Second go to recording start + Then go to ACDC Queue Step 2 : Dial 19006612 and hangup call within 3s - 5s. Reproduce step 1 and steps 2 many times. Actually Result : Sometimes the callflow succeed stop and do not go to cf_record_call . Sometimes the callflow can not stop and continue go to cf_record_call, cf_acdc_member like an alive call. I traced the log both freewitch and kazoo, then I saw there are two reasons which make the callflow 19006612 still continue even call hangup: Reason 1 : Sometimes Ecallmgr do not received channel_destroy from Freeswitch although Freeswitch already has CS_DESTROY for the call. Reason 2: Sometimes Ecallmgr receives channel_destroy as well from Freeswitch for the call, but callflow cf_play do not get channel_destroy of the call. Kazoo and Rabbitmq are on the same server. Freeswitch is other server. Node of Kazoo/Rabbitmq and node of Freeswitch are in internal network. For these issue, any body can help me in this direction. Thanks.
  3. Hello Forum Let me start by saying I am reeeeally new to Kazoo, so I can reaaaally use some help. I did a lot of research thou, and while I don't understand some details, I was able to get a cluster running (at least partially, hehe). These are the servers I put together: 1 * SBC Server (Kamailio) + Kazoo Apps + Monster UI 2 * Media Servers (FreeSWITCH) 3 * Database Servers (BigCouch) I used to have another SBC node, but then I realized it was causing issues with the presence (due to having two eCallManager instances with local queues and only one zone) so decided to stop the services on the second node for the time being. I've also spent some time reading multiple threads, resolved a few issues and it looks like everything is working now, but I keep getting a lot of email alerts with redirection_to_new_destination as follows: Alert redirection_to_new_destination 303 to 200 (outbound) on cc8cc1c9e996034bbc2ec09bcc72a105(cc8cc1c9e996034bbc2ec09bcc72a105) Producer node: kazoo_apps@b01.sip.smsdatacenter.com msg_id: d4dbb76ffb661496 Details app_name: ecallmgr app_version: 4.0.0 event_category: call_event event_name: CHANNEL_DESTROY msg_id: 1501007152730157 node: kazoo_apps@b01.sip.smsdatacenter.com call_id: b0dda268-7166-11e7-8c68-dd42a72235e1 billing_seconds: 0 call_direction: outbound callee_id_name: XXXXX callee_id_number: 200 caller_id_name: XXXXX caller_id_number: 303 channel_call_state: HANGUP channel_created_time: 1501007152589522 channel_name: sofia/sipinterface_1/200@XXX.sip.smsdatacenter.com channel_state: REPORTING duration_seconds: 0 from: 303@XXX.sip.smsdatacenter.com hangup_cause: REDIRECTION_TO_NEW_DESTINATION local_sdp: v=0 o=FreeSWITCH 1500975540 1500975541 IN IP4 s=FreeSWITCH c=IN IP4 t=0 0 m=audio 31612 RTP/AVP 0 8 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 a=sendrecv media_server: m01.sip.smsdatacenter.com other_leg_call_id: d881c0f6c8b53e1c1f61562adab0877d other_leg_caller_id_name: XXXXX other_leg_caller_id_number: 303 other_leg_destination_number: 0 other_leg_direction: inbound presence_id: 200@XXX.sip.smsdatacenter.com request: 200@XXX.sip.smsdatacenter.com ringing_seconds: 0 switch_nodename: freeswitch@m01.sip.smsdatacenter.com switch_uri: sip: switch_url: sip:mod_sofia@ timestamp: 63668226352 to: 200@XXX.sip.smsdatacenter.com format: ~s ~s to ~s (~s) on ~s(~s) Channel Vars username: 200 realm: XXX.sip.smsdatacenter.com owner_id: 90dee9c96ab01212adb5333712906b24 global_resource: false ecallmgr_node: kazoo_apps@b01.sip.smsdatacenter.com channel_authorized: true call_interaction_id: 63668226342-3b71322e bridge_id: d881c0f6c8b53e1c1f61562adab0877d authorizing_type: device authorizing_id: f1bb6a88886c7d69bb662775a6da5f3d account_id: cc8cc1c9e996034bbc2ec09bcc72a105 SIP Headers x_kazoo_aor: sip:200@XXX.sip.smsdatacenter.com Account Account ID: cc8cc1c9e996034bbc2ec09bcc72a105 Account Name: XXX Account Realm: XXX.sip.smsdatacenter.com I also reviewed the FreeSWITCH logs and found out these errors are consistent with the 302 messages coming from the phones, which end up on a hang up channel. I understand 302 is how SIP handles transfers to ask the device to re-issue the invite to a new destination, I am just not sure why I am getting all these notifications each time a redirection occurs. Is this something normal? is there any way to disable it? Thanks! Much! Ivan
  • Create New...