Re: [MEDIACTRL] ISSUE 4 - IVR Package - <record> append

Eric Burger <eburger@standardstrack.com> Wed, 13 October 2010 11:25 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525F63A69AF for <mediactrl@core3.amsl.com>; Wed, 13 Oct 2010 04:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRzEdOUihyVk for <mediactrl@core3.amsl.com>; Wed, 13 Oct 2010 04:25:12 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.249.249]) by core3.amsl.com (Postfix) with ESMTP id 2AFE83A6954 for <mediactrl@ietf.org>; Wed, 13 Oct 2010 04:25:12 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=gWio7msaEiPTmVpVF08mUd+eqt24njK7rhpQl3KkjWf26LRXEQvy8ROwuIntPBhDM4Oup19DTMrazT1wXi3sXZm1zpRnNt/2jnEGcREUI/OqoVoQ7h/4SaS7pJjRA7Si;
Received: from 216-130-127-50.static.cimcoisp.net ([216.130.127.50] helo=[192.168.5.69]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1P5zTL-0006Ox-JM; Wed, 13 Oct 2010 04:26:16 -0700
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-58--575660968; protocol="application/pkcs7-signature"; micalg=sha1
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <21866C7FE177A4449B9136B5B24B1B13052B6B35BB@EXMBXCLUS01.citservers.local>
Date: Wed, 13 Oct 2010 06:26:24 -0500
Message-Id: <91A38DF9-0307-40C0-9A85-AF00F9398878@standardstrack.com>
References: <C8D3D9CA.9524%Scott.McGlashan@hp.com> <21866C7FE177A4449B9136B5B24B1B13052A10605C@EXMBXCLUS01.citservers.local> <20101008131135.aa132047.lorenzo@meetecho.com> <AANLkTi=RV4nRva-CjXn7gMY7wcAr6K6Jm3yzrNnpPXKh@mail.gmail.com> <26335AEE-8347-4F6E-AF28-83E547E1D058@broadsoft.com>, <8C109CC9-2461-4A79-BC3B-ABE204100D26@standardstrack.com> <21866C7FE177A4449B9136B5B24B1B13052B6B35BB@EXMBXCLUS01.citservers.local>
To: Steve Liao <steve@broadsoft.com>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: "mediactrl@ietf.org" <mediactrl@ietf.org>
Subject: Re: [MEDIACTRL] ISSUE 4 - IVR Package - <record> append
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2010 11:25:13 -0000

I think this means we agree: since the Media Server already knows the structure of the container format and codec, and the Media Server knows what the very semantics of "append" means for the container and codec, that we should leave it up to the Media Server to decide. So long as on the other side it is just stock, RFC 2616 HTTP, I think we should be fine.

On Oct 12, 2010, at 4:08 PM, Steve Liao wrote:

> On the contrary, I believe we can run into media file viability problems if we mandate mapping append=true to HTTP POST.  As Stephane and Lorenzo stated, adding to a media file oftentimes requires detailed knowledge of the media format and oftentimes cannot be accomplished by simply adding bytes to the end of an existing file.
> 
> While it's quite conceivable for a Media Server to perform the container format conversions and/or transcodings as necessary to append media, this capability is not necessarily available on an HTTP server.
> 
> Therefore, how the Media Server provides append=true should be left up to implementation, so long as it satisfies the requirement of append=true resulting in a media file that properly incorporates the new media.
> 
> Regards,
> Steve
> 
> ________________________________________
> From: mediactrl-bounces@ietf.org [mediactrl-bounces@ietf.org] On Behalf Of Eric Burger [eburger@standardstrack.com]
> Sent: Tuesday, October 12, 2010 5:39 AM
> To: mediactrl@ietf.org
> Subject: Re: [MEDIACTRL] ISSUE 4 - IVR Package - <record> append
> 
> Will we run into interoperability problems if this is implementation-dependent? My guess is if it is up to the media server, the media server already knows the current file format and codec, so should also be able to know if it can just add bytes to the end of the current file or if it has to suck down the whole thing, repackage, and send it back.
> 
> On Oct 9, 2010, at 7:58 AM, Stéphane Bastien wrote:
> 
>> Hi,
>> 
>> Just appending data to the end of media files work for some audio file formats, but fails for common file formats such as MOV, 3GP, and MP4. (Even appending audio to a WAV file fails unless you modify the WAV header - which means that the HTTP server handling the POST must know how to do this.) And as Lorenzo mentions in another e-mail, how can the HTTP POST deal with issues such as the first part of a recording is in one codec, while the remainder of the recording is using some other codec. This is just one more failure mode when using plain HTTP POST for appending.
>> 
>> I strongly recommend that we leave the appending mechanism as an implementation-specific issue in the spec.
>> 
>> Stéphane
>> 
>> Le 2010-10-08 à 20:09, Victor Paulsamy a écrit :
>> 
>>> 2010/10/8 Lorenzo Miniero <lorenzo@meetecho.com>
>>> I agree with Stephane, appending to a media file is not like appending
>>> text and so a "brutal" POST might result in a corrupted file.
>>> 
>>> 
>>> Are you anticipating corruption or have you encountered it?
>>> 
>>> In my testing, during the last 8-months or so, append works like a charm -- even under load; I'm yet to run into recorded media corruption. We download files only for playback. Recorded media are transferred to remote (HTTP or NFS) storage, in chunks of about 40-ms audio, without storing it onboard (append is heavily used.)
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl