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>
Cc: IETF MMUSIC WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Associating packets with m-lines in a bundle
Precedence: list

On 28 May 2013, at 01:10, Bernard Aboba wrote:
> Colin Perkins said:=20
>> RTCP operates at a different level, so it's not clear why it needs to =
be bound to an m=3D 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=3D line and the corresponding decoding and =
rendering context.
>=20
> [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=3Dssrc 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.=20

Agreed.=20

> Colin also said:=20
>> Match the RTCP to the RTP based on the SSRC, and process it. There is =
no need to discard the RTCP in this case.
>=20
> [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=3D =
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).=20=


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.=20

--=20
Colin Perkins
http://csperkins.org/