ccrtp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ccrtp-devel] Confused about: Absolutely unreliable


From: Federico Montesino Pouzols
Subject: Re: [Ccrtp-devel] Confused about: Absolutely unreliable
Date: Sat, 12 Oct 2002 17:51:44 +0200
User-agent: Mutt/1.4i

        Hi,

On Thu, Oct 10, 2002 at 07:30:31PM +0200, Ernst Till wrote:
> Dear David
> 
> We?re students from a Swiss university making a Diploma-Work for the final 
> exam.
> Our work is based on making a isdn-to-sip-gateway, which can handle isdn 
> calls and map it to the right sip-user.
> For the rtp-stream we would like to use your ccrtp-lib. 
> We?re confused about your comment you?ve written in your rtphello-example:
> You wrote: Wait for an RTP packet. [Absolutely unreliable].
> We don?t understand why this should be unreliably, or how to make it better?

        The problem with that comment is that it is a bit outdated. In
earlier versions of the rtphello demo, a number was given to the
timestamp parameter of the method getPacket(). That number started
from 0 and were incremented in each loop iteration. That way, if some
packet were lost, rtphello would endlessly wait for it.

        Now, getFirstTimestamp() is used, so that problem has
disappeared and thus the loop is not unreliable. However, it is still
a not the best starting point for a real application. Using
getFirstTimestamp(), you will always get the earlier packet in the
reception queue, which may not be proper for real-time
apps. getFirstTimestamp() will work well only when there is no packet
misorder or you retrieve packets with a delay enough to give time to
reorder packets in the reception queue.

        It is very common (and surely the case for your application)
that the timestamp increment for every packet is fixed and known, in
which case it is better to specify the timestamp parameter of
getPacket() as a number which increases periodically. If the packet
corresponding to a timestamp is not available within a more or less
fixed period, the packet is ignored and the number is increased. With
ccRTP, once you ask for a timestamp, older packets are automatically
discarded and removed from the reception queue. These are packets
which have arrived too late.

> Could you please give us an example, or a hint to do our work the best?
> We?re glad to hear from you.
> Thank you for your time!
> 

        Beware that a new release of ccRTP is about to be available
and it will introduce a lot of changes.

> With best regards
> Ueli Gallizzi and Jeremi Ernst
> 
> Content Security by MailMarshal
> 
> 
> _______________________________________________
> Ccrtp-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/ccrtp-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]