[asterisk-scf-dev] New SIP configuration items

[Mark Michelson]

On 12/19/2011 10:51 AM, David Boyes wrote:
>> Based on the points raised above, it seems like there should be two routing
>> options. First, there should be an option to determine what service an
>> endpoint uses to route sessions from the endpoint. This option could be set
>> both in the general section or per endpoint. Second, there should be an
>> option to specify all routing services that should be able to locate an
>> endpoint. This, on the other hand, must be configured per endpoint.
>>
>> What are your thoughts on this approach?
> Rather than inventing a service-specific approach, I'd rather see a general policy service that returns the permitted relationships between two objects (in this case, routing services and endpoints). That would allow expressing a number of different relationships without inventing new ways to do it every time.
>
> Example:
>
> Policy(<endpoint>,<routing service>) would give you routing services permitted for that endpoint.
> Policy(<routing service>,<endpoint>) would give you endpoints available to a routing service.
>
> Null return = not permitted.
I've read this a few times and I'm not sure I totally get where you're 
coming from here.

First off, it seems like you're proposing a run-time hook rather than a 
preconfigured option. There can be a fine line regarding whether to 
implement something as pre-established configuration or as an extension 
point. In this case, we're not talking about information that varies 
from call to call, and we're not talking about something that would 
allow for a hook to "inject" itself into further operations. It feels 
more like something that should be configured in advance. The first 
Policy() call you show could be useful for exceptional cases where the 
routing service used needs to change temporarily (e.g. if the normal 
routing service for an endpoint is undergoing maintenance).

Second, I think the idea of having a general Policy() is not a good 
idea. I don't think a single generic interface could be developed that 
would work with all potential policies. The semantics could vary wildly 
depending on the types passed in; even in this specific example, the two 
calls to Policy() have very different meanings. Creating a general 
"Policy()" interface would also create situations where simple policy 
checks would have to conform to oddball syntax since more complex checks 
would require such syntax. I'm of the opinion that using smaller, 
domain-specific interfaces is easier to use, document, and understand. I 
also don't feel as though we would be re-inventing anything by creating 
separate interfaces for specific cases. It would certainly be possible, 
encouraged in fact, for new policy-based hooks to model themselves after 
existing ones. I don't feel that using the same interface for all of 
them is beneficial though.

Mark Michelson