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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 09 June 2013 22:02 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 7C7FE21F9050 for <mmusic@ietfa.amsl.com>; Sun, 9 Jun 2013 15:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.404
X-Spam-Level:
X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, 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 djaH5nOc8rGT for <mmusic@ietfa.amsl.com>; Sun, 9 Jun 2013 15:02:17 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 611FD21F9017 for <mmusic@ietf.org>; Sun, 9 Jun 2013 15:02:17 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id mN1J1l0031vXlb858N2Gir; Sun, 09 Jun 2013 22:02:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id mN2G1l00T3ZTu2S3dN2GHk; Sun, 09 Jun 2013 22:02:16 +0000
Message-ID: <51B4FB67.7000600@alum.mit.edu>
Date: Sun, 09 Jun 2013 18:02:15 -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>, <51B26996.1090006@alum.mit.edu> <BLU169-W64FD0D8AFD754835DD196C939B0@phx.gbl>
In-Reply-To: <BLU169-W64FD0D8AFD754835DD196C939B0@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=1370815336; bh=ThFTHFhLlNJwYTNKi0ROIRI4qgNO7eArGyL95IRc5cw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TYvoeQ2oXSrfaoZ4ZQ/TnFXyTOd4T8mMywV0AnOfiNNqb8zk4822Xr5rd+MIquGam Q6ydx+5Kkzqp+ju+EgBhW9BnXMPMnnFzhHUqoKyvj0HlDU68UQYXFSslqXTP3tFNA+ 3utUJ8tkiyeAms335XQAg+28SwfuBVARbTYEwu/2htJZz2Qt3NaxYQQjb+jcvGYc0e UlHb52t7BX5mgga160Lv1t7wjAFZF3gNXjUx1FlfahoFEpRg0yDuJiCufDE3IPMVAp j/KW9+hH/SZWXxs4iJW7p2orB8biJoLnLLDIFpwCgzS8XhlJP31kgbcVSHueXr9ETS m0hEPGFfefdew==
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: Sun, 09 Jun 2013 22:02:23 -0000

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.

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