Re: [MMUSIC] Proposal for what bundle should say about demux

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 24 May 2013 15:24 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 ECC1621F89E2 for <mmusic@ietfa.amsl.com>; Fri, 24 May 2013 08:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.536
X-Spam-Level:
X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_OBFU_RESULTING=1.666]
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 C2zgKA8toz4R for <mmusic@ietfa.amsl.com>; Fri, 24 May 2013 08:24:04 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id F03B121F8540 for <mmusic@ietf.org>; Fri, 24 May 2013 08:24:03 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id fnJX1l0051swQuc51rQ3gZ; Fri, 24 May 2013 15:24:03 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id frQ21l01Q3ZTu2S3brQ2lx; Fri, 24 May 2013 15:24:03 +0000
Message-ID: <519F8611.7000802@alum.mit.edu>
Date: Fri, 24 May 2013 11:24:01 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com> <519E80E4.6010904@jitsi.org> <519E9131.2080400@alum.mit.edu> <519F1424.8020803@jitsi.org> <CAMvTgcdpz5dh2zxRGu_xu1QdqsdAapgT-zziT5GzyzyodQxYXA@mail.gmail.com> <519F2BD8.8060803@jitsi.org> <CAMvTgcfx1t0d-NEavTxdq=9FEH9Z-wjX2S+HcSimFUgzg5-58g@mail.gmail.com> <519F2F8B.5080004@jitsi.org> <519F7633.1010902@alum.mit.edu> <CAPvvaaKMbee43bWf95iv-FgHZGaC5AWiydpuSh4Tgs122hcTtA@mail.gmail.com> <519F7FDC.2070001@alum.mit.edu> <CAPvvaaKyTf-rENA4UB=Z5ho+CSDsg3qbZRbdyim2oDshYQLrWQ@mail.gmail.com>
In-Reply-To: <CAPvvaaKyTf-rENA4UB=Z5ho+CSDsg3qbZRbdyim2oDshYQLrWQ@mail.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=1369409043; bh=MIWlvUGkhzyWV9uLiUtE5fkIG/YUkOzqq7vjAN9PGDo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ahsCvhBLmKxv7WQbZFr4LDpSiXHMnPvySrdeRWZHdvoKIZKgEmwyhAl/ToikBAov7 SKbTOb4qXTctaNYqV7QC/eotIFt54BiYF2D/RBEtBgIRiX/yMzvJPf6i5DPDQXsC3Y YOPvwtZxLwcuTxcEZsuzu0QqNl+gvKny0Pc2muxk/Avjw5Fk2ZyLYbxgmBFElEDEgW Xa7T5M7HEaBhQy0yB+pAQ50AnNur9ZcenkzbrXiixenmRUjwTN7avjcCl+GpHXRP3w OTWsRIW6dNOCKwdN/tjpNbN5C8/FDKCLY2KuybXHJCDvo0JKlj7pFkK0VZsbBiXU4s zGBvuUMiTC+rQ==
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Proposal for what bundle should say about demux
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: Fri, 24 May 2013 15:24:10 -0000

On 5/24/13 11:03 AM, Emil Ivov wrote:
> Paul,
>
> This looks very much like what I suggested initially in my response to
> Cullen, so I am not sure why you sound as if you are disagreeing.

Looking back, there is some similarity, but still some difference.

IIUC you are saying that the if the offerer doesn't know the 
capabilities of the answerer then it must construct the offer so that 
any possible answer that accepts the bundle will allow proper 
association to the correct m-line. And I am not saying that.

I am saying that the offer may indeed depend on the answer supporting 
some mechanism specified in the offer in order to make the association 
unique. If the answerer doesn't recognize that mechanism (and so ignores 
it) it should be able then to recognize that the answer it would 
construct will not provide uniqueness. It then needs to fix that, by 
refusing the bundle, or refusing some of the m-lines, or whatever.

	Thanks,
	Paul

> Emil
>
> --sent from my mobile
>
> On May 24, 2013 5:57 PM, "Paul Kyzivat" <pkyzivat@alum.mit.edu
> <mailto:pkyzivat@alum.mit.edu>> wrote:
>
>     On 5/24/13 10:40 AM, Emil Ivov wrote:
>
>         On May 24, 2013 5:16 PM, "Paul Kyzivat" <pkyzivat@alum.mit.edu
>         <mailto:pkyzivat@alum.mit.edu>
>         <mailto:pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>__>
>         wrote:
>           >
>           > On 5/24/13 5:14 AM, Emil Ivov wrote:
>           >>
>           >> On 24.05.13, 12:02, Kevin Dempsey wrote:
>           >>>
>           >>> I didn't say anything about changing the PTs.
>           >>
>           >>
>           >> Sorry, I misunderstood.
>           >>
>           >>> The answerer decides what
>           >>> it codecs it will use from the ones listed in the offer.
>         If it doesn't
>           >>> support any other mechanism to allow demux then it must
>         choose codecs
>           >>> that have PTs on only one m-line, or not accept the BUNDLE.
>           >>
>           >>
>           >> Matching packets to m= lines is the concern of the
>         receiving party. So
>           >> is the mechanism that it uses. What you are suggesting is
>         for the
>           >> answerer to basically say: "It seems to me that you won't
>         be able to
>           >> demux these two payloads so I will not send them to you
>         because I know
>           >> better".
>           >>
>           >> In the same time the offerer may be planning on using a
>         demux technique
>           >> that the answerer simply isn't aware of. For example (and
>         this is really
>           >> just to make a point, so please don't assume I am
>         suggesting something
>           >> like this in general) if 101 is mapped to both
>         telephone-event and VP8,
>           >> demuxing can be easily made without any other knowledge of
>         SSRC or
>           >> header extensions.
>           >
>           >
>           > ISTM that after the O/A exchange both sides need to have a
>         common
>           > understanding that their communications will be understandable.
>
>         I assume this means you agree that an offerer has to make sure
>         at least
>         one of the demuxing mechanisms it supports will be understood by the
>         answerer.
>
>
>     No. But the offerer had better ensure that there is some way to
>     answer that meets the requirements.
>
>     Then it becomes a requirement on the answerer to answer in a way
>     that makes the communication unambiguous. If it can't do that while
>     bundling then it must remove the bundle, or remove some m-lines from
>     the bundle, or reject some of the m-lines in the bundle, so that the
>     resullting answer constructs an unambiguous communication.
>
>     If the intent is to rely on "magic" then that can be achieved by
>     using fewer m-lines in the bundle, in a way that dumps more
>     streams/flows into the same m-line. So this is really only an issue
>     for plan A.
>
>              Thanks,
>              Paul
>