Re: [rtcweb] Plan A, respun

Colin Perkins <csp@csperkins.org> Mon, 13 May 2013 16:25 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F0B21F8E97 for <rtcweb@ietfa.amsl.com>; Mon, 13 May 2013 09:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KXF-oPuSHibs for <rtcweb@ietfa.amsl.com>; Mon, 13 May 2013 09:25:18 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2088221F8E7B for <rtcweb@ietf.org>; Mon, 13 May 2013 09:25:14 -0700 (PDT)
Received: from [130.209.247.112] (port=64999 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1UbvYj-00034Q-HS; Mon, 13 May 2013 17:25:12 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0CEB0C55-5944-4575-96EB-DC5FC0143327"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <BLU169-W136923A11448EE25CE64E9D93A00@phx.gbl>
Date: Mon, 13 May 2013 17:25:08 +0100
Message-Id: <5A28748F-AD55-4D8F-8960-B14C9423AF1D@csperkins.org>
References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no>, <A8F1D4FD-E7A3-4CCD-896E-CBD56ECB12FA@iii.ca>, <E34407D9-4BBE-44ED-8BB8-C18E1E02ACB3@csperkins.org> <BLU169-W136923A11448EE25CE64E9D93A00@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Plan A, respun
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2013 16:25:31 -0000

On 13 May 2013, at 17:20, Bernard Aboba wrote:

> Colin said: 
> 
> The RTP demultiplexing process, as I always understood it, was to look at the SSRC first, and based on that find your SRTP context, jitter buffer, RTCP state, etc., which are all indexed by SSRC. Then, look at the PT to determine what codec to use for the stream (noting that SSRCs can switch between PT values, and multiple SSRCs can use the same PT). Using the PT as the de-mux point for streams doesn't let you find the appropriate RTCP state or SRTP context, since those are indexed by SSRC, and requires you to use unique PT values for each stream, which is a much more limited space than the SSRC space (and, unlike the SSRC space, has no collision resolution built-in). 
> 
> [BA]  That is typically how I've seen it done, yes.  
> 
> Colin also said: 
> 
> I'm confused about what you mean by using a combination of SSRC and PT demux. You can't have two distinct SSRCs using the same PT values in a single RTP session, because you can't distinguish the RTCP packets for the two SSRCs, and we mandated the use of RTCP. 
> 
> [BA]  The statement above seems inconsistent with the earlier statement that "multiple SSRCs can use the same PT".  Or did you mean having multiple SSRCs, each using multiple PT values?  

Sorry, what I meant to say was that you can't do this while demuxing based on the PT, because you can't distinguish RTCP packets. You need to use the SSRC for demuxing. 

> Since the RTCP packets include the SSRC (but not the PT), distinguishing the RTCP packets by SSRC isn't a problem. I have seen multiple SSRCs use the same PT within an RTP session to enable several scenarios.  This includes RTP stream demux (e.g. the objective of "Plan B"), as well as simulcast and layered coding.  In the simulcast/layered coding case there are issues with understanding which RTP streams go together purely at the RTP level (e.g. adding this info to an SDES packet would be helpful), but it doesn't seem to cause problems for de-muxing. 

Agree.

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