From: sassan.ahmadi@nokia.com
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:  sampling rate
Date: Thu, 9 Sep 2004 14:21:08 -0700
Message-ID: <0B08EA1BF5F6304992CDC985EE02209E02342B61@sdebe002.americas.nokia.com>
Thread-Topic: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:  sampling rate
Thread-Index: AcSWQ+issUiv/oQ3RduK8D5EG7GY+gAZlXOA
To: <Qiaobing.Xie@motorola.com>, <magnus.westerlund@ericsson.com>
Content-Transfer-Encoding: quoted-printable
Cc: csp@csperkins.org, avt@ietf.org
Precedence: list
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Hi Qiaobing,

I think you are confusing people by frequently referring to the internal =
sampling frequency of VMR-WB. As I said in my previous reply, AMR-WB has =
the same internal frequency and NO where in RFC 3267 it is mentioned or =
referred.

The fact that VMR-WB is capable of processing narrowband (8 kHz) or =
wideband (16 kHz) media does not have anything to do with its internal =
sampling frequency.=20

This confusion is caused by lack of knowledge about VMR-WB and its =
operation.

Please see my reply to Magnus on the same topic as it may clear this =
issue.

Regards

-Sassan Ahmadi


> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On=20
> Behalf Of ext
> Qiaobing Xie
> Sent: Thursday, September 09, 2004 12:55 AM
> To: Magnus Westerlund
> Cc: csp@csperkins.org; avt@ietf.org; Ahmadi Sassan (Nokia-TP/SanDiego)
> Subject: Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>:=20
> sampling rate
>=20
>=20
> Hello, Magnus,
>=20
> Magnus Westerlund wrote:
>=20
> > Hi Sassan,
> >=20
> > Based on what you write in the previous mail. It seems that=20
> the only=20
> > reason for using different RTP timestamp rate between 8000=20
> and 16000 Hz=20
> > is to indicate the sampling rate of the source material. If=20
> the codec=20
> > does not need any indication at all if the source material=20
> is 8k or 16k=20
> > then, I think the usage of different RTP timestamp rates is=20
> creating=20
> > unnecessary interoperability barriers. The barrier is that=20
> one actually=20
> > needs to indicate the rate of the source material, and cope=20
> with RTP=20
> > timestamp switching.
>=20
> Right on! You nailed the issue perfectly.
>=20
> >=20
> > To avoid the unnecessary function I would propose that VMR-WB only=20
> > defines 16kHz as RTP timestamp rate.=20
>=20
> Agreed. This would effectively remove the interoperability=20
> barrier you pointed out above.
>=20
> My only concern is that this may create some interesting=20
> situations. Let's consider an=20
> example - original speech of 8k rate is passed to vmr-wb=20
> encoder and the decoder is set to=20
> output speech at 8k rate.
>=20
> Here, we would then have:
>=20
>   - source sampling rate =3D 8k
>   - actually sampling rate of the bit stream sent over RTP =3D 12.8k
>   - sampling rate output from vmr-wb =3D 8k
>   - RTP header timestamp rate =3D 16k!!!
>=20
> I am not sure this will cause any problem, but it seems strange.
>=20
>  > If there is desire to have
> > knowledge about source sampling rate that will be used,=20
> then one should=20
> > define a parameter that indicates that. But I am not=20
> certain it really=20
> > is needed. Such a parameter is declarative and does not matter in=20
> > regards to any interoperability and can be ignored without=20
> consequence.=20
>=20
> I, too, would like to first see some use case here. If we=20
> don't know how the information is=20
> going to be used, it makes no sense to specify a mechanism in=20
> RTP or even SDP to pass it around.
>=20
> regards,
> -Qiaobing
>=20
=20

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt