Calling `close` on an incoming UNANSWERED call does not fire the outgoing call's `close` event

[vladmashk]

Please, check for existing issues to avoid duplicates.

• No similar issues found.

What happened?

(Note, issues #636, #734, #752, #780, #832, #1032, #1084, #1089 and undoubtably more are similar to this, however they are all about calling close on an answered call, so the fix for this (commit e3b67a6) doesn't fix this issue.)

If Alice calls Bob and Bob 'declines' the call by calling close on it without answering it, Alice's call doesn't fire the close event.

I have found that you can work around this by having Bob answer the call without passing a stream and then call close on the call after a small amount of time. However, this seems like a hack. It shouldn't have to work this way.

How can we reproduce the issue?

1. Alice calls Bob
2. Bob calls close on the call without answering
3. The close event handler that Alice has set doesn't execute

What do you expected to happen?

The close event handler that Alice has set DOES execute

Environment setup

• OS: Windows 11
• Platform:
• Browser: Chrome, Firefox

Is this a regression?

No response

Anything else?

No response

[therealPaulPlay]

I am also experiencing this!

[radiorz]

how to resolve this problem?

[therealPaulPlay]

Pretty sure this is related to this Chrome bug that I reported: https://issuetracker.google.com/issues/395420661

[FlippingBinary]

Is this a privacy feature rather than a bug? The connection reveals potentially sensitive information about the parties involved, so there should be a way to ignore the connection early in the signaling process to avoid exchanging that information. If you establish the connection and use it to communicate a desire to reject the call (perhaps by sending a null packet or something), then close it, would that make it less hacky? Alternatively, Alice could have a timeout to determine when she treats the call as ignored so Bob can preserve some privacy and pretend he never got the call.