Re: [MMUSIC] Unified Plan for SDP Handling

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 16 July 2013 23:43 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E3721F9D1E for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 16:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level:
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc5eyccdj5ZR for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 16:43:42 -0700 (PDT)
Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by ietfa.amsl.com (Postfix) with ESMTP id 719CE21F9C7B for <mmusic@ietf.org>; Tue, 16 Jul 2013 16:43:42 -0700 (PDT)
Received: from BLU402-EAS280 ([65.55.111.71]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 16:43:41 -0700
X-TMN: [3Xw0WbruEAmN0RCBpNInCTjD7thHRdKn8rWrWada1io=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU402-EAS2805A3BE476532AC30F31DD93600@phx.gbl>
Date: Tue, 16 Jul 2013 16:43:34 -0700
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Roni Even <ron.even.tlv@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-OriginalArrivalTime: 16 Jul 2013 23:43:41.0204 (UTC) FILETIME=[4D245540:01CE827E]
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Unified Plan for SDP Handling
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 23:43:54 -0000

IMHO, correlation needs to be supported in an RTP extension as well as RTCP SDES, regardless of the SDP discussion. In WebRTC we shouldn't be wedded to SDP signalling and even if we are, the dynamism implied by simulcast and layered coding can't be accommodated in signalling.

Roni Even <ron.even.tlv@gmail.com> wrote:

Adam,
For correlation when the SSRC is not known in the SDP look at
http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and the
option to use SDES and not only RTP header extension.

BTW: there are other cases when the SSRC is not known using SDP before the
RTP stream arrives like when an MCU switch the video. Note that SDES is
distributed to the session when the source joins the RTP session which can
be long before the RTP media is sent to a specific receiver in the group.

Roni

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Adam Roach
> Sent: 15 July, 2013 10:05 PM
> To: mmusic@ietf.org
> Cc: rtcweb@ietf.org
> Subject: [MMUSIC] Unified Plan for SDP Handling
>
> [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
>
> /a
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic