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

["Adam Li" <[e-mail]>]

Rohit,

That looks alright with me.

Adam

> -----Original Message-----
> From: Kapoor, Rohit [mailto:[e-mail]]
> Sent: Tuesday, June 20, 2006 9:52 AM
> To: Adam Li; Qiaobing Xie
> Cc: Colin Perkins; AVT WG
> Subject: RE: Comments on draft-ietf-avt-compact-bundled-evrc-06.txt
> 
> 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