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

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

Hadriel,

In-line below.

Michael

-----Original Message-----
From: Hadriel Kaplan [mailto:[e-mail]] 
Sent: Wednesday, July 27, 2011 9:57 AM
To: Michael Ramalho (mramalho)
Cc: Kevin P. Fleming; [e-mail]
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be
discussedinAVTEXT


On Jul 26, 2011, at 6:43 PM, Michael Ramalho (mramalho) wrote:

> While a transcode from G.711 to G.729 "saves bandwidth" ... it also
> DEGRADES VOICE QUALITY.

It doesn't matter whether a particular codec or payload transform is
lossless or not, from the perspective of SDP and RTP.  SRTP
encrypt/decrypt and authentication is also completely "lossless".  You
could, in theory, do SRTP between two middleboxes.

MAR: Not even in theory .. but also in practice!

MAR: SRTP was designed (as I understand it) from day one to encrypt
between "session endpoints".

MAR: Insofar as the UAs facing each other in two consenting SBCs are SIP
dialog endpoints (i.e., "in the middle" of a longer end-to-end "call")
... they can do SRTP between them!

MAR: I guess I don't get the "in theory" part.

All you'd need is a way to exchange keys between the two middleboxes,
just like for G.711.0 you need a way to exchange payload types and
companding.

MAR: The companding for the "G.711.0 compression segment" (as defined in
the draft) is assumed to be the companding used in the true user
endpoints ... which can be determined from the incoming PT (0 or 8).

MAR: The communication/negotiation/exchange between the "G.711.0 tunnel
endpoints" is purposely unspecified in the draft. Indeed, how the
G.711.0 compression/decompression endpoints "find themselves" is also
purposely unspecified in the draft.

MAR: In the absence of middleboxes and NAT/PAT and in certain topologies
... there are a variety of simple "in-media" methods by which
compression/decompression endpoints can find themselves. There are many
"gotchas" for those use cases ... but again ... these cases are
purposely unspecified in the draft. Unfortunately, I was not allotted
enough time to go through those cases in the avtext meeting today.

MAR: My comment about various forms of header compression was to point
out, via example, that SBCs do not always know what is going on "within"
the flows that traverse them (I could put a friendly comment that SBCs
being "control freaks" ... but I'll refrain ;-) ).

Obviously SBCs and other middleboxes can and do SRTP
termination/origination, but we would never have done it the way this
draft is describing to do G.711.0.  I must be missing something about
your use-case that makes it different.

MAR: I wouldn't use per-flow encryption in your example either ... but
that is a different story.

> Do we signal to the endpoints that RTP header compression occurred
> somewhere on the end-to-end path? I don't think so.
> 

ROHC for RTP only works in extremely constrained deployment scenarios,
and as far as I'm aware can only be done either by the devices
generating the RTP so they know what IP/UDP combo stream is RTP
before-hand, or by channelization/separation and signaling for a
context.  And as far as I know it has signaling in ROHC itself - it's
not just blindly starting to compress without knowing the far-end is
capable of decompressing and what modes. 

-hadriel