Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT

["Michael Ramalho (mramalho)" <[e-mail]>]

Hadriel,

Thank you for asking your question.

Re: "Have any IPR disclosures been submitted to the IETF for this?"

For the G.711.0 IETF payload draft, no.

In the ITU-T there are four IPR disclosures for G.711.0 - one for each
of the collaborating companies.

However, Cisco had hoped for a disclosures to be filed at either the
IETF or the ITU-T by IETF 81 by all four collaborating companies
explicitly stating that G.711.0 for "consumer software terminals" (e.g.,
softclients) be royalty-free. We hope such a statement will be released
in the near future.

RE: "For one, just to be able to do this requires sniffing SDP "

Not true. Virtually every implementation using G.711 I have found in
practice uses the STATIC payload type of 0 or 8 for G.711.

Thus every RTP packet with PT = [ 0 | 8 ] can only have a G.711 payload
inside of it.

When G.711.0 is negotiated end to end, it will have its own media line.
The suggested "hint" in the G.711 SDP is not to "signal G.711.0", but
rather for middleboxes like NATs/Firewalls/etc. to "expect G.711" in
either uncompressed (real G.711 with PT = [0 | 8]) or compressed (with
PT = Q) form as equivalents.

Part of the reason for the "hint in the G.711 SDP" is because SBCs will
likely strip the G.711.0 m line from the SDP because it doesn't know
about G.711.0 and only let the m line for G.711 to pass ... it might
just let an unrecognized G.711 attribute through. I would like to get
opinions for the group and appreciate your question.

Re: SRTP

Yep, the raw G.711 needs to be in the clear for the compression to work.
Note that the PT is in the clear with SRTP (because the RTP header is in
the clear) ... and thus SRTP should be able to encrypt G.711.0 without
issues.

Re: "Cut out the "In the Middle" section".

That is a possibility. However I can say that we have explicit customer
requests that IF such a compression is likely to be used by "in the
middle entities" (i.e., service providers or administrative domains
within a service provider), that we provide guidance on how to
accomplish that compression so that everyone does it the same way.

I also agree that keeping it in the draft will cause heartburn relative
to its absence ;-). But I've got customers to please. And I have thick
skin ;-).

Re: "Middleboxes are a pain"

Yes they are; but the are also a fact of life. I have a longer talk in
which I enumerate the issues related to SBCs ... but that talk is
inappropriate for the IETF slot (at least that is what I have been
told).

Thanks again,

Michael Ramalho


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Hadriel Kaplan
Sent: Tuesday, July 26, 2011 10:12 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed
inAVTEXT

[sorry for cross-posting, but this draft is going to be presented in
avtext]

Hi,
I read this draft and I have a couple comments, as follows:

1) Have any IPR disclosures been submitted to the IETF for this?  I ask
because I believe there are several submitted to ITU for this codec.

2) The stuff in section 6 on "In the Middle" is really controversial,
and arguably a very bad idea.  

For one, just to be able to do this requires sniffing SDP which is only
possible if it's in cleartext, and if the sniffer can reassemble
fragments or stream segments, and if the sniffer is guaranteed to be in
the path for all SDP exchanges between the parties for ever.  And to be
able to really do it you have to *modify* the SDP which is a whole
different ballgame.  

And then there's the way in which the draft describes doing it, by
inserting an fmtp attribute line of the new payload type, which is wrong
in my opinion - it should either replace the payload type in the m-line
and add the original 711a/u-law info as a new attribute, or better yet
add the new payload type as another option in the m-line and wait for an
SDP answer to choose (for protocols that have an offer/answer model).
Otherwise the middlebox has to know another middlebox is in the call
path a priori.

And then there's the problem of SRTP: if SRTP prevents the middlebox
from doing the compression, the middlebox needs to know when SRTP is
going to be used by inspecting SDP, which isn't as straightforward as
looking for "SAVP" in the m-line... e.g. the endpoints could be using
RFC 5939.  

In summary: I would remove this idea/section from the draft.  Publishing
a draft defining the payload format and media type for G.711.0 is fairly
straight-forward and non-controversial (I think), but going beyond that
to "support" this man-in-the-middle thing is going to cause you
heartburn and delay getting the basic stuff published as an RFC.
Just my 2 cents.

-hadriel


On Jul 25, 2011, at 12:55 PM, Michael Ramalho wrote:

> This draft is a payload WG draft, but there isn't a payload meeting at
IETF 81. And this draft was previously scheduled to be discussed  the
AVT core timeslot prior to its being moved to AVTEXT (thus the reason
for the cross post to all AVT groups). Roni and Ali encouraged me to say
a few words prior to the discussion this week.
> 
> G.711.0 is a stateless and lossless compression of G.711 VoIP RTP
payloads. Thus it is a compression algorithm tailored for G.711. When
negotiated end-to-end it is negotiated "as if it were a codec".
> 
> However, being lossless and stateless, G.711.0 can be applied anywhere
within an end-to-end G.711 negotiated session. When applied in this
manner, it suffers no voice quality degradation relative to G.711 (duh,
its lossless).
> 
> Most of the open issues in the draft relate to the use of G.711.0
within the context of an and-to-end G.711 negotiated session.
> 
> I look forward to comments generated from the discussion of this draft
for those cases.
> 

_______________________________________________
payload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/payload