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

Kevin Dempsey <kevindempsey70@gmail.com> Fri, 24 May 2013 09:03 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 25DD721F9681 for <mmusic@ietfa.amsl.com>; Fri, 24 May 2013 02:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 C4SIJEQfChNc for <mmusic@ietfa.amsl.com>; Fri, 24 May 2013 02:02:59 -0700 (PDT)
Received: from mail-la0-x243.google.com (mail-la0-x243.google.com [IPv6:2a00:1450:4010:c03::243]) by ietfa.amsl.com (Postfix) with ESMTP id 324E821F968D for <mmusic@ietf.org>; Fri, 24 May 2013 02:02:56 -0700 (PDT)
Received: by mail-la0-f67.google.com with SMTP id fq12so1083459lab.6 for <mmusic@ietf.org>; Fri, 24 May 2013 02:02:55 -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=v0bcmk8aYoFaCKgjydPxpHBezfhvn+RjDvz7b5In7gw=; b=NgJqzvmwSAbmwboe8DlX5VkeGM8owUyNdJGbfhj/8iFd85UNY6c3qHpTsQTvVuvaBF 62f7fPXpk4aHPlyfay9v1K2w9tWpmaZt1jZTDYJpTxQ+Aq9tk3QCnzoZb0pa6NSw2QvT rPGAuv0OSgcqPaXyuSo8VF313jJ0dQJN5MSHmOqt9JksyxbI5qDBGlBRh/0oPpAAgsu6 mIGpfJPBgWLHibdz8o2aH5gc6XdZlonMlajg+QoI9giSFNRRp1lzE3ZWKSfRrPcq6WLM 4/4c+cw0tcbutIHCW7k4NUjWVy5m/MTP5ltZJvbk66Oj/qvt4CtY1GSlagpGjIE9A4os KdSQ==
MIME-Version: 1.0
X-Received: by 10.112.6.6 with SMTP id w6mr8314292lbw.123.1369386175802; Fri, 24 May 2013 02:02:55 -0700 (PDT)
Received: by 10.114.0.139 with HTTP; Fri, 24 May 2013 02:02:55 -0700 (PDT)
In-Reply-To: <519F2BD8.8060803@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>
Date: Fri, 24 May 2013 10:02:55 +0100
Message-ID: <CAMvTgcfx1t0d-NEavTxdq=9FEH9Z-wjX2S+HcSimFUgzg5-58g@mail.gmail.com>
From: Kevin Dempsey <kevindempsey70@gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: multipart/alternative; boundary=14dae93d973691b3d304dd7310ce
Cc: mmusic <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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 09:03:00 -0000

I didn't say anything about changing the PTs. 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.


On 24 May 2013 09:59, Emil Ivov <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>> 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>
> >     https://www.ietf.org/mailman/listinfo/mmusic
> >
> >
>
> --
> https://jitsi.org
>