simple rtp implementations

Hi, i am reading about rtp. most rtp sources are not straight foward to understand and hence novices like me find it difficult to understand.

Is there not a simple rtp program (server) sources in C which can be understood easily.

this will help to demonstate how rtp works in practice.

moreover this will clear concepts too. thanks and regards, John

Reply to
John
Loading thread data ...

Everyone finds it difficult the first few (dozen?) times through :-)

This is not a simple beast and there is no way to make it "simple" , IMHO.

This is implementation specific. There is no "C" standard for RTP. The particular code is only as good as the programmers who wrote it and commented/documented it. I'm not aware of an "intro to RTP" example :-(

If you want to see just how much of a beast this is, review the RFCs. Hold on to your head.

formatting link
Once you see how it's pieced together, you may know where in the source code to look for what you're interested in or how to narrow a google search for the bits you need.

A first try with something like this in google:

formatting link
good luck, prg

Reply to
prg

If I were you, I would not bother. Remember ISDN? RPT will suffer the same fate.

In a nuthsell, the Internet (and indeed the entire software industry) is hardly static enough for committees to be building grandiose, all-encompassing protocols on top of them that try to bind together 40 years of legacy systems. In fact, there are a significant number of technical questions that have been inappropriately "answered" by such protocols. A good way to spot these protocols is that they are rife with tedium, generally showing the layout of some structure inside the body of a UDP or TCP packet that has unlimited potential for "extensions" and "improvements" and special cases and assumptions that the digital world is pretty much going to stay the same for a while.

People who design protocols like RPT ofent underestimate the dynamic nature of distributed computing - the fact that, unlike, say, distilled water, there is so much more to say about it fundamentally than what has already been said. The result is typically a 400-page specification that has been meticulously examined and rexamined for "correctness" and spelling errors.

But then comes along a 19-year-old kid who writes one application with no committee, no conferences, no Perrier, perhaps 1 legal pad, and certainly no government grants, and all of a sudden, 250 man-years of collective effort, not to mention the expense of plane trips, hotels, boardrooms, phone calls, floor space, equipment, etc. suddenly becomes defunct and irrelevant.

If you are intending to do some type of multimedia streaming, the very best thing you can do is (1) study the fundamentals (data compression, sampling, transforms, coding), and (2) roll your own protocol (of course on top of UDP/TCP). As risky and presumptuous as this might seem, you'll actually come out ahead because (1) you will know the fundamentals, which are applicable no matter what happens, and (2) you will not have wasted time studying something that might have been stillborn. You might even take the 400-page spec and only take out only the concepts that are universally applicable and ignore the rest.

If it turns out that you underestimated the 400-page spec, that it indeed was a winner, you won't have too much to worry about because, by having studied the fundamentals, you will be able readily interpret what the others have done.

-Le Chaud Lapin-

Reply to
Le Chaud Lapin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.