kms_sdp_reject_media_handler_init_answer

[omidsaifpanahi]

We are using Kurento Media Server 7. In the backend, we use Node.js, and it works correctly for the web. However, since Kurento has not provided updates for Android for several years, we used pure WebRTC code to create SDP offers and ICE candidates. We did not see any errors in the Node.js project. However, on the media server, I see the following log:

0x7f0f8800b700 WARN sdprejectmediahandler kmssdprejectmediahandler.c:109:kms_sdp_reject_media_handler_init_answer:<KmsSdpRejectMediaHandler@0x7f0f8000df00> Rejecting media: 'video'

And the following piece of code in Node.js does not execute:

webRtcEndpoint.on("IceCandidateFound", function (event) {
    const candidate = kurento.getComplexType("IceCandidate")(event.candidate);

    socket.emit("iceCandidate", {
        candidate: candidate 
    });
});

As a result, ICE candidates are not being sent to the user.

I would appreciate it if someone could guide me on how to generate correct SDP from Android so that the media server does not encounter errors.

Have a nice day.

[j1elo]

Would be a good idea to show a sample SDP that is being sent to the server! Please share one, you can just copy it here (better if you apply "code" formatting in the reply editor)

From the top of my mind, the most common issue that could happen is that there are more than 1 audio and 1 video. Kurento doesn't implement support for multiple tracks per "Peer connection" (WebRtcEndpoint), so if you have e.g. 2 "m=video" lines, that will be rejected.

[omidsaifpanahi]

v=0
o=- 2851286527165273770 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS
m=video 9 RTP/AVPF 96 97 98 99 100 101 127 123 125 122 124
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:A71a
a=ice-pwd:WJirDZ4hMLDAKclWR0LXWd9b
a=ice-options:trickle renomination
a=mid:video
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 H264/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640c1f
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 H264/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=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:123 rtx/90000
a=fmtp:123 apt=127
a=rtpmap:125 red/90000
a=rtpmap:122 rtx/90000
a=fmtp:122 apt=125
a=rtpmap:124 ulpfec/90000

This is my SDP sample being sent from Android to the Node.js server. Please provide a solution to this problem. Thank you @j1elo

[j1elo]

Do you have any other warnings in the logs? Did you raise the logging level to Debug so more messages are displayed?

The target is to see if any relevant message appears in the log, such as this (1), this (2), this (3), or this (4).

[omidsaifpanahi]

Mr. Juan Navarro , thank you very much for your response. I didn't see the logs you mentioned. However, by comparing the SDP sent from the web with the SDP that came from Android, I noticed that the line 'a=fingerprint:sha-256 ...' was not being sent. By setting this value, we were able to see the presenter's video.

Have a nice day.
@j1elo