Did you know that your Webex recording might not capture what you saw and heard during your session? Let’s examine why.
My discovery stems from personal experience. I think you’ll find it instructive.
We start with the basics. I moderated a client webinar set up on Webex Events (that is the webinar version of their collaboration software, distinct from their peer-level meeting version). All went well during the webinar, without any notable tech issues. Several presenters participated from various locations around the world. Participants joined from many more countries. I had no complaints or reports of audio/video problems.
We recorded the webinar using the built-in Webex recorder and saved it to our Webex account on the cloud, as usual. When I reviewed the recording, everyone sounded great except for one presenter. Every time this person spoke, the audio was garbled to the point of being unintelligible. It’s important to remember that he sounded just fine in the live session. And that everyone else on the recording sounded fine. What the heck could cause the recording to repeatedly fail to capture what we all heard in the live session, and only have the symptom appear for one presenter?
I filed a support ticket with Webex and went through the usual obligatory rounds of confirming details, having it kicked up to higher levels of support investigation, and collecting log information from the affected presenter’s computer. I was assured that the Cisco engineering team was working on the case and that they would update me on the status.
To Cisco’s credit, they did keep me in the loop to ensure that the case was still open. Every few days I would receive a new email from my support contact informing me that they were still investigating. This went on for one month.
At the end of the month, I received the following reply:
Received an update from the Engineering team and they found that the garbled audio for one of the presenter happened because of the packet loss from speaker to server.
We appreciate your patience on this matter and understand the importance of this recording.
Engineering team has worked to the best of their efforts and apologizes for the inconvenience caused.
Kindly let me know if there is anything else we can help you with and feel free to email me.
I wrote back that I was confused. First of all, I could not tell whether this was a brush-off and that “Engineering team has worked to the best of their efforts” meant that they had determined there was nothing they could do and that the ticket was being closed without a fix. If that’s the resolution on a case, I think it needs to be much more explicit. (My interpretation was correct. That was indeed what they were telling me.)
My bigger confusion came from the statement that the underlying cause was packet loss from speaker to server. If the originating signal coming from the presenter’s computer up to the internet was bad, why wouldn’t we have heard that in the live session? His signal goes up to the server in the first place, where it gets redistributed back down to each participant’s computer. Shouldn’t we have heard the same garbled sound the recording captured?
When I posed this question to my support contact, I received the following breathtaking reply:
Server received audio data, if there is uplink loss, will do FEC mechanism to recover the lost packets, but it only apply to attendee, not for recording. If use latest recording solution video centric, it have FEC for recording as well.
My goodness, there is a lot to unpack there. I am no network engineer. FEC was a meaningless acronym for me. I looked it up and found that Forward Error Correction is a methodology used to compensate for the fact that the internet sometimes loses packets of data that get sent from one point to another. FEC appears to be particularly useful for WebRTC streams of audio/video media.
I can build a mental image of Webex “pulling” the data stream up from the presenter’s computer, then “pushing” it out to all the listening attendees on the webinar. It would appear that the FEC compensation for missing data occurs during the “push” side of the operation, so listeners don’t hear the dropouts that occurred during the “pull” operation. But the recorder doesn’t benefit from that extra FEC correction step, so it captures the uncorrected, lossy data stream.
Which takes us to that final sentence where I was told that if only I had used “latest recording solution video centric” all would have been well. I had to do a little more Googling to get to the bottom of this one. It turns out that earlier this year, Cisco added an option to their network recording options. If you use a supported browser, and you have the latest version of Webex, and you record to the cloud in MP4 format, and your meeting ONLY includes webcam video without any document shares or whiteboard, then you can record in Video Centric mode, which applies the error correction. By the way, if you share a video clip, it will work for certain video formats - but only for Webex Meetings and not Webex Events. Neat.
So there you have it. The Webex recording you save online may or may not have the same quality that you saw in the live session. It may be unlistenable. Good luck with that.
