Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: mod_conference
    • Security Level: public
    • Labels:
      None
    • Environment:
      debian jesse
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      346a60ed3d46c083d4b54f058572ca462127bfd1
    • GIT Master Revision hash::
      346a60ed3d46c083d4b54f058572ca462127bfd1

      Description

      I am running the latest master code as of friday(346a60ed3d46c083d4b54f058572ca462127bfd1)

      I am using sip.js/chrome as a client initially users are in recevonly for video then a reinvite is sent when video is attached.

      What appears to be happening is after a reinvite turning video on and a new member taking video over for the conference I am seeing keyframes missed every so often. If I toggle video on and off sending a reinvite each time the problem will usually be fixed but sometimes it takes more than 1 try.

      The video stream after that does not recover until chrome issues a new keyframe after about 100 seconds.

      When the issue occurs I receive this message.

      2016-09-06 15:16:46.778375 [WARNING] switch_vpx.c:1151 no keyframe, treating start as key. frames=51

      When researching is seems chrome sends a new keyframe every 3000 frames, so at about 30 fps its about 100 seconds for a new keyframe.







        Activity

        Hide
        pvertenten Peter Vertenten added a comment -
        This does not happen every-time. It usually takes me a couple of tries, but it not too hard for me to reproduce takes about a minute or so.
        Show
        pvertenten Peter Vertenten added a comment - This does not happen every-time. It usually takes me a couple of tries, but it not too hard for me to reproduce takes about a minute or so.
        Hide
        anthm Anthony Minessale II added a comment -
        Do you not see FS sending a PLI ?

        does uuid_video_refresh <uuid of member> fix it?
        Show
        anthm Anthony Minessale II added a comment - Do you not see FS sending a PLI ? does uuid_video_refresh <uuid of member> fix it?
        Hide
        anthm Anthony Minessale II added a comment -
        Try latest master, I added an explicit keyframe req to the place in the conference when it detects newly established video.
        Show
        anthm Anthony Minessale II added a comment - Try latest master, I added an explicit keyframe req to the place in the conference when it detects newly established video.
        Hide
        pvertenten Peter Vertenten added a comment -
        Same issue after updating.

        uuid_video_refresh did not seem to work.
        Show
        pvertenten Peter Vertenten added a comment - Same issue after updating. uuid_video_refresh did not seem to work.
        Hide
        anthm Anthony Minessale II added a comment -
        uuid_video_refresh did not trigger a PLI to chrome? Are you sure you have working rtcp traffic? You should be able to see it in a trace.
        Make sure the call has actually established working RTCP its possible that there is a bug in the js thing or chrome since you said its only when adding video to an existing call.

        When you issue uuid_video_refresh you should be able to spot clearly a pli feedback packet.

        Also look in chrome://webrtc-internals in the send and recv video panes for the current call.
        Show
        anthm Anthony Minessale II added a comment - uuid_video_refresh did not trigger a PLI to chrome? Are you sure you have working rtcp traffic? You should be able to see it in a trace. Make sure the call has actually established working RTCP its possible that there is a bug in the js thing or chrome since you said its only when adding video to an existing call. When you issue uuid_video_refresh you should be able to spot clearly a pli feedback packet. Also look in chrome://webrtc-internals in the send and recv video panes for the current call.
        Hide
        pvertenten Peter Vertenten added a comment -
        Looks like googFirsReceived & googNacksReceived & googPlisReceived are all 0 even after calling the uuid_video_refresh.

        The other side of the pond has numerous googPlisSent.

        I believe I was seeing the pli on my home network late last night, so it might just be our office network that is the culprit, so there might be some network related differences accounting for the issue. I will do some testing later tonight.



        Show
        pvertenten Peter Vertenten added a comment - Looks like googFirsReceived & googNacksReceived & googPlisReceived are all 0 even after calling the uuid_video_refresh. The other side of the pond has numerous googPlisSent. I believe I was seeing the pli on my home network late last night, so it might just be our office network that is the culprit, so there might be some network related differences accounting for the issue. I will do some testing later tonight.
        Hide
        pvertenten Peter Vertenten added a comment -
        So i did some testing on my home network last night, and things worked as expected, I was receiving googPlisReceived and googFirsReceived. The server environment was the same, just changed the network the clients are on.

        Its weird because the media comes through, and I thought chrome uses the same ports for rtp & rtpc.
        a=rtcp-mux

        Will start looking at pcaps next, with ssldump.



        Show
        pvertenten Peter Vertenten added a comment - So i did some testing on my home network last night, and things worked as expected, I was receiving googPlisReceived and googFirsReceived. The server environment was the same, just changed the network the clients are on. Its weird because the media comes through, and I thought chrome uses the same ports for rtp & rtpc. a=rtcp-mux Will start looking at pcaps next, with ssldump.

          People

          • Assignee:
            anthm Anthony Minessale II
            Reporter:
            pvertenten Peter Vertenten
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development