Sending on Multiple Tracks

[dgblack]

Hi again,

I am having trouble sending/receiving more than one video track at a time.

If peer A sends a single video track to peer B or vice versa, everything works perfectly. However, if peer B also sends video to peer A at the same time (on a separate track), only one of the peers receives video. If peer A tries to send video to peer B over two separate tracks at the same time, peer B does not receive anything. The tracks have unique MIDs, SSRCs, etc. Also, the onOpen event fires for both tracks, and both remain open throughout the test.

To find out where the messages are stopping, I wrote custom MediaHandlers that just print whenever new data passes through. I placed these at the end of the sending chain (i.e. the last thing to happen before sending) and the beginning of the receiving chain (the first thing that happens upon receipt of new data). The sending handlers print as normal at a high rate, but the receiving handlers never print a single message when there is more than one track. Thus, it seems the data is going missing between being sent by peer A and being received by peer B.

Do you have any idea what could be happening? I'm pretty stuck...

Thanks!
David

Edit: I'm testing this where peer A is a Windows 11 laptop and peer B is an Ubuntu 20.04 machine connected to Ethernet. If the Windows is sending 2 streams, they are received and shown on the Ubuntu. But if the Ubuntu is sending two streams, nothing reaches the laptop. If both are sending one and receiving one, only the Windows receives video.

[dgblack]

I've included the signaling messages in case they could help. They look correct to me... Thanks!

Offer:

v=0
o=rtc 1267851209 0 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video ultrasound
a=group:LS video ultrasound
a=msid-semantic:WMS *
a=ice-options:ice2,trickle
a=fingerprint:sha-256 07:4A:CE:EE:0F:A3:DB:D4:D2:AE:DA:62:53:B5:E6:AD:C5:4E:16:8A:36:35:E5:DF:B0:A4:55:06:2F:78:F2:BE
m=video 43630 UDP/TLS/RTP/SAVPF 96
c=IN IP4 192.168.4.83
a=mid:video
a=recvonly
a=ssrc:1274741924 cname:video
a=rtcp-mux
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1;level-asymmetry-allowed=1
a=setup:actpass
a=ice-ufrag:QheN
a=ice-pwd:ZhDWQwoS0YavylZGv/nTuG
a=candidate:2 1 UDP 2130706175 fd00::d72:1949:5e3e:571b 43630 typ host
a=candidate:3 1 UDP 2130705919 2001:a61:258b:801:d72:1949:5e3e:571b 43630 typ host
a=candidate:1 1 UDP 2122317823 192.168.4.83 43630 typ host
a=candidate:4 1 UDP 1686109439 93.104.74.195 43630 typ srflx raddr 0.0.0.0 rport 0
m=video 43630 UDP/TLS/RTP/SAVPF 96
c=IN IP4 192.168.4.83
a=mid:ultrasound
a=recvonly
a=ssrc:1555792254 cname:ultrasound
a=rtcp-mux
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1;level-asymmetry-allowed=1
a=setup:actpass
a=ice-ufrag:QheN
a=ice-pwd:ZhDWQwoS0YavylZGv/nTuG
a=end-of-candidates

Answer:

v=0
o=rtc 1405481970 0 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video ultrasound
a=group:LS video ultrasound
a=msid-semantic:WMS *
a=ice-options:ice2,trickle
a=fingerprint:sha-256 DC:47:82:29:25:E0:EE:A9:CA:4B:F8:DD:4E:97:C0:71:1A:EE:3C:9F:3F:E8:49:9E:7B:46:8B:DB:BF:82:DC:B3
m=video 39220 UDP/TLS/RTP/SAVPF 96
c=IN IP4 192.168.4.83
a=mid:video
a=sendonly
a=rtcp-mux
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1;level-asymmetry-allowed=1
a=setup:active
a=ice-ufrag:MFKL
a=ice-pwd:mxIC3XRKDoems+mDoNIxKg
a=candidate:2 1 UDP 2130706175 fd00::d72:1949:5e3e:571b 39220 typ host
a=candidate:3 1 UDP 2130705919 2001:a61:258b:801:d72:1949:5e3e:571b 39220 typ host
a=candidate:1 1 UDP 2122317823 192.168.4.83 39220 typ host
a=candidate:5 1 UDP 1686109183 93.104.74.195 39220 typ srflx raddr 0.0.0.0 rport 0
m=video 39220 UDP/TLS/RTP/SAVPF 96
c=IN IP4 192.168.4.83
a=mid:ultrasound
a=sendonly
a=rtcp-mux
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1;level-asymmetry-allowed=1
a=setup:active
a=ice-ufrag:MFKL
a=ice-pwd:mxIC3XRKDoems+mDoNIxKg
a=end-of-candidates

[paullouisageneau]

SSRCs must be set in the description by the sender of the stream, not by the receiver. Here, since the sender answers, you need to add the SSRC to the track media description in the onTrack callback:

pc->onTrack([mySSRC](shared_ptr<Track> track) {
    auto description = track->description();
    description.addSSRC(mySSRC, "video");
    track->setDescription(std::move(description));
});

[dgblack]

That did the trick, thanks so much!