Andrei Cristian Niculae wrote:
Hello,
I've been talking with Mircea Carasel about a JIRA issue he's been
working on - [1] - an issue about, among other things, introducing the
concept of user site location, as described in [2]. The user
site-location would represent physical location of the user.
We've been thinking of a way of expanding this concept to a more general
"site-location".
*Mcdaid, Paul* (GAL:IE319) wrote:
Andrei,
I assume that we would have a default-location which would mean
"here" or local-location, and this location would have time-zone, NTP
settings the same as the locally configured ones. It would be better if
this default location could not be deleted.
[AN] Yes, that's what I was thinking also
*Damian Krzeminski* wrote:
As far as I can tell everything that can be done with 'site-location' can
be done with groups.
So the usual questions:
- do we really need a new feature - why not just add 'Site Location'
panel/capability to group settings for users (and later for devices if needed).
D.
[AN] That was the main reason for this e-mail. Would it be better to
have this independently, for users, gateways and so on, or would it be
better if we had a centralized thing for all this.
*Lawrence, Scott* (BL60:9D30) wrote:
What is 'special' about site location as opposed to any other Group that
the administrator chooses to implement and put a user or phone in?
[AN] Well, a site-location would be a group, so from the implementation
point of view, nothing special.
But since this new type of group is needed for XCF-2407, we were
wondering what would be the benefits of managing these site-locations
independently from users and extending this concept to other devices.
Let's put this discussion on just one list, please... I suggest sipx-dev
[AN] I was curious if this made any sense to the users, that's why I
submitted the proposal to both list and kept any implementation details
aside. Again, this is just a proposal whether this feature is desirable
and if we should open a JIRA issue to track this. Perhaps I was too
vague in describing what I ment. Sorry.
*Picher, Michael* wrote:
I think this is a great idea... with the concept of clusters PBX's will
need to live in certain sites, Phones will need to prefer those proxies,
etc...
The site info could be utilized to program the 911 dialing from phone to
gateway also.
We use Groups for this a lot now, not sure how this would tie in
[AN] That's an interesting question. I guess that we could move some
settings from groups to location. Or we could have it in both places,
prioritizing them (if it's set in both group and location, the one in
group settings would be chosen). I guess this last approach would
eliminate backwards-compatibility issues Scott was concerned about.
*Martin Steinmann* wrote:
Combined with our new cluster management / multi-branch capabilities
it should be possible to define different locations for a certain
deployment. A location would include a location name, address, contact
of local amin (phone, email). I.e. there should be a new screen that
allows the definition of new locations and lists existing locations in
a table.
I like using the concept of groups for location designations. However,
we should probably call it location and make it different from groups
from a user perspective. I.e. the "user" screen would include a field
for group and then a field for location. A user can be in several
groups, but has only one current location. The same would be true for
e.g. a phone: it can be in several groups, but has only one location
(i.e. there are two fields when defining a phone). We could add a new
tab "Locations" under "System" to define locations.
It should also be possible to assign a location to a server in the new
service management view, a gateway or phones as was proposed earlier.
This would make it possible to list all resources available in a
certain location, such as users, servers, services, gateways, phones,
SBC, etc. As an advanced capability (out of scope for this) that page
could even display status for such elements (i.e. server & services
status, registered lines, etc.).
[AN] This would be a nice description for the JIRA issue if we decide to
open one for this feature.
Regards,
Andrei
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
