Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-vmr-wb-03.txt

From: [email-masked]
Date: Tue, 07 Sep 2004 12:14:51 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: Real-Time Transport Protocol (RTP) Payload and File Storage 
			  Formats for the Variable-Rate Multimode Wideband (VMR-WB) 
			  Audio Codec
	Author(s)	: S. Ahmadi
	Filename	: draft-ietf-avt-rtp-vmr-wb-03.txt
	Pages		: 33
	Date		: 2004-9-3
	
This document specifies a real-time transport protocol (RTP)
   payload format to be used for the Variable-Rate Multimode
   Wideband (VMR-WB) speech codec. The payload format is
   designed to be able to interoperate with existing VMR-WB
   transport formats on non-IP networks. In addition, a file
   format is specified for transport of VMR-WB speech data in
   storage mode applications such as email. A MIME type
   registration is included, for VMR-WB, specifying use of
   both the RTP payload and the storage formats

   VMR-WB is a variable-rate multimode wideband speech codec
   that has a number of operating modes, one of which is 
   interoperable with AMR-WB (i.e., RFC 3267) audio codec at
   certain rates. Therefore, provisions have been made in
   this draft to facilitate and simplify data packet exchange
   between VMR-WB and AMR-WB in the interoperable mode with no
   transcoding function involved.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vmr-wb-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-vmr-wb-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtp-vmr-wb-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Sep 2004 11:57:30 +0100

Sassan,

A couple of comments on the changes:

  - In section 3.1, it used to say "during a session, transition between
    narrowband and wideband processing is not RECOMMENDED due to 
different
    timestamps and other likely buffering and synchronization problems".
    This has changed to say "...is not advised due to different RTP
    timestamps...". I don't think this change is appropriate; instead it
    should be "...is NOT RECOMMENDED due to different...".

  - In section 7 it says:

      Note: The storage format described in this document uses several
      magic numbers to differentiate between interoperable and
      non-interoperable modes of VMR-WB as well as single and
      multi-channel files. This may be accomplished in other ways that 
are
      simpler and more straightforward that one should consider in design
      of future storage formats.

    This is reasonable, but should also explain why this format doesn't 
use
    the simpler and more straightforward alternatives.

Colin