> Request some clarification around the RTP analysis "plug-in" that Miha
Jemec had published. I think the code measures delay in arrival between two
consecutive packets.
That's correct.
> #1 To measure arrival delay between two adjacent packets, we don't need to
exploit the RTP timestamp in the packet. I think it is the difference
between the ethereal sniff times for the packets (which I think is in
pcap_pkthdr members ts.tv_sec and ts.tv_usec). Is that a correct assumption?
Yes.
> #2 I think the RTP timestamps on the packets are a relative count on some
random offset over the wallclock time maintained at the sender end. This
wallclock time is published in NTP units periodically in RTCP SR packets.
Without knowing the wallclock value, is there a way for the receiver to
measure the time a packet takes to travel between the sender and the
receiver just by looking at RTP packets? I don't need to measure the delay
between two consecutive packets, but rather the absolute travel time for
eack packet.
I can't imagine a way to do this if only one direction is taken into
account.
You can do it of course if you *exchange* packets between 2 endpoints (forth
and back).
That's exactly the way RTCP does it.
> #3 This is a slightly RTP oriented question, but I couldn't help ask this:
We can expect RTP traffic with good payload only when there is voice
exchange. With the marker bit set (silence detection?) in one arbitrary
packet, will consecutive packets be dropped for transmission until the next
time voice exchange resumes? In that case, even while calculating the delay
between consecutive packets, perhaps we should construe that when silence
detection is in force, the excessive delay between two consecutive packets
should not be interpreted as delay but as non-arrival of packets? Does this
have an impact on the calculation of absolute transmission time of packets?
I think don't get every aspects of this question.
What i can say is that in the RTP analysis module, delays between silence-
and/or bit-marked packets are *not* taken into account for the maximum delay
calculation (and that's the way it should be, i think).
Silence periods should not be considered "dropped" packets since this is
purely a protocol implementation/optimization thing and not related to
network problems, like the term "dropped" would suggest.
> #4 Any pointer on calculating absolute tarnsmission times (I am ok with
aggregate of encoding + insertion + propagation times).
As i mentioned above, have a look at how RTCP does to calculate the
network-only *roundtrip* delay. That's the only viable method i think.
best regards,
Lars Ruoff
