fix(calling): mute/unmute fix with bnr

[Kesari3008]

COMPLETES #https://jira-eng-gpk2.cisco.com/jira/browse/SPARK-511579

This pull request addresses

Issue 1: After disabling BNR on the same call, if we try to enable BNR in a muted state, then stream goes missing completely, and after unmuting, the stream is still missing.

Steps to reproduce: Enable BNR and disable BNR while the call is unmuted. Now mute the call and enable BNR. Unmute the call now and the stream should go missing without the fix.

Issue 2: In subsequent calls after disabling BNR, enabling BNR in an unmuted state messes up the mute-unmute behaviour again and the stream remains present always.

Steps to reproduce: Enable BNR and disable BNR while the call is unmuted and disconnect the call. Now establish second call and enable BNR in unmuted state. Now try to mute the call and the stream will always be present and can be heard on the other side. Muting the stream stops working without the fix.

by making the following changes

Instead of changing localAudioTrack.enabled property using setUserMuted() function on localAudioStream fixes the issue.

Change Type

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Documentation update
• [ ] Tooling change
• [ ] Internal code refactor

The following scenarios where tested

Issue 1 and Issue 2 were tested with the fix.

I certified that

• [x] I have read and followed contributing guidelines

• [x] I discussed changes with code owners prior to submitting this pull request

• [x] I have not skipped any automated checks

• [x] All existing and new tests passed

• [ ] I have updated the documentation accordingly

---

Make sure to have followed the contributing guidelines before submitting.

[Kesari3008]

https://jira-eng-gpk2.cisco.com/jira/browse/SPARK-511579

Yes, that makes sense. We should handle the system muted event too in Calling SDK and it will require thorough testing where we need to test the mute status getting updated and rfeflecting correctly irrespective whether user mute or system mute was triggered. Both the mute functions should be aligned along with the local audio stream getting updated and functioning correctly. And with BNR as well, we need to do testing as updateLocalTracks impacts the stream too which causes issue with mute/unmute behavior. Hence I will create a separate story where we can take care of the mute/unmute flow entirely.

[Kesari3008]

https://jira-eng-gpk2.cisco.com/jira/browse/SPARK-511579

Yes, that makes sense. We should handle the system muted event too in Calling SDK and it will require thorough testing where we need to test the mute status getting updated and rfeflecting correctly irrespective whether user mute or system mute was triggered. Both the mute functions should be aligned along with the local audio stream getting updated and functioning correctly. And with BNR as well, we need to do testing as updateLocalTracks impacts the stream too which causes issue with mute/unmute behavior. Hence I will create a separate story where we can take care of the mute/unmute flow entirely.

https://jira-eng-gpk2.cisco.com/jira/browse/SPARK-530539