Packet loss + H264 on iOS devices causes severe connectivity problems

[jonathan-emed]

What happened and what did you expect to happen?

We run a system in which a customer places a video call to a customer service agent. The customer's audio and video is sent but only the agent's audio is returned.

During our last surge we saw up to 70% of all customers using Safari-based Chime on iOS devices. Since most of these customers were traveling and using LTE service, packet loss and connectivity issues were a factor but should not have been show stoppers since every customer must pass the standard Chime readiness checker. Many users who were on strong WiFi connections were also seeing similar problems on 15.4 and 15.5.

Issues we saw

• Non-functioning video playback on the agent's side
• Grey/white video playback on the agent's side
• Resetting of the Chime Meeting session would not solve the problem.
• Long time for the customer to connect to the Chime Meeting.
• Camera/media device problems on iOS as reported by the Chime SDK.

Have you reviewed our existing documentation?

• GitHub issues
• FAQs page
• README page
• Feature-specific guides

Reproduction steps

Setup a Chime meeting between an iOS device and a Chrome desktop. Add some packet loss between the iOS device and the Chime server. Make sure the iOS device is sending H264 video.

Disabling H264 video saw our customer complaints drop almost 95%. We believe that this issue is still a problem #1059

Amazon Chime SDK for JavaScript version

2.30.0

What browsers are you seeing the problem on?

iOS

Browser version

15.5

Meeting and Attendee ID Information.

No response

Browser console logs

Can't provide right now

[hensmi-amazon]

Thanks for the issue cut @jonathan-emed . I agree that I have found the performance of H.264 (or at least the profile we use) to be a bit unstable. Hopefully I can find the time for a deeper dive into the issue and see if it makes sense to change the default to VP8, or if there are other profiles which perform better (as VP8 does have the tradeoff of using more battery).

In the meantime, I did PR an explicit API for codec selection (currently just between VP8 and H.264 CBP) so that a fork would no longer be required: #2292

[hensmi-amazon]

Resolving due to this primarily being an Apple issue and having workaround by using VP8.