Creating SDP for use with RTP forward feature

[Joe Palmer]

I have successfully setup Janus to forward a video stream as RTP using the video room demo and an API call to request rtp_forward. However, I have so far been unable play or decode the RTP stream as I don't think I have got my SDP file quite right yet. I can see data coming in on the port using netcat so I know the stream is working but I have been unable to get VLC or FFMpeg to understand it.

I have done a test and setup an instance of FFMpeg to stream video directly from my webcam using RTP. It gives me an SDP when I setup the stream which I can use to decode with another instance of FFMpeg. I tried modifying the SDP to define VP8 as the codex but still no joy:

v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 127.0.0.1
t=0 0
a=tool:libavformat 56.15.102
m=video 64592 RTP/AVP 96
b=AS:1000
a=rtpmap:96 VP8/90000

Does anyone have an SDP they have used with Janus to decode RTP forwarded data? Any suggestions on what is required in the SDP would be greatly appreciated.

Many thanks 

[Lorenzo Miniero]

The payload type must match what the browser is sending, so something different than 96.

L.

[Joe Palmer]

Thanks for the tip, I've managed to get it working!!! :)

Here is the SDP I have used:

v=0
o=- 0 0 IN IP4 127.0.0.1

s=RTP Video

c=IN IP4 127.0.0.1
t=0 0

m=video 10001 TCP 100
a=rtpmap:100 VP8/90000
a=fmtp:100 packetization-mode=1

I've underlined are the only parts I think need to be set dynamically based on what the browser sends and the assigned rtp_forward port (correct me if I'm wrong).

However, I've set the transport to TCP which is believe is correct based on this spec but I can see that it is still using UDP with this command:

sudo watch -n 0.1 "netstat -tulpn | grep janus"

Is there any way to get the RTP Forwarding to use TCP rather then UDP? If a TCP candidate was negotiated in the browser, would the RTP Forwarding also use TCP?

We are streaming very short videos and it is essential that there is no packet loss (it doesn't matter if the data is not transmitted in real-time).

Thanks again for you help.

[Lorenzo Miniero]

No, only udp is supported.

L.

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joe Palmer]

Ok, fair enough.

How hard do you think it would be to add TCP support to the rtp forward feature? If you were to get a pull request adding this functionality, is it likey to be accepted?

[Lorenzo Miniero]

Pull requests are always welcome :-)

That said, I don't believe it's needed, as the reason why it's UDP only is simple. UDP is connection-less, which means we can start forwarding even if no-one's listening, and we can even change listening/receiving apps on the fly and it still works. TCP would require the Streaming plugin to do a TCP connection towards the destination. What if it's not available? Should the request fail? Should it try again? Forever? What happens when the destination goes away and the connection is lost? Too much hassle, and not really needed. If you need TCP, just have the Streaming plugin send to, e.g., a local GStreamer pipeline, and have that pipeline simply forward stuff everything via TCP as you need it to. No need to reinvent the wheel.

L.