[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] Thinking about best-effort encryption




Hadriel Kaplan wrote:


-----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.
Conversely you could argue that there wouldn't be any reason to look for attributes telling you about such things if the "m=" line doesn't say you'll actually use an RTP profile where any of that matters. Still, you could make it work either way, but I think this is a prime argument for why we need to have explicit signaling indication as to exactly what semantics we are trying to convey. Trying to infer it based on presence or absence of one or more existing attributes with no such semantics defined is not a recipe for success IMO. 


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".


Agreed.


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.
;)
Not being concerned and being concerned to varying degrees are two different things :-) 

-- Flemming


-hadriel