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

["Roni Even" <[e-mail]>]

Hi Victor,

 

We can discuss the MELP at the Payload session in Prague, will you be there?

As for the comments see inline ( the response on the comments are as an
individual and not as the WG chair)

Roni

 

From: Victor Demjanenko, Ph.D. [mailto:[e-mail]] 
Sent: 22 June, 2015 3:40 PM
To: 'Roni Even'; [e-mail]; 'Ali C. Begen (abegen)'
Cc: 'Victor Demjanenko, Ph.D.'; [e-mail]
Subject: RE: [payload] comments on draft-demjanenko-payload-melpe-02

 

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?

[Roni Even] Yes

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?

[Roni Even] Please explain where you define the rate parameter

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.

 

[Roni Even] My reading is that the offer includes the send capabilities
while the answer is the receive capabilities. So it means that the result
MUST be symmetrical, you can provide better options if you use the send and
recv attributes.

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.

[Roni Even] If an offer is with MELP1200 can the answer use MELP rate =1200
or is it mandatory to use the same subtype name?

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