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

[Saúl Ibarra Corretgé]

Olle E. Johansson wrote:
> 25 feb 2013 kl. 17:59 skrev Saúl Ibarra Corretgé<saghul at gmail.com>:
>
>>> 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?
>>>
>> That looks like replicating what GRUU does, so why do it then? :-)
>>
>>> 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).
>>>
>> I haven't looked deeply into GIN (without tonic) but how do you think outbound affects this? If the "Dialplan SIP Address" is the AoR then when you Dial(SIP/oej at edvina.net;gr90e39898908) Asterisk should route it to all devices with that instance ID.
> THat's a different use-case. DIAL(SIP/<sip uri>) is bypassing the SIP accounts totally. THat's always available, but then you ignore any settings used in the configuration objects.
>

I guess my "user at domain ALL THE THINGS" thinking surfaced here :-) What 
if we could identify configuration objects like that? I *think* Josh 's 
original email had this in mind, somehow. Josh?

>>> 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
>>>
>> rAren't reg-ids associated with a sip.instance? So the way I see it we have:
>>
>> - Different sip.instance contacts with may have multiple undelying contacts
>     - Gruu's
>    - Reg-ids
>> - Different address families
> You just grouped them higher. But the Reg-IDs could also have different address families, so one Reg-ID with the same
> instance and one Contact for IPv4 and one for IPv6.
>
> You can also have a non-sip-instance device sending in multiple contacts, like IPv4 and IPv6. We saw this on SIPit.
>

I see. In any case, it's a list that can be flattened and filtered by 
instance id and/or address family, I'd assume.

>>> In addition we have the Path.
>>>
>> But that will affect routing, not choosing to what addresses to route to.
> Right. But it needs to be stored somewhere to find the device :-)
>
>>> So one device can have up to at least six contacts registred, maybe more.
>>>
>> Many more! ;-)
> Yep!
>
> Which makes it harder if we allow multiple devices to share one "account". If a device (without instance-id) reboots and re-registers from a new DHCP address (or goes from 3G to Wifi and re-registers), we suddenly have an "older" set of contacts and a new set of contacts for the same device without knowing it. How do we handle that situation?
>

We can't handle that. If the device goes away, bad luck, we'll try to 
route calls there anyway and fail. Unless qualify is set, in which case 
it can potentially be detected earlier. I'm not sure if one can set TCP 
keepalive for SIP TCP connections in Asterisk, but that could also help. 
Both OpenSIPS and Kamailio have it.

> We need to document all of this and come up with a solution that can be both supported and pbx architecture as well as SIP  compliant.
> /O
>
>>> 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
>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>     http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>> --
>> Saúl Ibarra Corretgé
>> http://saghul.net/blog | http://about.me/saghul
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-dev


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