Uploaded image for project: 'FreeSWITCH'
  1. FreeSWITCH
  2. FS-9525

Client initiated REINVITE with different audio codec into conference causes choppy audio

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.6.10
    • Fix Version/s: None
    • Security Level: public
    • Labels:
      None
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • uname:
      Linux bstnma-freeswitch3 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 8 jessie
    • lsb_release:
      debian
    • Compiler:
      gcc
    • Compiler Version:
      yours :)
    • FreeSWITCH GIT Revision:
      Yep, still like the packages
    • GIT Master Revision hash::
      Yep, still like the packages
    • FSS Support Agreement Customer Number and Company name:
      CounterPath

      Description

      In both 1.6.10 and unstable seeing RE-INVITE where a different codec is selected (opus or G722 in either direction) causing choppy audio after the re-invite.

        Activity

        Hide
        anthm Anthony Minessale II added a comment -
        Hi,

        2 things.

        1) The version in the log says its 1.6.10 not the unstable package which is required for debugging.
        2) When doing trances like this for cli can you turn on the sip trace?

        sofia global siptrace on
        sofia tracelevel alert
        console loglevel debug


        Show
        anthm Anthony Minessale II added a comment - Hi, 2 things. 1) The version in the log says its 1.6.10 not the unstable package which is required for debugging. 2) When doing trances like this for cli can you turn on the sip trace? sofia global siptrace on sofia tracelevel alert console loglevel debug
        Hide
        anthm Anthony Minessale II added a comment -
        Also are you setting any nonstandard vars related to codec negotiation on this box?
        Show
        anthm Anthony Minessale II added a comment - Also are you setting any nonstandard vars related to codec negotiation on this box?
        Hide
        jimdoesvoip Jim OBrien added a comment -
        Hi Anthony,
          The behaviour is the same on the unstable build from Friday and 1.6.10. I can collect wireshark traces and cli output on unstable if that helps with the additional cli debug output.

          For the vars.xml, we are not setting anything special... but I can send that file if it helps.

        Jim

        Show
        jimdoesvoip Jim OBrien added a comment - Hi Anthony,   The behaviour is the same on the unstable build from Friday and 1.6.10. I can collect wireshark traces and cli output on unstable if that helps with the additional cli debug output.   For the vars.xml, we are not setting anything special... but I can send that file if it helps. Jim
        Hide
        jimdoesvoip Jim OBrien added a comment -
        fs_cli output with requested items turned on and corresponding wireshark from unstable / FreeSWITCH Version 1.7.0-1010-2bd7cfd~64bit (-1010-2bd7cfd 64bit)
        Show
        jimdoesvoip Jim OBrien added a comment - fs_cli output with requested items turned on and corresponding wireshark from unstable / FreeSWITCH Version 1.7.0-1010-2bd7cfd~64bit (-1010-2bd7cfd 64bit)
        Hide
        anthm Anthony Minessale II added a comment -
        mostly I need FS traces, the wireshark are secondary but welcome.

        To try to reproduce, I called a listener leg into a stereo 48khz conference then called in a leg from another FS using opus and changed it to g722 with a re-invite and it worked fine.

        Maybe the new traces with full sip trace will show something.
        Show
        anthm Anthony Minessale II added a comment - mostly I need FS traces, the wireshark are secondary but welcome. To try to reproduce, I called a listener leg into a stereo 48khz conference then called in a leg from another FS using opus and changed it to g722 with a re-invite and it worked fine. Maybe the new traces with full sip trace will show something.
        Hide
        jgeras Jeremy Geras added a comment -
        In the trace 2016-09-19-call-pull-on-fs-unstable.cap notice that the RTP timestamps coming from FS increment by 960 *even after* the change to G.722. So the timestamps from that point onwards are possibly bogus; for G.722 it should increment by 160 (assuming a normal ptime). If the G.722 is attempted to be decoded/played with Wireshark, it might play fine (dep on your Wireshark settings), since Wireshark can be set to ignore RTP timestamps.
        Show
        jgeras Jeremy Geras added a comment - In the trace 2016-09-19-call-pull-on-fs-unstable.cap notice that the RTP timestamps coming from FS increment by 960 *even after* the change to G.722. So the timestamps from that point onwards are possibly bogus; for G.722 it should increment by 160 (assuming a normal ptime). If the G.722 is attempted to be decoded/played with Wireshark, it might play fine (dep on your Wireshark settings), since Wireshark can be set to ignore RTP timestamps.
        Hide
        jimdoesvoip Jim OBrien added a comment -
        wireshark trace and console log from 1022 build for same scenario
        Show
        jimdoesvoip Jim OBrien added a comment - wireshark trace and console log from 1022 build for same scenario

          People

          • Assignee:
            mikej Mike Jerris
            Reporter:
            jimdoesvoip Jim OBrien
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development