simple rtp implementations

Discussion in 'VOIP' started by John, Feb 18, 2006.

  1. John

    John Guest

    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, Feb 18, 2006
    #1
    1. Advertising

  2. John

    prg Guest

    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 rtp example code

    good luck,
    prg
     
    prg, Feb 18, 2006
    #2
    1. Advertising

  3. 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-
     
    Le Chaud Lapin, Feb 18, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rick Segal

    Asterisk Implementations in Toronto

    Rick Segal, Aug 5, 2003, in forum: VOIP
    Replies:
    2
    Views:
    1,018
  2. J
    Replies:
    0
    Views:
    423
  3. CCGolfer
    Replies:
    0
    Views:
    3,971
    CCGolfer
    Jun 8, 2004
  4. Piero
    Replies:
    5
    Views:
    727
    Piero
    Nov 18, 2004
  5. Replies:
    7
    Views:
    4,300
    Kimba W. Lion
    Jan 26, 2007
Loading...

Share This Page