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

Cullen Jennings <fluffy@iii.ca> Thu, 06 June 2013 05:41 UTC

Return-Path: <fluffy@iii.ca>
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 66C3521F84FD for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 22:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
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 2-xu5-AieMHs for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 22:41:28 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A3EAB21F9651 for <mmusic@ietf.org>; Wed, 5 Jun 2013 22:41:28 -0700 (PDT)
Received: from [10.70.233.131] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6BAFA22E256; Thu, 6 Jun 2013 01:41:25 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <BLU169-W137A3F08AC59282322B66A9939F0@phx.gbl>
Date: Thu, 6 Jun 2013 12:41:28 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <92D69433-78A7-4E90-8088-C8AAD10FB31D@iii.ca>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca> <BLU169-W137A3F08AC59282322B66A9939F0@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1503)
Cc: "mmusic@ietf.org" <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: Thu, 06 Jun 2013 05:41:42 -0000

inline but I agree


On Jun 5, 2013, at 9:09 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> Cullen said: 
> 
> > Imagine Alice sends an offer containing 
> > 
> > On May 27, 2013, at 10:56 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> > 
> > > m=audio 49172 RTP/AVP 96
> > > a=ssrc:2222 cname:alice@example.com
> > > a=rtpmap:96 G7291/16000
> > 
> > Let say that an offer sent like the above. That means nothing about the SSRC for the packets that Alice will receive. And it is likely to receive RTP packets before it receives an answer in some important scenarios. 
> > 
> > So a RTP packet SSRC 3333 arrives. There's no information from the SSRC about what m-line it matches too (but RTCP for it can be sent). 
>  
> [BA] Yes, there is no SSRC info but you do have the PT.  Assuming that the RTP packet has a PT of 96 and that PT value is unique among all m lines (with BUNDLE), then you know what m line the RTP packet is referring to, and that it represents an audio packet. 

yes - so for the layer C or sorting out the which m-line it goes to, I like the PT if it's unique and if you need more than that then PT + SSRC info you know. 

> 
> > Now an answer from Bob arrives with 
> > 
> > m=audio 55555 RTP/AVP 96
> > a=ssrc:4444 cname:bob@example.com
> > a=rtpmap:96 G7291/16000
> > 
> > Now a packet with SSRC 4444 arrives. That might be from Bob, but here's the rub. It might be from Charlie. If there was an SSRC collisions between Bob and Charlie, it will be awhile before some SDP shows up that says that there was a collisions and now Bob is using SSRC 5555. 
>  
> [BA] I understand why this can happen if Bob is an RTP translator, but if Bob is another browser, why would packets from Charlie be received on a peerConnection between Alice and Bob? 

agree - I should have said it but I was thanking about the hangout type situation with perhaps 1000s of clients

> 
> > This is all a disaster and the best solutions to it IMHO would be to define a new RTP Header extension that carries and identifier and that Alice can tell Bob in the SDP offer what value to put in the identifier for the RTP from Bob to Alice. 
>  
> [BA]  RTP extensions are optional, so even if you define one, you've got to be prepared to handle SSRCs that aren't pre-declared anyway, at least according to the RTP usage document. 

agree