If there is no information flowing back, then not only is the
round-trip time without meaning, even the one-way time is unknowable
in the absence of synchronized clocks. And even with the
synchronized clocks, only the recipient can know it, since (by
definition of the problem) there is no back traffic to carry the
knowledge back to the sender.
I think the problem is either mis-stated or strange...
At 7:34 -0400 14/09/07, Marshall Eubanks wrote:
> > Hi all,
> >
>>
>>
>> I would like to know the ways to calculate RTT on a RTP receiver (client)
>> that does not send back packets to sender (Server) in RTP session. Since,
>> receiver does not send back any packets to the sender, the sender should not
>> include receiver report blocks in the SR RTCP packets and hence receiver
>> does not know the "delay on the sender since it received last RR" and can
>> not calculate RTT using the scheme mentioned in section "6.4.1 SR: Sender
>> Report RTCP Packet".
>>
>>
>>
>> How does a receiver that does not send back any packets back to the sender
>> calculate RTT? I will be obliged if some one could help me on the same.
>>
>>
>>
>> I would like to add one more point.
>>
>> RFC 3550 also mentions that NTP can be used to calculate RTT, but I think
>> it can be used to calculate only one side delay and multiplying it by 2 to
>> get RTT may not be a great idea as the delay may be different.
>>
>>
>
>I may be missing something, but it seems that you want to calculate
>the round trip delay without actually having any round trips. Isn't
>doubling the one way delay (which of course may be inaccurate) the
>best you can do in that case ?
>
--
David Singer
Apple/QuickTime
_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt