I’ve had numerous people bring up the new PJSIP configuration and scream bloody murder at how different it is. Whether it’s good or bad is certainly open to interpretation (hey look, my blog has no comment system… for once I think that actually makes me happy ;) but there are legitimate reasons for the way it is right now.
The configuration system is actually a thin wrapper over the new sorcery API. In fact the configuration module itself is generic and has no idea about the PJSIP module. It takes the config file, transmogrifies it into internal objects, and stores those away for later retrieval. This comes at a cost though. In sorcery parts of an object can’t easily be stored in different ways. An example of this would be peers in chan_sip. A peer is normally created as a result of information in a configuration file but host information (if they register) is stored both internally and in the astdb. This separation in sorcery is done by having different objects and because the configuration system is a thin wrapper… you end up having different objects.
I’ve experimented with storing parts of an object in different ways in sorcery but it’s not really nice looking and the code is extremely complicated. I did manage to do it without any modifications though, so yay for that!
2. SIP Concepts
The internal data structures within the PJSIP module more closely map to real SIP concepts. There are endpoints which describe the configuration to use when talking to a device, we have AORs that a device can register to it, we have contacts which contain information about how to contact something, and finally authentication credentials.
3. Storage of objects
Remember how I said that sorcery forces you to create different objects if you want them stored differently? This is actually pretty useful. You can have endpoints from a configuration file, AORs from a database, contacts in the local astdb. That would be a silly configuration but it’s possible.
These are a few reasons of why it is how it is. Sorcery sort of requires things to be configured the way they are, and we wanted it to use more SIP concepts.
Does it have to be this way, though?
The answer is no…
Internally things expect the different types to exist but it does not care how they are created. Something could be built on top which implements a “type=phone” that automatically creates an endpoint, AOR, and authentication. Has it been done yet? No, but it certainly could be.
This is a nice solid base that can be built upon.