Paul Mossman wrote: > Damian wrote: >> Paul Mossman wrote: >>> Hi all, >>> >>> In general we want superadmins to avoid the Web interfaces >> of devices, >>> and do their programming exclusively through sipXconfig. >> Especially >>> for an Audiocodes Gateway because all configuration added >> through its >>> Web interface will be lost each time you reload the profile. >>> >>> In order to configure the Audiocodes SAS feature with >> sipXecs there is >>> some configuration that must be done through the gateway's Web >>> interface. (See >>> _http://list.sipfoundry.org/archive/sipx-users/msg13628.html_ Step >>> #4.) >>> >>> Any objections/suggestions to an enhancement request for >> adding IP -> >>> Tel Destination Number Manipulation table to Audiocodes Gateway >>> sipXconfig profile? >>> >> Maybe I do not understand all aspects of this feature but why >> not configure sipXecs to drop the digits by modifying dial plan. >> >> sipXecs should be in charge of number manipulation if >> possible: if it's centralized we can manage it and in future >> visualize and report errors. > > That's the thing. For the SAS feature to work, the number manipulation > must be done by the Audiocodes gateway. > > >> If you need to add this table: only add a specific >> functionality that is required for SAS: do not model entire >> number manipulation table. > > Not sure I follow. I'm pretty sure all the columns in this table are > useful. As for how many rows you need, that depends on your dial plan. > What aspect of the table are you suggesting we omit? >
Instead of modelling and exposing the table directy, model the feature on the higher level and expose only the parameters that makes sense for the feature. Then generate the table configuration based on the parameters entered by the user to configure SAS. In this way you ensure that capability of manipulating the numbers is not overused for things unrelated to SAS. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
