Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal

[Michael L. Young]

- On Nov 9, 2020, at 8:23 AM, Joshua C. Colp  wrote: 

> Since this is the first real time formalizing this once all the things are in
> place (process documented on wiki, deprecation list created from existing 
> state
> of things) I'll likely send out an email to -users and also post on the
> community forums so people are aware.

> Sound good to everyone?

Sounds like a good approach and reasonable. 

-- 
Michael L. Young 

(elguero) 
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal

[Michael L. Young]

- On Oct 1, 2020, at 6:45 PM, Seán C McCord ule...@gmail.com wrote:

> On Thu Oct 1, 2020 at 3:07 PM EDT, Joshua C. Colp wrote:
>> I think I personally hesitate to be so aggressive because long ago the
>> project was that way. We would push to remove things faster and such,
>> and the result was upset people and complaints. Years later I still had
>> people coming up to me at AstriCon talking about that stuff and how it 
>> screwed
>> them over.
> 
> I think this is a key point which we, as developers and integrators can easily
> overlook.  We're being pulled in two direction:  one, we must always keep
> up-to-date in our implementations, and two, we must be able to work with what
> the customers are willing to use.  Once things are deprecated, it is far 
> easier
> to push the customer to do the right thing.  Removal makes this easier.  Thus,
> faster deprecation and removal is better for the
> integrator/developer/consultant.
> 
> But we do not represent more than the barest fraction of the Asterisk user 
> base.
> The greater portion is running production workloads with very low tolerance
> for either change or down-time, and are resultingly very conservative with
> their upgrades and loathe to spend great effort into managing those upgrades.
> 
> If we accelerate deprecation, we may end up making the problem _worse_ (as it
> used to be), where users would simply not upgrade at all, because it was too
> difficult to do so.
> 
> I agree that 4 years feels like an eternity to _me_, but to an operator 
> working
> with very slim margins, it is not nearly so glacial.
> 

Totally agree with Seán's assessment.

--
Michael Young

(elguero)

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal

[Michael L. Young]

- On Oct 1, 2020, at 7:56 AM, Joshua C. Colp  wrote: 

> Greetings all,
> Around this time each year a discussion always spurs (be it on IRC or at
> AstriDevCon) about deprecating modules, and removing them. I always find 
> myself
> asking "what is our real process for doing this?" in my head and end up trying
> to piece it together based on some information here and there on the wiki plus
> past experience. I'd like to better document this and put something more
> concrete into place. To that end I'd like to propose the following:

> 1. All the changes listed below initially occur in standard releases - in my
> opinion beginning the process to remove a module is a big thing and we should
> gradually introduce it, gaining feedback from those who run standard releases
> first.
> 2. The first step is marking a module as deprecated and occurs for 1 standard
> release and 1 LTS release
> 3. The second step is marking a module as defaultenabled no which means it 
> will
> not be built by default. This occurs for 1 standard release and 1 LTS release
> 4. The third step is removing the module
> 5. There will be a wiki page to keep track of all modules which are in the
> process of being removed
> 6. When a new LTS branch is created the master branch becomes eligible again 
> for
> changing the state of modules, a reminder can be done as part of cutting the
> LTS branch

> Thoughts?

The steps outlined seem very reasonable and appropriate. 

Great job on getting this hashed out and documented. 

-- 
Michael Young 

(elguero) 
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Michael L. Young]

- On Jul 8, 2020, at 8:20 AM, Joshua C. Colp  wrote: 

| I'd like to propose that instead of cutting the 18.0 branch on July 15th we
| simply cut the 18 branch, and that it continues to receive all bug fixes.
| Approximately a month before a target release of 18.0.0 we create the first
| release candidate, 18.0.0-rc1. At this time we also create release candidates
| of the other branches. All release candidates will then be left available for 
a
| prolonged period of time to give people ample time to test. On the release 
date
| all will be released, ensuring that all branches including 18 have the same 
set
| of bug fixes as appropriate to their version.

