<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 6, 2014 at 12:02 PM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=mjordan@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">mjordan@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">><br>
>>Even though I've been using pjsip on my dev and test machines for a year,<br>
>> it's only in the last few weeks I've tried to implement pjsip in a prod<br>
>> environment and that's brought up some >issues. Unfortunately now that<br>
>> we're close to a 13 release there's some trepidation about addressing these<br>
>> issues in 12->13 as opposed to just trunk...<br>
><br>
<br>
Two thoughts here.<br>
<br>
1) Generally, I think the standard/LTS release cycle works pretty<br>
well. We got a lot of good feedback during the past 10 months from<br>
Asterisk 12, and I think we've seen some good adoption. Certainly<br>
we've gotten plenty of good bug reports against the PJSIP stack, and<br>
that generally tends to imply that people are using it. From the<br>
perspective of the intended purpose of "standard" and "LTS" releases,<br>
this is meeting what we hoped would happen.<br>
<br>
2) On the other hand, we did a lot of work in 12, and I think we might<br>
have done too good a job warning people. Thinking back to Asterisk 10,<br>
it does feel like fewer people have made the leap to 12 than the<br>
number of people who leaped to 10. I don't think this is a problem<br>
with upgrading or lack of information - if anything, we have a lot<br>
better documentation now than we did then (and yes, it could still be<br>
improved upon, no arguments there) - but we did warn people about the<br>
upgrade path. Plus, you can upgrade to 12 and _not_ use the new PJSIP<br>
stack, which means we might have had a good chunk of people upgrade<br>
and just not try it out yet.<br>
<br>
So there's some conflict here: on the one hand, we've seen progress;<br>
on the other, we're bound to still get some serious issues with people<br>
who are attempting to deploy something in their production<br>
environment. If we don't fix those kinds of issues, then people will<br>
have to wait another two years for the next LTS.<br>
<br>
><br>
>>res_phoneprov: Today's phoneprov infrastructure is strictly chan_sip using<br>
>> users.conf and sip.conf for all user related configuration. There's no<br>
>> pjsip support there at all. I have 2 patches posted >to RB ([1], [2])<br>
>> that make res_phoneprov pluggable and provide a pjsip provider for<br>
>> phoneprov. All existing functionality remains unchanged. You just get<br>
>> the same capabilities for pjsip that >you had for sip.<br>
><br>
<br>
I don't think there's any question that the patches you've put<br>
together are the right approach. It's definitely very, very good work.<br>
<br>
><br>
>>manager/config: From a remote configuration management perspective The AMI<br>
>> commands GetConfig, GetConfigJSON and UpdateConfig allow you to manipulate<br>
>> Asterisk config files, BUT >they don't work well on configurations that can<br>
>> have multiple sections with the same name. This was rarely a problem before<br>
>> pjsip but now you can have an endpoint, an aor, an auth, an identify >and an<br>
>> registration all named 'myitsp'. This makes it impossible to manipulate<br>
>> them via AMI. I have a patch to enhance manager.config with that<br>
>> capability as well as the cabability to >manipulate config templates via<br>
>> AMI. [3]<br>
><br>
<br>
Again, this is a good find and a good improvement to make an existing<br>
command work with the new configuration schemas.<br>
<br>
><br>
>>Finally, While thinking of alternatives for the config file dilemma, Josh,<br>
>> Brad and I tossed around the idea of a 'super' pjsip object or objects that<br>
>> could represent a 'trunk' or a 'user' thereby >eliminating having to specify<br>
>> separate endpoint, aor, auth, identify and registration objects for common<br>
>> scenarios. [4] I just started writing code for this today.<br>
><br>
<br>
This one still feels like an open debate to me (sorry!) :-)<br>
<br>
I'll defer that conversation to the thread you have going on it.<br>
<br>
><br>
>>So now the big question is... Can these items go into 12/13 or should<br>
>> they go only in ttrunk/14. I do need these patches but I can always apply<br>
>> them to my own distro. My opinion though is >that they should go into 12/13<br>
>> to help speed the adoption of pjsip. No one who uses phoneprov or AMI to<br>
>> manipulate config files will able migrate otherwise. Having said that, I<br>
>> realize that 13 >GA is almost upon us and having defined cutoffs is a very<br>
>> good thing.<br>
><br>
>><br>
><br>
>>Thought's? Opinions?<br>
><br><br></blockquote><div> </div><div><snip></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So that is some rambling thoughts. Where are we at?<br>
<br>
Clearly, there are some existing commands and infrastructure pieces<br>
that don't support the new PJSIP stack. For people to make use of<br>
their existing Asterisk setups, there would ideally be a way for them<br>
to support PJSIP.<br>
<br>
At the same time, we have also reached a point where we need to be<br>
very mindful of changes. Long Term Support releases should not receive<br>
the same kinds of additions as Standard releases: we should err on the<br>
side of caution and stability.<br>
<br>
I think we need to find a way to balance stability and functionality.<br>
This ideally would be something to hash out in two weeks at<br>
AstriDevCon, as we usually spend a good chunk of time working through<br>
project policies there. George's patches would ideally be available in<br>
13.0.0 (if everyone were okay with them going into that branch), so<br>
waiting until AstriDevCon to get a final say-so on the patches would<br>
not be a good idea.<br>
<br>
Therefore, what I'm proposing is the following:<br>
<br>
* For each change set listed above, I think we cannot have them merged<br>
into a branch of Asterisk without accompanying automated tests. In the<br>
case of both changes, nominal tests should be possible using the<br>
Asterisk Test Suite. If you need a hand with writing some of those<br>
tests, I'd be glad to help out with them. We can identify what those<br>
tests should be on this thread and work through that if you'd like.<br>
* At AstriDevCon, I think we need to consider laying out a proposal<br>
for a policy for changes in branches. I hesitate to do this here and<br>
now, as AstriDevCon is a great place to get a general consensus<br>
suitable for submitting to everyone on the mailing list. As a seed for<br>
thought, I'd state that the world we live in now and the state of the<br>
Asterisk project as it is today is not the same as when the zero<br>
tolerance "no new features in release branches" policy was first<br>
enacted. That is not a criticism of the policy, just a reflection that<br>
we have a lot of tests, continuous integration infrastructure, and<br>
other constraints that were not present at that time. But that's a<br>
rant best served in Las Vegas.<br>
<br>
Thoughts?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Thanks Matt! I do have unit tests for the config.c changes but the rest do need TestSuite tests as well. I actually started looking at these this weekend. The test for the AMI changes I can easily clone from existing AMI tests. The phoneprov test is even easier since it just has to look at the output of a text file. I should have those done this week.</div><div><br></div><div>The phoneprov and manager/config change sets both have "ship It"s but I'll hold off committing them until the tests are ready.</div><div> </div><div>george</div><div><br></div></div></div></div>