Re: [MMUSIC] Thinking about best-effort encryption

[Flemming Andreasen <fandreas@xxxxxxxxx>]

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

-- Flemming

> -hadriel
>
>
>  
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@xxxxxxxxx]
> > Sent: Sunday, November 05, 2006 10:22 PM
> >
> > Dan Wing wrote:
> >
> >    
> >
> > > I understood Francois was pointing out the difference in the m-lines of
> > >      
> > the
> >    
> >
> > > offer, not the answer.
> > >
> > > I don't care much, myself, if the answer's m-line shows the RTP profile
> > >      
> > the
> >    
> >
> > > answerer selected.  It probably does ease some things, and Francois,
> > > Hadriel, and I exchanged email a month ago that the offerer's RTP profile
> > >      
> > in
> >    
> >
> > > his m-line doesn't need to match the answerer's RTP profile in his m-
> > >      
> > line:
> >    
> >
> > > there is no RFC that requires those match.
> > >
> > >
> > >      
> > That would appear to be true (much to my surprise when I first saw this
> > in the Kaplan draft), however there is also no RFC that specifies what
> > to do if they don't match, and you can hardly argue this is in-line with
> > the general offer/answer philosophy. Still, I don't think we are at a
> > point where this particular question should drive the debate - we still
> > need to agree on problem scope and a few fundamental design guidelines
> > (per my note to EKR).
> >
> > -- Flemming
> >
> >    
>
>