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

Steve Liao <steve@broadsoft.com> Tue, 12 October 2010 21:07 UTC

Return-Path: <steve@broadsoft.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 AF2C43A6A8F for <mediactrl@core3.amsl.com>; Tue, 12 Oct 2010 14:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6]
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 In9rcjJEi0S4 for <mediactrl@core3.amsl.com>; Tue, 12 Oct 2010 14:07:29 -0700 (PDT)
Received: from smtpedge04.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.201]) by core3.amsl.com (Postfix) with ESMTP id 88D1E3A6A80 for <mediactrl@ietf.org>; Tue, 12 Oct 2010 14:07:29 -0700 (PDT)
Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 12 Oct 2010 14:08:44 -0700
Received: from EXMBXCLUS01.citservers.local ([::1]) by CASUMHUB02.citservers.local ([::1]) with mapi; Tue, 12 Oct 2010 14:08:43 -0700
From: Steve Liao <steve@broadsoft.com>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Tue, 12 Oct 2010 14:08:43 -0700
Thread-Topic: [MEDIACTRL] ISSUE 4 - IVR Package - <record> append
Thread-Index: ActqCotgP/rtnCNQS9O3FQo8hqmSpgAQ/XQn
Message-ID: <21866C7FE177A4449B9136B5B24B1B13052B6B35BB@EXMBXCLUS01.citservers.local>
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>
In-Reply-To: <8C109CC9-2461-4A79-BC3B-ABE204100D26@standardstrack.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 12 Oct 2010 21:07:30 -0000

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