Re: [payload] comments on draft-demjanenko-payload-melpe-02

["Victor Demjanenko, Ph.D." <[e-mail]>]

Roni, Ali,

 

I would like to have our MELP RTP payload discussed and advanced toward an
RFC at IETF-93 in July.  We have updated our draft as per appendix of
https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13.  I believe I
might not have addressed all of the below comments before so I will now.

 

I appreciate all the help and suggestions offered.  Please let me know what
else needs to be addressed.  Thanks.

 

Victor

 

From: payload [mailto:[e-mail]] On Behalf Of Roni Even
Sent: Wednesday, March 25, 2015 12:24 AM
To: [e-mail]
Subject: [payload] comments on draft-demjanenko-payload-melpe-02

 

Hi,

I looked at the document and have some comments

1.      The term MIME type is not used for RTP payload but we call it media
subtype name , the media type is audio in your case

v-> Looking at the 03 draft, I can find one place, near the end of section
4.2.  Are you suggesting this should be "media subtype name" instead?  Are
there other places where this needs to be changed?

2.      The term rate should probably be used for the clock rate and for
what you call "rate" maybe use "bitrate"

v-> Changed in the upcoming 04 draft to use "bitrate"

3.      I am not sure what is the meaning of rate=600,1200,2400 in the
offer, is that the sender capability to switch dynamically between these
three rates?

v-> Yes the sender may switch dynamically.  This is referred to as dynamic
rate switching.  Do you think I need to explain this more?  Where?

4.      Are both sides need to use the same rate option (symmetric)?

v-> No the section on SDP explains the negotiation and priority given to the
answerer's preferred bit rate.

5.      What is the meaning of an answer rate=600,1200 to the above offer?
Does it mean that both sides can switch only between 600 and 1200.

v-> Yes exactly.

6.      We prefer not to have the rate in the media subtype name so use only
MELP and MELPE and for fixed rate use the rate parameter.

v-> Unfortunately there are legacy deployed systems that use the MELP2400,
MELP1200 and MELP600 names.  Otherwise I would be in complete agreement on
your preference.

7.      An RTP payload document must also have a congestion control section.
You can look at https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-13
about how to write an RTP payload specification and also look at one of the
latest RTP audio payloads like opus
(https://tools.ietf.org/html/draft-ietf-payload-rtp-opus-08) for an example
about the structure of an audio RTP payload and how to have the congestion
control, security, IANA and SDP consideration sections

v-> This was done in the preparation of the 03 draft.  Hopefully I did not
miss anything important.  I know I did not split the suggested Background
section contents from the Payload Format section.  By this I mean I kept the
original identification of the MELP parameters immediately ahead of each
bit-rate payload format.  This seemed to be a more natural organization of
the material with less jumping between sections.

 

Thanks

Roni Even as individual