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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 10 June 2013 16:43 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 E027621F9948 for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 09:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.407
X-Spam-Level:
X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=0.030, 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 7tSY1WXBUaTx for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 09:43:00 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id F052621F9942 for <mmusic@ietf.org>; Mon, 10 Jun 2013 09:42:56 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id mc8y1l0011c6gX853givGK; Mon, 10 Jun 2013 16:42:55 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id mgiv1l0083ZTu2S3jgivKK; Mon, 10 Jun 2013 16:42:55 +0000
Message-ID: <51B6020E.4010103@alum.mit.edu>
Date: Mon, 10 Jun 2013 12:42:54 -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: Cullen Jennings <fluffy@iii.ca>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@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> <635C2BBF-DA79-430D-9911-A2001D171002@iii.ca>
In-Reply-To: <635C2BBF-DA79-430D-9911-A2001D171002@iii.ca>
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=1370882575; bh=oXdxIZb1KO6zCERZBV7njKanGWQNUMqzQGWKZeuaCB8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ULEdP6lzdSoN3EHqWAZwnfQdS6yteXnM3kc+DkOBRsN17cVhAMM6aQqqvElIHxh5h ru9Exyb6oACy6yo2uJ3tFO4s4k8nImexJZsbX/LuxtYYodTpFZ7COV0M+8MXKLOYME nK1s1teZPsQ0hu3mPoQ9W0NTaHlSInyexN/66r97C/N+4JMRoBoQHazoX1S6mzxPFo yRVEOGB/cZrrOlLUX0HwpgeGJyB8D74ReJOqhPYItEs+slguuGAPVetg0giBf6d0Qf IoA/ylNwtXKx0M8VJ8chjil8AXGnT1nzT2o7aaWu6soFibOd0oEnzvaP9cFP8nvrhz FPswIcSUJOtlA==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, 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: Mon, 10 Jun 2013 16:43:06 -0000

On 6/9/13 11:48 PM, Cullen Jennings wrote:
>
> On Jun 10, 2013, at 2:32 AM, Bernard Aboba <bernard_aboba@hotmail.com> 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.
>
> +1
>
> and "work with 1-800-gofedex" is a deliberate wording so we can make sure we work with at least one of the key use cases but at the same time not drag in every weird corner case that has been imagined for early media.

Here I guess you mean WebRTC work with 1-800-gofedex, right?

That will either require the fedex web site to directly support WebRTC, 
or else somebody to deploy a WebRTC-pstn GW.

I would expect that fedex would be one of the first to want to support 
WebRTC. And then they can make it work directly.

I don't know who will deploy a general WebRTC-pstn GW, but probably some 
will. Then there are sub-cases for that:

- would the GW be able to directly access 1-800-gofedex via a sip
   trunk that supports DTLS/SRTP and ICE, so that it need not process
   the media itself, and is dependent on it being processed downstream?

- or will the WebRTC-pstn GW be processing media, so it can do the
   ICE and DTLS/SRTP and then transition to a "normal" SIP trunk or
   pstn GW?

The main thing is to get a quick answer so that early media processing 
is not delayed. I don't see why 1-800-fedex presents any special problems.

	Thanks,
	Paul