| This removes the confusion for developers over whether to include a fix, since
| the 18.0 branch won't exist until rc1 at which point normal cherry pick rules
| apply. This also eliminates the confusion experienced by users since all
| releases will be on the same page at the same time at release.

| What do people think? Do we believe that a month out is ample enough? The 18
| branch itself will exist, so that can be used for early testing (and likely
| will be). If a month isn't enough it could be moved out further. Really I 
think
| thanks to the testing that happens and the code review I don't think we need 
as
| long of a stabilization period as has been needed in the past, so this helps
| shrink it.

The proposal sounds very reasonable. Yes, with all the testing that is in the 
project now, a month should be good enough. 

-- 
Michael L. Young 
(elguero) 
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Adding new ARI for application execute

[Michael L. Young]

- Original Message -
> From: "Sung-tae Kim" 
> To: "Asterisk Developers Mailing List" 
> Sent: Thursday, April 4, 2019 4:35:47 AM
> Subject: Re: [asterisk-dev] Adding new ARI for application execute

> 2019년 4월 4일 (목) 오전 12:07, Matt Fredrickson < [ mailto:cres...@digium.com |
> cres...@digium.com ] >님이 작성:

I concur with Joshua and Matt.

Just because you can do something doesn't mean you should.  We should be using 
the
right tool for the right job.  This is just setting the wrong precedent on how 
ARI
is intended to be used.


Michael L. Young
(elguero)

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Where is pjsip_evsub_set_uas_timeout?

[Michael L. Young]

- Original Message -
> From: "Alexander Traud" <pabstr...@compuserve.com>
> To: "Asterisk Developers Mailing List" <asterisk-dev@lists.digium.com>
> Sent: Wednesday, October 18, 2017 5:02:47 AM
> Subject: [asterisk-dev] Where is pjsip_evsub_set_uas_timeout?

> Because I use not the bundled PJProject, I have to examine whether Configure
> finds all symbols with my external PJProject 2.7. For
> "pjsip_evsub_set_uas_timeout" it is not able to do so. Before I investigate
> why, I would like to know where this is used in Asterisk at all. I found
> neither that symbol nor its guard (#if HAVE_xyz).
> 
> References
> <http://gerrit.asterisk.org/4916>
> <http://trac.pjsip.org/repos/changeset/5558>

According to the commit message, I don't believe it is used.

"An earlier approach was to add support for setting pjproject's timer (via a 
pjproject patch) and while that patch is still included here, we don't use that 
call at the moment."

--
Michael L. Young

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal to bring pjproject back into the fold

[Michael L. Young]

> From: "Jeffrey Ollie" 
> Sent: Wednesday, January 20, 2016 3:28:44 PM

> On Wed, Jan 20, 2016 at 11:04 AM, Tzafrir Cohen <
> tzafrir.co...@xorcom.com > wrote:

> > Hang on. This is RHEL. A stable platform. Why can't they just use
> 
> > pjproject packages and be done with it?
> 

> It's been my experience that a large number of Asterisk users compile
> almost everything from source because that's the way they've always
> done things, partly because that's just the way that they like to do
> things, and partly because that's the way they had to do it back
> when you couldn't get Asterisk packages and the only way to get it
> was to compile it yourself.

> --

> Jeff Ollie

I have to agree here with Jeff. 

Could most of the issues that are being encountered have to do with users 
upgrading their version of Asterisk on the same machine where they now have a 
mix of installed libraries instead of building a new system from scratch? Could 
that be part of the problem? 

My gut feeling is that users upgrading from Asterisk 11 to 13 are not reading 
the wiki. They are trusting that they already know how to install and setup 
Asterisk based on their prior experience and do not realize that PJSIP needs to 
be handled differently between those versions. I know the comment on the wiki 
that there is an Asterisk compatible version of pjproject available on github 
would make me think that I should be installing that rather than using the one 
provided by my Linux distro of choice because it would cause me less problems. 
At least that is what my first thought would be. Especially when I see later on 
in the wiki is describing downloading a newer version of the pjproject than 
what my distro provides. Again, someone looking at this page briefly and in a 
hurry, if they are looking at all, could miss a lot of the details that are 
right there if they would just pay attention to it. 

