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

Bernard Aboba <bernard_aboba@hotmail.com> Fri, 07 June 2013 22:51 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 B08A621F99DB for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 15:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.365
X-Spam-Level:
X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 M2CCIuBr9Ihl for <mmusic@ietfa.amsl.com>; Fri, 7 Jun 2013 15:51:35 -0700 (PDT)
Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id 6121421F99D3 for <mmusic@ietf.org>; Fri, 7 Jun 2013 15:51:35 -0700 (PDT)
Received: from BLU169-W68 ([65.55.116.74]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jun 2013 15:51:34 -0700
X-TMN: [EJ7tNNkKuf2iTTe/XIHsJ1uQXHWcy+5g]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W683BD404A78C1DD8E2B0D593990@phx.gbl>
Content-Type: multipart/alternative; boundary="_965dafed-8448-485c-bfd6-94c995446c3b_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Fri, 07 Jun 2013 15:51:34 -0700
Importance: Normal
In-Reply-To: <51B20CD1.5090002@alum.mit.edu>
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>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Jun 2013 22:51:34.0694 (UTC) FILETIME=[8F7C8460:01CE63D1]
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 22:51:41 -0000

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