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

[Olle E. Johansson]

22 feb 2013 kl. 22:55 skrev Jared Smith <jaredsmith at jaredsmith.net>:

> On Fri, Feb 22, 2013 at 8:19 AM, Joshua Colp <jcolp at digium.com> wrote:
>> There's a new small and straight forward API in the SIP work for location.
>> It allows querying for an AOR, getting contacts, adding contacts, and
>> updating contacts. It's really a thin wrapper around the new sorcery API
>> that adds automatic expiration of expired contacts and also static contacts.
>> Since it's using sorcery all of this can be stored wherever someone wants it
>> (flat file, local database, remote database, etc).
> 
> Awesome!
> 
>> Yes, you can have
>> multiple contacts for an AOR. The underlying API does not forbid this. For
>> external manipulation (a device registering) then the registrar would use
>> this API and enforce any restrictions on contacts.
> 
> Very awesome!  Can't wait to play with this.
> 
>> 1. Do we want my current usage options to go into the new SIP work?
> 
> Not really my call to make, but it sounds pretty good to me.
> 
>> 2. If not, how do we want to expose multiple contacts on an AOR?
> 
> I think it might be useful to have a dialplan function that returns an
> array of contacts, and then you can use dialplan code to cycle through
> them and do what you want with them.
> 
>> 3. If we don't want to, then do we even want to support multiple contacts
>> (for different targets) on an AOR?
> 
> Yes, please.

The question here is not about AOR or contacts, it's whether we want one sip account (not really the AOR since the AOR is the extension) to support multiple devices, like a hard phone and a sip softphone on a cellphone.

Do remember that there now are contacts with UUID/SIP.instance that is for ONE device - you can have multiple contacts for it - like SIP outbound or IPv4 and IPv6 contacts for the same device. This should not be exposed to the dialplan as multiple contacts, it's one device. Exposing them as multiple contacts will be very confusing and will cause errors.

I think we have to be careful here and expose the fact that we think there are multiple devices registred for an account and let the administrator decide how to behave. In any case, it has to be done in the dialplan within the dialstring concept and not somewhere else. Letting the SIP channel fork in a way hidden from the dialplan will cause very strange behaviour.

My old proposal of extending the HINT for every new device and use the ${HINT} variable in DIAL will still work for this.

And please make sure we use +sip.instance when Asterisk registers to a service.

/O