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

[Olle E. Johansson]

25 feb 2013 kl. 19:31 skrev Joshua Colp <jcolp at digium.com>:

> 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.
´
So how would device-state work here?

If one device is free and one busy - how would queue() parse that?

/O