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

Stéphane Bastien <stephane@broadsoft.com> Sat, 09 October 2010 11:57 UTC

Return-Path: <stephane@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 954263A69E0 for <mediactrl@core3.amsl.com>; Sat, 9 Oct 2010 04:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.809
X-Spam-Level:
X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 r6Mp3dzp5amt for <mediactrl@core3.amsl.com>; Sat, 9 Oct 2010 04:57:48 -0700 (PDT)
Received: from smtpedge04.partnerhosted.com (smtpout02.partnerhosted.com [173.225.22.202]) by core3.amsl.com (Postfix) with ESMTP id 21FA33A6894 for <mediactrl@ietf.org>; Sat, 9 Oct 2010 04:57:47 -0700 (PDT)
Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sat, 9 Oct 2010 04:58:53 -0700
Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Sat, 9 Oct 2010 04:58:53 -0700
From: =?iso-8859-1?Q?St=E9phane_Bastien?= <stephane@broadsoft.com>
To: Victor Paulsamy <vpaulsamy@ditechnetworks.com>
Date: Sat, 9 Oct 2010 04:58:50 -0700
Thread-Topic: [MEDIACTRL] ISSUE 4 - IVR Package - <record> append
Thread-Index: ActnqVe7eiHxQwI2RB2Z8bw5TnR8/w==
Message-ID: <26335AEE-8347-4F6E-AF28-83E547E1D058@broadsoft.com>
References: <C8D3D9CA.9524%Scott.McGlashan@hp.com> <21866C7FE177A4449B9136B5B24B1B13052A10605C@EXMBXCLUS01.citservers.local> <20101008131135.aa132047.lorenzo@meetecho.com> <AANLkTi=RV4nRva-CjXn7gMY7wcAr6K6Jm3yzrNnpPXKh@mail.gmail.com>
In-Reply-To: <AANLkTi=RV4nRva-CjXn7gMY7wcAr6K6Jm3yzrNnpPXKh@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR, en-US
Content-Type: multipart/alternative; boundary="_000_26335AEE83474F6EAF2883E547E1D058broadsoftcom_"
MIME-Version: 1.0
Cc: Melnikov Alexey <alexey.melnikov@isode.com>, "mediactrl@ietf.org" <mediactrl@ietf.org>, "mediactrl-chairs@tools.ietf.org" <mediactrl-chairs@tools.ietf.org>, "draft-ietf-mediactrl-ivr-control-package@tools.ietf.org" <draft-ietf-mediactrl-ivr-control-package@tools.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: Sat, 09 Oct 2010 11:57:51 -0000

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<mailto: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.)