Re: [payload] Progressing draft-ramalho-payload-g7110-00

[Noboru Harada <[e-mail]>]

Dear Michael and all,


Thanks for taking care of the G.711.0 payload format issues.

According to the ISSUES 1 and 2, 
I'm fine with the proposal to have two separated documents.

For ISSUE 3, please see my comments below.

> >>>>ISSUE 3: Any comments on this goal?
> 
> Assuming the partitioning proposed above is accepted, the only
> significant open items for the G.711.0 payload format draft are:
> 
> OPEN ITEM 1 - Is the specification of multiple G.711.0 "channels" within
> a single G.711.0 RTP session desired? If so, is the proposed method
> acceptable (reserving a presently unused "prefix code" as a channel
> delimiter and changing the decoding heuristic in Section 4.2.3)?
>
> and
> 
> OPEN ITEM 2 - The specification of the storage mode for long recordings.

For OPEN ITEM 1, I'm not fully confident about that supporting multiple
G.711.0 channels is really useful.

As stated in the current draft, I'm not sure if there is any real
application need to have more than one G.711 channel per a RTP session.
I have never seen such multi-channel implementation in traditional G.711
systems.
For teleconference applications, there may be several alternatives such
as down-mix all channels into one channel at MCU server or mesh
connection using NxN RTP sessions.
Note that I'm fine with having the function if someone could show us
that there is strong need and show us reasonable application scenarios.

According to the proposed method, I don't think any channel delimiter
required for the channel separation if we make use of given "ptime" and
"channels" information.

With following definition, no channel delimiter is needed.
We can just decode all samples using the current decoding heuristic in
Section 4.2.3 and then separate decoded samples.
 ----------------------------------------------------------
| left channel (160 samples) | right channel (160 samples) |
| (G.711.0 frames +padding)  | (G.711.0 frames +padding)   |
 ----------------------------------------------------------

I believe that this number of channels issue should not be solved in
G.711.0 bitstream level but should be solved in RTP payload level.
Even though there are some RESERVED magic numbers available in the
G.711.0 specification, we should restrict us to introduce as little
magic numbers as possible for solving RTP payload issues.


> OPEN ITEM 2 - The specification of the storage mode for long recordings.

According to the storage mode, I had a discussion with some experts who
are developing some VoIP services.
They said that supporting 2-channel may be helpful for the storage mode.
There is a need to store recorded down-link and up-link data into one
file (e.g., recording conversation between a customer and an operator
for some call-center application).


Other comments on sections 7.1 and 7.2:

We may want to amend ITU-T Rec. G.711.0 reference software in order to
add a support of "0x01" defined in Section 7.1 G.711.0 Erasure Frame
because implementing it without changing the G.711.0 decoder is quite 
complicated.

---
The magic number for G.711.0 A-law corresponds to the ASCII character
string "#!G7110A\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x30 0x41 0x0A".
Likewise, the magic number for G.711.0 MU-law corresponds to the ASCII
character string "#!G7110M\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x4E
0x4D 0x0A".
---

I have no strong opinion but I think we'd better think of an advantage
of using any RESERVED magic number for the G.711.0 Storage Mode header
instead of "#".
Starting from "#" looks good but "#" is already used as a pre-fix in the
G.711.0 specification.
Which means the short recordings storage mode file will never be able to
be decoded by the ITU-T G.711.0 reference software.
If we assigned any RESERVED prefix such as "0x01" or "0x47" as the first
byte of the file, we could add the support to the ITU-T G.711.0
reference software (perhaps, as an informative appendix).
Note that only the difference between the short recordings storage mode
file and the file that the G.711.0 reference software generates is
existence of this header part.
On the other hand, this may not be a big issue because we can assign an
unique file extension for the file so that the application can recognize
it is the storage mode file.

What do you think of it?


Best Regards,

Noboru


> Dear AVTEXT and PAYLOAD list members,
> 
>  
> 
> At IETF 81 I presented the initial draft for G.711.0 payload format
> (draft-ramalho-payload-g7110-00). This email solicits opinions for
> continuing the work in this draft.
> 
>  
> 
> This draft had the usual detail expected in a payload format draft PLUS
> some recommendations and use cases for employing the (lossless and
> stateless) G.711.0 compression "in the middle" of an end-to-end G.711
> call/session.
> 
>  
> 
> The rough consensus I interpreted from presenting the G.711.0 draft was
> that this draft should be split into two drafts:
> 
>  
> 
> 1 - A "G.711.0 only" payload format draft (mostly the existing draft
> without Section 6).
> 
>  
> 
> and
> 
>  
> 
> 2 - A "G.711.0 use cases / best practices" draft describing use of
> G.711.0 in the middle of an end-to-end G.711 call (mostly Section 6).
> 
>  
> 
> >>>ISSUE 1: Any objection to this partitioning or other suggestion?
> 
>  
> 
> Furthermore, it has been suggested that the former be a AVT PAYLOAD
> draft (e.g. draft-ramalho-payload-g7110-01) and the latter be a AVT EXT
> draft (e.g., draft-ramalho-avtext-g7110usecases-00).
> 
>  
> 
> >>>>ISSUE 2: Any objection to partitioning the draft into two drafts
> targeted for two different IETF AVT WGs or other suggestion?
> 
>  
> 
> The idea (which I agree with) is that the payload draft be targeted to
> be an eventual standards track RFC and the avtext draft be targeted to
> be an informational RFC. This suggestion was only briefly mentioned at
> the meeting, but was supported in my discussions afterwards.
> 
>  
> 
> >>>>ISSUE 3: Any comments on this goal?
> 
>  
> 
> Assuming the partitioning proposed above is accepted, the only
> significant open items for the G.711.0 payload format draft are:
> 
>  
> 
> OPEN ITEM 1 - Is the specification of multiple G.711.0 "channels" within
> a single G.711.0 RTP session desired? If so, is the proposed method
> acceptable (reserving a presently unused "prefix code" as a channel
> delimiter and changing the decoding heuristic in Section 4.2.3)?
> 
>  
> 
> and
> 
>  
> 
> OPEN ITEM 2 - The specification of the storage mode for long recordings.
> 
>  
> 
> >>>>ISSUE 4: Any commentary on the above issues are welcome.
> 
>  
> 
> Thanks in advance for any comments or suggestions you have.
> 
>  
> 
> Michael Ramalho
> 
>  
> 
>  
> 
> Michael Ramalho
> Technical Leader
> Product Development
> [e-mail] <mailto:[e-mail]> 
> Phone: [phone]
> Mobile: [phone]
> 
> 
> 
> Cisco Systems, Inc.
> 4564 Tuscana Drive
> Sarasota, FL 34241-4201
> United States
> http://ramalho.webhop.info
> Skype: mramalho_mar42
> 
>  
> 
>  
> 
>  Think before you print.
> 
> 
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact
> the sender by reply email and delete all copies of this message.
> 
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> <http://www.cisco.com/web/about/doing_business/legal/cri/index.html> 
> 
>  
> 
>  
> 

--------------------------------------
Noboru Harada
NTT Communication Science Laboratories
Tel: [phone]
FAX: [phone]
E-mail: [e-mail]
--------------------------------------