[asterisk-dev] Opinions needed: Should PJSIP support enhancements still be allowed in 12->13?
Eric Wieling
EWieling at nyigc.com
Wed Oct 1 12:29:46 CDT 2014
>From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of George Joseph
>Sent: Wednesday, October 01, 2014 1:16 PM
>To: asterisk-dev at lists.digium.com
>Subject: [asterisk-dev] Opinions needed: Should PJSIP support enhancements still be allowed in 12->13?
>
>Even though I've been using pjsip on my dev and test machines for a year, it's only in the last few weeks I've tried to implement pjsip in a prod environment and that's brought up some >issues. Unfortunately now that we're close to a 13 release there's some trepidation about addressing these issues in 12->13 as opposed to just trunk...
>
>res_phoneprov: Today's phoneprov infrastructure is strictly chan_sip using users.conf and sip.conf for all user related configuration. There's no pjsip support there at all. I have 2 patches posted >to RB ([1], [2]) that make res_phoneprov pluggable and provide a pjsip provider for phoneprov. All existing functionality remains unchanged. You just get the same capabilities for pjsip that >you had for sip.
>
>manager/config: From a remote configuration management perspective The AMI commands GetConfig, GetConfigJSON and UpdateConfig allow you to manipulate Asterisk config files, BUT >they don't work well on configurations that can have multiple sections with the same name. This was rarely a problem before pjsip but now you can have an endpoint, an aor, an auth, an identify >and an registration all named 'myitsp'. This makes it impossible to manipulate them via AMI. I have a patch to enhance manager.config with that capability as well as the cabability to >manipulate config templates via AMI. [3]
>
>Finally, While thinking of alternatives for the config file dilemma, Josh, Brad and I tossed around the idea of a 'super' pjsip object or objects that could represent a 'trunk' or a 'user' thereby >eliminating having to specify separate endpoint, aor, auth, identify and registration objects for common scenarios. [4] I just started writing code for this today.
>
>So now the big question is... Can these items go into 12/13 or should they go only in ttrunk/14. I do need these patches but I can always apply them to my own distro. My opinion though is >that they should go into 12/13 to help speed the adoption of pjsip. No one who uses phoneprov or AMI to manipulate config files will able migrate otherwise. Having said that, I realize that 13 >GA is almost upon us and having defined cutoffs is a very good thing.
>
>Thought's? Opinions?
If PJSIP in Asterisk 13 is *supposed* to have feature parity with chan_sip, then I’d call the above items bugs rather than enhancements.
I strongly support the policy of “no new features” after a branch has been released, but sometimes the changes are so important they should be made anyway. AELSub is a great example of the latter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141001/cbdc786d/attachment.html>
More information about the asterisk-dev
mailing list