webrtc

webrtc copied to clipboard

Your environment.

• Version: pionWebrtc v3.1.16
• Browser: Chrome newest version
• Other Information - Using simulcast feature with 16 video/audio tracks source

What did you do?

I'm building a livestreaming project and has a peer between chrome and pion (server), it was running by pm2. In my test case, i'm using ChromeA to peer and pushing video data to pionA, after that i forward data from pionA to pionB and pionB forward to ChromeB (~100 clients)

What did you expect?

PionB will receive all of PionA data.

What happened?

Randomly i got just one line, sometime a got lots of this. Incoming unhandled RTP ssrc(1353327085), OnTrack will not be fired. mid RTP Extensions required for Simulcast

So What's happen When we see this. If PionA send 16 tracks to PionB, it will not receive enough?

Hi @lamhai1401

Is PionB the instance printing the message? Can you reproduce this reliably? I have been trying to reproduce/fix this and haven’t been able too!

@Sean-Der Sorry to bother you This is what i have done.

Like the img below!

PionA & PionB has only one simulcast peer as P1 PionB & ChromeB has only one simulcast peer as P2 i have multiple ChromeA to peer with PionA (which have 1 video/audio track) For each ChromeA peering to PionA, P1 & P2 need to add one more track and need re-handshake. So if we have 16 ChromeA clients peering to PionA at the same time, P1 & P2 need to add 16 tracks and re-handshake one by one continuously.

So we have 16 times re-handshake but not at all export this line. Just randomly. Sometime only 1, sometime more than 1, sometime not. Incoming unhandled RTP ssrc(1353327085), OnTrack will not be fired. mid RTP Extensions required for Simulcast

Hope this help!

Great graph @lamhai1401 !

So sometimes when P1 renegotiates and adds another track PionB starts printing that error?

Does P1 ever remote tracks, or just add?

Hey @lamhai1401

Would you mind running https://github.com/pion/webrtc/commit/7cd8151261ec5bbb8e1b243ca94073cbc2754e69 and reproducing the issue? I am going to work on adding some tests to get to the bottom of this.

@boks1971 also hit this issue, so will be digging in :)

So sometimes when P1 renegotiates and adds another track PionB starts printing that error?

Yes

Does P1 ever remote tracks, or just add?

P1 just receive data from PionA and forward, only use add/remove track.

reproducing the issue?

I will do more test today, What things You want me to collect, like stdout/stderr or pprof?

@Sean-Der Here is my log file sdtout.log

@boks1971 Hey! What did you do until you saw that error, with the latency network, you will get it easier.

@lamhai1401 That line can happen if PionA sends before PionB has called SetRemoteDescription so it doesn't necessarily mean an error happened.

• Was video not working when these were printed?
• Can you log your SetRemoteDescription calls and confirm that those SSRCes were being sent to PionB

Really good data here, thank you so much for all this debugging.

Was video not working when these were printed?

This is my real problem. As I said, PionA send 16 tracks to PionB, sometime PionB just got 14, 15 When i checked log file OnTrack event was not call.

Can you log your SetRemoteDescription calls and confirm that those SSRCes were being sent to PionB

Of course but Is there a way for Me to get SSRC number for each time i call SetRemoteDescription ?

before PionB has called SetRemoteDescription

Could you tell me: 1.If I have 1 SDP, 10 candidates for each handshaking. So After I added SDP and 8 candidates peer state change to connected, 2 candidates incoming, i still call AddICECandidate, this is safe ?

2. I'm using simulcast peer. So i have to renegotiates multiple times. Handshake-A has SDP-A and Candidates-A (C-A) Handshake-B has SDP-B and Candidates-B (C-B) PionA send all of this to PionB at the same time. What if PionB receive SDP-A, C-A, C-B first and set it and receive SDP-B and set it after that, this is safe?

3. What do you think if we check something like CanSetRemoteDescription & CanAddICECandidate before we set ?

@lamhai1401 The specific issue I am looking is Firefox specific. It does not work when Firefox sends both screen share and video tracks in the same offer.

Your use case sounds like some signalling state mishap between Pion A and Pion B.

Hi @lamhai1401

Would you mind trying v3.1.19 ? Commits 65b51732e202203cb438af6f678c510fb27c4c05 and 2949e539b7b1d483dcb3c71abe68f49f5eeef7f8 both improve Simulcast. I am not sure if it will fix your issue (since we don't have a reproduce) but fixes one known issue we discovered.

The error comes up when the "Serve many PeerConnections with one UDP port" feature is enabled, while pion A is sending packets of Chrome A1 and A2 to the same port on Pion B

// Listen on UDP Port 8443
udpListener, _ := net.ListenUDP("udp", &net.UDPAddr{
    IP:   net.IP{0, 0, 0, 0},
    Port: 8443,
})

// Configure a SettingEngine to use our UDPMux. By default a PeerConnection has
// no global state. The API+SettingEngine allows the user to share state between them.
// In this case we are sharing our listening port across many.
settingEngine := webrtc.SettingEngine{}
settingEngine.SetICEUDPMux(webrtc.NewICEUDPMux(nil, udpListener))

// Create a new API using our SettingEngine
api = webrtc.NewAPI(webrtc.WithSettingEngine(settingEngine))

// Create a new PeerConnection
peerConnection_, := api.NewPeerConnection(webrtc.Configuration{})

Closing because I believe the issue has been solved, I haven’t gotten any reports of Simulcast probing failed.

@zslava88 hopefully things are working for you! If you are still having an issue please reach out on Slack or file a new issue.

Thanks for using Pion!