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

[Victor Paulsamy <[e-mail]>]

2010/10/8 Lorenzo Miniero <[e-mail]>

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

However, I'm not against leaving the append mechanism to implementers.

--victor

That said, I think append is a very useful functionality and would like
> to keep it: why not clarify that the mechanism used for appending is
> implementation specific? I doubt the same recorded media will be used
> by different MS implementations at the same time.
>
> L.
>
>
> On Thu, 7 Oct 2010 11:25:33 -0700
> Stéphane Bastien <[e-mail]> wrote:
>
> > Hi,
> >
> > We use extensively the append attribute. We implemented this behavior:
> >
> > 1. append=false: Use HTTP PUT to overwrite the content of the URL after
> the recording is completed.
> >
> > 2. append=true:
> >       a) Perform an HTTP GET on the URL
> >       b) Record new audio/video
> >       c) Append the new audio/video to the media file that was downloaded
> in step a)
> >       d) Perform an HTTP PUT to overwrite the old URL with the new media
> file.
> >
> > Note that our implementation also matches the behavior expected for a
> media file stored on the local filesystem and accessed using the URI
> file://.
> >
> > I do not agree with the proposal to enforce the usage of HTTP POST if
> append=true; because it makes the assumption that the remote HTTP server can
> append audio/video to an existing media file. The Media Server already knows
> how to handle audio tracks and video tracks, duplicating this functionality
> in the remote HTTP server seems counterproductive.
> >
> > Stephane
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf Of McGlashan, Scott
> > Sent: 7 octobre 2010 14:11
> > To: [e-mail]
> > Cc: Melnikov Alexey; [e-mail];
> [e-mail]
> > Subject: [MEDIACTRL] ISSUE 4 - IVR Package - <record> append
> >
> > Fourth (and final I think) issue for mailing list discussion following
> IESG review of the IVR package:
> >
> > In 4.3.1.4:
> >
> >    append:  indicates whether recorded data is appended or not to a
> >       recording location if a resource already exists.  A valid value is
> >       a boolean (see Section 4.6.1).  A value of true indicates that
> >       recorded data is appended to the existing resource at a recording
> >       location.  A value of false indicates that recorded data is to
> >       overwrite the existing resource.  The attribute is optional.  The
> >       default value is false.
> >
> > How is append/overwrite mapped to underlying protocol being used?
> > In particular, I think this is underspecified in case of HTTP.
> >
> > This is a good point and we don't say anything about how to map record
> upload to the underlying protocol. Since we mandated HTTP (and HTTPS), I'd
> prefer if we specify a mapping to HTTP. I'd propose something like:
> >
> > When a recording location is specified using the HTTP or HTTPS protocol,
> the recording operation is mapped to the HTTP POST and PUT operations
> depending on whether the append attribute is true or false:
> >
> > 1. append = false. The recording data is uploaded to the specified
> location using HTTP PUT and replaces any data that location on the origin
> server. Success if the origin server returns 201 (Created); any other HTTP
> response is treated as an upload error.
> >
> >
> > 2. append = true. The recording data is uploaded to the specified
> location using HTTP POST and is added to the resource - if any - at that
> location. Success if the origin server returns 204 (No Content) or 205
> (Reset Content); any other HTTP response is treated as an upload error.
> >
> > Let me know if you think this is along the right lines - any improvements
> (or other implementation experiences) welcome.  The other alternative is to
> delete the append attribute - especially if  no-one implements it .. If we
> do decide to delete the append attribute, I still think some text around the
> HTTP protocol mapping is useful.
> >
> > Thanks
> >
> > Scott
> > _______________________________________________
> > MEDIACTRL mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
> > _______________________________________________
> > MEDIACTRL mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mediactrl
> > Supplemental Web Site:
> > http://www.standardstrack.com/ietf/mediactrl
>
>
> --
> Lorenzo Miniero
> Meetecho s.r.l.
> http://www.meetecho.com
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>