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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 09 June 2013 21:48 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 1EC8E21F898B for <mmusic@ietfa.amsl.com>; Sun, 9 Jun 2013 14:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.402
X-Spam-Level:
X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.035, 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 jpMWJb52TU4T for <mmusic@ietfa.amsl.com>; Sun, 9 Jun 2013 14:48:07 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 2747A21F8916 for <mmusic@ietf.org>; Sun, 9 Jun 2013 14:48:06 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id mMKp1l0031ap0As5AMo68Z; Sun, 09 Jun 2013 21:48:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id mMo51l00K3ZTu2S3iMo5qY; Sun, 09 Jun 2013 21:48:06 +0000
Message-ID: <51B4F814.1050607@alum.mit.edu>
Date: Sun, 09 Jun 2013 17:48:04 -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>, <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, , <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, , <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org>, <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se>, <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org>, <51A3B070.1090006@alum.mit.edu>, <FF8A3ABB-992C-48D9-856F-A6A21A35A0C1@iii.ca>, <51AF5EEE.8080904@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se>, <51AF6BB9.3010807@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se>, <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca>, <51B20D64.7050600@alum.mit.edu>, <ED508E23-575A-471A-90AB-3D5DF3D90314@iii. ca>, <51B4B64B.1050101@alum.mit.edu> <BLU169-W17498C680BC2DD3D2C2381939B0@phx.gbl>
In-Reply-To: <BLU169-W17498C680BC2DD3D2C2381939B0@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=1370814486; bh=0SECy0ayFTopx7LPpGWFPMn/aovLKN29LKoxM66nW9Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m4+TsH0N8wpAUD5kos7m0Zz6Ahmc6X1+aTNtVJPfvTB7J612lN+i9QFuEdErnF4CB QccNdjY+O+4xHpIYygdz7+Ge46Cgrp6WqJfoEHUaw51pOc2HymObdiV0so5jNnptv4 CnDPLz216dNmIPe7QZrSQrX1mdshkSFUoS+zhwXcmsRdLvCgrfhw/LZx804NXvbb8s fIoMlbl25sqol86EDOu1hognIxMptF7v7FIbQCqvo23561QPVty6shUOtGdeq8pdC7 Qora0xqj4qJI0AAzAX0bm9CU3OdOy3srSg/V20Gys3nRoDx1qMuMPeQDassTPu7G1L qgwLqbxkGse4w==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Cullen Jennings <fluffy@iii.ca>, Christer Holmberg <christer.holmberg@ericsson.com>
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 21:48:13 -0000

On 6/9/13 1:32 PM, Bernard Aboba wrote:
> Paul said:
>
>  > I see no reason to struggle for ways to work around that if mandating
>  > PRACK would solve the problem.
>
> [BA]  "solving the problem" requires more than just PRACK.  In a WebRTC
> implementation, I believe that the requirement is to be able to receive
> media before setRemoteDescription is called.   Unless that
> functionality (which is not specifically called out in the use case
> document) is implemented, it doesn't matter whether PRACK is supported
> or not.

I don't think it means that at all.

The PRACK means a reliable provisional has been sent, and so SDP carried 
is a true answer rather than a hint about a future answer.

If gatewaying between SIP and RTCWEB, that means that an ANSWER can be 
delivered rather than a PRANSWER. So AFAIK that means 
setRemoteDescription can be called.

	Thanks,
	Paul