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
>>>
>>>
>>
>