>
> 
>Damian Krzeminski wrote:
>> 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".
>>> This new concept would act like a general group not just for users, but 
>>> also for devices, like phones, gateways or SBCs. The first benefit for 
>>> this is that the administrator could make settings based on site 
>>> location, settings like timezone, or NTP server, these being the 
>>> starting point of our discussion (because of [3]).
>>> The site location would be available in a different page, let's say 
>>> under System->Site Locations.
>>> Here, one would have the possibility to display users, phones, gateways 
>>> and SBCs from a specific location and make settings based on that 
>>> location just like with group settings.
>>>
>>> I'm sure that besides time-zone settings and per-user gateways there are 
>>> a lot of other things that could use from this concept. So please share 
>>> your opinions.
>>>
>>> This e-mail is mainly about collecting opinions whether or not we should 
>>> open a JIRA to implement this feature and the benefits this would bring.
>>> As soon as there is an agreement upon this, I'll come back with details 
>>> about what we thought would be the first phase in implementing this.
>>>
>>> Regards,
>>> Andrei
>>>     
>>
>> As far as I can tell everything that can be done with 'site-location' can 
>> be done with groups.
>>
>>   
>Correct - there is also what we were thinking of  - a site location is 
>basically a group (saved in group_storage) and with 'resource': 
>site-location
>> 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)
>>   
>This is what is required for XCF-2407 - but we were thinking that it can 
>be useful to have a central place (a dedicated page for location) where 
>different location specific settings
>can be set...
>> D.
>>>

For the purpose of XCF-2407, i.e location used to select a GW/route for 
outbound calls, there is only one location required. We could extend that 
concept later so that the user could select a current location from the user 
portal if he/she roams around, but that is out of scope for XCF-2407.

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.).

--martin






_______________________________________________
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