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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 10 June 2013 16:45 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 9B9AC21F88D8 for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 09:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.408
X-Spam-Level:
X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Jwt4oAa-C9qe for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 09:45:03 -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 C0B0E21F9452 for <mmusic@ietf.org>; Mon, 10 Jun 2013 09:45:01 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id mcDR1l0020mv7h056gl1R9; Mon, 10 Jun 2013 16:45:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id mgl11l0033ZTu2S3Xgl1Wh; Mon, 10 Jun 2013 16:45:01 +0000
Message-ID: <51B6028C.20606@alum.mit.edu>
Date: Mon, 10 Jun 2013 12:45:00 -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: "Stach, Thomas" <thomas.stach@siemens-enterprise.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>, <51B26996.1090006@alum.mit.edu> <BLU169-W64FD0D8AFD754835DD196C939B0@phx.gbl> <51B4FB67.7000600@alum.mit.edu> <F81CEE99482EFE438DAE2A652361EE121144B94F@MCHP04MSX.global-ad.net>
In-Reply-To: <F81CEE99482EFE438DAE2A652361EE121144B94F@MCHP04MSX.global-ad.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370882701; bh=YPYymbHYc84NybN5vr8mPYSllL0z49KxmChutT4GxK4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=I9vRVx1qW3HdBaWdR7M7Qq3at5hGtENylfYZ8BuZK/r/BZmVqIGtreM+zkkTHDlC0 ZG0IW1EYtL5PkqcGFD6JbSKH1HxorJvyrpv0I+np7gdKdG0zMiNe1AhrYz19oo1ksb nRdkJX6ypXbrFFIgAQqwqmS+o3BoldhyDKlGL3kNtQoEcWgT/1S/y+jrw04T7xoL4O WJc9tfJEdi3kvtJi3tAPo30hkrPuS+0DVGERnS5eDinGlhy+Lwl0YHkgQsRDzMwnG8 T0LgTdXsrUZlxCgg9YBYVeHavxYr3kJDkk2GiqhgLju/4T3eYNUNpPGoVUSeh0OglJ 0fokc2mHispfg==
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: Mon, 10 Jun 2013 16:45:09 -0000

On 6/10/13 8:40 AM, Stach, Thomas wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
>> Im Auftrag von Paul Kyzivat
>> Gesendet: Montag, 10. Juni 2013 00:02
>> An: Bernard Aboba
>> Cc: mmusic@ietf.org
>> Betreff: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
>>
>> On 6/9/13 1:48 PM, Bernard Aboba wrote:
>>> Paul said:
>>>
>>>   > 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.
>>>
>>> [BA] So you're saying it is sufficient to enable media once a 183 is
>>> received, but not before?  I believe that is consistent
>> with the current
>>> WebRTC API.   The use case document isn't clear that this is the bar
>>> that is being set, though.
>>
>> I'm suggesting that in the case of BUNDLE, there be a
>> requirement that
>> media not be sent until an answer is known to have been
>> received by the
>> other end. Sending a reliable 183 and awaiting the PRACK
>> before sending
>> media would satisfy that. Presumably something similar can serve in a
>> pure WebRTC environment.
>>
>> That will ensure no clipping.
>>
>> The objection I hear to this is that some don't implement PRACK. I'm
>> just saying that we could require support for PRACK with support for
>> BUNDLE. Then that argument becomes bogus.
> Just as well, we could require ICE together with BUNDLE and
> re-use how ICE deals with reliability of provisional reponses.
> In the RTCWEB this would be a non-issue.
> Environments that don't support ICE could still require PRACK.

The key is to ensure that the offerer gets an answer in a timely way to 
avoid clipping. PRACK is one way. ICE is another. We could require 
either/or.

	Thanks,
	Paul

> Regards
> Thomas
>
>>
>> Then we can say that it is ok if something in the answer is
>> needed for
>> the offerer to demux incoming media.
>>
>>> One issue is what the WebRTC gateway will do if it gets
>> media before the
>>> 183.    If it just forwards it on, then it will be dropped by the
>>> browser until the 183 shows up and setRemoteDescription is called.
>>> Should it buffer it until the 183 arrives?
>>
>> My proposal is that it should not transmit media until it knows the
>> answer has been received. I don't care how it achieves that, but I
>> imagine dropping it would be a good choice.
>>
>> Or, if people prefer, we could allow it to be sent, but allow
>> the other
>> end to drop it. But still expect the early answer so that the period
>> when media is lost is brief.
>>
>>>   > 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.
>>>
>>> [BA] Personally, I don't see PRACK as being required for BUNDLE, at
>>> least in WebRTC uses. However, a WebRTC/SIP gateway probably should
>>> support PRACK.
>>
>> PRACK wouldn't be required in JSEP. But the equivalent would
>> be expected
>> - a quick ANSWER, before media is sent.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>