RE: [MMUSIC] Thinking about best-effort encryption

["Dan Wing" <dwing@xxxxxxxxx>]

> > The offer in 
> > draft-andreasen-mmusic-sdp-capability-negotiation-01.txt, on
> > page 16, is here (I show the interesting lines with "**"):
> >
> >            v=0 
> >            o=- 25678 753849 IN IP4 128.96.41.1 
> >            s=  
> >            c=IN IP4 128.96.41.1 
> >            t=0 0 
> >      **    m=audio 3456 RTP/AVP 0 18  
> >            a=sqn: 0 
> >      **    a=cdsc: 1 audio RTP/AVP 0 18  
> >      **    a=cdsc: 3 audio RTP/SAVP 0 18  
> >            a=capar: 1 a=crypto:1 AES_CM_128_HMAC_SHA1_32    
> >            inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32  
> >            a=pcfg: c=3,4 a=1 
> >            a=pcfg: c=1,2  
> >
> > The answer is described and shown on page 17:
> >
> >         Bob receives the SDP offer from Alice. Bob supports 
> >         RTP, but not 
> >         SRTP, and hence he accepts the potential 
> >         configuration for RTP 
> >         provided by Alice: 
> >
> >            v=0 
> >            o=- 24351 621814 IN IP4 128.96.41.2 
> >            s=  
> >            c=IN IP4 128.96.41.2 
> >            t=0 0 
> >      **    m=audio 4567 RTP/AVP 0 18  
> >            a=acfg: c=1,2 
> 
> Isn't that because it's not doing crypto in this example:

The offer, above, is for best-effort SRTP.  

The answerer can't do SRTP.



>         Bob receives the SDP offer from Alice. Bob supports 
>         RTP, but not 
>         SRTP, and hence he accepts the potential 
>         configuration for RTP 
>         provided by Alice: 
> 
> I read this text form S 4.4.2. as implying that if the answerer
> had been willing to do SRTP you would need RTP/SAVP in the m-line.

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.

> 
>         If the answerer chooses to accept one of the 
>         alternative potential 
>         configurations instead of the actual configuration, 
>         the answerer MUST 
>         generate an answer as if the offer contained that potential 
>         configuration instead of the actual configuration 
>         included. The 
>         answerer MUST also include an actual configuration 
>         attribute in the 
>         answer that identifies the potential configuration 
>         from the offer 
>         used by the answerer. The actual configuration 
>         attribute in the 
>         answer MUST include information about the 
>         capabilities. Furthermore, 
>         if the offered potential configuration included 
>         attribute capability 
>         parameters and/or transport protocol capabilities, 
>         those parameters 
>         MUST be included in the actual configuration 
>         attribute in the answer 
>         as well.  
> 
> But maybe I've just misunderstood Flemming's draft.

I certainly miunderstood Francois' post, so my response to him may have been
confusing.

-d