Re: [AVTCORE] Possible Additional functionalities fordraft-brandenburg-avt-rtcp-for-idms

[Kevin Gross <[e-mail]>]

I do not consider the loading with null or dummy data "unnecessary". You
will often get different measurements on an unloaded network. Your proposal
will potentially give us a quick assessment of parameters but since the
measurement conditions are different (unloaded) from operating conditions
(loaded), the accuracy may not be as good as in the method I have proposed.

I do however appreciate that parameters may change a great deal over the
duration of a session so the importance of accuracy of these measurements
should be given due consideration in this discussion. The reason for my
proposal is primarily for simplicity - we use the same protocol mechanisms
for startup as we do for the running case.

Kevin

2011/10/21 Fernando Boronat Seguí <[e-mail]>

>  Qin,
>
> I understand that the Packet Receipt Times Report Block defined in the
> section 4.3 of RFC3611 is to provide feedback of the reception time of data
> RTP packets. It could be used in the solution proposed by Kevin (sending
> null data packets).
>
> Our aim is to calculate the one-way delay with the lower overhead possible.
> If we adopt the Kevin's proposal we understand that sending RTP packets at
> the same data rate than during the session will suppose an unnecessary extra
> load prior the starting of the session that can be avoided with our
> solution. Notice that prior the session start is when all the users join the
> session with the corresponding control packets implosion.
>
> We only need a reference of the maximum one-way delay between source and
> SCs, not the exact value, as the initial playout instant will be larger than
> that value (allowing receivers to have received enough media units to
> guarantee a continuous playout avoiding underflow/overflow situations). The
> calculation of this is out of the scope of the I-D.
>
>