[asterisk-bugs] [JIRA] (ASTERISK-27353) H323 audio starts with a delay of 2 seconds.

[Marco Giordani (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marco Giordani updated ASTERISK-27353:
--------------------------------------

    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.


  was:
During an h323 call setup, we noticed that RTP audio start 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 disappear 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.



> H323 audio starts with a delay of 2 seconds.
> --------------------------------------------
>
>                 Key: ASTERISK-27353
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27353
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Addons/chan_ooh323
>    Affects Versions: 13.17.1
>         Environment: FreePBX 13.0.192.18 / Centos 6.6
>            Reporter: Marco Giordani
>            Severity: Minor
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)