[asterisk-dev] SIP: So you mean you want to be able to *dial* something?
cslee-list at cybericom.co.uk
Mon Feb 25 14:33:46 CST 2013
On 25/02/13 18:31, Joshua Colp wrote:
> Since the conversation has gotten so... large... I'm snipping and summarizing.
> A lot of excellent points have been raised but I'd like to keep us focused on
> things here relating to how we dial things and how that is expressed to the
> end user. Stuff relating to registrar support and additional functionality
> that would entail I would prefer that we wait until we get to that feature
> before talking about it. It's a bit premature for this discussion. The design
> and usage of location shouldn't preclude the implementation.
> I've heard throughout the years that people want to register multiple
> *devices* to an account. I personally would use that in an instant and an
> actual user, Jared, has expressed interest in this thread itself for that.
> We've also got multiple contacts for a single device these days as Olle has
> raised. These are all things to take into account. Fundamentally though why is
> this hard? Well... it's not something that's really ever been done in
> Asterisk. Does that mean we shouldn't do it? I don't think so. It's just
> uncharted territory.
> We seem to really be coming at this from a few different views:
> 1. Only allow multiple contacts for a single device, use multiple accounts for
> multiple devices
> 2. Allow multiple devices and expose this minimally to the core by allowing
> channel drivers to return multiple channels when dialed
> 3. Allow multiple devices and change the core to be better aware of it by
> extending view 2 to include automatic hint updating, device state, and
> per-contact and per-device capability knowledge
> 4. Allow multiple devices and expose without using the core, use a dialplan
> function to return contacts and allow user to iterate as they see fit and
> I think really from my personal perspective a combination of 2 and 4 is what
> we should do at this point in time, using the approach that Mark has
> mentioned. Yes it's a compromise but I came to that conclusion based on what I
> feel we can achieve and what I've seen people ask for throughout the years.
> Changing the core slightly to allow returning multiple channels is a minor
> change that is not terribly invasive. Providing the ability to retrieve and
> explicitly dial specific contacts is also minor.
> Making the core better aware of this should be a goal in the future but at
> this point in time I think with the above we can meet what a lot of end users
My expected use case as a user is that I would expect to be able to do the
1. From any device log into my account so that calls destined for my account
would route to that device.
2. Decide weather 1 or more of my devices would stay connected when I log in
from a new device.
3. Configure my account to receive/route calls for any or all my
4. Configure routing rules for each identity so that calls to those identities
would route to the devices (list of previously logged in devices etc.) I have
designated at the times I have designated if I am logged in on those devices.
5. Make changes to my account settings from a logged in device or web browser.
Not technical I know but I think this is the place we should be looking at how
the user expects to use the system and work out how to go from there.
I have used a fair few PBX systems and the ones that give that level of
functionality give a user much more flexibility and prevent the limitations of
the device centric systems.
More information about the asterisk-dev