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.

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

_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to