Subject: [AVT] New AMR draft available

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 Jan 2002 10:10:25 +0100

Hi,

The updating of the AMR RTP payload format draft has now produced some
results. A new draft has been submitted to the IETF draft repository,
until it is available there you can get it at the following location:

"http://standards.ericsson.net/westerlund/draft-ietf-avt-rtp-amr-11.txt"

So please start reviewing immediately as we are trying to meet a
deadline. There are only a single technical change in this version
compared to version 10, and that is multi-channel support. This has been
added without changing a single bit when using a single channel. There
is major editorial changes, like restructuring, and added text,
explaining things better.

Happy reading

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Faerber Tobias ICM MP PO8 RD MCH83 <[email-masked]>
Date: Wed, 30 Jan 2002 14:52:45 +0100

hi all,
please include like in draft10 (2.7) an own little section describing which
part is to be considered mandatory and which is optional ? i know there is
written something in 4.2 but to make it easier for implementers all features
and the their implementation considerations should be given globally.

is multichannel support optional ? I guess yes....

about fomatting: to my opinion it would be nice to include the hint for bit
sorting into classes that the tables of Annex B in TS26.101 should be used

best,
Tobi

----------------------------------------------------------------------------
-------
> Faerber Tobias		Siemens AG
ICM MP PO8 RD MCH83 	Information and Communication Mobile

> Tel:	+49 89 722 58578	Grillparzerstrasse 10 a
> mobile:  +49 175 5721351	81675 Munich, Germany
> Fax:	+49 89 722 59070	
mailto:[email-masked]
----------------------------------------------------------------------------
-------

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Mittwoch, 30. Januar 2002 10:10
> To: IETF AVT WG
> Subject: [AVT] New AMR draft available
> 
> 
> Hi,
> 

Happy reading

Magnus Westerlund

---

From: [email-masked]
Date: Thu, 31 Jan 2002 10:46:59 +0200

hello Tobias,

> and the their implementation considerations should be given globally.

As you mention, section 4.2 says that robust sorting, interleaving and frame CRCs are optional. But it really could be a good idea to edit the wording a bit to state this more clearly.

> is multichannel support optional ? I guess yes....

Support for multichannel operation is optional, the number of channels can be explicitly specified in session setup and can therefore be forced to be one.
I hope this is indicated clearly enough by following quotations from the draft.

Excerpt from section 3.5 Support for Multi-Channel Session:
"
   At the session setup, out-of-band signalling, e.g., using the
   rtpmap attribute in SDP, must be used to indicate the number of
   channels in the session and the order of the speech frames from
   different channels in each frame-block.
"

Furthermore, in section 8.3. Mapping MIME Parameters into SDP the drafts says:
"
    - The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
      the encoding name.  The RTP clock rate in "a=rtpmap" MUST be
      8000 for AMR and 16000 for AMR-WB, and the encoding parameters
      (number of channels) MUST either be explicitly set to N or
      omitted, implying a default value of 1. The values of N that are
      allowed is specified in Section 4.1 in [24].
"

> sorting into classes that the tables of Annex B in TS26.101 

I think the bit-sorting issue is taken care of by the references to 3GPP specifications (from section 4.3.3. Speech Data):
"
   ... The order and numbering notation of the
   bits are as specified for Interface Format 1 (IF1) in [2] for AMR
   and [4] for AMR-WB. As specified there, the bits of speech frames
   have been rearranged in order of decreasing sensitivity, while the
   bits of comfort noise frames are in the order produced by the
   encoder. The resulting bit sequence for a frame of length K bits
   is denoted d(0), d(1), ..., d(K-1).
"
where [2] and [4] are references to 3GPP frame format documents for AMR and AMR-WB, respectively. These documents specify the bit ordering for both codecs.
Do you think this is not clear enough definition?

> Tobi

br,
Ari

---

From: Faerber Tobias ICM MP PO8 RD MCH83 <[email-masked]>
Date: Thu, 31 Jan 2002 14:48:14 +0100

hi,
everythiong which is to be known you can find in the text but if you start
out implementing it is the easiest to have an own section containing a
mandatory and optional hint. currently we and some other companies are doing
interop testing at IMTC and it shows that such a clear statement makes work
much easier instead of having to search through the reffering passeges in
the text.
just two lines or like that:

X.x Implementation rules

mandatory features: bw eff. mode, octet alignment
optional features : robust sorting,CRC,interleavin, multichannel support

about sorting:
of course it is clear. just wanted to point it out more directly. 

best regards,
Tobi

> From: [email-masked] [mailto:[email-masked]]
> Sent: Donnerstag, 31. Januar 2002 09:47
> To: Faerber Tobias ICM MP PO8 RD MCH83;
> [email-masked]; [email-masked]
> Subject: RE: [AVT] New AMR draft available
> 
> 
> hello Tobias,
> 
> > 
> > hi all,
> As you mention, section 4.2 says that robust sorting, 
> interleaving and frame CRCs are optional. But it really could 
> be a good idea to edit the wording a bit to state this more clearly.
> 
> Support for multichannel operation is optional, the number of 
> channels can be explicitly specified in session setup and can 
> therefore be forced to be one.
> I think the bit-sorting issue is taken care of by the 
> references to 3GPP specifications (from section 4.3.3. Speech Data):
> "
> where [2] and [4] are references to 3GPP frame format 
> documents for AMR and AMR-WB, respectively. These documents 
> specify the bit ordering for both codecs.