FWIW I'm still working on trying to make those patches more palatable to the 
Avaya guys. The basic difficulty I've been having is they want everything 
checked and 'safe' by the polycom plugin yet some of the features tread into 
global areas of the system (the speed dial directory). The feature you want (I 
believe) does not however, its local to the polycom plugin. Scott even said in 
a later post responding to someone else wanting to add custom config to their 
polycom cfg files [paraphrased] '4.2 can already do that' -- though he didn't 
answer when I asked how, I'm guessing he meant you can edit the .vm files 
(which I personally think is very error prone and ditches all the functionality 
you get from the 'group' mechanism).

I did consider writing a bunch of M4 macros and perl scripts to semi-safely 
deal with this stuff outside of sipxecs purview, but it seemed silly to 
reproduce the powerful functionality we already have in sipxconfig.

I will post my patches to a JIRA once they're as 'tuned' up as I can make them, 
the pressure is off me personally since I'm running my own build from svn and 
the features/speed dial changes are working for us in the small (10 polycoms) 
pilot -- but I will get these cleaned up hopefully before they freeze the db 
schema for 4.2.

-Eric

On Mar 9, 2010, at 2:13 PM, Josh Patten wrote:

> I agree something needs to be discussed on making call flows easier for those 
> of us that use Polycom phones (which is probably the majority).
> 
> If I could add config snippets as discussed here: 
> http://article.gmane.org/gmane.comp.voip.sipx.devel/20862/match=polycom+phone+configuration+patches
>  to groups of phones then I could work around these issues.
> Josh Patten
> Assistant Network Administrator
> Brazos County IT Dept.
> (979) 361-4676
> 
> On 3/9/2010 2:03 PM, Tony Graziano wrote:
>> 
>> 
>> 
>> On Tue, Mar 9, 2010 at 2:21 PM, Paul Mossman <[email protected]> wrote:
>> Josh wrote:
>> ...
>> > What Ke is suggesting is that setting automata in the config
>> > file is the only way.
>> 
>> It is indeed the only way.
>> 
>> 
>> > What I am curious about is if Polycom ever implemented the
>> > capability to parse things like
>> >
>> > <plcm:button function="xfer"/>
>> >
>> > based on your mailing list post.
>> 
>> That suggestion was not implemented.
>> 
>> 
>> -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/
>> 
>> In light of that, are there any discussions to support some of the EFK 
>> functionality? Essentially offering a blind transfer button, and being able 
>> to hit a speeddial to complete it? (i.e., 2 button blind transfer, or a 
>> blind vm transfer).
> _______________________________________________
> 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/

Reply via email to