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

[Mark Michelson]

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.
>
>
> 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.

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.

>
> Cheers,
>