[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 10:59:10 CST 2013
> 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.
> 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
- Different address families
> In addition we have the Path.
But that will affect routing, not choosing to what addresses to route to.
> So one device can have up to at least six contacts registred, maybe more.
Many 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.
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
Saúl Ibarra Corretgé
http://saghul.net/blog | http://about.me/saghul
More information about the asterisk-dev