This might help to learn more about FFmpeg:
https://www.kurento.org/blog/rtp-ii-streaming-ffmpeg
I'd say, use something like port 20000 for audio's RTP and 20001 for
audio's RTCP.
Similarly, use 20002 and 20003 for video. This is because FFmpeg
doesn't really support "a=rtcp", if I recall correctly.
Apart from that... if you read the blog post carefully, you'll learn
what is the problem here: there are TWO semantically opposite
versions of SDP.
1) The SDP used in WebRTC and Kurento (even for the RtpEndpoint) is
one for SDP Offer/Answer, where every endpoint states the ports
where
they are listening. So, if Kurento replies with an SDP Answer
saying "
m=video
48128", it means
Kurento is listening on port
48128.
2) The "imperative" SDP (for a lack of a better name...) that
tells
some program where it must access a stream. And this is the type of
SDP supported by FFmpeg!
So if you get the SDP Answer from Kurento (type 1) and pass it to
FFmpeg (which assumes type 2), what is happening is:
* Kurento says "I'm listening on port 48128"
* You tell FFmpeg "hey, open a socket on port 48128" (which is
already in use by Kurento)
The way this should work is that you pass FFmpeg the SDP Offer that
you gave Kurento. This way, I believe you'd be close to make it
work, because Kurento would be sending data to the ports stated in
the SDP Offer, and FFmpeg would be getting data from that same port.
Regards
--
Juan Navarro
Kurento developer
@j1elo at GitHub & Twitter