Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 02 July 2013 20:00 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 D334621F9AF3 for <mmusic@ietfa.amsl.com>; Tue, 2 Jul 2013 13:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.549
X-Spam-Level:
X-Spam-Status: No, score=0.549 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 N+V9jetBWzxc for <mmusic@ietfa.amsl.com>; Tue, 2 Jul 2013 13:00:09 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 074F621F9AFA for <mmusic@ietf.org>; Tue, 2 Jul 2013 13:00:07 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta08.westchester.pa.mail.comcast.net with comcast id vPfh1l0040xGWP858Y07th; Tue, 02 Jul 2013 20:00:07 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id vY061l0113ZTu2S3YY07Yd; Tue, 02 Jul 2013 20:00:07 +0000
Message-ID: <51D33146.9010402@alum.mit.edu>
Date: Tue, 02 Jul 2013 16:00:06 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C3BA9EF@ESESSMB209.ericsson.se> <511DF9CE-FEDD-4175-BF36-D44ACBE285DE@csperkins.org> <51CF0768.7030504@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48CF17@xmb-rcd-x14.cisco.com> <51D2DE2A.20300@alum.mit.edu> <3879D71E758A7E4AA99A35DD8D41D3D91D48DBCF@xmb-rcd-x14.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3C19FE@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372795207; bh=i/J5msaHlUMDbOtBFWUPkvk3kWk1GZBmY/JH8bAbYNg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=R0pnj8lqJPnTvRYV0MDjWqslsTYQBwc+cKOSGvKzEgl1qQy2+3N893YAIf86Qz/09 aWVRZTyQU4dKfS/6M7kFD+K35gBAbQiwvOglmGznUEz6vYNtWocrjd58EtNd0gHhzs JREMgbx8nKatBFyhLPPzsUHFUNUlTbkCEkdNy+N3Ymd0ghkadN+Huyzvj5o12WMxr3 Xgp4mXzOjkc/UeXYB05Kn7aTsaO4AMYn/+0QKKH1xRepjO9lUvn3OsPC3o6JNt++BP gvi2JbwyQZwpuEp0lZ7qbeCK7VdRO6FmPHUdgYy4qhD/nDIec0Vlk6doByc11il6oQ GWDIxRQmoM9SQ==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
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, 02 Jul 2013 20:00:13 -0000
+1 (Except that I *am* Paul) On 7/2/13 2:30 PM, Christer Holmberg wrote: > Hi, > > I am not Paul, but just to verify that I understand his issue, the question is: > > Why do you need 4 m- lines for the thumbnails, when you could use 1 m- line? > > Regards, > > Christer > > -----Alkuperäinen viesti----- > Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mo Zanaty (mzanaty) > Lähetetty: 2. heinäkuuta 2013 19:09 > Vastaanottaja: Paul Kyzivat > Kopio: mmusic@ietf.org > Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? > > An attempt at "an answer that makes sense". (Just snippets, not full SDP.) > > m=video 10000 RTP/SAVPF 96 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=42001F <--- HD 720p30 main speaker > > m=video 10000 RTP/SAVPF 97 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly > > m=video 10000 RTP/SAVPF 97 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly > > m=video 10000 RTP/SAVPF 97 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly > > m=video 10000 RTP/SAVPF 97 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly > > No need to map thumbnail packets to specific m-lines, so reuse of PT=97 is fine. Just render the last 4 thumbnail sources received (in addition to the main speaker). > > You could mandate that PT must be unique to allow unique mapping. > > You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever. > > Which do you want to mandate and why? > > Cheers, > Mo > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, July 02, 2013 10:06 AM > To: Mo Zanaty (mzanaty) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? > > On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote: >> Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechanism. You MAY use the mechanism(s) described here, or some other mechanism." But why mandate such a tautology? >> >> The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple streams with the same processing. I don't think we want to force bundle to pick a plan. > > I'm going to keep asking this question until I get an answer that makes > sense: > > Please explain to me a meaningful situation when there are multiple m-lines in a bundle and there is insufficient information to associate each packet with an m-line. > > The *point* of plan A is that there be an m-line per "flow", and that the offerer is enumerating the flows. So clearly it knows the mapping. > If the answerer isn't capable of doing the same mapping, then the use of plan A has failed. > > The part that I want to be normative is that an O/A is not valid unless the mapping is possible with the information in the O/A, and that the offerer and the answerer would agree about the mapping of each packet. I don't care if they actually do the mapping, though if they are doing any sensible processing then they will be doing something *equivalent* to the mapping. > > Thanks, > Paul > >> Mo >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Saturday, June 29, 2013 12:12 PM >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line? >> >> On 6/29/13 8:50 AM, Colin Perkins wrote: >>> Christer, >>> >>> On 25 Jun 2013, at 12:16, Christer Holmberg wrote: >>>> There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's not needed. >>>> >>>> We haven't had that much discussion about it yet, so I will not ask >>>> a DECISION question at this point, but I would really like to get >>>> some input from people who have opinions about this :) >>> >>> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care. >> >> I just replied elsewhere on this. >> My opinion turns out to be the exact opposite of yours: we need to >> support multiple algorithms, and that all applications should care. >> >> I won't repeat the stuff about multiple algorithms. >> >> I will repeat what I have said about the need for being able to associate: >> >> There must have been *some* reason that two m-lines were used, rather >> than just one. Each m-line heads a media section of the SDP that >> contains a bunch of declarations. Something must be different in those >> two media sections, or else a single media section would have been >> enough. Presumably whatever it is that is different is intended to >> affect how received packets are processed or interpreted. (If not, >> again there is no need for it to be there.) If you can't associate the >> packet with the m-line, then you don't know which of the multiple >> interpretations to apply to the packet. >> >> Maybe there is some exception to this, though I haven't come up with >> anything. If there is, then I hope someone will call it out. If so, >> then the constraint can be tightened. >> >> Thanks, >> Paul >> >> >> _______________________________________________ >> 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 >
- [MMUSIC] BUNDLE DISCUSION: Always mandate mechani… Christer Holmberg
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Christer Holmberg
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Christer Holmberg
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Christer Holmberg
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Colin Perkins
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Mo Zanaty (mzanaty)
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Mo Zanaty (mzanaty)
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Christer Holmberg
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Mo Zanaty (mzanaty)
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Mo Zanaty (mzanaty)
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Christer Holmberg
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Christer Holmberg
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Parthasarathi R
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Parthasarathi R
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Mo Zanaty (mzanaty)
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Christer Holmberg
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat
- Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mec… Paul Kyzivat