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

[Randell Jesup <rjesup at wgate.com>]

David McGrew <mcgrew at cisco.com> writes:
>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.

This is quite problematic for RTP:

1) If you replay headers, you are simulating another source (ssrc).  While
   in theory the receiver should handle a different timestamp base and set
   of sequence numbers for a different source (practice might be another
   question... and what it does when it sees a new source - it might well
   just ignore the new stream), if there's an SSRC collision there's no way
   to respond to it.
2) No action other than real-time replay is possible - no FF/REW/skip/etc.
3) Big problem - the PT you send has to be the PT that the *other* side
   said it wanted for the codec (not to mention the offer/answer
   parameters).  If they sent an INVITE (or OK) with PT 99 being iLBC, and
   your stored message has 98 as iLBC, you're screwed.  If you stick to
   "static" codecs (especially PCMU/A), it's easier - modulo things like
   support for silence suppression, etc.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

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