Handling of custom RTP connection

Topics: Question
Apr 13, 2015 at 3:48 PM
Dear Julius,

again thanks for your support with the H.264 stream. I had a look at your source code, but my understanding is still very limited (not really a programmer and only recently started working with C#), so I thought I directly ask.
  1. I would like to be able setup a RTP connection without contacting a RTSP server, because I have a device broadcasting to my PC. I have some technical details regarding the stream, but to make it as simple as possible, I would like to "listen" on a certain port, receive rtp packets there, select a certain payload and then process this as before. One idea I had was to provide the SDP as a string, derive a RTPClient from this and process the packets on the RtpFrameChanged event depending on the payload. Do you think this is possible? Furthermore, is it possible to setup such a connection without SDP, by knowing port and payload?
  2. How would I deal with custom payloads not covered by your library or the RFC* specifications for the same scenario as before (port + payload known)? E.g. something like a "raw depayer", just waiting until the frame is completed (e.g. marked), then reordering the payload and providing this. Looking at your code, I think creating a new class based on RtpFrame / RFC2435Frame would be the way to go.
Thanks in advance for your support!
Coordinator
Apr 13, 2015 at 4:02 PM
Edited Apr 13, 2015 at 4:03 PM
1) Anything is possible :-)

This scenario is already realized with both the RtpSource and RtpClient classes. See the FromMediaDescription method.

The RtpFrame is a raw depayloader or more correctly depacketizer, no modifications should be required at that level for any profile. (Proprietary or otherwise)

2) There's simply no reason to do this as the result is propriety, your better off going with a proprietary protocol rather than attempting to make rtp or rtsp work for your scenario.

With that being said its completely possible and a person who wants to do such would understand how based on whatever profile they envisioned with respect to the provided existing proposed standards.

If you can outline what your trying to do, how and why I will provide any additional information you may require.
Marked as answer by juliusfriedman on 4/13/2015 at 8:02 AM
Apr 13, 2015 at 4:37 PM
Edited Apr 13, 2015 at 4:37 PM
Wow.. that was fast, thanks for the reply!

1) I found the method FromMediaDescription with which I can get a rtpClient I only need to Activate, but how about the non-sdp approach? Or you think it's easier to just generate a small SDP for such a scenario (port, payload, maybe source_ip)? E.g. for H.264 with given port and payload it could look like (can not test at the moment)
v=0
c=IN IP4 SOURCE_IP
m=video PORTNUMBER RTP/AVP PAYLOAD
a=rtpmap:PAYLOAD H264/90000
2) Thanks for the hint, that RtpFrame already serves that purpose. I understand, that something proprietary is not favorable, but I am not the designer on the sender side, just trying to receive and process it ;)

Outline:
I am receiving two RTP streams on two different ports: One is a video stream encoded as H.264, the other unfortunately proprietary, the raw RTP depacketizer should sufficient here. I know the payload of the latter one and how I can further process this, but first I have to get the data.
Coordinator
Apr 13, 2015 at 4:44 PM
Edited Apr 14, 2015 at 3:58 PM
It's not just easier its required.

Without a Sdp there's no standard way to negotiate the format of the rtp session..

Therefore just generate one as it will come in handy in various places.

The designer or architect should have documents describing the payload format.

The sdp would simply need to be augmented to support the description of the profile.

Again if you can provide more information I can provide more specific answers.

Last, If you can't or don't want to have a media description then you will have to handle the packet events and provide your own frame events.
Marked as answer by juliusfriedman on 4/13/2015 at 8:44 AM