[MMUSIC] Proposal for what bundle should say about demux

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Thu, 23 May 2013 18:23 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8E2DF21F9705 for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 11:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.556
X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zeyOkzmr0WhS for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 11:22:57 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6EB5D21F84F5 for <mmusic@ietf.org>; Thu, 23 May 2013 11:03:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1325; q=dns/txt; s=iport; t=1369332189; x=1370541789; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=AthhxXYEsBoryLBTCsniJrHAXitOqW0PmYiDDuUecDU=; b=EXL+ykmFg4JIJFPFrslpv3sFot9sOhBALJ3PGw3g6P+N6u9S3haDiJUX 9SoxSlSJ82lD8KhI3AMx62ZEXgrEUxZYLT9tJzmbjHeqIAZbSFSDM6Bpl mLmG5faunDSUpjggzDbqvNomVP0JSYlrPMv5GC+sr4TBQ1hlotrXzr9It Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAH1ZnlGtJXG9/2dsb2JhbABZgwjCW4ELFnSCJQEEOlEBKhRCJwQbiAWaEKAujmyDK2EDk2qVEYMPgiY
X-IronPort-AV: E=Sophos;i="4.87,729,1363132800"; d="scan'208";a="214263398"
Received: from rcdn-core2-2.cisco.com ([]) by rcdn-iport-6.cisco.com with ESMTP; 23 May 2013 18:03:01 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com []) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4NI31MY008424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Thu, 23 May 2013 18:03:01 GMT
Received: from xmb-aln-x02.cisco.com ([]) by xhc-aln-x13.cisco.com ([]) with mapi id 14.02.0318.004; Thu, 23 May 2013 13:03:00 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: mmusic WG <mmusic@ietf.org>
Thread-Topic: Proposal for what bundle should say about demux
Thread-Index: AQHOV9/DVjr8src5NEuGXcSJwmehbA==
Date: Thu, 23 May 2013 18:02:37 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7A7C3CE1291E044884E1E0D0B7101FA4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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 18:23:23 -0000

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 

2) If the PT type is uniquely identifies a mapping, use that to form the mapping

3) If application knows the SSRC the other side will use, use that to form the mapping 

4) if there is no way to know which pipeline to pass it too, the packet MAY be discarded or the application MAY decide to buffer it until the mapping is known 

This is trivial to implement. It meets the requirements for Plan A, Plan B, UCIF, CLUE, and so on. 

We could swap the order of step 2 and 3, My thinking for this order was the only time it made any difference the order was if the PT were unique and indicated a different mapping than the SSRC. The only way this could happen is with a SSRC collision so the PT is the one that would be correct not the SSRC. If someone feels strongly the order of steps 2 and 3 should be the opposite way around, I can live with that.