Uploaded image for project: 'FreePBX'
  1. FreePBX
  2. FREEPBX-18378

Call recording issues when using Opus

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Not an issue
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • ToDo:
    • Asterisk Version:
      13, 15, 16
    • Distro Version:
      Sangoma Linux release 7.5.1805 (Core)
    • Distro:
      FreePBX Distro

      Description

      Recently tried enabling Opus on one of our systems and ran into a problem with call recordings. A bit of background:

      • In Asterisk SIP Settings, Opus is enabled (and set as the first codec.) We have G.722 and ulaw enabled and selected as the 2nd and 3rd codecs, respectively.
      • Call recordings for outbound calls (from PBX to PSTN) seem to work OK.
      • Call recordings for inbound calls to our direct numbers seem to work OK.
      • Call recordings for inbound calls to our primary business number DO NOT work properly.

      The call recordings that do not work properly essentially DO record, but playback is very slow. I've found that bringing the recording into Audacity and speeding it up by three times seems to make it play correctly. So, it seems to be some sort of sampling rate issue.

      Calls to our primary business number first hit an announcement, then a ring group. Calls to our direct numbers just ring directly to our extensions.

      I'm inclined to believe that the playback of the announcement has something to do with the issue here, getting a sample rate stuck somewhere it shouldn't. Of note, some of the calls with "bad" recordings are ulaw from our carrier, then G722 to the endpoint on our PBX. (I need to change the primary codecs on those devices to Opus as well for inbound Opus to work, but I would still be concerned about devices we have that don't support Opus and thus would use G.722 instead.)

      I've noticed that the read and write formats for some channels is sln48, and others are sln16. Not sure if that ties into it or not.

      Let me know if any additional debugging/information is needed, will definitely try to get whatever information I can that'll help fix this issue.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                kd4ned Jeremy Gault
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  NextupJiraPlusStatus

                  Error rendering 'slack.nextup.jira:nextup-jira-plus-status'. Please contact your Jira administrators.