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

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 05 June 2013 02:10 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 08FC921F96FE for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 19:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.574
X-Spam-Level:
X-Spam-Status: No, score=-101.574 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 2lhVs34eF3Ly for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 19:10:33 -0700 (PDT)
Received: from blu0-omc3-s9.blu0.hotmail.com (blu0-omc3-s9.blu0.hotmail.com [65.55.116.84]) by ietfa.amsl.com (Postfix) with ESMTP id 32CCC21F93E0 for <mmusic@ietf.org>; Tue, 4 Jun 2013 19:10:33 -0700 (PDT)
Received: from BLU169-W137 ([65.55.116.72]) by blu0-omc3-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jun 2013 19:09:34 -0700
X-TMN: [4SZh+N3ixlqv+0HDHzqIc0E4aqbhiCow7p3O/TloOT0=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W137A3F08AC59282322B66A9939F0@phx.gbl>
Content-Type: multipart/alternative; boundary="_d7fce800-06cb-4036-af6c-bdf6e1ce9114_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Date: Tue, 4 Jun 2013 19:09:33 -0700
Importance: Normal
In-Reply-To: <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Jun 2013 02:09:34.0074 (UTC) FILETIME=[B8E8CDA0:01CE6191]
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: Wed, 05 Jun 2013 02:10:45 -0000

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. 

> 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? 

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