[asterisk-dev] SIP: So you mean you want to be able to *dial* something?

[Chris Lee]

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
> pick/choose
>
> 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
> want.
>
Hi All,

My expected use case as a user is that I would expect to be able to do the
following:
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
identities/phone numbers
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.

Regards,
Chris.