No track data from remote peer. Make sure the publisher peer is sending packets for this track

[pSapien]

Community Question Link: https://community.cloudflare.com/t/turn-server-connection-issue/771271/2

I have asked the similar question in the community but to no avail.
Due to this issue, we have not yet realized our app yet.
Any help would be appreciated.

[Breathe97]

In an indescribable mess.

[pSapien]

In an indescribable mess.

not sure what this is about?

[Breathe97]

In an indescribable mess.

not sure what this is about?

You can try calling sessions/new before publishing. This is CF's own mistake and they are terrible.

[pSapien]

In an indescribable mess.

not sure what this is about?

You can try calling sessions/new before publishing. This is CF's own mistake and they are terrible.

In my mental model, this is how it works

A
-> Create a new session
-> Create RTCPeerConnection
-> Push Local Tracks

B
-> Create a new session
-> Create RTCPeerConnection
-> Push Local Tracks

A->B (add remote tracks of A to B)
B->A (add remote tracks of B to A)

this is how it should work, right?
You mean, we need to call again. Could you describe to me in detail?

[Breathe97]

In an indescribable mess.

not sure what this is about?

You can try calling sessions/new before publishing. This is CF's own mistake and they are terrible.

In my mental model, this is how it works

A -> Create a new session -> Push Local Tracks

B -> Create a new session -> Push Local Tracks

A->B (add remote tracks of A to B) B->A (add remote tracks of B to A)

this is how it should work, right? You mean, we need to call again. Could you describe to me in detail?

I can give you some advice.You're theoretically right to do this.But in the new version,The new session is not being conducted separately.They put the new session in the publish or subscribe section together.

So:
1、Publish : new tracks（await serve new session return sdp）.
2、Publish success and connected: setRemoteDescription and onconnectionstatechange .
3、Subscription is not necessary unless you want to see the other party.He's similar to publishing.

If you follow the above steps, you will still encounter a problem: CF will connect to RTC first before publishing (Fack) If you also encounter this problem, then you should need to manually perform a new session with the publisher or subscriber

[pSapien]

In an indescribable mess.

not sure what this is about?

You can try calling sessions/new before publishing. This is CF's own mistake and they are terrible.

In my mental model, this is how it works
A -> Create a new session -> Push Local Tracks
B -> Create a new session -> Push Local Tracks
A->B (add remote tracks of A to B) B->A (add remote tracks of B to A)
this is how it should work, right? You mean, we need to call again. Could you describe to me in detail?

I can give you some advice.You're theoretically right to do this.But in the new version,The new session is not being conducted separately.They put the new session in the publish or subscribe section together.

So: 1、Publish : new tracks（await serve new session return sdp）. 2、Publish success and connected: setRemoteDescription and onconnectionstatechange . 3、Subscription is not necessary unless you want to see the other party.He's similar to publishing.

If you follow the above steps, you will still encounter a problem: CF will connect to RTC first before publishing (Fack) If you also encounter this problem, then you should need to manually perform a new session with the publisher or subscriber

I have multiple peers from multiple ISPs, but the above problem only persists in a fixed set of peers.

Suppose there are 5 peers with 5 different ISPs.
Every combination works, instead of one. I suppose the problem is with the turn server itself which is unable to relay the media across those two peers.

[Breathe97]

In an indescribable mess.

not sure what this is about?

You can try calling sessions/new before publishing. This is CF's own mistake and they are terrible.

In my mental model, this is how it works
A -> Create a new session -> Push Local Tracks
B -> Create a new session -> Push Local Tracks
A->B (add remote tracks of A to B) B->A (add remote tracks of B to A)
this is how it should work, right? You mean, we need to call again. Could you describe to me in detail?

I can give you some advice.You're theoretically right to do this.But in the new version,The new session is not being conducted separately.They put the new session in the publish or subscribe section together.
So: 1、Publish : new tracks（await serve new session return sdp）. 2、Publish success and connected: setRemoteDescription and onconnectionstatechange . 3、Subscription is not necessary unless you want to see the other party.He's similar to publishing.
If you follow the above steps, you will still encounter a problem: CF will connect to RTC first before publishing (Fack) If you also encounter this problem, then you should need to manually perform a new session with the publisher or subscriber

I have multiple peers from multiple ISPs, but the above problem only persists in a fixed set of peers.

Suppose there are 5 peers with 5 different ISPs. Every combination works, instead of one. I suppose the problem is with the turn server itself which is unable to relay the media across those two peers.

I'm not sure what caused it, it's always good and bad here, but it's terrible anyway.But if I try to call new session again, it will become normal.

[pSapien]

In an indescribable mess.

not sure what this is about?

You can try calling sessions/new before publishing. This is CF's own mistake and they are terrible.

In my mental model, this is how it works
A -> Create a new session -> Push Local Tracks
B -> Create a new session -> Push Local Tracks
A->B (add remote tracks of A to B) B->A (add remote tracks of B to A)
this is how it should work, right? You mean, we need to call again. Could you describe to me in detail?

I can give you some advice.You're theoretically right to do this.But in the new version,The new session is not being conducted separately.They put the new session in the publish or subscribe section together.
So: 1、Publish : new tracks（await serve new session return sdp）. 2、Publish success and connected: setRemoteDescription and onconnectionstatechange . 3、Subscription is not necessary unless you want to see the other party.He's similar to publishing.
If you follow the above steps, you will still encounter a problem: CF will connect to RTC first before publishing (Fack) If you also encounter this problem, then you should need to manually perform a new session with the publisher or subscriber

I have multiple peers from multiple ISPs, but the above problem only persists in a fixed set of peers.
Suppose there are 5 peers with 5 different ISPs. Every combination works, instead of one. I suppose the problem is with the turn server itself which is unable to relay the media across those two peers.

I'm not sure what caused it, it's always good and bad here, but it's terrible anyway.But if I try to call new session again, it will become normal.

what makes it terrible? Everything, apart from those peers, works in my case. Nothing looks terrible to me though