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

Colin Perkins <csp@csperkins.org> Mon, 27 May 2013 19:09 UTC

Return-Path: <csp@csperkins.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 4E69721F96C7 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 12:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.179
X-Spam-Level:
X-Spam-Status: No, score=-106.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 BQ-x74LwwsyV for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 12:08:57 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id A558C21F93EB for <mmusic@ietf.org>; Mon, 27 May 2013 12:08:57 -0700 (PDT)
Received: from [81.187.2.149] (port=37890 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1Uh2mu-0004pA-5F; Mon, 27 May 2013 20:08:57 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <51A3AAC3.9030905@alum.mit.edu>
Date: Mon, 27 May 2013 20:08:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EC91C7A-E0EE-4A2C-BF86-E2864DF7A4F3@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>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
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:09:02 -0000

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. 

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

You can use some combination of the payload type and a=ssrc: lines to perform the mapping at step C. That's fine. 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.

-- 
Colin Perkins
http://csperkins.org/