RTP endpoint doesn't get UDP as media input (which gstreamer probably does)

[RobotnickIsrael]

[X] I have read the SUPPORT document [X] I have checked the Troubleshooting Guide [X] I have tested with the latest version of Kurento

Issue description ENHANCMENT

I gave kurento RTPEndPoint the following SDP:

v=0
o=- 0 0 IN IP4 10.88.5.148
s=bla
c=IN IP4 239.10.30.70
t=0 0
a=tool:libavformat 58.10.100
m=video 51000 UDP 96
a=rtpmap:96 H264/90000
a=control:mpegts-transport
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1; sporp-parameter-sets=Z2QAHqwspQLASbAUiAAAAwAIAAADAZcTAAExLAAD0JP4xwdoWLRY,a0kJNSUA; profile-level-id=64001E
a=sendonly

VLC works fine with this SDP. This video displays well on vlc+ffmpeg (though ffmpeg doesn't work with the sdp, only if I give the ip+port directly. Don't know why).

Context

Getting an error in kms:

sdpagent: kms_sdp_agent_handler: Unmanaged protocol: video UDP, handler: KmsSdpRtpAvpfMediaHandler Cannot handle media 'video UDP'

How to reproduce?

Give RTPendpoint with the same offer.

Expected & current behavior

Expected: Handle UDP

(Optional) Possible solution

1. Just pass the sdp data to gstreamer , it probably knows how to handle UDP.

INFO about Kurento Media Server

• Kurento version: 6.13.2
• Server OS: Centos running offical kms docker
• Installation method:
  • [] apt-get
  • [X] Docker
  • [] AWS
  • [] Built from sources

INFO about your Application Server

• Language: Node.js
• Kurento Client version: 6.13.1

INFO about end-user clients

• Device(s): Desktop
• OS(es): Windows 10
• Browser(s): Chrome 73

INFO about your environment

RTPEndpoint->WebRTC Endpoint No stun\Turn on server (external_IP), but stun to chrome

[j1elo]

I gave kurento RTPEndPoint the following SDP:

v=0
o=- 0 0 IN IP4 10.88.5.148
s=bla
c=IN IP4 239.10.30.70
t=0 0
a=tool:libavformat 58.10.100
m=video 51000 UDP 96
a=rtpmap:96 H264/90000
a=control:mpegts-transport
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1; sporp-parameter-sets...
a=sendonly

Did you copy the SDP message as-is? Especially this line, did you copy literally like the original, or is it cut down at the end?

a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1; sporp-parameter-sets...

those three dots seem strange: sporp-parameter-sets...

I think you wrote that one by hand, because the correct name for the attribute is "sprop-parameter-sets", and it usually looks like this:

sprop-parameter-sets=Z0IAKeNQFAe2AtwEBAaQeJEV,aM48gA==

Please copy the whole SDP, as the crash could be coming from parsing the info from this field.

[RobotnickIsrael]

I fixed the SDP to be as it is, I don't think it's related. The crash was on my original report but I noticed what caused these errors (2 KMS having the same port), so I took it out from the report just a few minutes after. It's only an enhancement that is probably rather easy to do. (gstreamer should work with UDP just as with RTP, probably some validation doesn't let the sdp data get to gstreamer)

[vanhungoz]

@RobotnickIsrael how did you fix it?

[RobotnickIsrael]

I didnt fix kurento, just the opened issue... I'm trying to see if i can get it to work with udp while writing rtp on the sdp, but the multicast also makes problems

[RobotnickIsrael]

@vanhungoz Evantually what I did is created a ffmpeg process that changes the UDP transport to RTP transport - without transcoding. (running with zero latency mode) It takes about 2.4% CPU on my computer and no noticeable lag or latency. Of course I release it when I release the KMS.

It's actually very useful - it solves me the multicast problem that KMS does not support and the fact the many of my client do not "SDP negotiate", they just send the stream to some port. This way after I get the SDP answer from KMS I use ffmpeg to redirect what I get from the client from whatever port they send to whatever port KMS listens too. And the best bonus is that ffmpeg also knows to create SDP files - so I take the SDP file and give it to kurento.

works like a charm. (Though takes 7-10 seconds to connect)