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

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

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.

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). 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.

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