[asterisk-dev] SIP: So you mean you want to be able to *dial* something?
mmichelson at digium.com
Mon Feb 25 09:40:29 CST 2013
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
> 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.
> 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
> 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.
More information about the asterisk-dev