Subject: Re: [payload] draft-demjanenko-payload-melpe

From: "Victor Demjanenko, Ph.D." <[email-masked]>
Date: Wed, 22 Oct 2014 09:07:11 -0400

Everyone,

We have updated our proposed RTP payload/SDP exchanges for MELPe based on
reviewer comments (thanks Ian and others) and SIP/SDP packet captures from
another SIP/MELPe implementation.  We would like to obtain support for
advancing this draft to an RFC as several such SIP/MELPe systems will be
interoperating shortly.

Comments are always welcome.

Regards,

Victor Demjanenko

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Ian Coolidge
Sent: Thursday, June 19, 2014 12:26 AM
To: [email-masked]
Cc: [email-masked]
Subject: [payload] draft-demjanenko-payload-melpe

Hello IETF Payload,

My name's Ian Coolidge, and I work at TrellisWare Technologies.
We are interested in interoperability of many codecs with RTP.
We'd like to endorse this effort to standardize a source format for MELPe
RTP payloading.

Victor,

I have the following comments on draft 0 of the document:

1) Considering the variety of systems that this packetization may occur on,
it seems prudent to refer to the raw data as contained in octets,
considering there are specific descriptions of bit offset quantities.
Using RFC 4867 as reference, this is generally done except where describing
endianness specification, as in network byte ordering.

2) The core of this document is trying to say that metadata about the raw
MELPe frames can be found within the unused bits of the raw data, described
as 'coder rate bits.'
It seems like a passage in the introduction reflecting that might be useful,
or at least in section 3.1.

3) In section 3.1, there is text, "Unused bits are coded as zeros." After
adhering to the specification of this document, however, this should not be
the case necessarily.
It may be useful to clear up that distinction.

4) Is a contiguous sequence of MELPe frames ever to be handled? If I
understand correctly, there could be some ambiguity about how an RTP
payloader should interpret that data. Consider the case of 77 octets in a
single buffer arriving to an RTP payloader. (77 is chosen because it is the
LCM of 7 and 11, the size in octets of 2400bps/600bps and 1200 bps data,
respectively) In this case, since both 7 and 11 divide 77 evenly, the length
of the buffer alone cannot be used to infer which bits to use for
interpreting the 'coder rate bits', since these are different between the
two size-classes of MELPe frames.

Thanks,
Ian
_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload