[asterisk-dev] [Code Review] Explicit context set in SIP peeroverridden by default domain context

[Olle E. Johansson]

22 apr 2010 kl. 14.16 skrev Nick Lewis:

>> We need to get domains into caller ID structure 
>> and into the extension somehow...
> I agree but this could be a bit tricky as sip domains contain dots which
> are already wildcards in the dialplan. Also domains in other
> technologies may take a different form.
I was thinking of a separate field, like CALLERID(domain)
To integrate it into the extension is propably an impossible task.
> 
> Is the @ character still available to be hyjacked for use as syntax in
> the dialplan? If so, extension/callerid matching could look something
> like:
> 
> exten =>
> _sales-!@secondtenant[.]com/_c[etf]o at topcustomer[.]com,1,noop(any sales
> team take this call now)
> 
>> On the topic of domain contexts I have at some 
>> point started working on collecting settings on 
>> a domain level so that we will have inheritance 
>> from [generic] defaults to [domain] defaults to 
>> peers in that domain. Trunk has a lot of global 
>> settings in a structure instead of separate 
>> variables because of this.
> Ok so this is a work in progress. I can see how this would help. A
> "phone" peer could be in a specific [domain] but a "service" peer could
> be in [general] and serve many tenants.
> 
>> The idea I had with the current domain context 
>> was just a replacement of the context in
>> general, without any inheritance to the peer. I 
>> don't know if this has been changed. Peers has 
>> no relationship to domains currently, which is 
>> where I was heading at some point.
> 
> My understanding is that Philip has found that there is inheritance to
> the peer context from the general domain-context in the current
> implementation and that is what he is trying to sort out. I do not know
> how long this functionality has been in place and how many people will
> scream if it is removed now

I just wonder how there's any connection between a peer and a domain.
There could be a mistake in the ordering of lookups though that is not really
related to domains.

/O