[asterisk-dev] New SIP Channel Driver Data Access Layer

[Olle E. Johansson]

3 dec 2012 kl. 17:04 skrev Joshua Colp <jcolp at digium.com>:

> Hi everyone!
> 
> I know it's been a bit since the new SIP channel driver has been talked about on the -dev list but I'd like to change that with this email. You may look at the subject and go "huh? what?" so let me explain a bit. As many of us know there are just some fundamental aspects of a channel driver that have to exist, outside of other decisions being made (such as chosen SIP stack). Configuration and the data objects that entails is one of them.
> 
> In past times there has never been a real clear boundary between the user of the data, the data itself, and that which provides or stores the data. Stuff has sort of leaked and blended together all over especially when it comes to real time. The data access layer is one different approach in the new SIP channel driver to help with this. All of the logic (configuration file access, real time, etc) will be hidden behind a unified API and the consumer will be none the wiser. Any details specific to the logic will be isolated to its implementation and will not have to be maintained outside of it. This will also allow the implementations to easily change without having to make major modifications to the rest of the channel driver if need be.
> 
> Before going down the road of looking at what such an API might look like though I've put together what I think are the fundamental objects it would provide. These do *not* represent every object that will exist or every option. More will naturally be defined as development progresses and additional features and functionality are implemented.
> 
> To help track this effort I have created a wiki page at https://wiki.asterisk.org/wiki/display/AST/SIP+Data+Access+Layer+Objects which contains my stab at the fundamental objects.
> 
> This is by no means set in stone which is why I'm sending this email as I'd like to bring about discussion to come to a collective agreement on what they should be and to get some input from others.
> 
> What are YOUR thoughts?

A lot of these needs to be grouped into a "domain" object. an AOR belongs to a Domain, like a certificate. When resolving a domain with NAPTR/SRV, you get a list of endpoints using various transports, ports and addresses in various families.

/O