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

Cullen Jennings <fluffy@iii.ca> Wed, 05 June 2013 00:02 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 79D1421F9A3A for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level:
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1]
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 t+pRWi049eTn for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:02:07 -0700 (PDT)
Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 2129D21F9A2B for <mmusic@ietf.org>; Tue, 4 Jun 2013 17:01:59 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id D76302FD7CD for <mmusic@ietf.org>; Tue, 4 Jun 2013 20:01:54 -0400 (EDT)
Received: from [10.70.232.182] (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 5F17A22E256; Tue, 4 Jun 2013 20:01:51 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <51A39023.1070605@alum.mit.edu>
Date: Mon, 3 Jun 2013 16:51:19 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1503)
Cc: 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 00:02:19 -0000

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

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. 

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. 

I've see more than one system that have stuffed that identifier in the existing CSRC field which is sort of an awful hack and sort of very cool.