Summary: | ASTERISK-27353: H323 audio starts with a delay of 2 seconds. | ||
Reporter: | Marco Giordani (marco_g) | Labels: | patch |
Date Opened: | 2017-10-17 01:49:28 | Date Closed: | 2017-11-27 10:52:19.000-0600 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Addons/chan_ooh323 |
Versions: | 13.17.1 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | FreePBX 13.0.192.18 / Centos 6.6 | Attachments: | ( 0) ASTERISK-27353.patch |
Description: | During an h323 call setup, we noticed that RTP audio starts with a delay from 0 to 2 seconds after ooh323_indicate is queued. This happens only in the first two seconds of a call normally during ringback or early audio.
This problem is particularly annoying because with a 2 seconds delay in Italy (and in a lot of other countries) the first ring disappears completely and the delay appears like as a 6 seconds delay. After some investigations, we discovered that the problem seems to be related to the ooMonitorCallChannels (ooh323c/src/oochannels.c) timers defined as: toMin.tv_sec = 2; /* 2 sec */ toMin.tv_usec = 100000; /* 100ms*/ reducing these values to 0 seconds and 500ms modifies the channel behavior and RTP audio starts with a shorter delay (0 to 500ms) with a better user experience. We are testing these new values without any problem so far. We are evaluating if could be useful to introduce a config file setting or just change this value at compilation time. We experienced the bug on version 13.17.1 but a quick look at the code shows the same problem even on versions 14 and 15. | ||
Comments: | By: Asterisk Team (asteriskteam) 2017-10-17 01:49:28.797-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Joshua C. Colp (jcolp) 2017-10-20 11:31:57.621-0500 [~may213] Hi there! I've assigned this to you for triage. By: Joshua C. Colp (jcolp) 2017-10-20 11:35:48.500-0500 Or at least, I'm trying to. By: Alexander Anikin (may213) 2017-11-03 18:40:58.346-0500 Hi, really some time that bug found and i solved it already some years ago internally. By: Alexander Anikin (may213) 2017-11-03 18:48:21.558-0500 add ooCreateCallCmdConnection on call creation By: Alexander Anikin (may213) 2017-11-03 18:49:44.616-0500 Hi Macro, please test issue with attached patch By: Marco Giordani (marco_g) 2017-11-15 02:45:59.319-0600 Hi Alexander, thank you for your help. The patch works perfectly. Marco By: Friendly Automation (friendly-automation) 2017-11-27 10:52:20.635-0600 Change 7355 merged by George Joseph: add cmd connection creation on creation ooh323 call data structure [https://gerrit.asterisk.org/7355|https://gerrit.asterisk.org/7355] By: Friendly Automation (friendly-automation) 2017-11-27 10:52:45.699-0600 Change 7353 merged by George Joseph: add cmd connection creation on creation ooh323 call data structure [https://gerrit.asterisk.org/7353|https://gerrit.asterisk.org/7353] By: Friendly Automation (friendly-automation) 2017-11-27 11:18:46.237-0600 Change 7356 merged by Jenkins2: add cmd connection creation on creation ooh323 call data structure [https://gerrit.asterisk.org/7356|https://gerrit.asterisk.org/7356] |