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

Paul Kyzivat <> Fri, 07 June 2013 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90C3821F96FB for <>; Fri, 7 Jun 2013 09:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.377
X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iDz-ClWc5UWJ for <>; Fri, 7 Jun 2013 09:39:56 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:211]) by (Postfix) with ESMTP id BF2C021F965B for <>; Fri, 7 Jun 2013 09:39:47 -0700 (PDT)
Received: from ([]) by with comcast id lPFm1l0040EZKEL5BUfmhd; Fri, 07 Jun 2013 16:39:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id lUfm1l00A3ZTu2S3MUfmvu; Fri, 07 Jun 2013 16:39:46 +0000
Message-ID: <>
Date: Fri, 07 Jun 2013 12:39:45 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Cullen Jennings <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1370623186; bh=Dey51hnbKefs1OPIHPJhbugFcpjPuPjBsSqSw/RgLik=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CPNoBy5QNSwZmBQKJm7x1cT5x4apJ33x7F0Cflr8wtNIJJFtkfApPQYeJGA/pgxt5 B9W1HzTbBq5jEnT/5MmKLLW9OcNdneeXd464OJcy42JHaTXRIx5Czn7fQKz2/eQm2h dPtUfypU35FPt5Z487N2+M7iN6DjK0e5fyHzjDrY5PvbBMJ+WxuTxbdxAMDjQKUEJY 5i2UB9ozZDEQ17mXOwbndSyoQfDLoy6MTR5RUV/ZoHvtHDgYZYkpl8MT+Lsf/ofgud flwJ08CPR6nAZVVquP/gXU+fDleztUwxzR2Wu4MKnLnAGaF+azZdNhB7HU1DnC645K Jhswzehs5qARA==
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: Fri, 07 Jun 2013 16:40:08 -0000

On 6/6/13 1:41 AM, Cullen Jennings wrote:
> 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.

We're mixing apples and oranges here I think.

In a pure sip environment there probably won't be a data channel, except 
for CLUE. But perhaps CLUE is what we should be considering when we are 
talking about bundle in a pure sip environment.

Even webrtc won't always be using a data channel.

In cases where there is a data channel, I don't know how much data will 
be exchanged over it before the "alerting" is done and the connection 
acknowledged. I certainly want that to be very constrained. So I'm not 
sure what the relevance of the data channel is to this discussion.

Reliable provisionals only apply when SIP is involved, on at least half 
of the call. But it doesn't matter, because for RTCWEB the equivalent 
thing exists - simply sending an answer early on. Once that has 
happened, the UAC can know what SSRCs to expect from the other end and 
use that as part of the process of associating packets with m-lines.

So my question is still: is it unreasonable to expect an answer to be 
returned and confirmed before the UAS starts sending media? This can 
happen as early as the commencement of alerting at the UAS. That means 
requiring 1.5 round trips over the signaling channel before starting to 
send. It will very likely require more round trips than that over the 
media channel (because of ICE) before media can flow in any case.

Also, until the UAC receives an answer it can't do ICE. So when ICE is 
in use aren't you guaranteed to have had a chance to get those SSRCs 
from the UAS?