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

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

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