[AVT] RE: Comments on draft-ietf-avt-compact-bundled-evrc-06.txt

["Kapoor, Rohit" <[e-mail]>]

Adam,

Please see some of my answers below.

> -----Original Message-----
> From: Adam Li [mailto:[e-mail]]
> Sent: Tuesday, June 20, 2006 8:20 AM
> To: Kapoor, Rohit; 'Qiaobing Xie'
> Cc: 'Colin Perkins'; 'AVT WG'
> Subject: RE: Comments on draft-ietf-avt-compact-bundled-evrc-06.txt
> 
> Rohit,
> 
> Personally I would like a little more detailed explanation for the
clarity
> for the reader. Section 1.3 is the only place talks about DTX, and it
> makes
> it not so easy to connect the parameters (dtxmax, dtxmin, and
hangover) to
> the brief description in Section 1.3. Maybe we can move some
descriptions
> of
> those parameters to 1.3 to make the DTX process easier to understand
from
> reader's perspective. This is up to you.

<Rohit> Good suggestion. At the end of this last call, we can make a
small editorial change to move some descriptions of the parameters to
1.3.

> 
> A little more detail for the other issue I mentioned in original
comments:
> In the asynchronous stream, a default dtxmax of 32 may imply a
necessary
> buffer of 0.64 seconds. That's more than 1.2 seconds round trip. I
would
> suggest maybe you can define a default dtxmax different from the 3GPP2
> default (which I believe is set with synchronous operation is mind,
based
> on
> changing of the silence characteristics).

<Rohit> Since 3GPP2 will be the primary user of this RFC, we'd like to
leave the default value to the 3GPP2 value. But we will add a sentence,
as you suggested below, to inform the reader of the impact of dtxmax
(more below).


> And I think definitely it would
> be
> helpful to point out the impact of dtxmax on the detection delay,
which
> some
> text such as "Note that the dtxmax parameter will affect the amount of
> delay
> the RTP receivers have to have for detecting DTX in the stream" in
> corresponding places in Section 6.
> 

<Rohit> We propose to add the following sentence (a small change to your
proposed sentence): "Note that if the RTP receiver elects to detect DTX
using dtxmax, the dtxmax parameter will affect the amount of delay the
RTP receiver sees before detecting DTX in the stream".

Please let us know if this would sufficiently address your concerns.

Thanks,
Rohit


> Hope it helps.
> 
> Adam
> 
> 
> > -----Original Message-----
> > From: Kapoor, Rohit [mailto:[e-mail]]
> > Sent: Monday, June 19, 2006 4:32 PM
> > To: Adam Li; Qiaobing Xie
> > Cc: Colin Perkins; AVT WG
> > Subject: RE: Comments on draft-ietf-avt-compact-bundled-evrc-06.txt
> >
> > Adam,
> >
> > In order to address your concern, we propose to add the following
text
> > for detection of DTX, at the end of Section 1.3.
> >
> > "An RTP receiver can detect that it is in a DTX period using
information
> > from RTP sequence number and timestamp, since RTP sequence number
> > increments for each transmitted packet, whereas RTP timestamp
increments
> > regardless of whether frame is transmitted or dropped due to DTX
[RFC
> > 3550]".
> >
> > Please let us know if this addresses your concern.
> >
> > Thanks,
> > Rohit
> >
> > > -----Original Message-----
> > > From: Adam Li [mailto:[e-mail]]
> > > Sent: Monday, June 19, 2006 1:35 PM
> > > To: 'Qiaobing Xie'
> > > Cc: Kapoor, Rohit; 'Colin Perkins'; 'AVT WG'
> > > Subject: RE: Comments on
draft-ietf-avt-compact-bundled-evrc-06.txt
> > >
> > > Hi Qiaobing,
> > >
> > > I understand that DTX is backward compatible with EVRC decoders
not
> > > implementing it (Note here you talked about EVRC decoders).
> > >
> > > However, we are here talking about RTP sender/receivers of EVRC
> > stream. If
> > > you want to add DTX features in the RTP payload protocol, it is
> > natural
> > > that
> > > you will need to define how DTX is used and detected in the RTP
> > > sender/receivers.
> > >
> > > It makes little sense to have DTX in RTP but do not say anything
about
> > how
> > > it is used in the RTP sender and how it detected in the RTP
receiver,
> > just
> > > because the EVRC decoder after the RTP receiver can always decode
it
> > even
> > > without knowing DTX.
> > >
> > > In my opinion: if we define a feature in the protocol, specify how
it
> > is
> > > used and maybe discuss the impact of its usage. Arguing that the
> > decoder
> > > will work without using the feature is irrelevant.
> > >
> > > Adam
> > >
> > > > -----Original Message-----
> > > > From: Qiaobing Xie [mailto:[e-mail]]
> > > > Sent: Monday, June 19, 2006 11:43 AM
> > > > To: Adam Li
> > > > Cc: 'Kapoor, Rohit'; 'Colin Perkins'; 'AVT WG'
> > > > Subject: Re: Comments on
draft-ietf-avt-compact-bundled-evrc-06.txt
> > > >
> > > > Hi, Adam,
> > > >
> > > > ...
> > > > >>>(1) It would be helpful to discuss how the receiver detects
DTX
> > > during
> > > > a
> > > > >>>session (by detecting the gap in the stream by matching RTP
> > header
> > > > >>>timestamp intervals with payload duration?)
> > > > >>
> > > > >><Rohit> The receiver may not need to use RTP timestamp to
detect
> > that
> > > it
> > > > >>is in a DTX period. Some implementation could decide to
generate
> > > comfort
> > > > >>noise if it sees some missing packets (either due to DTX or
lost
> > data).
> > > > >>This is largely an implementation choice.
> > > > >
> > > > > How does one detect missing packets without looking at the SN
of
> > the
> > > > next
> > > > > received RTP packet? Also, is there a way to detect
discontinuity
> > in
> > > an
> > > > > asynchronous stream by other methods than looking at the time
> > stamps?
> > > > Maybe
> > > > > you can clarify in the draft on how those are achieved in RTP
> > instead
> > > of
> > > > the
> > > > > synchronous environment in the wireless networks.
> > > >
> > > > Detecting discontinuity in a RTP stream using timestamp is a
common
> > > > operation of any RTP endpoint and there is absolutely no
intention
> > to
> > > > change that here. I think what Rohit meant to say was that the
RTP
> > > > receiver in this case does not have to know whether it is in a
DTX.
> > > >
> > > > >
> > > > > "How to detect DTX" is a protocol issue when the specification
> > > supports
> > > > DTX.
> > > > > "What to do after it is detected" is an implement issue.
> > > >
> > > > The DTX algorithm was worked out in 3GPP2 TSG-C and for backward
> > > > compatibility reasons it was deliberately made so that the
receiver
> > does
> > > > not need to know whether DTX is in force. In other words, it is
NOT
> > a
> > > > requirement by the design of the DTX algorithm for the receiver
to
> > > > detect DTX. (Of cause, a given implementation is free to build
DTX
> > > > detection in its receiver if it feels that's something good to
do).
> > > >
> > > > regards,
> > > > -Qiaobing
> > > >
> > > > >
> > > > > Adam
> > > > >
> > > > >
> > > > >
> > >
> >
> 


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt