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

Cullen Jennings <> Thu, 06 June 2013 05:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3E2421F96FF for <>; Wed, 5 Jun 2013 22:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id urWTWBkFhQys for <>; Wed, 5 Jun 2013 22:41:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AF1F321F9690 for <>; Wed, 5 Jun 2013 22:41:48 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 56A7F22E259; Thu, 6 Jun 2013 01:41:38 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <>
In-Reply-To: <>
Date: Thu, 06 Jun 2013 12:41:41 +0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Paul Kyzivat <>
X-Mailer: Apple Mail (2.1503)
Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Jun 2013 05:41:54 -0000

On Jun 5, 2013, at 11:17 PM, Paul Kyzivat <> wrote:

>>  And it is likely to receive RTP packets before it receives an answer in some important scenarios.
> You keep saying that. But is it really true when ICE is used?
> Need it be true even without ICE? After all, bundle is new usage, so we can demand new behavior when using it. So requiring a reliable provisional with an answer before sending media doesn't seem so unreasonable.

I'm assuming that some applications will bring up a data channel (using ICE), as soon as the far end starts alerting the user so this will be done by the time the far end users agrees to send media. At that point it would be nice to start sending media with no clipping. That allows all the ICE setup time to disappear from the media clipping latency problem. 

I realize lots of applications will not work this way.