ccrtp-devel
[Top][All Lists]
Advanced

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

Re: [Ccrtp-devel] RTP for distributed simulations


From: Max Hofer
Subject: Re: [Ccrtp-devel] RTP for distributed simulations
Date: Thu, 22 Jul 2004 16:09:27 +0200
User-agent: KMail/1.6.2

On Thursday 22 July 2004 15:16, John Moren wrote:

> Normally, an RTP stack will automatically assign a timestamp value to each
> RTP packet, and you are responsible for writing data to the payload part of
> the packet. Each packet can be a different size if you want. So you should
> be able to use any RTP stack to meet your needs.
this means i would have to dynamically change the payload depending on the 
package i send on each package?

as far as i understood the payload is rather "static" (from the application 
point of view).

most packages are small (varies between 4 to 60 bytes). and i have no 
information how often a package will be send (the application is producing 
variable events depending on the user input).

how is a payload calulated for this kind of data?

> Your idea of putting the NTP value in the payload is probably the way to
> go. The timestamp in an RTP packet is typically just an increasing value
> that has no relation to the actual time of day.
my main problem is i do not understand the connection between 
payload/clockrate/RTP-timestamp/NTP (real time) for not periodic data.

i have to timestamp my data, send it over network (on a missig package if have 
to resend it again - missing packages are detected by a timeout on a receiver 
ACKN), and on the receiving side i have to control (filter) on basis of the 
source and the stamp.

the timestamp on the sender side should be done when the application sends the 
value (not after passing the sending queue in the RTP stack).

it seems the RTP package does not provide the means to put the NTP time value 
directly in the package but produces a RTP timestamp (based on a sample rate 
- and a random additional value). as long i can implement a time filtering 
(by means of the RTP timestamp + additional information about the source) i 
will do fine.

i rereaded the RTP RFC sections about payload/timestamp a couple times now but 
i do not understand the concept for data with no fixed samplerate (for audio 
and video i have a "fixed" sample rate --> which leads to a payload depending 
on the sample clock and package size).

my application does not have a sample rate, nor a fixed size. so there is no 
way to produce a RTP timestamp from a sample clock (or a payload).

my question are:
* on the receiver side: how can i retrieve the information when the package 
was send on the sender side?
* when is the RTP timestamped? i would like to timestamp it when the 
application writes the data and not when the data passed the RTP stack.
* how does my payload affect RTP timestamping?

> One nice thing about using RTP is Ethereal knows how to decode an RTP
> packet. This will help big time when you start sniffing packets.
that's one reason why i want use NTP and not stuff "house-made" information in 
an UDP package. :-)

-- 
Max Hofer
APUS Software G.m.b.H.
A-8074 Raaba, Bahnhofstra├če 1/1
T| +43 316 401629 11
F| +43 316 401629 9
W| www.apus.co.at
E| address@hidden




reply via email to

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