RE RE: [AVT] RTP - RTT

["Vikal Kumar Jain" <vikalkj at slingmedia.com>]

I would like to use round trips but that is not possible in the scenario
I mentioned below for the receiver (client). 

I may be able to do so by extending the RTCP headers in the scenario I
mentioned below; I can't do that using the standard headers since there
is no RTP data sent back from receiver to sender like in case of a video
conferencing system.  

I am more interested in having a solution that exist and does not
require me to extend any of the standard headers. 

Moreover, there may be no notion of a wall clock on many systems and I
am not very sure of the complexities involved in using a NTP server to
get NTP timestamps.
 
Regards,
Vikal.



-----Original Message-----
From: Marshall Eubanks [mailto:marshall.eubanks at gmail.com] 
Sent: Friday, September 14, 2007 5:05 PM
To: Vikal Kumar Jain
Cc: avt at ietf.org
Subject: Re: [AVT] RTP - RTT

Hello;

On 9/14/07, Vikal Kumar Jain <vikalkj at slingmedia.com> 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 ?

Regards
Marshall

>
> Regards,
>
> Vikal.
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>
>

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt