Re: [MMUSIC] Associating packets with m-lines in a bundle

Colin Perkins <csp@csperkins.org> Tue, 28 May 2013 10:11 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 16BE921F91B8 for <mmusic@ietfa.amsl.com>; Tue, 28 May 2013 03:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.999
X-Spam-Level:
X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 NWD4wr2t4SOK for <mmusic@ietfa.amsl.com>; Tue, 28 May 2013 03:11:30 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id BA99521F85BF for <mmusic@ietf.org>; Tue, 28 May 2013 03:11:29 -0700 (PDT)
Received: from [130.209.247.112] (port=56627 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 1UhGsC-0004Ef-Rq; Tue, 28 May 2013 11:11:23 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <BLU169-W5F02AED8725E7A1D94E4D93970@phx.gbl>
Date: Tue, 28 May 2013 11:11:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <77D67F21-E702-448C-9E67-DB59C9A5E0F9@csperkins.org>
References: <519E5F54.3000806@alum.mit.edu> <BLU403-EAS11291D50BCA39955DE3C9C393940@phx.gbl> <51A381E2.9040203@alum.mit.edu>, <DC56B228-927A-4ADB-B366-0CC739416CE2@csperkins.org> <BLU169-W5F02AED8725E7A1D94E4D93970@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: IETF MMUSIC WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Associating packets with m-lines in a 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: Tue, 28 May 2013 10:11:35 -0000

On 28 May 2013, at 01:10, Bernard Aboba wrote:
> Colin Perkins said: 
>> RTCP operates at a different level, so it's not clear why it needs to be bound to an m= line. Use the SSRC to group related RTP and RTCP packets according to source, and match them to a de-jitter buffer and the state for RTCP processing. Use the PT to match those sources with the payload format, m= line and the corresponding decoding and rendering context.
> 
> [BA] I believe that the stats API requires the mapping of received RTCP packets to a peerConnection object.   Without BUNDLE, there is no issue.  With BUNDLE and without a=ssrc lines, it is possible to receive RTCP RRs from SSRCs that have not yet sent packets, so that it wouldn't be possible yet to group the RTCP and RTP packets according to source and match those sources with the PT and payload format.  So if you had more than one peerConnection object, it might not be clear which object the RTCP packet related to. 

Agreed. 

> Colin also said: 
>> Match the RTCP to the RTP based on the SSRC, and process it. There is no need to discard the RTCP in this case.
> 
> [BA] What if no RTP has been received from that SSRC, but an RTCP RR arrives?  This is the case I was referring to.   I agree that there is no need to discard the RTCP assuming that an RTP packet from that SSRC arrives first, permitting a mapping of SSRC to PT, corresponding m line and peerConnection object.

Unless you've signalled SSRC values, you won't be able to map an RTCP packet that arrives before the corresponding RTP packet onto an m= line and peerConnection object. However, you'd know that the SSRC of the RTCP packet existed, and is to be avoided for collisions, and you could begin to setup some RTP layer state in the receiver. You'd also mention the SSRC of the RTCP packet in the RTCP RR packets you send (this can be a useful diagnostic if the other side is actually sending RTP, but you're not receiving it for some reason; it's one of the conditions the circuit breaker algorithm checks to detect some types of path failure). 

In summary, you might not be able to make an RTCP packet that arrives before the corresponding RTP packet available to the higher layers of your application (depending on what was signalled), but there is useful processing that can be done with that packet when it's received, and it shouldn't be discarded. 

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