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

[Lorenzo Miniero <[e-mail]>]

Hi Victor, see inline.


On Sat, 9 Oct 2010 07:09:39 +0700
Victor Paulsamy <[e-mail]> wrote:

> 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?
> 


Just anticipating actually: I guess it really depends on the format and encoding used for the media to append to, if both audio and video are involved, if source and target are of the same type and so on.


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


-- 
Lorenzo Miniero <[e-mail]>