[Top][All Lists]
[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