Subject: RE: [MMUSIC] FW: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 Sep 2006 07:39:53 +0100

I think it's a lot simpler, addressing this particular problem of SSRTP
versus RTP.

John 

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 05 September 2006 21:43
> To: Elwell, John; Hadriel Kaplan; [email-masked]
> Subject: RE: [MMUSIC] FW: I-D 
> ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt
> 
> 
> > It is a question of whether a new RFC, 
> > perhaps defining a new attribute, would be worthwhile in 
> > terms of gaining a larger catchment of legacy devices with 
> > which we can fall back to RTP.
> 
> 
> How is that any different from the sdp-cap proposal in Montreal? 
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Sep 2006 13:53:26 -0500

I'm not sure I agree.

The sdp-cap proposal was a "usage" of an existing RFC. 

While it may be "more complex" from a theoretical point of view, the
process 
of standardizing yet another SDP extension to do this seems much more
"complex" 
from a procedural point of view.

This group has an appetite for making seamingly simple problems complex.
I do not
see why this particular one wouldn't expand to be just as "complex" as
the sdp-cap
proposal when we are done with it.

As I stated in Montreal, what really bothers me about this is the
unresponsiveness
of the IETF in providing a mechanism for supporting best-effort
backward-compatible
SRTP.

We are at a point now where the industry is way ahead of the standard.
Implementors have 
been working on this particular item for 2-3 years now. Implementors
don't understand why
IETF can't make up our mind on such a trivial problem.

The consequence of this is a proliferation of ways to do best-effort
SRTP. They mostly
are variations of either port overloading, multiple ports and
AVP+crypto/kmgmt.
Mostly not interoperable obviously.

We are very close to a point of losing our relevance. 

<<<<rant off>>>>

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 11:40 PM
> To: Audet, Francois (SC100:3055); Hadriel Kaplan; [email-masked]
> I think it's a lot simpler, addressing this particular 
> problem of SSRTP versus RTP.
> 
> John 
> 
> > > It is a question of whether a new RFC, perhaps defining a new 
> > > attribute, would be worthwhile in terms of gaining a larger 
> > > catchment of legacy devices with which we can fall back to RTP.
> > 
> >