One-sided MediaStreamTrack always Inactive? (How to activate an Inactive track?)

[ha-ves]

Scenario:

PeerA is the Caller.
PeerB is the Callee.

Both are already connected with a data channel (because no media is needed yet).

Then,

1. PeerA now wants to receive video, so it creates a RecvOnly MediaStream,
2. Renegotiation is requested and signaling is being done,
3. PeerB receives the signaling and accepts a new MediaStream which says LocalTrack is Inactive (& RemoteTrack is RecvOnly).

I thought a workaround would be so PeerB creates a SendOnly MediaStream?
But instead, it quite obviously creates a different "channel"

The same happens if PeerB wants to send video.

[ChristopheI]

SDP must not be used to request a media butdescribes how medias are managed for each Peer

So in your case since you have a DataChannel, using it, PeerA can asked PeerB to add a video.
PeerB in the SDP will create a SendOnly Video MediaStream

On PeerA since you have no video to stream, you will set a RecvOnly Video MediaStream

If later, Peer A needs also to send Video, you can set the Video MediaStream from RecvOnly to SendRecv

[ha-ves]

@ChristopheI

Do you mean PeerB must addTrack a SendOnly before PeerA sends an offer with RecvOnly? Does that mean I have to handle suppression of the onnegotiationneeded event? I made it to be following the perfect negotiation pattern.

or

Do you mean by calling SetMediaStreamStatus on PeerA's VideoStream? Because I did that and it now complains about SecurityContext, here's my setup now:

1. PeerB addTrack of SendRecv,
   1. It fires onnegotiationneeded
      1. which does createOffer
      2. setLocalDescription
      3. send the offer to PeerA
2. PeerA receives the offer from PeerB
   1. setRemoteDescription from the SDP
   2. checks if VideoRemoteTrack (PeerB's) is SendRecv or SendOnly
   3. SetMediaStreamStatus(SDPMediaTypesEnum.video, MediaStreamStatusEnum.RecvOnly)
   4. createAnswer
   5. setLocalDescription
   6. send the answer to PeerB
3. PeerB receives the answer
   1. setRemoteDescription from the SDP
   2. wait for VideoRemoteTrack to be not null
   3. starts video
4. PeerA warns about "RTP or RTCP packet received before secure context ready."
   Is it because it doesn't have a MediaStream beforehand, which then creates with Inactive status without a SecureContext?

[ChristopheI]

Do you mean PeerB must addTrack a SendOnly before PeerA sends an offer with RecvOnly?
Yes.

Could you share SDP (offers and answers) exchanged between peers ?

[ha-ves]

SDPs

{"type":"offer","sdp":"v=0
o=- 37942 0 IN IP4 127.0.0.1
s=sipsorcery
t=0 0
a=group:BUNDLE 0 1
m=video 9 UDP/TLS/RTP/SAVP 96 100
c=IN IP4 0.0.0.0
a=ice-ufrag:VVRA
a=ice-pwd:CXZGKMOPSHAQJWUAJVVICGAM
a=fingerprint:sha-256 FE:9A:B2:F3:01:FB:47:E1:D4:2F:88:95:56:1F:B3:92:D2:39:CA:D0:04:C5:7A:64:21:AD:3D:6E:05:41:43:B1
a=setup:active
a=candidate:1231603315 1 udp 8447 <relay_ip> 58575 typ relay raddr 0.0.0.0 rport 0 generation 0
a=candidate:1231603315 1 udp 8447 <relay_ip> 58575 typ relay raddr 0.0.0.0 rport 0 generation 0
a=candidate:1231603315 1 udp 8447 <relay_ip> 58575 typ relay raddr 0.0.0.0 rport 0 generation 0
a=ice-options:ice2,trickle
a=mid:0
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtpmap:100 H264/90000
a=rtcp-fb:100 goog-remb
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtcp-mux
a=rtcp:9 IN IP4 0.0.0.0
a=end-of-candidates
a=sendonly
a=ssrc:49129812 cname:3190ed7b-1274-46c2-93d7-41b2110f78ef
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:VVRA
a=ice-pwd:CXZGKMOPSHAQJWUAJVVICGAM
a=fingerprint:sha-256 FE:9A:B2:F3:01:FB:47:E1:D4:2F:88:95:56:1F:B3:92:D2:39:CA:D0:04:C5:7A:64:21:AD:3D:6E:05:41:43:B1
a=setup:active
a=ice-options:ice2,trickle
a=mid:1
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sctp-port:5000
a=max-message-size:262144
"}

{"type":"answer","sdp":"v=0
o=- 14969 0 IN IP4 127.0.0.1
s=sipsorcery
t=0 0
a=group:BUNDLE 0 1
m=video 9 UDP/TLS/RTP/SAVP 96 100
c=IN IP4 0.0.0.0
a=ice-ufrag:JSUR
a=ice-pwd:LNITUPUYTWDNPSWETOIJKEPI
a=fingerprint:sha-256 AA:64:5B:ED:09:59:CC:DD:10:12:FF:82:8B:8B:E1:C3:A2:BF:FC:66:16:10:88:DC:38:9C:06:49:21:B2:2D:9D
a=setup:active
a=candidate:1231603315 1 udp 8447 <relay_ip> 50153 typ relay raddr 0.0.0.0 rport 0 generation 0
a=candidate:1231603315 1 udp 8447 <relay_ip> 50153 typ relay raddr 0.0.0.0 rport 0 generation 0
a=candidate:1231603315 1 udp 8447 <relay_ip> 50153 typ relay raddr 0.0.0.0 rport 0 generation 0
a=candidate:1231603315 1 udp 8447 <relay_ip> 50153 typ relay raddr 0.0.0.0 rport 0 generation 0
a=ice-options:ice2,trickle
a=mid:0
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtpmap:100 H264/90000
a=rtcp-fb:100 goog-remb
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtcp-mux
a=rtcp:9 IN IP4 0.0.0.0
a=end-of-candidates
a=recvonly
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:JSUR
a=ice-pwd:LNITUPUYTWDNPSWETOIJKEPI
a=fingerprint:sha-256 AA:64:5B:ED:09:59:CC:DD:10:12:FF:82:8B:8B:E1:C3:A2:BF:FC:66:16:10:88:DC:38:9C:06:49:21:B2:2D:9D
a=setup:active
a=ice-options:ice2,trickle
a=mid:1
a=sctp-port:5000
a=max-message-size:262144
"}

Similar problem with #1135, except that there wants to have the ontrack event, here I just want to activate the track.

[ChristopheI]

All seems correct in SDP

PeerB receives the answer

1. setRemoteDescription from the SDP
2. wait for VideoRemoteTrack to be not null

=> You don't need to check this

3. starts video

once the PeerConnection is again connected you can start the video

[ha-ves]

I tested browser creates a RecvOnly instead of Inactive for this case.

Since it's not implemented internally in SIPSorcery, this is some pseudo signaling I used:

// if offer

if (sdp.Media.Any(m => m.MediaStreamStatus is MediaStreamStatusEnum.SendOnly or MediaStreamStatusEnum.SendRecv))
{
    PC.addTrack(new MediaStreamTrack(/*VideoFormat(s)*/, MediaStreamStatusEnum.RecvOnly));
}

PC.setRemoteDescription(sdpstr);

// signal the answer