Re: [MMUSIC] Demultiplexing via indexes in RTCP SDES packets

worley@ariadne.com (Dale R. Worley) Tue, 07 May 2013 20:31 UTC

Return-Path: <worley@shell01.TheWorld.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 5B21421F92F5 for <mmusic@ietfa.amsl.com>; Tue, 7 May 2013 13:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.985
X-Spam-Level:
X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 qrym0b-KzzeS for <mmusic@ietfa.amsl.com>; Tue, 7 May 2013 13:31:12 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1A721F8E4C for <mmusic@ietf.org>; Tue, 7 May 2013 13:31:07 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r47KUIjj013722; Tue, 7 May 2013 16:30:20 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r47KUIEn4335890; Tue, 7 May 2013 16:30:18 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r47KUI534331379; Tue, 7 May 2013 16:30:18 -0400 (EDT)
Date: Tue, 7 May 2013 16:30:18 -0400 (EDT)
Message-Id: <201305072030.r47KUI534331379@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
In-reply-to: <517F7859.4060600@ericsson.com> (magnus.westerlund@ericsson.com)
References: <201304292159.r3TLxwMs3753609@shell01.TheWorld.com> <517F7859.4060600@ericsson.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Demultiplexing via indexes in RTCP SDES packets
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: Tue, 07 May 2013 20:31:22 -0000

> From: Magnus Westerlund <magnus.westerlund@ericsson.com>
> 
> I do agree that part of a solution is the possibility to bind one or a
> set of SSRCs to a particular usage that is signalled somehow. However,
> there is several different types of bindings that is needed here. Just
> binding to a m= line is likely short sighted, restrictive and incomplete.
> 
> I support your proposal of including a level of indirection enabling us
> to avoid having to update the SDP for any addition of SSRCs, which a
> a=ssrc based solution would require.
>
> However, SDP is not the only signalling solution, it is the currently
> dominating one, but if you ever is going enable us of breaking out of
> the SDP trap, we need to ensure that the solutions around are not SDP
> specific.
> [A lot of examples of additional "binding" information that is
> needed.]

What you say is true, but those aren't the problems I'm looking at.
My assumption is that any problem that needs to be solved will be
solved (by somebody else) in a way that is workable in "SDP without
bundling".

Once that has been solved, then how do you solve the problem in a way
that is workable in "SDP with bundling"?

The latter is the part of the problem I'm looking to solve.  It breaks
into two parts:  One part is the particular way bundling is signaled
in SDP.

The other part is the way that the RTP/RTCP over the bundled
connection is demultiplexed.  At this layer of analysis, all that is
needed is to be able to sort the RTP and RTCP regarding which m= line
it is associated with.

The remaining parts of the SDP provide the other binding information
that you discuss -- once the RTP is associated with the correct m=
line, the problem is reduced to what the problem would be without
bundling.

Of course, if the signaling protocol isn't SDP, the demultiplexing I'm
considering does not apply.  But in that case, "bundling" as such
isn't a consideration, because "bundling" is essentially how to use
only one transport association to carry all of the packets described
by an SDP description.  Presumably any newer and better signaling
protocol would be designed to not have the limitations of the existing
SDP, and so the bundling problem would be taken care of from the
beginnin.

> I think one important question here is if you really want and think it
> is possible to bind have each different usage or purpose for an RTP
> media stream (specific SSRC) can be captured with its own unique Media
> Description (m= block)?

I've previously believed that media sources can be separated into a
small number of "roles"; that any application intrinsically defines a
(very) small number of roles; and that the multiple SSRCs for the
multiple media sources that all have the same role can all be sent
under one SDP m= line without confusion.

But it appears that the above belief is not true, so I'm considering a
different demultiplexing algorithm, one that does not require distinct
payload type numbers for different m= lines (and thus can support a
large number of m= lines and a large number of payload type numbers
for each m= line).

A fundamental problem with this sort of demultiplexing is how to do it
without putting a prefix or encapsulation on every RTP packet (as that
makes it harder for intermediate devices to see the nature of the
contained data).  But we can do indirection, following the SSRC from
the RTP packet to information carried in the corresponding RTCP.

Dale