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

Saúl Ibarra Corretgé saghul at gmail.com
Mon Feb 25 06:04:08 CST 2013

hey Josh!

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

I'll just throw my 2 cents here. I think we shouldn't expose multiple 
contacts to the user. The user will just dial the AoR and everything 
else would work behind the scenes.

Now, if one wants to dial a particular device he could just dial it's GRUU:

- saghul at sip2sip.info -> would fork to all my registered contacts
- saghul at sip2sip.info;gr=jhfu4hf09fpo4f -> would only dial those devices 
which specified that sip.instance when they registered.

So yeah, add GRUU to my shopping list then ;-)

Now, how to know what device I want to dial then? (someone may ask). 
This information can be learned with presence or with the reginfo event 
(add that one also to my shopping list).


Saúl Ibarra Corretgé
http://saghul.net/blog | http://about.me/saghul

More information about the asterisk-dev mailing list