Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling

Please forgive me for coming a bit late to the discussion on this, but what
types of "legacy devices" are being targeted?  At least from what I have
seen, most legacy equipment doesn't support ICE, definitely does not
support DTLS-SRTP, most do not support SDES-SRTP, none bundling, none
rtcp-mux, etc.

I believe that there might be some sort of legacy interop with disabling of
bundling, rtcp-mux possibly as well, and supporting SDES or non encrypted
sessions.  Otherwise, I don't know what legacy devices means in the context.

Is there a place where a definition of a "legacy device" (as mentioned in
your draft) is given in the webrtc specs?

Matthew Fredrickson

On Mon, Jul 15, 2013 at 2:04 PM, Adam Roach <adam@nostrum.com> wrote:

> [Cross-posting to RTCWEB; follow-ups to MMUSIC, please]
>
> After significant work, Justin, Martin and I have managed to produce a
> compromise plan that provides a high degree of interoperability with
> existing devices (and future non-WebRTC devices) while not being
> excessively onerous for WebRTC implementations or applications that use
> them. It's been a tricky balancing act, but I think we've found a good mix
> between the two that can form a solid basis for the working group to move
> forward.
>
> Rather than summarize the key points of the document in this email, I
> direct interested parties to section 2 of the document, which summarizes
> the key aspects of the plan in eight relatively concise bullet points.
>
> I apologize for the late publication date of this document -- there's
> actually been a lot more work put into coming up with a unified draft than
> I originally anticipated, and the production of this document took at least
> two weeks longer than I expected it to.
>
> Note that this document is intended to be a plan for the work to be done
> in this area, and not a specification in itself. The intention is that its
> contents are used as the basis for work in several other drafts -- some
> new, some not -- that form the corpus of work necessary for RTCWEB (and
> potentially CLUE) to move forward. Except in rare cases, the document does
> not attempt to explicitly call out venues or documents for such work, as we
> (or, at the very least, I) anticipate guidance from the various working
> group chairs to assist in such decisions.
>
> Comments prior to Berlin would be very helpful, although this will clearly
> be a point of significant discussion at the face-to-face meeting.
>
> Document link:
>
> http://www.ietf.org/id/draft-**roach-mmusic-unified-plan-00.**txt<http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt>
>
> /a
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>