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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 07 June 2013 23:15 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 C752B21F99A9 for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 16:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9-Jg49Dz7A8 for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 16:15:37 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id E967B21F9936 for <mmusic@ietf.org>; Fri, 7 Jun 2013 16:15:36 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id lbDr1l0031vXlb856bFbfG; Fri, 07 Jun 2013 23:15:35 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id lbFb1l00i3ZTu2S3dbFbDg; Fri, 07 Jun 2013 23:15:35 +0000
Message-ID: <51B26996.1090006@alum.mit.edu>
Date: Fri, 07 Jun 2013 19:15:34 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
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 <bernard_aboba@hotmail.com>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>, <51A39023.1070605@alum.mit.edu>, <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>, <51AF6490.1040409@alum.mit.edu>, <CD0D36C1-25C5-4222-B37E-D02AE2331E8B@iii.ca>, <51B20CD1.5090002@alum.mit.edu> <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; d=comcast.net; 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: "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: 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 
sender.)

	Thanks,
	Paul

> 4.3.2.1
> <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10#section-4.3.2.1>.
> 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.
>
>
>