We used to compile Asterisk because that is what was always done and how we 
were always shown how to get Asterisk installed. Also, we could deal with the 
occasional hiccups from using the latest and greatest when it came to libraries 
and applications. There were no packages for Asterisk and in order to have 
latest and greatest with all those bug fixes in them, it was best to get the 
latest code and compile it. 

Now, times have changed. We need to use packages and choose to use stable 
packages wherever it is possible. As our company has grown, security standards 
and stability now take priority over the easiness that comes with downloading 
and compiling. We are no longer allowed to have code or any development tools 
on our production servers. 

The steps that the project took over the past few years to make Asterisk easier 
for those of us who now are required to create / use the packages for our 
production servers was great and it helped to ease our burden. 

Perhaps it is just a culture change within the community in regards to how we 
are accustomed to getting Asterisk on our systems and this is part of the pains 
associated with this shift in what was once considered the "norm". 

Anyways, just some insight from a different perspective on this issue. 

I completely understand the problems that Matt outlines. The issue, from what I 
understand, has to do with user experience and the ability to support the user. 
We have two different projects with two different approaches. It is too late 
now but I believe one of the main concerns with going with a third-party SIP 
stack during those discussions was whether or not we could work with the 
upstream whenever a problem arised. It would appear that this goal is not 
easily attainable with pjproject based on what Matt just outlined in his prior 
email if I understood it correctly. If the only way to keep Asterisk moving 
forward without wasting time and effort on the same problem over and over again 
is to bring it back in, then I think the decision to be made is very easy. The 
rest of us will have to find a way to deal with it when it comes to packaging. 

Just my thoughts that I have been having for the past few days while following 
these discussions. I hope it helps to give some more insight from the "front 
lines" perspective while trying to make a decision on this. 

Michael 

(el guero) 
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in repotools[master]: Add web proxy support to commit_msg.py

[Michael L. Young (Code Review)]

