RE: [MMUSIC] Thinking about best-effort encryption

["Hadriel Kaplan" <HKaplan@xxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@xxxxxxxxx]
> Sent: Monday, November 06, 2006 7:45 PM
> 
> Hadriel Kaplan wrote:
> 
> >Just a note that in the end we chose to have the answer use the same m=
> line
> >transport as the offer, even if SRTP is chosen, specifically because
> >everyone thought it was illegal otherwise.
> >
> There doesn't seem to be any text anywhere outlawing such behavior.

Indeed, that was our argument back to everyone else!  
But in the end we decided it was better to avoid having the same debate with
everyone and not do it to begin with.


> However, I'm not as concerned about syntax as semantics.
> 
> > Oh, and it will help get through
> >middle-boxes that look at SDP and expect the offer/answer to match.  ;)
> >
> >
> True, however it will be problematic if such middle-boxes actually use
> the information for anything, e.g. authorize QoS (ande not knowing there
> will be an additional MAC overhead), a firewall or other deep packet
> inspection engine actually looking at the resulting media stream etc. 

Au contraire.  Having the term "SAVP" no more helps a middle-box determine
bandwidth/packet-size than "AVP".  Whether the authentication tag is in the
RTP or not, and its length, depends on the transform used; and whether the
MKI is present or not, and its length, depends on the signaling.  There are
other packet size modifying things going on in AVT that will not be new m=
line transports, but rather attributes, as well.

A middle-box would either have to understand those, or the UA would have to
signal the bandwidth explicitly, or the middle-box would have to always give
"slack".


> In
> the absence of an additonal O/A exchange with the actual negotiated
> media stream parameters (which I'm not advocating as a requirement,
> albeit it may be helpful as an optional procedure), this of course may
> be an issue for either alternative. I still think it's important that
> the signaling messages exchanged clearly indicate what is going on, and
> my preference would be to have the m= lines reflect as closely as
> possible what the state of affairs actually is, but we are getting into
> a detailed design question where each alternative has pros and cons.

But I thought you weren't as concerned about syntax as semantics.  If so,
then whether the syntax would be "m=...." or "a=...." shouldn't concern you.
;)

-hadriel