# Error: connect() already called

**URL:** <https://mediasoup.discourse.group/t/error-connect-already-called/870>\
**Category:** mediasoup libraries\
**Created:** [April 24, 2020, 1:05pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870 "2020-04-24T13:05:48Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![jbis9051](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@jbis9051](https://mediasoup.discourse.group/u/jbis9051)\
**Post date:** [April 24, 2020, 1:05pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/1 "2020-04-24T13:05:48Z")

</div>

I am having the exact same issue listed [here](https://mediasoup.discourse.group/t/error-connect-already-called/59).

I read over the responses and solution there and I don’t really understand why there is an issue with what he is doing. (I am doing something similar, I am creating a sending and receiving transport at the same time which is likely generating the error).

This was his code, I am using it for simplicity.

```auto
let transport;

async function publish(track) {
  if (!transport) {
    transport = await device.createSendTransport();
    transport.on('connect', connectTransport);
  }
  await transport.produce({ track });
}

function startMic() {
  ...
  publish(audioTrack);
}

function startWebcam() {
  ...
  publish(videoTrack);
}

```

Why is this an issue? When the `connect` event is emitted on the client side, `connectTransport` is called which makes a request to the server with the transport’s id and `dtlsParameters`. On the server, it uses the id to find the transport and then calls [`transport.connect({dtlsParameters})`](https://mediasoup.org/documentation/v3/mediasoup/api/#webRtcTransport-connect). This shouldn’t cause an issue with connect being called twice as the id is being checked before it is called.

For example, if startMic is called and creates a transport with an id of “1”. Then startWebcam is called creating a transport with an id of “2”. There should be no issue, as the server will use those id’s to connect. `connect()` should never be be being called twice.

Additionally, there should be a way to check whether the transport is already connected server side. Obviously there is a check going on internally in order to produce that error, is there a way we can check? Even if the client side code is fixed, we should be able to check server side as the client can make any request they want. Would you suggest storing connected state in `appData`?

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [April 24, 2020, 1:20pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/2 "2020-04-24T13:20:08Z")

</div>

The issue is in server side. Obviously you are calling `connect()` multiple times in the same server side transport. You must create a **new** server side transport for each client side transport, you cannot reuse them.

> [@jbis9051](#):
>
> For example, if startMic is called and creates a transport with an id of “1”. Then startWebcam is called creating a transport with an id of “2”. There should be no issue, as the server will use those id’s to connect. `connect()` should never be be being called twice.

In your code snippet above you are using the **same** transport in client side for audio and video, which is fine, and not two transports.

Again: go to your server side and check why `transport.connect()` is being called twice on the same transport.

---

<div class="post-metadata">

**Author:** ![jbis9051](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@jbis9051](https://mediasoup.discourse.group/u/jbis9051)\
**Post date:** [April 24, 2020, 1:35pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/3 "2020-04-24T13:35:21Z")

</div>

> The issue is in server side. Obviously you are calling `connect()` multiple times in the same server side transport. You must create a **new** server side transport for each client side transport, you cannot reuse them.

I think I am.

> In your code snippet above you are using the **same** transport in client side for audio and video, which is fine, and not two transports.

On the other thread [Error: connect() already called](https://mediasoup.discourse.group/t/error-connect-already-called/59) you say

> That’s indeed a bug in your code since you are creating separate send transports for audio and video.

I have posted the same code (just as an example here). How is it different?

* * *

There are two issue at hand here.

1. Based on the code snippet, I don’t think `connect()` should be being called twice. Since transports are refered to by id this shouldn’t be an issue:

> If startMic() and startWebcam() are called immediately one after the other, then two transports are created which leads to dual call to connectTransport().

startMic and startWebcam should crete unique id’s of transports. You _should_ be able to create a separate transport for audio and video if you like.

1. Regardless of the code on the client side, you should be able to check **server** side if `connect()` was called. If this check isn’t possible, then you are **trusting the client** not to call connectTransport twice. We shouldn’t _need_ to trust the client. There should be a mechanism server side to check if connect has been called to prevent an error from occurring.

---

<div class="post-metadata">

**Author:** ![jbis9051](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@jbis9051](https://mediasoup.discourse.group/u/jbis9051)\
**Post date:** [April 24, 2020, 1:38pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/4 "2020-04-24T13:38:34Z")

</div>

To make it simpler lets use the following example.

```auto
const transports = [];

async function publish(track) {
    const transport = await device.createSendTransport();
    transport.on('connect', connectTransport);
    transports.push(transport);
    await transport.produce({ track });
}

function startMic() {
  ...
  publish(audioTrack);
}

function startWebcam() {
  ...
  publish(videoTrack);
}

```

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [April 24, 2020, 2:11pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/5 "2020-04-24T14:11:09Z")

</div>

> [@jbis9051](#):
>
> On the other thread [Error: connect() already called](https://mediasoup.discourse.group/t/error-connect-already-called/59) you say
> 
> > That’s indeed a bug in your code since you are creating separate send transports for audio and video.

Well, that’s not a bug but probably undesirable behavior.

> [@jbis9051](#):
>
> Based on the code snippet, I don’t think `connect()` should be being called twice. Since transports are refered to by id this shouldn’t be an issue:

What can I say? I am not in front of your server side code. I just can guarantee that `Error: connect() already called` just happens if you call `transport.connect()` twice on the same server side transport.

> [@jbis9051](#):
>
> startMic and startWebcam should crete unique id’s of transports. You _should_ be able to create a separate transport for audio and video if you like.

You can perfectly do that if you like.

> [@jbis9051](#):
>
> Regardless of the code on the client side, you should be able to check **server** side if `connect()` was called. If this check isn’t possible, then you are **trusting the client** not to call connectTransport twice. We shouldn’t _need_ to trust the client. There should be a mechanism server side to check if connect has been called to prevent an error from occurring.

We are not gonna add getters in mediasoup just to avoid app-level errors. That’s our philosophy (do less, do it fine). You should check why you client side is sending `connect` signal twice for the same transport (check your sent messages from client to server) and/or why your server side code is calling `connect()` twice on the same transport.

---

<div class="post-metadata">

**Author:** ![jbis9051](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@jbis9051](https://mediasoup.discourse.group/u/jbis9051)\
**Post date:** [April 24, 2020, 2:28pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/6 "2020-04-24T14:28:23Z")

</div>

> What can I say? I am not in front of your server side code. I just can guarantee that `Error: connect() already called` just happens if you call `transport.connect()` twice on the same server side transport.

Fair enough I will do more debugging and try to figure out the issue.

> We are not gonna add getters in mediasoup just to avoid app-level errors. That’s our philosophy (do less, do it fine). You should check why you client side is sending `connect` signal twice for the same transport (check your sent messages from client to server) and/or why your server side code is calling `connect()` twice on the same transport.

Again, I don’t think we should have to rely on the client. Should our client side code be written so this doesn’t happen? Yes, it should. But, **it’s on the client**. We can’t trust the client not to make the same request twice. There should be a way server side to do the check.

If you think we should just store it ourselves or using a try/catch pattern, I strongly disagree however I recognize it is your library. Thank you for the help.

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [April 24, 2020, 2:34pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/7 "2020-04-24T14:34:24Z")

</div>

> [@jbis9051](#):
>
> Again, I don’t think we should have to rely on the client. Should our client side code be written so this doesn’t happen? Yes, it should. But, **it’s on the client**. We can’t trust the client not to make the same request twice. There should be a way server side to do the check.

On `await transport.connect()` success, you can do:

```js
transport.appData.connected = true;

```

And then check that flag if attempted to call the same again.

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [April 24, 2020, 2:35pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/8 "2020-04-24T14:35:45Z")

</div>

Said that, I don’t want to add a `transport.connected` getter because people may thing that it means “everything is connected at ICE and DTLS” level while it’s not.

---

<div class="post-metadata">

**Author:** ![jbis9051](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@jbis9051](https://mediasoup.discourse.group/u/jbis9051)\
**Post date:** [April 24, 2020, 4:09pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/9 "2020-04-24T16:09:03Z")

</div>

I think this is a decent solution. I will note, however, this isn’t the source of truth (the source of truth is at the c++ level). But it should work.

Maybe add this to demo and/or docs?

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [April 24, 2020, 4:16pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/10 "2020-04-24T16:16:49Z")

</div>

> [@jbis9051](#):
>
> I think this is a decent solution. I will note, however, this isn’t the source of truth (the source of truth is at the c++ level). But it should work.

This is the source of truth because if `await transport.connect()` completes you know that it can be properly processed in C++.

Now, if you call twice to `transport.connect()` while the first call did not even complete… that’s a different problem.

> [@jbis9051](#):
>
> Maybe add this to demo and/or docs?

I cannot add to the demo something that fixes or improves nothing. That “issues” does not happen in the demo. And I cannot document “use transport.appData.connected to blablabla” because users can use `appData` for whatever thing they wish.

---

<div class="post-metadata">

**Author:** ![jbis9051](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@jbis9051](https://mediasoup.discourse.group/u/jbis9051)\
**Post date:** [April 24, 2020, 4:24pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/11 "2020-04-24T16:24:28Z")

</div>

Ah, I assumed you were do to the other post.

> BTW I’ve seen the “Error: connect() already called” error in the mediasoup demo server, so something can be improved.

Ok. I understand. Hopefully people will see this thread if they Google search. Thanks.

---

<div class="post-metadata">

**Author:** ![ibc](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ibc/32/1540_2.png) [@ibc](https://mediasoup.discourse.group/u/ibc)\
**Post date:** [April 24, 2020, 4:47pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/12 "2020-04-24T16:47:36Z")

</div>

> [@jbis9051](#):
>
> BTW I’ve seen the “Error: connect() already called” error in the mediasoup demo server, so something can be improved.

I’ve not seen that for a while. If that happens there is a but in the demo app code. I don’t want to hide it with a check. The check is already there: `transport.connect()` rejects so the server catches the exception and tells the client.

---

<div class="post-metadata">

**Author:** ![jbis9051](https://avatars.discourse-cdn.com/v4/letter/j/e47c2d/32.png) [@jbis9051](https://mediasoup.discourse.group/u/jbis9051)\
**Post date:** [April 24, 2020, 6:34pm UTC](https://mediasoup.discourse.group/t/error-connect-already-called/870/13 "2020-04-24T18:34:14Z")

</div>

I’d probably do a check (with the app data) and if it fails, then _handle the error_ by logging it. But the fact that you haven’t seen it in a while, does indicate that I likely have an issue in my front end code more than an underlying bug in mediasoup.