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

Paul Kyzivat <> Fri, 07 June 2013 23:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C752B21F99A9 for <>; Fri, 7 Jun 2013 16:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, 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 u9-Jg49Dz7A8 for <>; Fri, 7 Jun 2013 16:15:37 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:56]) by (Postfix) with ESMTP id E967B21F9936 for <>; Fri, 7 Jun 2013 16:15:36 -0700 (PDT)
Received: from ([]) by with comcast id lbDr1l0031vXlb856bFbfG; Fri, 07 Jun 2013 23:15:35 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id lbFb1l00i3ZTu2S3dbFbDg; Fri, 07 Jun 2013 23:15:35 +0000
Message-ID: <>
Date: Fri, 07 Jun 2013 19:15:34 -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: Bernard Aboba <>
References: <>, <>, <>, <>, <>, <> <BLU169-W683BD404A78C1DD8E2B0D593990@phx.gbl>
In-Reply-To: <BLU169-W683BD404A78C1DD8E2B0D593990@phx.gbl>
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=1370646935; bh=JDx6KOzSD35i7o04U2akRelQNSRdLiZc0LAnY33Q9FM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hCiUZ5w5OmBpXbG0kxbg10kmczfDPWzMhPD55JJmdCxcCJIfeMwp2QgUUpfifUymz 4ky/sT8bryr6VgLhUSzM81hwHBFvfswThXjDN+2M+bcNoWwAxsm3FvSInMPK0unfor +e365hv2ieViae33Tbr5qajP2sg8ls5+F2Zrc+xY58pfYPCiu6//kgoeQL2C5bDVmx elNHiSLmIPbYG6LjrkAhosTnpkH08yLfaXtvmRHysjVFL1OxNofWlvE3+RK2jhS61I pOx9hC0v1prqK/Cb3gE4mzC25I4lzgPMkBG36MweEWpq2Nn6P1d/mJH1n9RAu3gJ41 otVsrhGlI9XnA==
Cc: "" <>
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 23:15:41 -0000

On 6/7/13 6:51 PM, Bernard Aboba wrote:
> Paul said:
>  > 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?
> [BA] I think we need to distinguish the browser-browser use case from
> browser-gateway.  By "can't do ICE" you mean "can't start connectivity
> checks".  However, connectivity checks only restrict the ability to
> send, not receive.  In the browser-browser use case, this should
> restrict either side from sending until the Answer is received.
> However, in the browser-gateway case the gateway may only support ICE
> lite, so it will not send connectivity checks, only respond to them.  As
> a result, the gateway can send media once it receives the Offer; it is
> not restricted from doing so by having to send and receive a response to
> a connectivity check.  Of course, it will not have media to send until
> it actually gets some, but in the event that it receives early media, it
> does seem possible that it could forward that media on to the browser
> before the Answer were to arrive.
> I guess the question is how much we care about preventing clipping in a
> case like this.  Note that Section 4.3.2 of the use case document does
> hint at this, although it (and the requirements) don't explicitly point
> to a need to support of "early media".

There is a big difference between clipping for one second until the 183 
is received, and clipping until the phone is answered and a 200 received.

But I was suggesting that we couple a requirement for PRACK with BUNDLE, 
and say that media should not be sent until the PRACK is received. So 
then there won't be clipping at all.

(According to a formal definition of clipping. In practice it doesn't 
matter whether the audio was dropped by the receiver or dropped by the 


> <>.
> Description
> Alice uses her web browser with a service something like Skype to be
> able to phone PSTN numbers. Alice calls 1-800-gofedex. Alice should be
> able to hear the initial prompts from the fedex IVR and when the IVR
> says press 1, there should be a way for Alice to navigate the IVR.