This is the client side. But you said that you was recalling the same transport whenever another user wants to talk (with whom?) What does this mean?
You must use different transports for consuming and producing and these transports should be assigned to each user, you cannot mix them.
@vpalmisano Each user is assigned a consumer and producer transport when they first connect. That voice.getConsumer()
line is pulling the Transport object out of memory.
ConnectMutation
/**
* Connect to the Mediasoup server as a producer and consumer, using
* WebRTC. This allows voice transmission to all other parties in the
* current room.
*/
connect: async (
_parent: Mutation,
{ room }: MutationConnectArgs,
{ voice, user }: SharedContext
): Promise<Connection> => {
if (!user) throw new AuthenticationError('You must be signed in')
const { producer, consumer } = await voice.connect(room, user.id)
return {
producer: {
id: producer.id,
iceCandidates: producer.iceCandidates as IceCandidate[],
dtlsParameters: producer.dtlsParameters as DtlsParameters,
iceParameters: producer.iceParameters as IceParameters
},
consumer: {
id: consumer.id,
iceCandidates: consumer.iceCandidates as IceCandidate[],
dtlsParameters: consumer.dtlsParameters as DtlsParameters,
iceParameters: consumer.iceParameters as IceParameters
}
}
},
voice.connect():
/**
* Connect to a room on this voice server. Hands back the transports
* for the given user and the router for the room.
*/
async connect (room: string, user: string): Promise<VoiceConnection> {
// find the router for this room, either on an existing worker or by finding the least-used worker
const router = await this.getRouter(room)
// create the WebRTC transports using Mediasoup
const producer = await createWebRtcTransport(router)
const consumer = await createWebRtcTransport(router)
// this is just a fancy in-memory store of all transports connected to the server
this.transports.add(user, producer, consumer)
return { producer, consumer, router }
}
@snnz See aboveâŠWhen the user connects to the server, Iâm creating both their producer and consumer transports and storing those objects into memory. Then, when a user wants to consume another producerâs stream, they execute the consume()
mutation and that recalls the consumer transport that was created for that user in the connect()
mutation (These are GraphQL mutations btw).
edit: also of note, these two snippets (and the last one) are from the server-side, not the client-side, in case that was not clear.
From what you posted, you are calling createWebRtcTransport
and after then you need also transportConnect
to complete the transport initialization. Next you can call produce
and consume
on it.
Actually the transport initialization is done as a part of the first produce/consume (and internal send/recv methods of the handlers). So the transports could pretty well sit uninitialized until then. And there is at least client-side âconnectâ event handler (otherwise transport.consume would have throwed an exception). The question is what is really happening during the connection phase, how is the âconnectâ event handled. Itâs difficult to judge from the fragmented picture.
Check recvTransport.connectionState value in the receiver side.
client and server in same pc ?
if not same you can control firewall port access
@snnz The first snippet of code I posted was the GraphQL mutation thatâs called when the user is trying to connect and needs its transport options. The second snippet is from voice.connect()
, which is an instance of a class I made to hold the transport objects between mutations. Sorry if thatâs all a bit confusing, but one big pain point I had when developing this was the amount of shared state that was required between API calls. I couldnât find a way to look up a Transport object from Mediasoup that I had already created.
@ibc Before I call recvTransport.consume()
on the client side, recvTransport.connectionState
is ânewâ. After I call consume()
, it changes to âconnectedâ.
@hdoru yes, client and server are on the same PC.