> -----Original Message----- > From: Scott Lawrence [mailto:[email protected]] > Sent: Monday, April 26, 2010 4:48 PM > To: Nair, Arjun (Arjun) > Cc: [email protected] > Subject: RE: [sipX-dev] XX-8242 Uploaded MOH not played > through secondary conference server > > On Mon, 2010-04-26 at 09:14 -0400, Nair, Arjun (Arjun) wrote: > > > I do recall there were some issues with transfering large > files over > > XML-RPC (something to do with XML-RPC timeouts). If that's > no longer > > the case, I can go ahead and use this to transfer the audio files. > > There are some, but it's not clear we'll hit them. Raymond > made some improvements in this area. > > I suggest we try some files to see how big we can handle with > what we've got, and then decide whether or not that's good enough. >
My findings so far: - http://track.sipfoundry.org/browse/XX-8298 SipXsupervisor seg-faults when transferring large files ( > 21MB) through File.replace XML-RPC - We will need to add additional support in the File.replace API to support uploading audio files, namely, the ability to declare a directory as a process resource, and being able to write an arbitrary number of files into this directory. As far as I can tell, we currently don't support this. - From the code it looks like we read the entire file contents into memory before writing it out. IMO, A "streaming" model would be more appropriate here, esp. w.r.t. large files. >From sipXconfig side: - I would prefer to do a high level fix (maybe at the AssetSelector class) which will carry out all file manipulations through sipXsupervisior. This would be a fairly engaging task, but it will de-couple a lot of services from being "co-resident" with sipXconfig. Based on these, I think XX-8242 is a 4.3 candidate. Arjun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
