Joe Attardi wrote: > Hi all, > > I'm working on XCF-3026, which pertains to the configuration conference > bridges. In brief: We are removing the functionality of adding/removing > conference bridges from the Conferencing section of the UI. Instead, the > "conference bridges" will be any FreeSWITCH services on any servers in > the cluster. > > Damian started off this effort by creating a basic settings page for the > FreeSWITCH service. The problem is, that now we have a few duplicate > settings: > > SIP port - There is a "Conferencing Server SIP Port" setting in the > Bridge class, and "SIP Port" under the FreeSWITCH service configuration. > XML/RPC port - There is a "Provisioning port" setting in the Bridge > class, and "XML/RPC Port" under the FreeSWITCH service configuration. > > The other problem now is that we have two setting sets representing the > same thing - a FreeSWITCH service instance and a conference bridge are > one and the same. > > So, my first proposal here is to dump the Bridge class, and combine the > two setting models into just one. Then the information is not > duplicated, and is not split up between two sources. We don't need the > extra work of keeping an instance of a Bridge 'in sync' with a > FreeSWITCH service object. > > That said, I don't think the settings should all appear on the page for > editing the service. Service related parameters - the SIP port, XML-RPC > port, etc, belong in the service configuration page, but some parameters > - DTMF sequences, etc, I think still belong in the conferencing section > of the UI.
Correct. > > So, in summary, my proposal is twofold: > > (1) Get rid of the Bridge class; and > (2) Split the settings for the FreeSWITCH service between the service > configuration page and the conferencing page, putting the settings where > they are most relevant. > > What do people think? Am I looking at this the wrong way? > > Joe > UI makes sense: freeswitch port and XML/RPC port are practically never changed - so yeah: get them from Freeswitch. That said - do not get rid of the Bridge class - keep conference specific settings there. 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
