Dale Worley wrote:
> On Mon, 2009-09-21 at 10:05 -0400, Paul Mossman wrote:
>> Some questions on domain-config...
>>
>> 1. Could we add a CONFIG_URL setting, in the same form as it appears in
>> sipxivr.properties?  (e.g. configUrl=https://puppy.org:8443)  Not sure
>> if it would entirely replace CONFIG_HOSTS... 

I think it's possible? What would that be used for?

>>
>> 2. Could we add a HOSTNAME setting?  Basically 'hostname -f' on the
>> server.
> 
> Which server?  If the domain has multiple servers, which hostname would
> we put in domain-config?
> 

sipXconfig could put a different (correct) name for each server if that's
what needed

>> 3. Why both SIP_DOMAIN_NAME and SIP_REALM?  (In the velocity template
>> these are ${domain.name} and ${domain.sipRealm}.)
> 
> We've always supported using a different SIP realm than SIP domain name.
> Not like many customers use that, but we do.  IIRC, it makes it easier
> to move a testing system into production -- you don't want to have to
> change the realm, ever, because you'd have to re-enter the user's
> passwords.  So you configure the test system with the company's domain
> as the SIP realm, but a subdomain as the SIP domain.
> 

Exactly: realm does not have anything to do with SIP domain name, once you
initialize the system you cannot change the realm without dropping all the
passwords, you can however change the domain name

>> Along these lines, my new feature be writing a file into
>> %{phonedir}/profile/tftproot on occasion.  Should it be doing this with
>> replication?  Or will I just introduce the restriction that this service
>> must run on the master server?
> 
> At some point in the not-too-distant future, we'll want to run the
> feature support process on a non-master server, so I'd suggest using
> replication.
> 

Once we externalize provisioning service it'll probably get it's own file
management API that sipXconfig would use.
I am not convinced yet if it's going to be implemented on top of
sipXsupervisor replication. I think it's OK to write those files directly.
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
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to