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

[Saúl Ibarra Corretgé]

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


Cheers,

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