Re: [MMUSIC] Proposal for what bundle should say about demux
Emil Ivov <emcho@jitsi.org> Fri, 24 May 2013 14:40 UTC
Return-Path: <emcho@sip-communicator.org>
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 C6A1521F90AC for <mmusic@ietfa.amsl.com>; Fri, 24 May 2013 07:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 TrHgV3Laix9I for <mmusic@ietfa.amsl.com>; Fri, 24 May 2013 07:40:26 -0700 (PDT)
Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id DA13221F8624 for <mmusic@ietf.org>; Fri, 24 May 2013 07:40:26 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa10so4345463pad.5 for <mmusic@ietf.org>; Fri, 24 May 2013 07:40:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=r2n1yeoh1Dmd2XMZRfZNRs/nV6DhtA8aCB9m1lsqZfM=; b=H9Nfhs7zhgnQeP1JxKvMA3sE0YG49sm3aFPmYSWIvofzBi+2n1BiPHoy2RQ6zl38DQ v7TseuRPbeBZcRmz2DH+bbekc9p1iHNjlzAlnruaN3Zs2AOLxBTF7AEB4/gBq+yGopTO HKb7mvakYohLSxaY517wMX8di5+WyCeroD7lNBYRBaepGQ84fnPgr8RhwsHkKkRmT1A/ Qs6+bL+oEdrBrmzSUfSq9dWfsOv8nvK2rvi1kC0wK1KbSu33FkY9doeoHXKYpOVxiMf+ cd0DPvzfFr/oEHR4goGePaF+o1VuiyIUNjYPI69Fote3WxW4jWpHD45OVbcl+W+XNAyt OtYw==
X-Received: by 10.68.197.195 with SMTP id iw3mr17977507pbc.177.1369406426396; Fri, 24 May 2013 07:40:26 -0700 (PDT)
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by mx.google.com with ESMTPSA id cc15sm17750167pac.1.2013.05.24.07.40.25 for <mmusic@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 07:40:26 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id 10so4228393pdi.17 for <mmusic@ietf.org>; Fri, 24 May 2013 07:40:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.221.201 with SMTP id qg9mr9529350pbc.87.1369406425514; Fri, 24 May 2013 07:40:25 -0700 (PDT)
Received: by 10.66.89.234 with HTTP; Fri, 24 May 2013 07:40:25 -0700 (PDT)
Received: by 10.66.89.234 with HTTP; Fri, 24 May 2013 07:40:25 -0700 (PDT)
In-Reply-To: <519F7633.1010902@alum.mit.edu>
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>
Date: Fri, 24 May 2013 17:40:25 +0300
Message-ID: <CAPvvaaKMbee43bWf95iv-FgHZGaC5AWiydpuSh4Tgs122hcTtA@mail.gmail.com>
From: Emil Ivov <emcho@jitsi.org>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="e89a8ff243378be59004dd77c7f0"
X-Gm-Message-State: ALoCoQnPBEs3cliklcIBas/7lijpIrJ9bjCrhYXUGHSdS548QU+J/1SN2DHOgbd71TMGLz8SgzQg
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 14:40:44 -0000
On May 24, 2013 5:16 PM, "Paul Kyzivat" <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. Emil --sent from my mobile > > If the combination of the offer and answer aren't sufficient for each side to encode what it sends in a way that it knows can be demuxed according in accord with the O/A, then that offer should be incorrect. > > IMO injecting "magic" into this isn't helpful. > > Thanks, > Paul > > >> Cheers, >> Emil >> >> >>> >>> >>> On 24 May 2013 09:59, Emil Ivov <emcho@jitsi.org >>> <mailto:emcho@jitsi.org>> wrote: >>> >>> On 24.05.13, 11:40, Kevin Dempsey wrote: >>> > Isn't the onus on the answerer to ensure the demux is possible, >>> since it >>> > is accepting the bundle. Therefore if it doesn't support signalling >>> > SSRCs or an offerred 'fancy-RFC m-line matching' method, it must only >>> > send PTs that are tied to a single m-line. >>> >>> PTs are defined by the offerer. The answerer cannot change them for the >>> offerer-bound direction (even if it could request different values for >>> the packets that it, the answerer, is going to receive). >>> >>> Emil >>> >>> >>> > >>> > >>> > On 24 May 2013 08:17, Emil Ivov <emcho@jitsi.org >>> <mailto:emcho@jitsi.org> >>> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote: >>> > >>> > On 24.05.13, 00:59, Paul Kyzivat wrote: >>> > > IMO the "before the O/A completes" issues are separate from >>> the "after >>> > > the O/A completes" issues. I'm still not convinced that the >>> > "before the >>> > > O/A completes" issues are important. (We have reliable 183 >>> > responses to >>> > > deal with it.) But I'm ok with Cullen using PT to solve that >>> > problem if >>> > > he thinks he needs to. >>> > >>> > I wasn't referring to "before the O/A completes" situations. >>> If your >>> > peer does not support fancy-RFC m-line matching nor does it >>> provide >>> > SSRCs, you have to be able to fall back to PT demuxing. >>> > >>> > Therefore, all your offers have to accommodate for that >>> possibility >>> > unless you know that the offer is going to someone who also >>> supports >>> > other mechanisms. >>> > >>> > Emil >>> > >>> > -- >>> > https://jitsi.org >>> > _______________________________________________ >>> > mmusic mailing list >>> > mmusic@ietf.org <mailto:mmusic@ietf.org> >>> <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>> >>> > https://www.ietf.org/mailman/listinfo/mmusic >>> > >>> > >>> >>> -- >>> https://jitsi.org >>> >>> >> >
- [MMUSIC] Proposal for what bundle should say abou… Cullen Jennings (fluffy)
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Emil Ivov
- Re: [MMUSIC] Proposal for what bundle should say … Martin Thomson
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Mo Zanaty (mzanaty)
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Dale R. Worley
- Re: [MMUSIC] Proposal for what bundle should say … Cullen Jennings (fluffy)
- Re: [MMUSIC] Proposal for what bundle should say … Martin Thomson
- Re: [MMUSIC] Proposal for what bundle should say … Emil Ivov
- Re: [MMUSIC] Proposal for what bundle should say … Emil Ivov
- Re: [MMUSIC] Proposal for what bundle should say … Kevin Dempsey
- Re: [MMUSIC] Proposal for what bundle should say … Emil Ivov
- Re: [MMUSIC] Proposal for what bundle should say … Kevin Dempsey
- Re: [MMUSIC] Proposal for what bundle should say … Emil Ivov
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Emil Ivov
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Emil Ivov
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Colin Perkins
- Re: [MMUSIC] Proposal for what bundle should say … Christer Holmberg
- Re: [MMUSIC] Proposal for what bundle should say … Cullen Jennings (fluffy)
- Re: [MMUSIC] Proposal for what bundle should say … Cullen Jennings (fluffy)
- Re: [MMUSIC] Proposal for what bundle should say … Colin Perkins
- Re: [MMUSIC] Proposal for what bundle should say … Colin Perkins
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Colin Perkins
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Colin Perkins
- Re: [MMUSIC] Proposal for what bundle should say … Paul Kyzivat
- Re: [MMUSIC] Proposal for what bundle should say … Mary Barnes
- Re: [MMUSIC] Proposal for what bundle should say … Cullen Jennings (fluffy)
- Re: [MMUSIC] Proposal for what bundle should say … Colin Perkins
- Re: [MMUSIC] Proposal for what bundle should say … Cullen Jennings