I HAVE A DREAM NEW CallerID Superfecta 2.2.4: THE MODULE

[raphou]

I try with John Doe
(212) 861-2456
Without SugarCRM: Problem (connection&mismatch)


with sugarCRM: idem



Stranger and stranger isn't it?

PS: on a previous version of CallerID Superfecta, I didn't hace this resolving host problem....

 

[tshif]

My friend - All I really needed was a little cut and past data from the Debug screen. I'm as big a fan of wall murals as anybody else, but did you notice how your full-size screen captures make reading the forum much harder?

Ok - so - you have said the previous version of Superfecta did not have the "resolving host problem". Exactly what version of Superfecta did not have the problem? We recently began using curl for the http functions. Can you tell us what version of curl you are running?

Then you also said "I have seen that problem with other apps. (saying it can't connect to server) Where could it come from?" What other apps are giving the same error?

In the first delux-sized graphic in this message, in the debug data, I see "Searching Address.com Yellow Pages...Couldn't resolve host."

That's a combination of TWO different source script messages. I cant imagine what to make of it.

So - tell us this (please, without a mural sized graphic), What Distribution are you using? For Example, PBXIAF 1.2, or TriceBoxCE 2.6, or ??

I admit - its pretty strange. Does your system exibit any other quirky behaviours?

Puzzled in San Diego-

 

[Lost Trunk]

Comments after a day of actual use...

raphou - Terribly sorry - but at this time, Superfecta can not deal with number formats longer than 10 digits.

We continue to plan for better support for international formatted numbers - but that is the future.

Do you mean that Superfecta will not deal with 11 digit numbers in the form 1NXXNXXXXXX? It sure SEEMS to, so I just want to make sure.

