Re: [AVT] question on draft-mattsson-srtp-store-and-forward-00.txt

["Dan Wing" <dwing at cisco.com>]

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of David McGrew
> Sent: Monday, July 28, 2008 8:21 PM
> To: john.mattsson at ericsson.com; 
> fredrik.lindholm at ericsson.com; yi.cheng at ericsson.com; Rolf 
> Blom J (KI/EAB); "Mats Näslund (KI/EAB)"; Karl Norrman ((KI/EAB))
> Cc: AVT
> Subject: [AVT] question on 
> draft-mattsson-srtp-store-and-forward-00.txt
> 
> Hello,
> 
> Section 3.2.1 says that "The answering machine, acting as a 
> streaming  
> server when sending the data to the callee, will not use the exact  
> same RTP headers on the outgoing SRTP traffic as was used on the  
> incoming SRTP traffic. SRTP as specified in [RFC3711] will 
> not work in  
> this case, since parts of the RTP header is input to the encryption/ 
> authentication transforms."
> 
> However, some parts of the RTP header would need to be stored along  
> with the payloads.  Since the answering machine is storing 
> ciphertext  
> payloads in this case, it would need to store and play back the RTP  
> timestamp field, since otherwise the answering machine could not  
> effectively determine what values to put into this field.  The same  
> considerations would probably apply to the PT field.
> 
> Since some parts of the header necessarily need to be stored as part  
> of the solution, why not store the entire header, then replay 
> the SRTP  
> session from the answering machine exactly as it was sent to it?    
> This is a simple solution that avoids the need for RTP endpoints to  
> implement new SRTP transforms and options.  It can be implemented by  
> the answering machine's RTP/SRTP stack, without any effect on  
> signaling or any need for explicit support in any other 
> RTP/SRTP stack.

A technical similar to that was described in Section 3.4 of
draft-wing-avt-dtls-srtp-key-transport-01
<http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-01#section-
3.4>, but I pulled it in the most recent version because in Philadelphia Dave
Oran pointed out that SPEECHSC found that such audio storage didn't work well
(for RTP), and thus would not work well for SRTP.  I am curious if
draft-mattsson-srtp-store-and-forward uncovered a new solution that doesn't
bump into the problems SPEECHSC found (but I wasn't curious enough to ask at
the microphone today).

-d

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt