Re: [MMUSIC] Scope of RTP payload types in BUNDLE?

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 27 May 2013 19:28 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 14E6721F96D0 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 12:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.137
X-Spam-Level:
X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 V56OVVbvd8sj for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 12:27:59 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 334C721F96DD for <mmusic@ietf.org>; Mon, 27 May 2013 12:27:58 -0700 (PDT)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta14.westchester.pa.mail.comcast.net with comcast id h6AB1l00317dt5G5E7Tylc; Mon, 27 May 2013 19:27:58 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id h7Ty1l00A3ZTu2S3Z7TyWA; Mon, 27 May 2013 19:27:58 +0000
Message-ID: <51A3B3BD.4010004@alum.mit.edu>
Date: Mon, 27 May 2013 15:27:57 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <B7E3612F-241F-4119-A973-12D3F7DB36BC@csperkins.org> <51A3AAC3.9030905@alum.mit.edu> <6EC91C7A-E0EE-4A2C-BF86-E2864DF7A4F3@csperkins.org>
In-Reply-To: <6EC91C7A-E0EE-4A2C-BF86-E2864DF7A4F3@csperkins.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369682878; bh=UUueJzQSbgiVvNKLn/GE7TPtc6DSTGkUAhOtX5PpJus=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kXsHkSWn5SW+U7fjr6gMLhORxeakAeF5Yir/nc0IPIGM4IXnzXJM+8NrcuzfDr/PZ JiA6154UnLv2auF13hwzQhsAQa+dmA3r2mtBgb4bVMidOhk3zW9tSoNFdVWqEbPFSm cimiKEZ60etPFXpLzE03x4RTINLKRThru1irbHCa9AVhOAGX/DSfog3zdJwcgvytBz UpPOBCw25+zRGYpMVxQodbZ8+cJ2t+UKG/R8ZAP2gUXTU56vhw5dgUdk0PRjOG1vAf i1cXcABxVHdJpRhEnLivBD1dbX4immQY0mRDQrmtTPB4CkBRUqRlLSqU2FXZB7f/+V Xe4+ocKIOF+0w==
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
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: Mon, 27 May 2013 19:28:04 -0000

Colin,

On 5/27/13 3:08 PM, Colin Perkins wrote:
> On 27 May 2013, at 19:49, Paul Kyzivat wrote:
>> On 5/27/13 2:29 PM, Colin Perkins wrote:
>>> What would that other characteristic be? The only thing you have is the SSRC, and SDP doesn't scope "a=rtpmap:" lines to be per "a=ssrc:" line, and RTP certainly doesn't treat payload types as per SSRC.
>>
>> This is all part of defining the precise semantics of bundling!
>>
>> In the example I gave below, what I am suggesting is that:
>>
>> - SSRC 1111 is associated with m-line X, and SSRC 22222 is associated
>>   with m-line Y.
>>
>> - When a packet is received, it must first be associated with
>>   an m-line. If it has SSRC=1111 then it can be associated with
>>   m-line X. Then, m-line X gives the mapping of PT 96 to audio
>>   and AMR. If it has SSRC=2222 then it can be associated with
>>   m-line Y. Then, m-line Y gives the mapping of PT 96 to audio
>>   and G.7291. (If a packet with some other SSRC is received
>>   then the mapping to an m-line is unknown, unless we introduce
>>   some other rule.)
>>
>> - in some other example, if some PT is unique to a single m-line,
>>   then a packet with that PT can be associated to that m-line.
>>
>> Have I made myself clear yet?
>
>
> Yes, but I think that's the wrong approach.

I think what I am talking about can be tweaked to fit with what you are 
suggesting. (This is where my limited understanding of RTP causes me 
trouble.) I've been viewing B & C as a single black box. I've no problem 
with decomposing it.

> When an RTP or RTCP packet arrives it first needs to be associated with an RTP source (step B in the diagram in http://www.ietf.org/mail-archive/web/mmusic/current/msg11251.html). That RTP source then, if you care about such things, can be associated with an m= line (step C in the diagram).

OK. Based on the other things you have said, this seems fine.

> You can use some combination of the payload type and a=ssrc: lines to perform the mapping at step C. That's fine.

Then all the logic to bind the packet to an m-line can appear in step C.
I *think* it really only needs to be done once per SSRC, the first time 
the SSRC is seen. But maybe it can't be done by the first packet that 
arrives for that SSRC. (Certainly that may be so if the SSRC is first 
seen an an RTCP packet.)

> I'm arguing, however, that step B is important for RTP to work right, and that we can't just map to sources based on the payload type.

OK.

	Thanks,
	Paul