On Feb 19, 2010, at 11:25 AM, Paul Mossman wrote:
> Scott wrote: >> One suggestion I'd make based on your description is that I'd >> rather see real file management for the audio files - that >> is, they should probably be in a directory of their own and >> managed through something more specific that 'unmanaged files'. > > Yes, I agree. > > In particular, we'll only take a Speed Dial framework change if it is > available for use by all phones. > I added a generic 'ring' field (as a 'string') to the speed dial directory, the idea was other phones that allow ring-per-speeddial could use it as well (rather than making it an integer or pulldown that is polycom specific). Also the specification for a ringtone could be more than just a ring file, it could be a tone script or something else. I only have Polycoms so I don't know what breadth of functionality is available in this area from other vendors. > I think the audio files can still appear as "Device Files', but each > should be explicitly added as a 'Ringtone'. These files can then be > offered as options on the Speed Dials screens. > One snag is that different devices may require different file formats (or may not even use files), if we have a pulldown it will have to understand which files apply to which classes of phones. This is true even within polycom, where the video phones take 32k and 48K files but the other ones do not. Maybe the answer for ring scripts/etc is to put those in a file and manage them as a ringtone file (kind of a hassle, but it would allow the pulldown menu w/o free form entry) and just ignore the possibility that some ringtones are not compatible with some phones. The velocity template rendering for a phone that supports ring scripts could open the files and try to figure out if they are a script or a file. (?) Sounds a little icky but workable. The other idea I had to allow this simple 'dsitinctive ring' functionality w/o messing with the global speed dial schema was (for the polycoms) to simply block insert (at the velocity level) an uploaded file into the -directory being built (this is in effect how I'm doing it today, though by editing the .vm file directly). The downside of this is the speed slots are no longer managed and if you entered a slot # that was dynamically assigned it would overlap. I will go try to figure out the managed files classes for the ringtone at the very least. > (And please link your original post in the JIRA: > http://list.sipfoundry.org/archive/sipx-dev/msg22108.html ) Will do. > > Thanks. > > > -Paul > [email protected] > > > _______________________________________________ > 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/ _______________________________________________ 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/
