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

John wrote:
> 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.

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

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

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

> this will help to demonstate how rtp works in practice.

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
:-(

> moreover this will clear concepts too.

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

http://www.faqs.org/rfcs/np.html#RTP

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:
http://www.google.com/search?q=linux...example%20code

good luck,
prg

John wrote:
> 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.

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-