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

[Olle E. Johansson]

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.

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

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