[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