Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013

Kevin Dempsey <kevindempsey70@gmail.com> Thu, 06 June 2013 12:40 UTC

Return-Path: <kevindempsey70@gmail.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 3F63721F994D for <mmusic@ietfa.amsl.com>; Thu, 6 Jun 2013 05:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 kwmODXShB9ZC for <mmusic@ietfa.amsl.com>; Thu, 6 Jun 2013 05:40:52 -0700 (PDT)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 77BE821F96E8 for <mmusic@ietf.org>; Thu, 6 Jun 2013 05:40:51 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id w20so3026419lbh.10 for <mmusic@ietf.org>; Thu, 06 Jun 2013 05:40:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oEdNIhLeXID2zLt+e6ZZh8V94U3xhajtpt+S/GUwVg0=; b=J5pEikWR3HcSa3IrKTpWM2qukIPwQikeHaHOSh7G3bUOBuDd/9qv52frBOljiphE9r q7uYdjRKxz6iOg9E0Fd9CqVhGLtLQHYzuWxDvGRnV8EscA0jagsqTmnZYefMhu83oLyK R7yMRDqMLU8XZzL50CS1mFkgrydDlg5V/q+rMFCgIpl/95nhycyqGUCzYps2gf7OTB7K O14n7bcVOxM92A7p60oYWerWeDhL3vwvLOiyaT6e5Ay/gPYR4nuwYXgscO1f9zPncN42 FUWu4WfCyCigYPV+363HxYn42/2VVFYjX9uAbVickmTl9d44exrDF7j9Pe1XwzuOSWB9 jt6g==
MIME-Version: 1.0
X-Received: by 10.112.185.104 with SMTP id fb8mr9530861lbc.96.1370522450280; Thu, 06 Jun 2013 05:40:50 -0700 (PDT)
Received: by 10.114.80.161 with HTTP; Thu, 6 Jun 2013 05:40:50 -0700 (PDT)
In-Reply-To: <CAPvvaaJ0agd-7xNb7ZC-B-Mfw52VWYkXqmdF0K+-JR73OLy9hA@mail.gmail.com>
References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl> <51AEC23B.1010509@cisco.com> <51AF14DB.5020009@jitsi.org> <51AFDFDB.40500@cisco.com> <CAPvvaaJ0agd-7xNb7ZC-B-Mfw52VWYkXqmdF0K+-JR73OLy9hA@mail.gmail.com>
Date: Thu, 6 Jun 2013 13:40:50 +0100
Message-ID: <CAMvTgcdM9nEG3X4Yzib-bsZOhrbQyRYP+bL8YDGVXV6byMfkmA@mail.gmail.com>
From: Kevin Dempsey <kevindempsey70@gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: multipart/alternative; boundary=001a11c3c9a4ce490f04de7b9f6f
Cc: Flemming Andreasen <fandreas@cisco.com>, Ari Keranen <ari.keranen@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013
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: Thu, 06 Jun 2013 12:40:56 -0000

Am i right in saying that what No Plan needs MMUSIC to say is that for
BUNDLE to be usable the applications must use some method to determine
which m- line a RTP stream is to be matched to? That method can be anything
the applications at both ends can agree upon. That can include SSRC
signalling within the SDP, unique PTs across m- lines, or even custom SIP
headers etc.

In the RTCWEB case, the signalling is already application specific. So that
signalling path could be used by such application.


On 6 June 2013 08:06, Emil Ivov <emcho@jitsi.org> wrote:

> Hey Flemming,
>
> Just to be clear, are you saying all this because you believe No Plan
> should NOT be on the agenda of the mmusic interim meeting?
>
> Emil
>
> On Thu, Jun 6, 2013 at 3:03 AM, Flemming Andreasen <fandreas@cisco.com>
> wrote:
> >
> > On 6/5/13 6:37 AM, Emil Ivov wrote:
> >>
> >> Hey Flemming,
> >>
> >> You are right, there are no specific SDP updates that "No Plan" is
> asking
> >> from mmusic.
> >>
> >> That said however, the same is pretty much true about Plan A and Plan B.
> >> They both discuss ways of using SDP and the extensions that might be
> implied
> >> to these ways are considered mostly collateral:
> >>
> >> Plan A:
> >>
> >>   This document describes a *modest*
> >>   set of extensions to SDP which allow it to cleanly handle arbitrary
> >>   numbers of flows while still retaining a large degree of backward
> >>   compatibility with *existing* and non-RTCWEB endpoints.
> >>
> >> Plan B:
> >>
> >>   Plan B mostly uses *existing* IETF standards, introducing a single new
> >>   draft [I-D.lennox-mmusic-sdp-source-selection] to specify how
> >>   individual media sources can be accepted/rejected at the SSRC level
> >>   via SDP.
> >>
> >> I might be off, but it was my understanding that the interim meeting was
> >> not going to be about these specific extensions (which could possibly be
> >> specified regardless of which Plan we go for) but mostly about the best
> ways
> >> to use SDP with multiple sources. The choices we make could have an
> impact
> >> on multiple working groups, which, I assumed, was the main reason for
> having
> >> the discussion mmmusic.
> >>
> > Agree with the latter part. In terms of approaches however, we previously
> > had 2 (A and B), each of which seemed reasonably self-contained, and
> while
> > clearly driven by RTCWeb, have broader scope than RTCWeb.
> >
> >
> >> In that sense I see "No Plan" as quite related to this discussion.
> >>
> > I agree it's related, but at the same time, the mechanism proposed seems
> to
> > be tied to RTCWeb in terms of discussing RTCWeb APIs and leaving a lot of
> > the machinery unspecified. Examples from the document:
> > <quote>
> >    The actual Offer/Answer semantics presented here do not differ
> >    fundamentally from those proposed by Plan A and Plan B.  The main
> >    differentiation point of this approach is the fact that the exact
> >    protocol mechanism is left to WebRTC applications.  Such applications
> >    or lightweight signalling gateways can then implement either Plan A,
> >    or Plan B, or an entirely different signalling protocol, depending on
> >    what best matches their use cases and topology.
> > </quote>
> >
> > and
> >
> > <quote>
> >    All of the above semantics are best handled and hence should be left
> >    to applications.  There are numerous existing or emerging solutions,
> >    some of them developed by the IETF, that already cover this. This
> >    includes CLUE channels [CLUE], the SIP Event Package For Conference
> >    State [RFC4575] and its XMPP variant [COIN].  Additional mechanisms,
> >    undoubtedly many based on JSON, are very likely to emerge in the
> >    future as WebRTC applications address varying use cases, scenarios
> >    and topologies.
> > </quote>
> >
> > The above may be perfectly reasonable from an RTCWeb point of view, but I
> > don't see MMUSIC as the place to make that decision. On the other hand,
> if
> > it's more a matter of coming up with a general framework for how to
> > establish/signal sessions that support a multitude of multimedia
> > participants in a session subject to certain requirements
> (port-efficient,
> > large number of participants can come and go dynamically, per source
> control
> > of media parameters, etc.) via SDP signaling, then MMUSIC probably is the
> > right place. The document should probably change a bit in some places
> then.
> >
> >
> >> Am I right in assuming this and if so does the above answer your
> question?
> >>
> > I think it's clearly related, however I want to make sure that the scope
> is
> > not limited to RTCWeb and hence does not assume anything RTCWeb specific
> > (e.g. APIs, etc. which should not be the subject of MMUSIC
> > discussions/documents).
> >
> > I'd like to hear what other people think about this though (incl. the
> RTCWeb
> > chairs).
> >
> > Thanks
> >
> > -- Flemming
> >
> >
> >> Emil
> >>
> >> On 05.06.13, 06:44, Flemming Andreasen wrote:
> >>>
> >>>
> >>> On 6/4/13 10:41 PM, Bernard Aboba wrote:
> >>>>
> >>>> Yes, you are missing something. No plan analyzes issues with both
> Plan A
> >>>> and Plan B and describes how to fix them. As they stand, both Plan A
> nor
> >>>> Plan B result in O/A exchanges that aren't needed and will break
> congestion
> >>>> control. Also, neither satisfies the requirements of the RTP usage
> doc or is
> >>>> compatible with a number of legacy implementations. No  plan offers a
> >>>> solution to these and other issues.
> >>>
> >>> I understand that "no plan" sees issues with Plan A and Plan B as
> >>> currently defined. What I don't understand is what extensions or
> updates
> >>> to SDP signaling mechanism are being proposed here and hence which part
> >>> of this discussion belongs in MMUSIC as opposed to RTCWeb simply
> >>> specifying how it wants to use a set of current/developing mechanisms
> >>> (or rely on app specific mechanisms, etc.) ? In other words, what does
> >>> "no plan" seek from MMUSIC ?
> >>>
> >>> Thanks
> >>>
> >>> -- Flemming
> >>>
> >>>> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" <fandreas@cisco.com>
> >>>> wrote:
> >>>>
> >>>>> On 5/31/13 6:46 AM, Emil Ivov wrote:
> >>>>>>
> >>>>>> Dear chairs,
> >>>>>>
> >>>>>> Could you please also consider the following draft for the interim
> >>>>>> meeting agenda:
> >>>>>>
> >>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
> >>>>>
> >>>>> Sure, however I could use some clarification here. On one hand, the
> >>>>> draft falls squarely in the middle of the overall "Plan" discussion
> we have
> >>>>> and hence is highly relevant, but at the same time, if I understand
> >>>>> correctly, the draft is not asking MMUSIC to do anything in terms of
> >>>>> protocol development. Rather, if this approach is adopted, it would
> be more
> >>>>> of an RTCWeb usage document specifying how one could use several
> different
> >>>>> mechanisms (and possibly WebRTC APIs) to implement signaling. There
> doesn't
> >>>>> seem to be a "mandatory to implement" mechanism for guaranteeing
> >>>>> interoperability (in contrast to Plan A/B), but rather there are
> references
> >>>>> to "app specific signalling" mechanisms, etc. Am I missing something
> here ?
> >>>>>
> >>>>>
> >>>>>> I apologise if not stating this earlier has introduced any
> confusion.
> >>>>>
> >>>>> No worries.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> -- Flemming
> >>>>>
> >>>>>> Regards,
> >>>>>> Emil
> >>>>>>
> >>>>>> On 30.05.13, 21:56, IESG Secretary wrote:
> >>>>>>>
> >>>>>>> Greetings,
> >>>>>>>
> >>>>>>> This is to announce a(nother) virtual interim meeting for the
> MMUSIC
> >>>>>>> Working Group to take place on Monday, June 17, from 7:00 am -
> 10:00
> >>>>>>> am
> >>>>>>> Pacific Time. The goal of this meeting is to come to a resolution
> on
> >>>>>>> the
> >>>>>>> so-called "Plan A" or "Plan B" approach related to SDP signaling
> >>>>>>> needed
> >>>>>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m="
> lines
> >>>>>>> or
> >>>>>>> very few "m=" lines and to what extent is there sub-negotation and
> >>>>>>> signaling at the SSRC level).
> >>>>>>>
> >>>>>>> A more detailed agenda and logistics will be sent out separately on
> >>>>>>> the
> >>>>>>> MMUSIC mailing list. For now, people should take a close look at
> the
> >>>>>>> following two drafts:
> >>>>>>>
> >>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt
> >>>>>>>
> >>>>>>>
> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
> >>>>>>>
> >>>>>>> You may also want to look at
> >>>>>>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>> -- Ari & Flemming (MMUSIC co-chairs)
> >>>>>>>
> >>>>>>>
> >>>>>>> PS: Per our previous interim meeting announcement, we tried to
> >>>>>>> schedule
> >>>>>>> a longer and in-person physical interim meeting, however it has
> >>>>>>> proven
> >>>>>>> impossible to find a set of dates where we could get critical mass
> >>>>>>> for
> >>>>>>> such a meeting. Scheduling even a virtual interim before the Berlin
> >>>>>>> IETF
> >>>>>>> has been surprisingly difficult with the above date being the only
> >>>>>>> viable option at this point.
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>>
> >>>> .
> >>>>
> >>>
> >>>
> >>
> >
>
>
>
> --
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
> http://jitsi.org                       FAX:   +33.1.77.62.47.31
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>