Attempting to mute a unanswered call makes it unmuteable after answer

[KraftyKraft]

We're running JsSIP v3.6.1.

When session.mute() is called on an unanswered incoming call, the following error is thrown.

TypeError: Cannot read property 'getSenders' of null
    at RTCSession._toggleMuteAudio (RTCSession.js:3029)
    at RTCSession.mute (RTCSession.js:984)

I suppose that since the call is not answered yet, its RTCPeerConnection is null. However, the variable RTCSession#_audioMuted is set to true regardless.

After answering the call, we can attempt to mute it again by calling session.mute(). Since _audioMuted is still true, nothing happens, and no tracks are disabled. The call is unmuteable at this point.

There are pretty easy, somewhat hacky, ways to get around this - calling RTCSession.unmute first, checking for a connection, etc - but it seems somewhat buggy, so we thought an issue is appropriate :)

[jmillan]

In order to allow muting before connection is created we could add a check in _toggleMuteAudio and _toggleMuteVideo.

 _toggleMuteAudio(mute)
  {
    // RTCPeerConnection is not created yet, skipping.
    if (!this._connection) {
      return;
    }

    const senders = this._connection.getSenders().filter((sender) =>
    {

But then everywhere we do this._connection.addTrack(track, stream); in RTCSession we must check if we are muted (audio|video) and call the _toogleMuteXXXX() accordingly.

[ibc]

I think we should just document that, for receiving invites, (un)mute(), (un)hold() methods will throw if the call is not answered. And obviously we should really throw and not change flags state (_audioMuted, _videoMuted) if so.