[BUG] Breaking change in the "Enabled Sounds" state due to AudioHelper change

[kamalbennani]

• I have verified that the issue occurs with the latest twilio.js release and is not marked as a known issue in the CHANGELOG.md.
• I reviewed the Common Issues and open GitHub issues and verified that this report represents a potentially new issue.
• I verified that the Quickstart application works in my environment.
• I am not sharing any Personally Identifiable Information (PII)
  or sensitive account information (API keys, credentials, etc.) when reporting this issue.

Code to reproduce the issue:

This PR has introduced a breaking change making the enabledSounds state not persist when calling the device.updateOptions function.

device.updateOptions recreate a new Instance of the AudioHelper each time this method is called, and because now the enabledSounds state is stored on the AudioHelper class, this state doesn't persist as it used to be.

A simple solution, would be to pass the enabledSounds to the new AudioHelper instance before destroying the previous one.

What do you think?

The issue was introduced in v2.4.0

Software versions:

• Browser(s): Arc Version 0.110.1 (39837) / Chromium Engine Version 114.0.5735.198
• Operating System: MacOS
• twilio.js: 2.5.0
• Third-party libraries (e.g., Angular, React, etc.): React

[charliesantos]

Hey @kamalbennani thanks for reporting. We will take a look and consider your suggestion.
Prior to v2.4.0, device.updateOptions do not work anyway due to this bug correct? #14
Let me know if you're seeing the same behavior.

[kamalbennani]

Hi @charliesantos
It used to work, the API was just not exposed via TS if I recall.
But now, the API looks good but a new regression has been introduced.
I can push a fix if you want to?

[charliesantos]

Hey @kamalbennani yes feel free to submit a PR and I will review.