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

[Olle E. Johansson]

25 feb 2013 kl. 16:40 skrev Mark Michelson <mmichelson at digium.com>:

> On 02/22/2013 09:19 AM, Joshua Colp wrote:
>> Hey all,
>> 
>> I've been tackling the area of outbound session creation in the new SIP work and the concept of location in general. I've experimented with stuff and ended up breaking it into two parts:
>> 
>> * Note #1: all of this is in a branch and has not yet been put up for review. I'd just like to hold a discussion about the usage aspect.
>> ** Note #2: you can still dial straight up SIP URIs regardless of this work.
>> 
>> Storage
>> 
>> 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). 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.
>> 
>> Usage
>> 
>> When I say usage I'm referring to actually using the above information for the purposes of setting up a session. I've sort of demoed/accomplished this twofold:
>> 
>> The GULP_DIAL_CONTACTS dialplan function produces a properly formatted dial string which creates a channel for each contact on an AOR. This can be pretty expensive, since you've got an Asterisk channel + RTP instance + SIP internal structure + pjsip internals, but it works!
>> 
>> You can dial just the AOR. This uses a single Asterisk channel, a single SIP internal structure, a single RTP instance, but multiple pjsip internal structures. It's not as heavy as GULP_DIAL_CONTACTS but accomplishes the same thing in the end and yes, it works. This was really a *can I do this* thing and a few hours later it was up and running.
>> 
>> So really, my questions are:
>> 
>> 1. Do we want my current usage options to go into the new SIP work?
> 
> tl;dr version: yes, but we need to be careful
> 
> And now the long version:
> 
> The ability to dial an AoR and result in multiple devices being called is cool. Since AoRs generally map to a single logical entity (e.g. "Bob" or "a member of the sales queue"), it makes a lot of sense to dial an AoR as a single thing from the dialplan. Also, since Asterisk still sees the most use as a PBX, dialing an AoR will, the majority of the time, result in a single device being called.
> 
> On the other hand, it seems like it's going to result in logic from app_dial being replicated in chan_gulp. For instance, app_dial currently could dial two SIP peers, have one return a 404 and the other return a 486 and it would know what hangupcause to report. Now that same sort of hangup cause aggregation logic has to be applied to chan_gulp. Same thing goes for connected line and redirecting aggregation when dialing multiple entities. Similarly, app_dial (likely) has code in it that makes it so that early media from multiple sources is handled gracefully. Now that has to be in chan_gulp also. Furthermore if one of the devices being dialed forwards the call, that can create a myriad of difficulties. What if the forward is to a non-SIP device? What if call forwards are supposed to be ignored on this call?
> 
> For people who want to do oddball things with contacts and AoRs, having something like Jared suggested would be useful: have a dialplan function to return an array of contacts, allowing for them to create any sub-combination of contacts to be placed in a Dial. Ideally, people wouldn't be binding logically disparate contacts to an AoR in this way, but people are weird. This also could be (at least short term) a solution for OEJ's point about how contacts are not necessarily equal to devices. For people in situations where they know that multiple contacts actually map to the same device (but who don't use Outbound or other means of specifying device IDs) they can use the dialplan function to cut out redundant contacts.
> 
> As OEJ has brought up, we will have to be careful with what we end up dialing when dialing an AoR though since one contact does not always equal one device.
We do need to have a few real-time discussions on this. 
>> 
>> 
>> 2. If not, how do we want to expose multiple contacts on an AOR?
>> 
>> 3. If we don't want to, then do we even want to support multiple contacts (for different targets) on an AOR?
>> 
>> 4. What would *you* like usage of this to be like?
> 
> Tell me what you think of this:
> 
> We change ast_request() to be able to return multiple channels. Or we add a new function ast_request_multiple() that can be called if a channel technology supports multiple devices per dial target. This way, someone can specify a SIP AoR to be dialed and chan_gulp can return multiple channels that map to the devices bound to the AoR. This does become "expensive" in the sense that there are multiple channels, RTP structures, SIP sessions, etc. allocated, but it also means that there is no need to replicate app_dial logic in chan_gulp for outbound calls.
If we break this up, device-states and other things will have to be redesigned to be on a contact level and not on a SIP account level (trying to avoid "peer" and "user") like we have today.


> 
> We can still offer a dialplan function for getting a list of the bound devices if someone wishes to be able to specify certain ones in a Dial for whatever reason.

Another reason for wanting to actually parse contacts in the dialplan is to be able to reach contact header parameters, like "I support video". Unless we create a protocol-independent device query API, which would feel more like an Asterisk-way of handling things.

/O