No track received despite having a valid `m` field in the SDP

Unity Engine
, ,
1

Hello.

I have an issue where the OnTrack function attached to my RTCPeerConnection never seem to be called.
The way things are implemented right now is the following :

  1. I call .AddTransceiver(TrackKind.Video); on my peer connection
  2. I generate an Offer using .CreateOffer and call .SetLocalDescription with it
  3. I send it to my other peer (not a unity client)

The next steps are concurent so they can executed in any order :

  • At this point the trickle ICE start and I start to receive ICE candidate which I add to my peer
  • I receive a answer SDP from the other peer, which include a valid m field (exemple later) and call .SetRemoteDescription on my peer with it.

Usually, the ICE connection is already at Completed before .SetRemoteDescription is called.

What I was expecting was to receive at least one video track (corresponding to the m field) on the OnTrack callback, but I never receive anything.

The proposed video track use VP8 and I checked the media capability of the unity peer at runtime and it is supported.

That is why I don’t understand why it doesn’t work.

Here is an example of answer sdp received :

v=0
o=- 2265323530188218573 1634655033 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 2C:A5:smile:2:0B:73:18:FF:10:8E:9B:3D:5C:F1:62:78:4C:67:61:3B:AF:89:B1:18:75:2B:8B:E8:BC:F0:9D:01:BF
a=group:BUNDLE 0
m=video 9 UDP/TLS/RTP/SAVPF 127
c=IN IP4 0.0.0.0
a=setup:active
a=mid:0
a=ice-ufrag:FBqBTHhpgwvyksDG
a=ice-pwd:KazjYfHfKRAGKlKwhHrzOtTigORjPhzh
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:127 VP8/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=recvonly
2

It seems not valid candidates might not exist on your network environment.
You can check candidates with this tool.

3

Gathering candidate and connection do seem to be working fine : I receive valid candidate from my remote peer and add them to my peer connection. The RtcIceConnectionState of my peer do go from New all the way to Completed.

4

I just noticied that a=recvonly is present in the answer, so it probably come from that

5

You can change recvonly/sendonly in SDP using a property RTCRtpTransceiver.direction.

6

Setting it to recvonly fixed my issue ! Thanks :slight_smile: