Re: [rtcweb] Plan A, respun
Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 08 May 2013 20:14 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE5C21F8ECA for <rtcweb@ietfa.amsl.com>; Wed, 8 May 2013 13:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.156
X-Spam-Level:
X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, RDNS_NONE=0.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 V0wAL77QK3tq for <rtcweb@ietfa.amsl.com>; Wed, 8 May 2013 13:14:47 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5D21F8EBF for <rtcweb@ietf.org>; Wed, 8 May 2013 13:14:46 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id ZPup1l0041uE5Es55YEm3m; Wed, 08 May 2013 20:14:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id ZYEm1l0063ZTu2S3cYEmuS; Wed, 08 May 2013 20:14:46 +0000
Message-ID: <518AB235.3040205@alum.mit.edu>
Date: Wed, 08 May 2013 16:14:45 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>
References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com> <51896D91.9070004@alum.mit.edu> <00c201ce4b70$986ffee0$c94ffca0$@gmail.com>
In-Reply-To: <00c201ce4b70$986ffee0$c94ffca0$@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368044086; bh=oWAwtzZVtUYCCLdWtCXTvaIoQkf2F5u92YaX7AyM88w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eA0ZZluWasBtDxJVmJyEkIatlD71ZaTajf3hGgyjRXID+lIfWSdp8Gb+7tfuEQVbg mTQWGkS+2+NJGxfNvbYaPvpDkcDpgualjuEGut/gBwWPDJA5aedKUuPVkKu1i95ehm XCXiGD4bftQkc6oMasqLiN0mu3+pYg0FbrqD5kUC7d5gYlJxgw0LY8Wd79Ob7mPgmv Vq1hHNOVrdkRVfMO07b95W3CVfJT/chiSMJRziSuRIjyjTLaqii+rM/4rOTgTTYH7c OMYh4sG7HqOzs/fsOyFJNkIzdsH2JioDkykVVIFHv7EdeMgFRnLOrce7xlUV1AChRv oQ9i5V5uODGyw==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan A, respun
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 May 2013 20:14:51 -0000
On 5/7/13 6:16 PM, Roni Even wrote: > Hi Paul, > The problem in the CLUE case in the example you gave is that the receiver > will get an RTP stream with a new SSRC not in the SDP to the same port and > will need to know how to map it to one of the media capture replacing the > previous one. My assumption was that each m-line would correspond to a capture, and according to what Adam specified, it would have to be demuxed by payload type. And also, according to Adam's assumptions, whatever SSRCs are received would all be assumed to be part of the same capture. So it works in a limited way, without a header extension, used PT demux. But its limited by the number of PTs. > I think that this mode can work in plan B as an additional case, multiple > RTP streams in an m-line but the SSRC or mapping to media capture is done > via RTP header extension. For plan A it works only if it will allow multiple > RTP streams based on the same m-line. The assumption in both cases is that > both sides identify that they understand this specific usage, for example, > by support of the specific header extension Either scheme can be *made* to work for the clue dynamic capture case using a header extension. But we have to work out the details of how. Thanks, Paul > Roni > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 08 May, 2013 12:10 AM > To: Adam Roach > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Plan A, respun > > On 5/7/13 4:00 PM, Adam Roach wrote: >> On 5/7/13 14:29, Paul Kyzivat wrote: >>> If I bundle an m-line without a=ssrc, and with unique PTs, do you >>> consider it ok if there are multiple "anonymous" flows each complying >>> to the attributes of the m-line? >> >> I presume, by "multiple anonymous flows," you mean multiple series of >> packets with the same PT, but with different SSRC values. >> >>> Or do you assume that all packets with that PT are treated as one >>> flow, switching from one SSRC to another as they are received? >> >> In the example you gave, all of those packets are defined to be >> associated with the same media line. Looking at basic principles, the >> intention here is that the semantics would be identical to non-webrtc, >> non-bundle clients receiving multiple SSRCs on the same port. >> Admittedly, those semantics have never been crystal clear, but my >> experience is that most systems would use this approach to send >> multiple streams that are semantically the same "thing" and should be >> rendered as one "thing" (e.g., window, speaker, etc). >> >> Specifically, we are *not* trying to allow the situation in which (1) >> the SDP has no SSRC for the m-lines in a bundle group; (2) the party >> who generated the SDP receives multiple streams (distinguished, >> presumably, by SSRC) with the same PT, and (3) the recipient then >> deduces that there should be two different rendering outputs (e.g., > windows) as a result. >> That is specifically and intentionally one of the behaviors we removed >> from the Orlando proposal, since it severely dilutes the value of >> preserving existing SDP semantics. >> >> Does that answer the question you're answering? > > Yes, that exactly answers the question I was asking. > > It fits a clue case, of a "dynamic switched capture", where a single logical > flow (capture) may be conveyed via unknown SSRCs. > > But it doesn't cope well with a case where there a several of those, because > each will require distinct PTs, and that may not work. > > To adequately cover that, I think we need the potential to signal a > *different* demux algorithm, instead of PT or SSRC. (We are assuming a new > RTP header extension). > > Bottom line, instead of saying the demux is by ssrc if present, and > otherwise by PT, I suggest that we explicitly signal the demux mechanism, > with options being at least those, plus another one once we get it defined. > > Otherwise I think what you are proposing can work for CLUE. > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > >
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Harald Alvestrand
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Jonathan Lennox
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Harald Alvestrand
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Dale R. Worley
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Martin Thomson
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Jonathan Lennox
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Emil Ivov
- [rtcweb] MSID fallback for non-MSID case (Re: Pla… Harald Alvestrand
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Kevin Dempsey
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Christer Holmberg
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Bernard Aboba
- Re: [rtcweb] Plan A, respun Cullen Jennings (fluffy)