Hello everyone,
I am new to this forum although I have been following your good work all this time. Thanks for all the benefit you bring!
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.
#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?
#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.
#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?
#4 Any pointer on calculating absolute tarnsmission times (I am ok with aggregate of encoding + insertion + propagation times).
Thanks for your patience if you have read this far. Will be a genuine help for any answers/tips/suggestions.
Jonmejoy