Bigger question: There is one provider which, on only SOME of its servers, sends TWELVE character numbers in the form +1NXXNXXXXXX. Ideally what I wish Superfecta would do is handle those as well, but also rewrite the CallerID(num) variable without the + (the callback function on some phones will send the + if you don't strip it). Right now I use a bit of code in extensions_custom.conf that looks something like this:

[custom-from-trunk]
exten => _X!,1,NoOp(Caller ID name received from provider is ${CALLERID(name)})
exten => _X!,n,GotoIf($["${CALLERID(num):0:2}" != "+1"]?noplusatstart)
exten => _X!,n,NoOp(Changing Caller ID number from ${CALLERID(num)} to ${CALLERID(num):1})
exten => _X!,n,Set(CALLERID(num)=${CALLERID(num):1})
exten => _X!,n(noplusatstart),Goto(from-trunk,${EXTEN},1)
exten => h,1,Macro(hangupcall,)

Now the first line of this is something I just added yesterday because I suspected that, even though I am specifying the lookups in this order:

* Asterisk Phonebook
* PhoneSpamFilter
* Trunk Provided
* Superfecta Cache
* (....the rest....)

It is apparently in some cases skipping the "Trunk Provided" name. For example, I saw one come in today where the Noop statement was showing that the provider was sending the name in the form LASTNAME,FIRST and yet the Caller ID being sent to the end user is First Lastname, which it probably got from AnyWho (this is a number that's definitely NOT in the Asterisk Phonebook).

This is the "sanitized" CLI output from that call (actual numbers and name changed):

    -- Executing [12345678900@custom-from-trunk:1] NoOp("SIP/12345678900-b7d14960", "Caller ID name received from provider is LASTNAME,FIRST") in new stack
    -- Executing [12345678900@custom-from-trunk:2] GotoIf("SIP/12345678900-b7d14960", "0?noplusatstart") in new stack
    -- Executing [12345678900@custom-from-trunk:3] NoOp("SIP/12345678900-b7d14960", "Changing Caller ID number from +18005551212 to 18005551212") in new stack
    -- Executing [12345678900@custom-from-trunk:4] Set("SIP/12345678900-b7d14960", "CALLERID(num)=18005551212") in new stack
    -- Executing [12345678900@custom-from-trunk:5] Goto("SIP/12345678900-b7d14960", "from-trunk|12345678900|1") in new stack
    -- Goto (from-trunk,12345678900,1)
    -- Executing [12345678900@from-trunk:1] Set("SIP/12345678900-b7d14960", "__FROM_DID=12345678900") in new stack
    -- Executing [12345678900@from-trunk:2] Gosub("SIP/12345678900-b7d14960", "cidlookup|cidlookup_6|1") in new stack
    -- Executing [cidlookup_6@cidlookup:1] Set("SIP/12345678900-b7d14960", "CALLERID(name)=First Lastname") in new stack

Note that I had already stripped the + before Superfecta ever got hold of the number, so that should not be the issue.

I will also mention that for now I'm only using the basic set of "Ignore keywords": unknown, wireless, toll free, unlisted

I am wondering if the comma in the Caller ID name might for some reason be causing Superfecta to think the name is invalid? That's just a shot in the dark, though.

I know it's probably a bit much to ask, since apparently your module isn't set up to do any output to the CLI, but it would certainly be helpful in debugging if it could print one line to the CLI in the form "Superfecta: Caller ID name set to (name used) - source was: (source name)." And also, if any time it checks the "Trunk Provided", it would output a line to the CLI that says "Superfecta: Caller ID name from provider is (name received, or words 'not received' if it was null)" - so if the name looks valid and yet Superfecta is using a name from a different source, you'd know there's an issue somewhere.

 

[Lost Trunk]

Speedup suggestion

It occurs to me that with certain services you may wish to use a lookup table of vaild area codes that the service will check. For example, in the case of a Canada-only service, there's no point in even trying a number with a U.S. area code, so if you had a list of Canadian area codes you could first look at the number and if it isn't from one of those area codes, simply consider it a failed lookup and move on to the next on the list. Why waste a fraction of a second on a lookup that has no chance of succeeding? Just a thought.

 

[tshif]

Do you mean that Superfecta will not deal with 11 digit numbers in the form 1NXXNXXXXXX? It sure SEEMS to, so I just want to make sure.

I stand corrected. We do handle the 11 digit format - solely by stripping off the leading digit it seems.

Bigger question: There is one provider which, on only SOME of its servers, sends TWELVE character numbers in the form +1NXXNXXXXXX. Ideally what I wish Superfecta would do is handle those as well, but also rewrite the CallerID(num) variable without the + (the callback function on some phones will send the + if you don't strip it). ....

Do you really feel that a Caller ID lookup program should be rewriting CallerID(num) for the system? Think about that.... I really think that's something that belongs in FreePBX. So far Superfecta only adds data where absent. Your talking about changing existing data - which could potentially have systemic results through out the system. What if you had two inbound routes from the famous +-sign provider - and one you pass through superfecta, the other one you didnt. The resultant CallerID(num) would be inconsistent between these two inbound routes, even though they are from the same provder.

I cant vote for this one - But I do think FreePBX probably needs to hear your thoughts on this. Open a ticket and see if they are willing to discuss it - it makes sense to me.

even though I am specifying the lookups in this order:

* Asterisk Phonebook
* PhoneSpamFilter
* Trunk Provided
* Superfecta Cache
* (....the rest....)

It is apparently in some cases skipping the "Trunk Provided" name. For example, I saw one come in today where the Noop statement was showing that the provider was sending the name in the form LASTNAME,FIRST and yet the Caller ID being sent to the end user is First Lastname, which it probably got from AnyWho (this is a number that's definitely NOT in the Asterisk Phonebook).

This is the "sanitized" CLI output from that call (actual numbers and name changed):

    -- Executing [12345678900@custom-from-trunk:1] NoOp("SIP/12345678900-b7d14960", "Caller ID name received from provider is LASTNAME,FIRST") in new stack
    -- Executing [12345678900@custom-from-trunk:2] GotoIf("SIP/12345678900-b7d14960", "0?noplusatstart") in new stack
    -- Executing [12345678900@custom-from-trunk:3] NoOp("SIP/12345678900-b7d14960", "Changing Caller ID number from +18005551212 to 18005551212") in new stack
    -- Executing [12345678900@custom-from-trunk:4] Set("SIP/12345678900-b7d14960", "CALLERID(num)=18005551212") in new stack
    -- Executing [12345678900@custom-from-trunk:5] Goto("SIP/12345678900-b7d14960", "from-trunk|12345678900|1") in new stack
    -- Goto (from-trunk,12345678900,1)
    -- Executing [12345678900@from-trunk:1] Set("SIP/12345678900-b7d14960", "__FROM_DID=12345678900") in new stack
    -- Executing [12345678900@from-trunk:2] Gosub("SIP/12345678900-b7d14960", "cidlookup|cidlookup_6|1") in new stack
    -- Executing [cidlookup_6@cidlookup:1] Set("SIP/12345678900-b7d14960", "CALLERID(name)=First Lastname") in new stack

Note that I had already stripped the + before Superfecta ever got hold of the number, so that should not be the issue.

I will also mention that for now I'm only using the basic set of "Ignore keywords": unknown, wireless, toll free, unlisted

I am wondering if the comma in the Caller ID name might for some reason be causing Superfecta to think the name is invalid? That's just a shot in the dark, though.

I opened a bug report so we can look into your suspicions about the "," in the returned data.

... it would certainly be helpful in debugging if it (Superfecta) could print one line to the CLI in the form "Superfecta: Caller ID name set to (name used) - source was: (source name)." And also, if any time it checks the "Trunk Provided", it would output a line to the CLI that says "Superfecta: Caller ID name from provider is (name received, or words 'not received' if it was null)" - so if the name looks valid and yet Superfecta is using a name from a different source, you'd know there's an issue somewhere.

I opened a feature request so this will be discussed - and then possibly acted on.

 

[tshif]

It occurs to me that with certain services you may wish to use a lookup table of vaild area codes that the service will check. For example, in the case of a Canada-only service, there's no point in even trying a number with a U.S. area code, so if you had a list of Canadian area codes you could first look at the number and if it isn't from one of those area codes, simply consider it a failed lookup and move on to the next on the list. Why waste a fraction of a second on a lookup that has no chance of succeeding? Just a thought.

This speaks to a broader topic - supporting non USA / Canada numbers. I believe this will be considered with that case.

 

[Lost Trunk]

I opened a bug report so we can look into your suspicions about the "," in the returned data.

Okay, I think I have figured it out, and it has nothing to do with the comma. In source-Trunk_Provided.php it looks like you are first executing a core show channels, trying to pick out the right one, and then doing a core show channel (Channel ID) to get the extended info. Which, at least on my box, works great on some trunks, but not others. The reason is that in some cases the full channel identifier gets truncated in the core show channels display, therefore the core show channel doesn't work!

AND THE SOLUTION IS...

Use "core show channels concise" instead. It does NOT truncate the channel identifier. It uses ! characters as separators between fields, like this:

SIP/12345678900-b7d15628!ivr-2!s!12!Up!BackGround!custom/ivr-main!8005551212!!3!7!(None)

I don't know what the fields all are, but I'm guessing that the first (and maybe the eighth) are the two that would be significant to the operation of this module. The beauty is that you don't get any head or tail information lines that have to be knocked out. So you could just look at the eighth field of each line until you match the caller ID number, then use the channel identifier in the first field (which is NOT truncated) as the argument of your core show channel to get the name.

Yes, I HAVE been up all night trying to track this down, and FINALLY the light dawned.

I bet this post sets some kind of record for the number of times edited since original creation, as I definitely went down a few blind alleys before finding the cause of the problem.

 

[FitnessPlus]

Hi!
I found some bug:
Mismatch between SugarCRM and Yellowpages? Number not well translated (international format)?

I found a bug in the code, reporting back Yellowpages as the source when SugarCRM is running. Someone (probably me) cut and pasted incorrectly. For now when you select SugarCRM as a source, the debug code will report it as YellowPages, but SugarCRM code is actually running. This will be corrected in the next bug fix.

 

[FitnessPlus]

Okay, I think I have figured it out, and it has nothing to do with the comma. In source-Trunk_Provided.php it looks like you are first executing a core show channels, trying to pick out the right one, and then doing a core show channel (Channel ID) to get the extended info. Which, at least on my box, works great on some trunks, but not others. The reason is that in some cases the full channel identifier gets truncated in the core show channels display, therefore the core show channel doesn't work!

AND THE SOLUTION IS...

Use "core show channels concise" instead. It does NOT truncate the channel identifier. It uses ! characters as separators between fields, like this:

SIP/12345678900-b7d15628!ivr-2!s!12!Up!BackGround!custom/ivr-main!8005551212!!3!7!(None)

I don't know what the fields all are, but I'm guessing that the first (and maybe the eighth) are the two that would be significant to the operation of this module. The beauty is that you don't get any head or tail information lines that have to be knocked out. So you could just look at the eighth field of each line until you match the caller ID number, then use the channel identifier in the first field (which is NOT truncated) as the argument of your core show channel to get the name.

Yes, I HAVE been up all night trying to track this down, and FINALLY the light dawned.

I bet this post sets some kind of record for the number of times edited since original creation, as I definitely went down a few blind alleys before finding the cause of the problem.

Thank you for the input, you seem to have struck upon something. I have implemented your suggested changes and it appears to be working on my system. Since your system is exhibiting the symptoms, I've attached a revised version of the source file. Can you copy this source file over to your machine and give it a test. If this corrects the problem it will be implemented in the next bug fix release.

 

[raphou]

My friend - All I really needed was a little cut and past data from the Debug screen. I'm as big a fan of wall murals as anybody else, but did you notice how your full-size screen captures make reading the forum much harder?

I tried, but everytime it goes as original. I've removed the pictures..makes it easier to read indeed. Sorry about that!

Ok - so - you have said the previous version of Superfecta did not have the "resolving host problem". Exactly what version of Superfecta did not have the problem? We recently began using curl for the http functions. Can you tell us what version of curl you are running?

I think it was version 2.0.0. I use curl 7.19.4-5 on fedora10 (I'm running VPN in a flash with asterisk 1.4)

Then you also said "I have seen that problem with other apps. (saying it can't connect to server) Where could it come from?" What other apps are giving the same error?

It was with SugarCRm but problem solved..

In the first delux-sized graphic in this message, in the debug data, I see "Searching Address.com Yellow Pages...Couldn't resolve host."

That's a combination of TWO different source script messages. I cant imagine what to make of it.

So - tell us this (please, without a mural sized graphic), What Distribution are you using? For Example, PBXIAF 1.2, or TriceBoxCE 2.6, or ??

VPN in a flash

I admit - its pretty strange. Does your system exibit any other quirky behaviours?

Puzzled in San Diego-

Thanks a lot for your help!

 

[Lost Trunk]

Thank you for the input, you seem to have struck upon something. I have implemented your suggested changes and it appears to be working on my system. Since your system is exhibiting the symptoms, I've attached a revised version of the source file. Can you copy this source file over to your machine and give it a test. If this corrects the problem it will be implemented in the next bug fix release.

Well, in a fairly limited test (one call, but via a trunk where this never worked before) it actually did work as expected, so I think you've done it. Thanks much!

Note: The trunk I tested it on sends a ten digit Caller ID. I have not tested it with a pattern of 1NXXNXXXXXX nor +1NXXNXXXXXX for incoming Caller ID - we have one other trunk that sends the info in that format (it sends it with the +1, but I strip the + character before Superfecta sees it) but since that trunk "belongs" to a particular user, I don't dare touch it during the day. However, I can observe the incoming calls on the CLI (if they get any today) and see if that appears to be working. I can tell the difference because this trunk sends Caller ID in ALL CAPS. But, I'm guessing you'd know whether the incoming number length might make any difference.

 

[FitnessPlus]

Note: The trunk I tested it on sends a ten digit Caller ID. I have not tested it with a pattern of 1NXXNXXXXXX nor +1NXXNXXXXXX for incoming Caller ID ... I'm guessing you'd know whether the incoming number length might make any difference.

Yes, it will probably only work in cases where the CID number is exactly 10 digits.... I can probably modify it so that it matches the last 10 digits of what the CLI contains...this way leading numbers and characters such as "+" won't affect it.

I'll go ahead and make the change so that it matches the last 10 digits.

 

[Lost Trunk]

I'll go ahead and make the change so that it matches the last 10 digits.

That would be great. Thanks very much!

 

[WAudette]

Contributed_Modules Application Process

I’ve been following the [FONT=&quot]Caller ID Superfecta[/FONT] mod, which I like BTW, and this is a bit off topic but I felt I had to reply to Lost Trunk and clear up some mis-perceptions and mis-conceptions that tend to propagate unless properly addressed.

So, Lost Trunk, it’s with respect that I reply to this. As always I applaud critical thinking and you are of course welcome to any opinion you have. However, there are some points that need clearing up.

At risk of sounding a bit negative, I will just say, "don't hold your breath." There are many great third-party modules awaiting some hint of recognition, let alone acceptance, but the FreePBX development team (which at this point isn't so much a team as one guy, or so I'm told).

Please note that Philippe is indeed the Project Lead. IMHO he is a good one and just what the project needs right now. He is also one of 16 devs who have full SVN access to FreePBX and there are at least 8 additional devs who have access to the Contributed_Modules branch. As you I am sure know, but others may not, SVN is one of the main tools they use to manage the code’s deployment, contributions, and revisions.

Developer contributions come in spurts and batches given the volunteer nature of the project, but at any given time there may be half a dozen of these devs actively submitting code within a few month period of time, usually more so during active beta programs. There are also many Contributors that never actually use SVN but instead submit their contributions via Trac.

If you ever wonder if anything is actually happening because you haven’t seen an update or your bug, fix, feature, or Mod added for some time just look at this link to see all the activity. You’ll quickly realize that Philippe (and others) are often busting their butts and knocking off tickets left and right. http://freepbx.org/trac/timeline

Likewise if you ever want to view the actual code through a web interface you can go here to browse it: http://freepbx.org/trac/browser

Another point I might add here is that it’s not uncommon for Philippe or another Dev to have to spend dozens of hours or more getting a contributed module cleaned up and/or adjusted enough so it’ll properly integrate into the standard repository in Module Admin. This gives them time to adjust the code enough that it’s ready for whatever upgrade paths and feature integrations that are coming down the pike from many sources, Asterisk 1.2, 1.4, 1.6 , or from conceptual changes from FreePBX as it grows, as well as addressing deficiencies often found in new modules that were overlooked. (Examples include lack of API calls to integrate with the extension and destination registries used for system integrity, hard coded SQL and Manager credentials, etc.)
It’s a tough sell to get some volunteer to get excited enough about a Mod to contribute that much time for a one time integration let alone getting a team to commit to taking on at least some responsibility for the code from point of integration forward.

A (probably partial) list of such modules can be found here.

This is indeed a list of the Contributed Modules. You’ll note that Philippe has at least one in there that he created as well, that is NOT part of the standard repository. Pretty much anyone can submit a module and it’ll be placed in here, you need only ask for access to this area and it will be granted. This sort of a landing zone for new ideas, submissions, and contributors. It’s also a proving ground of sorts.

Getting a mod into the “Standard Repository” is a little tougher as Modsules accepted into this group generally have to pass some criteria before being integrated. You know, common stuff, like not breaking other mods, not messing the frames up, not causing system instability, etc. I’ve also personally witnessed groups of developers evaluating if and when to move certain modules into the main project. (You should note it was a discussion, not just ‘the project leader’ making that decision.)

I observed a bit of chatter on one of the channels the other day that for some reason led me to think that at some point there may be another "fork" of FreePBX, ... but because although it may be an open source project, it's not an open community at this point - basically one guy holds all the power, and just doesn't seem to be very accepting of contributions by others (it's not that he outright rejects them, but from outward appearances he just sort of leaves them "lying on the floor" until the developer takes the hint and goes away

). ...

There may be a version of FreePBX written for FreeSwitch only time will tell. Forks happen it’s open source. Why anyone would want to is beyond me at the moment.
As for the lying on the floor comment in the hopes a Contributor takes a hint and just goes away, I haven’t seen that happen. Two ways to get your Modules submitted are:

1. Use Trac to open a ticket to have your mod added to Contribute_Module
2. [FONT=&quot]Pop into IRC and just ask. I have not seen Philippe refuse to add any mod yet. [/FONT]

Maintainers wishing to keep their mods up to date can even get SVN access to the Contribute_Mods when they are ready to ask for it. If you feel something is being over-looked, then ping the developers and get their attention. People are busy juggling many things, they may have to be reminded.

I do know that Rob Thomas, who was one of the orginal developers of FreePBX, submitted a new routepermissions module (it's also listed on the above-mentioned page) and so far it hasn't even been considered for acceptance, despite the fact that it was apparently written to be part of the main distribution. Things must be getting weird when the previous lead developer can't get a module accepted (at least not in a fairly timely manner).

XRob is the past Project Lead and is still a full Dev and still much loved. He has full SVN access. He put this mod into the Contribute_Modules section himself and he himself hasn’t elevated his own module. You would have to ask him why, but I could imagine it may be that he also knows such actions are typically discussed amongst some developers, and maybe there are other reasons. (And keep in mind, the 2.6 beta program has not been formally kicked off yet. As a result, I would not make any assumptions as to what is or is not going to be moved to or from the 2.6 branch at this point) So in closing, nothing is weird, but these Devs are _volunteers_ and lead fulfilling and busy lives outside of this community. If a project slows down it more than likely has little to do with any weirdness.

Personally, I hope that if anyone does start a project that competes with FreePBX, they build it around FreeSWITCH rather than Asterisk. Exerything I've heard about FreeSWITCH recently has been very positive, but unfortunately there has not (so far) been anything like FreePBX built or adapted to work with FreeSWITCH (despite the similarity of the names, the two projects are not related, at least not as far as I know).

Well, I don’t know what is happening exactly but this site http://freepbx.org/projects does lead one to suspect that the LARGE Coming Soon graphical image may eventually be sitting beside the other large image and it won’t say Asterisk & FreePBX but might say FreeSwitch & FreePBX. FreePBX is a frontend GUI written to be somewhat agnostic as to what platform it is written to manipulate.

As it sits now, this module truly does deserve to be part of the main freePBX distribution, or at least included in the "official" third-party modules distribution. But as I say, I would not hold my breath. Of course, getting recommended by Uncle Ward and included with PiaF is the next best thing!

Others agree! I read that JJShoe specifically is working on integrating his favorite mods from PBXInAFlash into the 2.6 branch.

I spoke with Philippe specifically on this subject and learned that 2.6 will include and “Extended Repository” of sorts that will point to many of the “non FreePBX Team supported modules” that are generally considered solid and reasonably well maintained. This will be done so that they would be accessible through the GUI, simply by choosing a select box that access the “Extended Repository.” In my opinion, this mod, [FONT=&quot]Caller ID Superfecta[/FONT], would be an excellent candidate for this category, though it would have to be in the FreePBX contributed_module repository to be considered, which is currently not the case although one need only ask for the SVN access required to put it there and it will be granted.

Disclaimer: I am NOT a FreePBX developer, so don't get the idea that I have any "inside knowledge."

I don’t know who you are through your handle Lost Trunk, but in closing your thoughts, concerns, consideration, and critical thinking are welcome. I don’t have any special connection to the FreePBX Team excepting that I am a lowly contributor (read not a Dev) and generally am ultimately concerned with keeping things positive and productive for one of my favorite open sourced projects.

For further reading this link is informative: http://freepbx.org/freepbx-development

Best Regards,


William S. Audette

 

[Lost Trunk]

William, thank you for your explanation of what is happening "behind the scenes" with FreePBX development. I had no idea there were that many people actively participating in development.

Probably some of my comments were a lot more negative than they should have been, and for that I apologize, but on the other hand it would be nice if the development process were just a bit more open. If there are concerns about a certain module that might preclude it being placed in the main distribution, maybe those ought to be documented somewhere.

You said, "Getting a mod into the “Standard Repository” is a little tougher as Modules accepted into this group generally have to pass some criteria before being integrated." My only question is, is that criteria actually documented anywhere, or do module developers just have to submit and hope they haven't broken some unwritten rule or policy? If it's the latter then I hope you can see whay that might be a problem, and why some developers might take it the wrong way. How can you follow the rules if the rules only exist in someone's mind?

IMHO there probably ought to be a section of the FreePBX wiki specifically devoted to helping developers create modules, and stay within whatever parameters are necessary to not "break" anything else. And I definitely do agree that you can't have one module breaking another, or part of the main distribution, but as far as I can tell there's really no way for a developer to know in advance what not to do.

Also, just as a point of information, why is the FreePBX wiki "closed", as opposed to, for example, the one at voip-info.org, when anyone can register and then add relevant information to any page immediately? All I'm saying is that to an outsider, it almost seems like the FreePBX community (if such exists) is designed to make information sharing and openness more difficult than it should be. I feel as though there is more of an active community here than at the FreePBX site - note my interaction with the developers of the Superfecta module in this thread - I doubt I'd ever get that level of response and help in the FreePBX forums. And because they were so open, I was in turn able to help them figure out what was causing one particular bug.

Anyway, had I not written that post when I was tired and maybe a little cranky, I might not have been quite so hard on the development team, because I do know they work very hard. I also know it's primary a volunteer effort, so I apologize for my original negativity. My only wish is that the FreePBX community were a bit more "inclusive" toward third-party developers, of which I am NOT one, but I really appreciate a lot of the "extras" they have come up with.

By the way, I just checked and noticed that the routepermissions module that I mentioned in my earlier post has finally appeared in the third-party repository - not sure when that happened (looks like yesterday from the file date), but it's good to see it there.

 

[p_lindheimer]

Lost_Trunk:
I was pointed at this thread at their being some possible concerns or clarifications needed and saw some of your questions. It was great to see the post that William wrote wrt to your earlier post and for the most part, I think he has spoken quite accurately about things so I will clarify some of the subsequent questions you had.

...but on the other hand it would be nice if the development process were just a bit more open. If there are concerns about a certain module that might preclude it being placed in the main distribution, maybe those ought to be documented somewhere...
...You said, "Getting a mod into the “Standard Repository” is a little tougher as Modules accepted into this group generally have to pass some criteria before being integrated." My only question is, is that criteria actually documented anywhere, or do module developers just have to submit and hope they haven't broken some unwritten rule or policy? If it's the latter then I hope you can see whay that might be a problem, and why some developers might take it the wrong way. How can you follow the rules if the rules only exist in someone's mind?...

The development process is very open, all activity that occurs can be seen on the timeline. There are often discussions that occur on the IRC which is an open channel. Unfortunately, there are also phone conversations that occur and those are hard to capture...

The issue of putting a module in the 'main' repository is not purely a technical question of how the module is written. It is also very much a 'subjective' question of future support and maintenance expectations. When we put a module into the Standard repository, it has the implication that we are going to support it very responsively by the core team, beyond the original author's ability or availability to support it. That decision, by its very nature, is subjective and amongst other things, may very much be based on passed track record of the author's support on other things within the project.

For that reason we created the "Extended Repository" in 2.6 that William eluded to. For all practical purposes that extended registry is 'as good' as the main registry. If you choose it the modules show up in the GUI and you can install them just as any other module. The only difference is you are forced to read a very short 'disclaimer' the text of which is very straight forward, at the time of this writing:

"You have selected to access the Extended Repository. This repository contains some Third Party and un-supported modules. Although these modules are believed to work with FreePBX, they are either developed by third parties in conjunction with optional PBX components, or they are not directly sponsored by the core FreePBX team and may not receive the same level of responsiveness to issues as the main code base does."
​

As you can see, there is no negative implication of any sort. Simply the realities of life in the world of OS.

This does not mean every module that is in the contributed_repository will be exposed through the GUI. We still need to make a judgment call if there is going to be reasonably responsive support for any such modules. You asked if there are published 'rules' for this and the answer is not at this time as this new Extended Repository is in 2.6 who's beta program has not even formally been kicked off.

As a result of the new repository we will work on creating guidelines of technical expectations, as this is new, that will be also. However, even for the Extended Repository there are guidelines that are subjective. We need to feel comfortable that these modules will be supported by the authors or other contributors since there is a very real expectation of quality that comes with such 'easy' and 'apparently endorsed' access to anything that you can simply download and install from with FreePBX.

IMHO there probably ought to be a section of the FreePBX wiki specifically devoted to helping developers create modules, and stay within whatever parameters are necessary to not "break" anything else. And I definitely do agree that you can't have one module breaking another, or part of the main distribution, but as far as I can tell there's really no way for a developer to know in advance what not to do.

The trac site has a wiki section where there is developer documentation. Unfortunately much of the documentation is stale. Anyone with an account can modify this wiki, it's the unfortunate nature that many developers aren't always known for proactively writing documentation, and new developers who use that information and find some of it is stale are not updating it, which is what you expect in documentation.
Have a look at voip-info.org, the informal 'official' documentation site for Asterisk with a MUCH larger set of "Asterisk dialplan developers" (to make up a term). You will find that there is tons of stale and incomplete data there as well. Unfortunately but yet a reality, I go to the Asterisk source code for the authoritative set of information...

Also, just as a point of information, why is the FreePBX wiki "closed", as opposed to, for example, the one at voip-info.org, when anyone can register and then add relevant information to any page immediately?

You are referencing the 'drupal' side of FreePBX.org vs. the wiki that is part of trac. The answer to your question is very straight forward. When we setup drupal we found it to be very fragile and the required 'fine grain permissions' module that would allow access to 99% of the site (which is our desire) broke all sorts of things. Taking the significant amount of time to setup a new test server to try to get that right has just not made it to the top of the priority list. As a stop gap, ANYONE who has ever asked how they can get access to the site to contribute has been granted that permission. It just unfortunately involves enough 'exposure' to breaking things that they must ask to get it vs. every single account having the level of access that we are currently capable of providing through that mechanism. There are dozens of users who do have permission to update the site.

All I'm saying is that to an outsider, it almost seems like the FreePBX community (if such exists) is designed to make information sharing and openness more difficult than it should be. I feel as though there is more of an active community here than at the FreePBX site - note my interaction with the developers of the Superfecta module in this thread - I doubt I'd ever get that level of response and help in the FreePBX forums. And because they were so open, I was in turn able to help them figure out what was causing one particular bug.

I'm sorry that you feel that way as it is not the case at all. Given the roughly 60+ modules that FreePBX.org has, you are going to get a wide variance on responsivness on any give request depending on what module it is, who is around and what the nature of the request is. It's a bit different then a module actively being developed and maintained by the current author.

Anyway, had I not written that post when I was tired and maybe a little cranky, I might not have been quite so hard on the development team, because I do know they work very hard. I also know it's primary a volunteer effort, so I apologize for my original negativity. My only wish is that the FreePBX community were a bit more "inclusive" toward third-party developers, of which I am NOT one, but I really appreciate a lot of the "extras" they have come up with.

You have the right to write what you want, we live in a wonderful world of 'freedom of speech.' However, it's also a good idea to "check your sources" as a good newspaper typcially would

By the way, I just checked and noticed that the routepermissions module that I mentioned in my earlier post has finally appeared in the third-party repository - not sure when that happened (looks like yesterday from the file date), but it's good to see it there.

Well as William mentioned, 2.6 is not even out and what you see wether in the main repo or in the extended repository does not mean they are or aren't going to be there.
However, to answer your question, Rob never ran the first phase "publish.pl" script that creates the tarball necessary for the Extended Repository to include it. Therefore, the server side script which "creates" the xml for the repository ends up failing on that module and removes it from the publishing process. This is the same server side script that makes sure every module published to the xml is correct and the MD5SUMs match the actual tarballs so you don't get those occasional errors that use to occur many moons ago when trying to download a module that had be published incorrectly. I just noticed that the other day when I was looking through some of the modules in the contribued_modules directory and ran it for him

 

[wardmundy]

Sitting in judgment at 30,000 feet today, and I think it's helpful to get all of this clarified for everybody. I'm not much of a vBulletin expert (and don't want to be) so movement of individual messages seems like a waste of time. I'm glad the FreePBX development team has clarified the ground rules for everybody. That will be incredibly helpful as more and more new developers join our community.

P.S. And speaking of hijacking threads, the Rockies really are beautiful out my Delta window.

 

[cosmicwombat]

Tony, if you don't want a jihad, why are you trying your best to start one?

I just don't see the point of going there. The FreePBX project was more or less attacked by Lost Trunk ( unknown person ) and that requires a response.

I am too feeble minded to write code, non-the-less I am cognizant of what is involved. As a long time community member, I have been watching to goings on across several fronts and these comments feel way off to me.

To be fair, I may not have made this clear enough...But, I mentioned putting FreePBX modules in the contributed modules section of the dev svn, which was saying that can be set up for you. I am not sure how much more inclusive a project can be?

What am I missing?

 

[cosmicwombat]

Tony... huh?

 

[phoneguy]

This is Joel/jjshoe/f$#@ face/hey you - I'll answer to just about any of them.

I'm posting from phoneguy's account as I waited over 24 hours for my own account to get posting permission and still haven't been granted permission. Freepbx is closed down? pft.

I could rant and rave for days, or I could mention that your post is the exact reason I don't reach out to the community more. Signal to Noise ratio seems to be that the forums are a far bigger hassle then help.

<deleted ranting and raving>

Stop pissing in the pool, it makes the water miserable for everyone.

-Disclaimer-
These opinions are mine, not phoneguy's
No puppies, kittens, or seals where hurt in the creation of this message
No IP spoofing was used