RE: Early media and AVP vs. SAVP

> -----Original Message-----
> From: Randell Jesup [mailto:rjesup@xxxxxxxxx]
> Sent: Wednesday, August 09, 2006 10:46 AM
> To: Hadriel Kaplan
> Cc: ietf-rtpsec@xxxxxxx
> Subject: Re: Early media and AVP vs. SAVP
> 
> I'm confused (not being up-to-speed on the reasons for decisions in
> secdes)
> why transmit-side keys were chosen - normal INVITE SDP usage is that you
> have to be ready to receive as soon as the INVITE is sent - but in secdes
> you aren't ready to actually receive until you see the answer.  In
> packet-loss and longer-SIP-delay cases, you might have 1/2, 1 or even more
> seconds of clipping of the answerer.  When each side is ready to send they
> have the key they need to send, if you use receive-side keys in the
> exchange.

Yeah, I didn't like it either but the reasons are fairly legit.  The authors
included the reasons in the Appendix to RFC 4568.  Rob Raymond and Dan Wing
had a draft for an early-media version which tried to address this, but I
think that draft expired.  The only answer to your issue right now is
pre-conditions, AFAIK. 

 
> An issue (perhaps resolvable?) with using MKI:
> 
> How does MKI really help you distinguish between RTP and SRTP?  If you
> know
> that the codec encoding is a fixed length, you can key off the payload
> length to know there's an MKI there, but many codecs (video especially)
> are
> variable-length, so you'd have to look at the last N bytes of the packet
> and see if they "appear" to be an MKI tag - and you could get fooled
> unless
> there's a reasonably strong hash value to use.

Yup, that's one of the issues with it, and I figured you would note that
(being a video-focused guy :)
Is there a real-world need/use for early-video?  We're not talking about
video before the user actually answers - we're only talking video before an
SDP answer comes back, which can be in 18x.  I was going to say "don't
decode it if you don't know". 

 
> Instead of MKI, we may want to consider the payload-value based
> distinction
> from my proposal.   It also answers the [note] from the paragraph I
> quoted,
> allows early media, and doesn't lock one into secdes.

Yeah, that was one of the proposals, as was specifying a ssrc, using another
port, using the padding mechanism, and setting the marker bit.  The unique
PT was my favorite of those 3, but I was worried it would make it harder for
sdes-supporting UA's to modify themselves to support it, and it results in a
lot of PTs. (I was going for ease-of-transition to get broader use)  Also,
you have to be able to handle SRTCP, fwiw.  But I'm cool with anything that
makes it work and will be popular.

-hadriel