Damian wrote:
> >> 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?
Isn't this URL required for a REST call?
> >> 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
Yes, the running server. You could use this value instead of executing
`hostname -f`, which I'm told doesn't do what we expect on Suse systems
anyway.
> >> 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
I see. Basically then I want SIP_DOMAIN_NAME, unless I'm md5'ing the
value with a username and raw password. :)
> > 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.
Sounds good.
Thanks.
-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/