Michael L. Young has uploaded a new patch set (#3).

Change subject: Add web proxy support to commit_msg.py
..

Add web proxy support to commit_msg.py

This patch allows the commit_msg.py script to connect to the issue
tracker from behind a web proxy in order to get the data it needs
to create the commit message template.

Change-Id: Ie71ccb85e09cce005847ce9bf70c603fbee3d58a
---
M commit_msg.py
1 file changed, 20 insertions(+), 15 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/repotools refs/changes/13/13/3
-- 
To view, visit https://gerrit.asterisk.org/13
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Ie71ccb85e09cce005847ce9bf70c603fbee3d58a
Gerrit-PatchSet: 3
Gerrit-Project: repotools
Gerrit-Branch: master
Gerrit-Owner: Michael L. Young elgueromexic...@gmail.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in repotools[master]: Add web proxy support to commit_msg.py

[Michael L. Young (Code Review)]

Michael L. Young has uploaded a new patch set (#2).

Change subject: Add web proxy support to commit_msg.py
..

Add web proxy support to commit_msg.py

This patch allows the commit_msg.py script to connect to the issue
tracker from behind a web proxy in order to get the data it needs
to create the commit message template.

Change-Id: Ie71ccb85e09cce005847ce9bf70c603fbee3d58a
---
M commit_msg.py
1 file changed, 20 insertions(+), 15 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/repotools refs/changes/13/13/2
-- 
To view, visit https://gerrit.asterisk.org/13
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Ie71ccb85e09cce005847ce9bf70c603fbee3d58a
Gerrit-PatchSet: 2
Gerrit-Project: repotools
Gerrit-Branch: master
Gerrit-Owner: Michael L. Young elgueromexic...@gmail.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in repotools[master]: Ignore JIRA uploads with license #2.

[Michael L. Young (Code Review)]

Michael L. Young has posted comments on this change.

Change subject: Ignore JIRA uploads with license #2.
..


Patch Set 1: Code-Review+1

-- 
To view, visit https://gerrit.asterisk.org/12
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ia76d2fe7e7357901f0e38b158b42f4323ccd120f
Gerrit-PatchSet: 1
Gerrit-Project: repotools
Gerrit-Branch: master
Gerrit-Owner: Corey Farrell g...@cfware.com
Gerrit-Reviewer: Michael L. Young elgueromexic...@gmail.com
Gerrit-HasComments: No

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in repotools[master]: Add web proxy support to commit_msg.py

[Michael L. Young (Code Review)]

Michael L. Young has uploaded a new patch set (#2).

Change subject: Add web proxy support to commit_msg.py
..

Add web proxy support to commit_msg.py

This patch allows the commit_msg.py script to connect to the issue
tracker from behind a web proxy in order to get the data it needs
to create the commit message template.

Change-Id: Ie71ccb85e09cce005847ce9bf70c603fbee3d58a
---
M commit_msg.py
1 file changed, 20 insertions(+), 15 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/repotools refs/changes/13/13/2
-- 
To view, visit https://gerrit.asterisk.org/13
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Ie71ccb85e09cce005847ce9bf70c603fbee3d58a
Gerrit-PatchSet: 2
Gerrit-Project: repotools
Gerrit-Branch: master
Gerrit-Owner: Michael L. Young elgueromexic...@gmail.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in repotools[master]: Add web proxy support to commit_msg.py

[Michael L. Young (Code Review)]

Michael L. Young has uploaded a new change for review.

  https://gerrit.asterisk.org/13

Change subject: Add web proxy support to commit_msg.py
..

Add web proxy support to commit_msg.py

This patch allows the commit_msg.py script to connect to the issue
tracker from behind a web proxy in order to get the data it needs
to create the commit message template.

Change-Id: Ie71ccb85e09cce005847ce9bf70c603fbee3d58a
---
M commit_msg.py
1 file changed, 20 insertions(+), 15 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/repotools refs/changes/13/13/1

diff --git a/commit_msg.py b/commit_msg.py
index e342d47..fa7a8a5 100755
--- a/commit_msg.py
+++ b/commit_msg.py
@@ -9,7 +9,7 @@
 - Add patch license number when available via REST
 
 
-from httplib import HTTPSConnection
+from urllib2 import Request, urlopen, URLError
 from optparse import OptionParser
 import sys, os
 import json
@@ -23,16 +23,18 @@
 if not args:
 print  sys.stderr, Requres a JIRA issue number
 sys.exit(1)
-
-con = HTTPSConnection('issues.asterisk.org')
-con.request(GET, /jira/rest/api/latest/issue/%s/ % (args[0],))
-res = con.getresponse()
-data = json.loads(res.read())
-
-if res.status != 200:
-print  sys.stderr, res.status, res.reason
-print  sys.stderr, json.dumps(data, indent=4)
-sys.exit(1)
+try:
+req = Request('https://issues.asterisk.org/jira/rest/api/latest/issue/%s' 
% (args[0],))
+res = urlopen(req)
+except URLError as e:
+if hasattr(e, 'reason'):
+print  sys.stderr, 'Reason: ', e.reason
+sys.exit(1)
+elif hasattr(e, 'code'):
+print  sys.stderr, 'Error code: ', e.code
+sys.exit(1)
+else:
+data = json.loads(res.read())
 
 print \nDoes this commit close issue %s? (y/n) % (args[0],),
 if raw_input()[0] in ['y', 'Y']:
@@ -59,11 +61,14 @@
 for x in data['fields']['attachment']:
 licenseid = 0
 try:
-con.request(GET, /jira/rest/api/2/attachment/%s/ % x['id'])
-res = con.getresponse()
+req = 
Request('https://issues.asterisk.org/jira/rest/api/2/attachment/%s/' % x['id'])
+res = urlopen(req)
 licenseid = json.loads(res.read())['properties']['license']
-except:
-'''Supress Exception'''
+except URLError as e:
+if hasattr(e, 'reason'):
+print  sys.stderr, 'Reason: ', e.reason
+elif hasattr(e, 'code'):
+print  sys.stderr, 'Error code: ', e.code
 attachments.append(%s submitted by %s (license %d) % 
(x['filename'], x['author']['name'], licenseid))
 except:
 attachments = None

-- 
To view, visit https://gerrit.asterisk.org/13
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ie71ccb85e09cce005847ce9bf70c603fbee3d58a
Gerrit-PatchSet: 1
Gerrit-Project: repotools
Gerrit-Branch: master
Gerrit-Owner: Michael L. Young elgueromexic...@gmail.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in repotools[master]: Update commit_msg.py output format.

[Michael L. Young (Code Review)]

Michael L. Young has posted comments on this change.

Change subject: Update commit_msg.py output format.
..


Patch Set 2: Code-Review+1

(2 comments)

Everything looks good.

https://gerrit.asterisk.org/#/c/6/2/commit_msg.py
File commit_msg.py:

Line 68: attachments.append(%s uploaded by %s (license %d) % 
(x['filename'], x['author']['name'], licenseid))
One minor thing I noticed when looking at the wiki for commit messages.

It looks like uploaded by has been replaced with submitted by?  I didn't 
realize that had changed until now when reviewing the wiki page.


Line 106: f.write(Patches:\n)
Just a nit-pick.

It would seem (in looking at changes to the wiki page) that Patches was 
intentionally changed to lower case patches.  I guess that is now preferred.  
I looked at recent commit messages and that appears to be the case.


-- 
To view, visit https://gerrit.asterisk.org/6
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If9f3a7adf2ca0d1d38d625fc5ba6922b99fb37f7
Gerrit-PatchSet: 2
Gerrit-Project: repotools
Gerrit-Branch: master
Gerrit-Owner: Corey Farrell g...@cfware.com
Gerrit-Reviewer: Michael L. Young elgueromexic...@gmail.com
Gerrit-HasComments: Yes

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in repotools[master]: Update commit_msg.py output format.

[Michael L. Young (Code Review)]

Michael L. Young has posted comments on this change.

Change subject: Update commit_msg.py output format.
..


Patch Set 4: Code-Review+1

(1 comment)

https://gerrit.asterisk.org/#/c/6/4/commit_msg.py
File commit_msg.py:

Line 105: f.write(Patches:\n)
You missed this one.


-- 
To view, visit https://gerrit.asterisk.org/6
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If9f3a7adf2ca0d1d38d625fc5ba6922b99fb37f7
Gerrit-PatchSet: 4
Gerrit-Project: repotools
Gerrit-Branch: master
Gerrit-Owner: Corey Farrell g...@cfware.com
Gerrit-Reviewer: Corey Farrell g...@cfware.com
Gerrit-Reviewer: Michael L. Young elgueromexic...@gmail.com
Gerrit-HasComments: Yes

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in repotools[master]: Update commit_msg.py output format.

[Michael L. Young (Code Review)]

Michael L. Young has posted comments on this change.

Change subject: Update commit_msg.py output format.
..


Patch Set 6: Code-Review+1

-- 
To view, visit https://gerrit.asterisk.org/6
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If9f3a7adf2ca0d1d38d625fc5ba6922b99fb37f7
Gerrit-PatchSet: 6
Gerrit-Project: repotools
Gerrit-Branch: master
Gerrit-Owner: Corey Farrell g...@cfware.com
Gerrit-Reviewer: Corey Farrell g...@cfware.com
Gerrit-Reviewer: Matt Jordan mjor...@digium.com
Gerrit-Reviewer: Michael L. Young elgueromexic...@gmail.com
Gerrit-HasComments: No

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Michael L. Young]

- Original Message -
 From: Olle E. Johansson o...@edvina.net
 To: Asterisk Developers Mailing List asterisk-dev@lists.digium.com

 So we have yet another internal resolver? Is that a good thing? Why
 are we not using the system resolver?
 
 We need to have some direction here. I think adding yet another DNS
 resolver is bad and will make it hard to add functions like
 DNSsec/DANE support. Making it possible for one piece of asterisk to
 use another DNS resolver is poor design, we should not open up for
 that.  The number of debug problems and runtime issues I see is
 reaching infinity. I can ping this server, but the sip channel
 can't reach it is just a start.
 
 Is there a way we can either avoid using yet another resolver, or
 since this is propably better - switch all of Asterisk to use it and
 we'll get asynch DNS everywhere?
 
 I can understand why a library like PJsip have support for this, in
 some cases it's the only way when writing clients like soft phones.
 That doesn't mean we have to expose it. We can still select and
 decide for ourselves about our design.
 
 Summary
 - Don't add yet another DNS resolver randomly
 - Don't allow using different DNS servers in parts of a server app
 and please don't allow anyone to configure anything else than the
 system resolvers in a server application.

I understand what Olle is getting at and I agree with it.  Why do we want 
res_pjsip using something different from the rest of Asterisk?  Everything 
should be using the same DNS resolver.  Otherwise, we are opening up a can of 
worms here when it comes to supporting Asterisk and trying to troubleshoot DNS 
issues.

This just doesn't seem like the right direction to go here.

Michael

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

RE: [asterisk-dev] Re: qwell: branch 1.2 r2434 - /branches/1.2/

[Michael L. Young]

I can confirm that I had the same problem trying to upgrade to zaptel 1.4.2
last night.  Whenever a call is hung-up, the system crashes immediately.  I
was offsite and tried to upgrade, so I am unable to provide the specifics at
this time.  But after I went back to 1.4.1, everything went back to normal.

Packages installed when getting kernel panic: asterisk 1.4.3, zaptel 1.4.2,
libpri 1.4.0

Since this is a production box, I quickly went back to asterisk 1.4.2,
zaptel 1.4.1, libpri 1.4.0 after it crashed the first time and then trying
zaptel 1.4 branch with the same results.  I didn't have time to try zaptel
1.4.1 with asterisk 1.4.3.

Hope this helps.

Michael L. Young

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:asterisk-dev-
 [EMAIL PROTECTED] On Behalf Of Tony Mountifield
 Sent: Wednesday, April 25, 2007 6:26 AM
 To: asterisk-dev@lists.digium.com
 Subject: [asterisk-dev] Re: qwell: branch 1.2 r2434 - /branches/1.2/
 
 In article [EMAIL PROTECTED],
  [EMAIL PROTECTED] wrote:
  Author: qwell
  Date: Tue Apr 24 13:33:29 2007
  New Revision: 2434
 
  URL: http://svn.digium.com/view/zaptel?view=revrev=2434
  Log:
  Backport pre-echocan debugging for ztmonitor
 
  Added:
  branches/1.2/jpah.h   (with props)
  Modified:
  branches/1.2/zaptel-base.c
  branches/1.2/zaptel.h
  branches/1.2/zconfig.h
  branches/1.2/ztmonitor.c
 
 Why is this NEW functionality being backported to the STABLE 1.2 branch?
 And then being tagged for release so quickly?
 
 I tried this new 1.2 from SVN last night, and it gives me a kernel panic
 when hanging up a call (see below). This is using a TE405P with trunk 1
 looped back to trunk 3. Not sure why EC stuff is being called, as I have
 EC disabled. Also not sure why it was doing a ZT_SETCONF when I wasn't
 using conferencing (the call was just an IAX call into the box, routed
 out through Zap and back in through Zap, into MusicOnHold).
 
 I haven't had time to investigate it fully yet, so can't file a proper bug
 yet, but if it IS to be in 1.2, it should be checked out more thoroughly
 before being released.
 
 Cheers
 Tony
 
 
 Unable to handle kernel NULL pointer dereference at virtual address
 00b4
  printing eip:
 d09e3c88
 *pde = 0a056067
 Oops:  [#1]
 Modules linked in: parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc
 wct4xxp(U) zaptel(U) crc_cc
 itt dm_mirror dm_mod button battery ac r8169 e100 mii ext3 jbd
 CPU:0
 EIP:0060:[d09e3c88]Not tainted VLI
 EFLAGS: 00010082   (2.6.9-42.0.2.EL)
 EIP is at zt_chanandpseudo_ioctl+0x13db/0x1bcb [zaptel]
 eax:    ebx: 0001   ecx: ffea   edx: 
 esi: ce0c0410   edi:    ebp: ce0c0410   esp: ca411df0
 ds: 007b   es: 007b   ss: 0068
 Process asterisk (pid: 5958, threadinfo=ca411000 task=c9dcacd0)
 Stack: cf00e9b8 c1220514 cb74e005 d662d853 0009 cf80dc00 ca411e2c
 ca411000
c01299d0 3b9aca00 462e6ecb 10bbb3d8  01ff cc1eacc0
 cbcde2c4
c014d59d 0153bfd5  ca411f34  005b 0001
 
 Call Trace:
  [c01299d0] current_fs_time+0x44/0x4c
  [c014d59d] __generic_file_aio_write_nolock+0x33d/0x36b
  [c014d604] generic_file_aio_write_nolock+0x39/0x7f
  [c014d7f3] generic_file_aio_write+0x77/0xcd
  [d09030af] ext3_file_write+0x19/0x8a [ext3]
  [c016c2e9] do_sync_write+0x97/0xc9
  [c0121853] autoremove_wake_function+0x0/0x2d
  [c01771fc] sys_stat64+0x1e/0x23
  [d09e575b] zt_ioctl+0xc1/0xc7 [zaptel]
  [c0180401] sys_ioctl+0x297/0x336
  [c016c4b9] sys_write+0x5a/0x62
  [c0318e57] syscall_call+0x7/0xb
  [c031007b] build_polexpire+0x81/0xe0
 Code: 8b 44 24 74 77 1e 8b 1c 85 a0 ae a0 d0 ba d0 00 00 00 a1 84 ce 36 c0
 e8 35 04 77 ef 89 83 b4 0
 0 00 00 eb 27 8b 04 85 a0 ae a0 d0 8b 80 b4 00 00 00 e8 e7 07 77 ef 8b
 44 24 74 8b 04 85 a0 ae a0
  0Kernel panic - not syncing: /usr/src/zaptel-1.2/zaptel-base.c:5593:
 spin_lock(/usr/src/zaptel-1.
 2/zaptel-base.c:ce0c0410) already locked by /usr/src/zaptel-1.2/zaptel-
 base.c/3832
 
  Badness in panic at kernel/panic.c:118
  [c0123ea0] panic+0x135/0x142
  [d09e6044] __zt_ec_chunk+0x5d/0x5dd [zaptel]
  [d09e6a65] __zt_transmit_chunk+0x16/0x33 [zaptel]
  [d0975577] t4_receiveprep+0x4ea/0x55f [wct4xxp]
  [d097659f] t4_interrupt+0x1e5/0x484 [wct4xxp]
  [c0107f00] handle_IRQ_event+0x25/0x4f
  [c01088ce] do_IRQ+0x18a/0x2bf
  ===
  [c0319830] common_interrupt+0x18/0x20
  [c02b007b] cpufreq_register_driver+0xe5/0x271
  [c0129a84] __do_softirq+0x2c/0x79
  [c0109446] do_softirq+0x46/0x4d
  ===
  [c01089f7] do_IRQ+0x2b3/0x2bf
  [c0319830] common_interrupt+0x18/0x20
  [c01068ee] die+0x1d0/0x22b
  [c011db59] do_page_fault+0x380/0x4dc
  [d09e3c88] zt_chanandpseudo_ioctl+0x13db/0x1bcb [zaptel]
  [c0120114] __wake_up+0x6e/0xca
  [d084a6a6] journal_stop+0x425/0x42f [jbd]
  [d090ac72] __ext3_journal_stop+0x19/0x34 [ext3]
  [d0905471] ext3_ordered_commit_write+0xb6/0xc5 [ext3]
  [c0317593] __cond_resched+0x14/0x3b
  [c011d7d9] do_page_fault+0x0