Twilio-video.js: [Bug] Unexpected state "closed" for handling a "heartbeat" message from the TCMP server.

Created on 29 Aug 2020  路  11Comments  路  Source: twilio/twilio-video.js

  • [x] I have verified that the issue occurs with the latest twilio-video.js release and is not marked as a known issue in the CHANGELOG.md.
  • [x] I reviewed the Common Issues and open GitHub issues and verified that this report represents a potentially new issue.
  • [x] I verified that the Quickstart application works in my environment.
  • [x] 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:

Upon creating the room, I get an error as follows:

Unexpected state "closed" for handling a "heartbeat" message from the TCMP server. 

Expected behavior:

TODO

Actual behavior:

TODO

Software versions:

  • [ ] Browser(s):
  • [ ] Operating System:
  • [ ] twilio-video.js:
  • [ ] Third-party libraries (e.g., Angular, React, etc.):

Most helpful comment

I ran into this problem. Exact same issue as @amitky described.

The problem was that I had two (local) users using the same JWT token i.e. I had:

  1. User A connects to room with JWT token ey_123 (for example).
  2. User B in a different browser connects to the same room with same JWT token (ey_123).

The fix was to generate two different JWT tokens and make the video.connect call accept a token that was taken from an <input /> field.

That way I could paste in different JWT tokens for the two different users. Once I had 2 different videos showing, I could build the UI like I wanted.

Pro-tip: In development, populate the input field with a value from URL params like ?token=ey_123. Then when you change your code locally and refresh the page, you don't need to copy/paste anything.

All 11 comments

Thank you for reporting this @shunkakinoki - I do see the log line you mentioned as well. It looks like its just a warning and does not prevent from joining the room, but I have filed a task to remove this warning (JSDK-2982)

Thanks,
Makarand

Hi, I am seeing the same warning in the following scenario in a video call.
1st user creates room and 2nd user joins the same room. The 1st user console show this warning. And finally, only 1 participant count shows.

This is actually happening to me in the latest firefox. Uncaught (in promise) TypeError: 'get peerIdentity' called on an object that does not implement interface RTCPeerConnection. And then i get the Unexpected state "closed" for handling on chrome (other participant's console). Even after joining the room the other browser closes the connection after a few seconds.

What is the status on this bug? IMO, it's a huge problem. We can consistently reproduce it. In our application, the user with the bad browser causes connection reset for every other user. Any attempt to rectify the situation (through browser refresh in our case) causes someone else's connection to get reset. And there is an endless set of resets where people are getting kicked out of the meeting. It's causing a terrible experience - and it can be traced right back to this exact issue. Can we bump up the priority on this one? How can we get more attention to this?

I ran into this problem. Exact same issue as @amitky described.

The problem was that I had two (local) users using the same JWT token i.e. I had:

  1. User A connects to room with JWT token ey_123 (for example).
  2. User B in a different browser connects to the same room with same JWT token (ey_123).

The fix was to generate two different JWT tokens and make the video.connect call accept a token that was taken from an <input /> field.

That way I could paste in different JWT tokens for the two different users. Once I had 2 different videos showing, I could build the UI like I wanted.

Pro-tip: In development, populate the input field with a value from URL params like ?token=ey_123. Then when you change your code locally and refresh the page, you don't need to copy/paste anything.

This morning I discovered this issue caused participantConnected to simply not fire, resulting in my entire video app not working. Having not pushed any changes in over a week, this was quite a puzzle (and no good for my customers).

The access token ended up being the culprit - thank you @samhendohinge for this tip. Something must have changed over the weekend that resulted in the access token to have different behavior in the backend somewhere.

I will strongly second the desire to resolve this issue.

What is the solution then. I am facing the same problem.
I want to use this for two way means only two person can join a meeting but the problem is that when a user joins using the participantConnected and then again when the second user joins then the first user getting disconnected.

Any help will be really very much appreciated.

I ran into this problem. Exact same issue as @amitky described.

The problem was that I had two (local) users using the same JWT token i.e. I had:

  1. User A connects to room with JWT token ey_123 (for example).
  2. User B in a different browser connects to the same room with same JWT token (ey_123).

The fix was to generate two different JWT tokens and make the video.connect call accept a token that was taken from an <input /> field.

That way I could paste in different JWT tokens for the two different users. Once I had 2 different videos showing, I could build the UI like I wanted.

Pro-tip: In development, populate the input field with a value from URL params like ?token=ey_123. Then when you change your code locally and refresh the page, you don't need to copy/paste anything.

I also realized the same problem having the same identity being assigned to subsequent users. Silly of me ;)
Thanks @samhendohinge for mentioning here.

On a related note, I just noticed that Twilio's documentation does not list identity as a property of RemoteParticipant any longer. I am wondering if this is a deliberate change we should be noting or if it's absence is just an oversight.

Without this property it's impossible to know which video streams belong to which participants, so I would imagine it remains important.

@dpaola2, Sorry for super late reply. The property identity is still available for RemoteParticipant which extends from Participant (https://media.twiliocdn.com/sdk/js/video/releases/2.13.1/docs/Participant.html#.Identity__anchor)

Thanks,
Makarand

We have the same problem.
Unexpected state "closed" for handling a "heartbeat" message from the TCMP server.

And we have error:
{"errorMessage":"TwilioError: Participant disconnected because of duplicate identity","errorCode":"53205"}

This error message is generated on room.once('disconnected', (room, error) => {});

No other user with the same identity joins the call.

Twilio version: 2.12.0.
Room sid: RM56cb85d61f68acc45da6d1cef081bf90

Was this page helpful?
0 / 5 - 0 ratings