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

[Olle E. Johansson]

25 feb 2013 kl. 13:04 skrev Saúl Ibarra Corretgé <saghul at gmail.com>:

> 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).
I think we should have one "Dialplan SIP address" per account. Now we could enable sub-accounts for an account, but still expose them to the Dial string. What's the use case for dialing only one device registred to an account that can't be solved with multiple accounts?

We do need a conference call and whiteboard to discuss how to integrate outbound and gruu into this and handle various registration methods - including GIN (but not yet Tonic).

But first, we need to separate AOR for calls and AOR for registrations, unless we're going to come up with a totally new concept.

* The AOR is what we call to reach someone, exposed in the dialplan in Asterisk. 
* The AOR is the To: header in the registration, which is the SIP account name in SIP. 
* We could also start using the Digest Auth username because it doesn't need to be the same as the SIP account name.

We also need a name for a "group of contacts" that belong to the same +sip.instance - or device.
These involve:
- Different reg-id's 
- Different address families
- GRUU's

In addition we have the Path.

So one device can have up to at least six contacts registred, maybe more. 

For GIN, we need to accept a username-free contact and the new "replace username with phone number" concept when dialling out to the registred user. How this works with SIP outbound is something I haven't looked into. That's one RFC I did
not have reason to go through on my travels back home from SIPit, but will need to go back to again.

/O