Asterisk
  1. Asterisk
  2. ASTERISK-4152

Increasing delay over time on non-Zap channels in MeetMe

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Labels:
      None
    • Mantis ID:
      4252
    • Regression:
      No

      Description

      Over a period of time, participants on SIP or IAX channels in a MeetMe conference experience increasing delay in hearing the conference.

      By instrumenting the reads and writes in the main loop of conf_run() I discovered that data was appearing on the pseudo-fd more often than it was appearing on the incoming channel. This data was being written to the channel, gradually building up a backlog in the channel driver.

      My patches (for STABLE and HEAD) provide an interlock between the reading and writing of the channel, so that the same number of frames are written to the channel as are read from it. Each time a frame is read, the channel becomes eligible to have one frame written to it. The frame in fr, if it cannot be written immediately, will pend until the next incoming frame is read. If further data arrives from the pseudo-fd in the meantime, it will overwrite the pending frame. The effect of all this is to avoid the buildup of a backlog going out to the channel.

      Please folks, try these patches and feedback here.

                • ADDITIONAL INFORMATION ******

      Disclaimer on file.

      Please note that this is NOT a duplicate of bug ASTERISK-3519, but a completely separate problem. ASTERISK-3519 concerns delay introduced due to the sounds on joining a conference. This report concerns the gradual increase in delay over time.

        Activity

        Hide
        Chih-Wei Huang added a comment -

        Yes, I used 2005-10-04-3-asynchronous.patch. In fact I have read it. It patches four files: channel.c, app_milliwatt.c, app_sms.c and app_chanspy.c, right? Since I don't use module milliwatt, sms and chanspy, I assumed it only affect channel.c. Correct me if I'm wrong.

        I'm using Scientific Linux SL Release 4.0, with its default kernel 2.6.9. CPU is Mobile AMD Geode(t}=0~{ processor, as shown by cat /proc/cpuinfo. I have three types of clients: SIP, MGCP and H.323.
        SIP and MGCP are the native channel drivers, while H.323 use chan_oh323 from inaccessnetworks. The codec is G.723.1 from Intel IPP library.

        The Asterisk version is 1.2-beta1. Should I try the latest CVS?

        Show
        Chih-Wei Huang added a comment - Yes, I used 2005-10-04-3-asynchronous.patch. In fact I have read it. It patches four files: channel.c, app_milliwatt.c, app_sms.c and app_chanspy.c, right? Since I don't use module milliwatt, sms and chanspy, I assumed it only affect channel.c. Correct me if I'm wrong. I'm using Scientific Linux SL Release 4.0, with its default kernel 2.6.9. CPU is Mobile AMD Geode(t}=0~{ processor, as shown by cat /proc/cpuinfo. I have three types of clients: SIP, MGCP and H.323. SIP and MGCP are the native channel drivers, while H.323 use chan_oh323 from inaccessnetworks. The codec is G.723.1 from Intel IPP library. The Asterisk version is 1.2-beta1. Should I try the latest CVS?
        Hide
        Kevin P. Fleming (Inactive) added a comment -

        This problem should now be solved in CVS HEAD. The previous code was unable to handle slight timing diferences between the conference timing source and the VOIP channels; the new version should be able to handle this without trouble.

        If you still experience this issue after upgrading, please reopen this bug.

        Show
        Kevin P. Fleming (Inactive) added a comment - This problem should now be solved in CVS HEAD. The previous code was unable to handle slight timing diferences between the conference timing source and the VOIP channels; the new version should be able to handle this without trouble. If you still experience this issue after upgrading, please reopen this bug.
        Hide
        Tony Mountifield added a comment -

        As the original submitter of this bug, I just wanted to say that I've now concluded the patches I submitted for this particular issue are not correct, as they make invalid assumptions, such as assuming the incoming frames are the same size as the outgoing ones, which is not always the case.

        Please could the meetme patches on this bug be removed?

        This issue is much better solved with the asynchronous patch in bug ASTERISK-5230, which I have tried with great success.

        Show
        Tony Mountifield added a comment - As the original submitter of this bug, I just wanted to say that I've now concluded the patches I submitted for this particular issue are not correct, as they make invalid assumptions, such as assuming the incoming frames are the same size as the outgoing ones, which is not always the case. Please could the meetme patches on this bug be removed? This issue is much better solved with the asynchronous patch in bug ASTERISK-5230 , which I have tried with great success.
        Hide
        BJ Weschke added a comment -

        meetme patches removed and bug is now closed based on softins' note.

        Show
        BJ Weschke added a comment - meetme patches removed and bug is now closed based on softins' note.
        Hide
        Digium Subversion added a comment -

        Repository: asterisk
        Revision: 7033

        U trunk/ChangeLog
        U trunk/apps/app_meetme.c
        U trunk/configs/meetme.conf.sample

        ------------------------------------------------------------------------
        r7033 | kpfleming | 2008-01-15 15:55:00 -0600 (Tue, 15 Jan 2008) | 2 lines

        issues ASTERISK-3519 and ASTERISK-4152

        ------------------------------------------------------------------------

        http://svn.digium.com/view/asterisk?view=rev&revision=7033

        Show
        Digium Subversion added a comment - Repository: asterisk Revision: 7033 U trunk/ChangeLog U trunk/apps/app_meetme.c U trunk/configs/meetme.conf.sample ------------------------------------------------------------------------ r7033 | kpfleming | 2008-01-15 15:55:00 -0600 (Tue, 15 Jan 2008) | 2 lines issues ASTERISK-3519 and ASTERISK-4152 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=7033

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development