[BUG] Huawei cannot connect successfully as a viewer

[Nomidia]

Logging
success.log
fail.log
sdp samsung.log
sdp huawei.log

Describe the bug

1. REMOTE_SDP and LOCAL_SDP do not match when I use Huawei as a viewer. The attributes of audio and video are "sendrecv" and "recvonly" in remote sdp, however the corresponding attributes in local sdp are "sendonly" and "sendrecv". It seems the attributes of audio and video are wrong.

The first mediaSectionId is 0, corresponds to audio. But here the media track is video.

amazon-kinesis-video-streams-webrtc-sdk-c/src/source/PeerConnection/SessionDescription.c

Line 533 in f3a34c2

pSdpMediaDescriptionRemote = &pRemoteSessionDescription->mediaDescriptions[mediaSectionId];

I modify the attributes temporarily as follows, but Huawei still can not connect successfully.

        if (pRtcMediaStreamTrack->codec == RTC_CODEC_OPUS || pRtcMediaStreamTrack->codec == RTC_CODEC_MULAW ||
               pRtcMediaStreamTrack->codec == RTC_CODEC_ALAW) {
            STRCPY(pSdpMediaDescription->sdpAttributes[attributeCount].attributeName, "sendrecv");
        } else {
            STRCPY(pSdpMediaDescription->sdpAttributes[attributeCount].attributeName, "sendonly");
        }

It shows the H264 is missing, I will confirm with the app team.

Since the lack of "a=rtpmap:100 H264/90000", it only delete the audio track and add it to the the tail of the list.

amazon-kinesis-video-streams-webrtc-sdk-c/src/source/PeerConnection/SessionDescription.c

Line 873 in f3a34c2

STATUS reorderTransceiverByRemoteDescription(PKvsPeerConnection pKvsPeerConnection, PSessionDescription pRemoteSessionDescription)

Now it looks the root cause is the lack of "H264/90000". We need to check on app first.

[Nomidia]

After I delete this line, the app succeeds to connect the device, but no frames, since the codec does not match.

amazon-kinesis-video-streams-webrtc-sdk-c/src/source/PeerConnection/SessionDescription.c

Line 744 in f3a34c2

CHK_STATUS(reorderTransceiverByRemoteDescription(pKvsPeerConnection, pRemoteSessionDescription));

[hassanctech]

Can you please confirm which commit you're using and if you're using the master sample directly or if you've made any changes?

In the fail.log case I see that the remote description (viewer side) provides the audio m-line first and the video m-line second. In our Master Sample we start off with the transceivers in the other order (video first, then audio) and we proceed to construct the answer in the same order unless we see the offer is in a different order in which case we call the method you mentioned to swap the order:

amazon-kinesis-video-streams-webrtc-sdk-c/src/source/PeerConnection/SessionDescription.c

Line 744 in f3a34c2

CHK_STATUS(reorderTransceiverByRemoteDescription(pKvsPeerConnection, pRemoteSessionDescription));

You should not delete that line. It appears though that the missing codec would cause the problem, if the codec is missing it will select 0 in the answer which means that transceiver is not going to be actively transmitting. Also is it is a requirement (according to WebRTC spec) that the audio / video m-lines must be in matching order in the answer. If I look at samsung.log for both offer and answer the order is audio then video. The failure in the huawei case is that the offer has audio m-line then video m-line but the answer has the reverse -- this will fail to stream, you must make sure the reorder transceiver is there so the order of m-lines is respected. I think once you resolve your issue for not having the matching codec then this problem will be resolved.

[hassanctech]

I assume this is answered and am closing the ticket. Let me know if there are open issues.

[Nomidia]

Indeed there are two transcerivers for audio and video. When the device receives the remote sdp offer at first, the order is audio first. When the reorderTransceiverByRemoteDescription is called, after the audio is put to the tail, due to the absence of h264 in remote sdp offer, the order of video is not adjusted again. After that the order is video first. It seems there is something different that causes the absebce of h264 on Android app, we are still working on it.

[hassanctech]

There are two known issues open that I have not had the time to work on yet but are on my radar that I think may be related, you can have a look and maybe +1 them if it is impacting you:

#867 (reorder fails when codec not found)
#803

In either case even if it is fixed your real issue is why h264 is absent from your Android app, once you fix that it should work.