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

Emil Ivov <emcho@jitsi.org> Thu, 23 May 2013 21:35 UTC

Return-Path: <emil@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 C40EB21F95C4 for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 14:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level:
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599]
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 gsbYXVVqeEBy for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 14:34:58 -0700 (PDT)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 35E8321F8618 for <mmusic@ietf.org>; Thu, 23 May 2013 13:49:45 -0700 (PDT)
Received: by mail-bk0-f43.google.com with SMTP id jm2so509463bkc.30 for <mmusic@ietf.org>; Thu, 23 May 2013 13:49:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=mr2Lmd8EEAT/EITCa9Hx8H+zu1NnAt5NaXUDDA+LbTI=; b=TYG7LsQWg+aH1Af5h9r3oc8mjlsS9IUqaD9XK62Rq5yp1ztFX9+JViRVYp0IBOP76m UoiQVoKoU0CvsgSkwSqocemBcE3/pL5kerEKrILqWqUKAbOeHBZOHve72+I0Y+eijP5i wlIblHe8dj0L04QA9gA6A71Dec6k9WDptaGlJUY0GleZfngXlx4+vmYut+YrRr5uoyHk PmQ1FumpXDH+pvHgkksUoZmo92TTF8bF5TyAMzR85eTuWI09rqCRj2o0hgRZxulLWzDt XZd7MCyFi9GNhMzZQauCgonZHgxcJ7emIHIAMa6sf9GCZf6PAZ3yBSkYxGfaYUOAMKw9 lWmw==
X-Received: by 10.204.200.139 with SMTP id ew11mr7882859bkb.70.1369342184987; Thu, 23 May 2013 13:49:44 -0700 (PDT)
Received: from [192.168.43.3] ([212.5.158.176]) by mx.google.com with ESMTPSA id es13sm3747318bkc.8.2013.05.23.13.49.42 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 13:49:44 -0700 (PDT)
Message-ID: <519E80E4.6010904@jitsi.org>
Date: Thu, 23 May 2013 23:49:40 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlw/voLHSyrj9xWpjjlO3ZjUIshLEwDE7GNto/f6spy2HubPC40nBQNYP2XY78gNcKjjC2M
Cc: mmusic WG <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: Thu, 23 May 2013 21:35:09 -0000

Hey all,

So first of all, I'd like to say that I like the approach and think this
is the way to go.

I have just one concern here. I already mentioned it in the call but I
am not quite sure what the answer was. So here I go:

On 23.05.13, 21:02, Cullen Jennings (fluffy) wrote:
> 
> Here's is my proposal for roughly what the bundle draft should say about this demux topic 
> 
> Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows:
> 
> 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping 

So my problem with having the above as number one is that while it would
work perfectly with protocols like XMPP that have good discovery
support, it would be a problem for SDP O/A based ones like SIP and WebRTC.

The reason is that even when demuxing RFCs like that exist, an offerer
won't know if the remote party supports them. They would hence always
need to construct an offer where a fallback to another mechanism could
be possible (like for example falling back to uniquely allocated PTs).

Now, if the offerer does indeed know in advance that the fancy demuxing
RFC will be supported, and only then, they would be able to rely on it
and be careless about PT allocation.

I believe we've built bundle port allocation and trickle ICE (and a
number of other O/A mechanisms) around the same model.

Emil


-- 
https://jitsi.org