Do you want to build a snow man?


(TheJames) #1

image
It doesn’t have to be a snowman…

For those who don’t know me I was one of the core developers and created much of the development documentation for FreePBX over the last decade. I am now a Sr Software engineer for Clearly IP where I work on a lot of cool communications projects some of these still overlap and use FreePBX. Some use Asterisk and newer features such as ARI and things that haven’t fully come in to the FreePBX realm.

While I spent a good chunk of my tenure documenting FreePBX development it seems there is still a lot of mystery and voodoo. When I started working on FreePBX everyone who wanted to develop basically had to reverse engineer a module or two to learn the plumbing. Even then it was hit and miss of whether you got it right. Programming for FreePBX and in general is not a static skill. You learn as you go. New toys, new tricks, new tech. So if you are looking at my code or documents from 5-10 years ago is id unlikely you are looking at the “best way” to do the given task. Some code examples were written to accomodate PHP 5.2, I know right.

I don’t know the format yet but I would like to build out some content for those focused on the developer side. Quick snipits, code, tutorials etc to help people make cool things. Could be “blog” style, a youtube video or a quick gist on github. If you have something specifically you would like covered let me know. I am happy to cover some general programming topics too but for the sake of this post things should apply to FreePBX.

I believe I still have wiki edit rights too if there is some developer content you think could use a reprise but likely examples and stuff will probably live on github


Module self signing video
(Lorne Gaetz) #2

How about a walkthru on how to make edits to an existing OSS module and then how to self-sign it.


Module self signing video
(Dave Burgess) #3

Especially this.


(Ted Mittelstaedt) #4

To this day there’s still occasional messages along the lines of “I was using chan_sip and X broke and I switched to chan_pjsip and it worked” along with their corresponding “I was using chan_pjsip and X broke and I switched to chan_sip and it worked” messages.

Obviously there is differences in how those sip modules speak SIP that impacts different hardware - friendlier to some and not to others.

Documenting exactly HOW these are different would be great and would allow the pjsip code to be modified to match how chan_sip behaves. That I think is the biggest obstacle to moving 100% to pjsip. It’s not migrating configurations it is just that a lot of gear simply doesn’t work right with pjsip, and the owners of that gear have heard the “you gotta throw away your gear and buy different gear that works with pjsip” so often that they have basically given up trying to get the developers to “fix” pjsip.

While it’s perfectly valid to say “we are not going to develop chan_sip anymore because we don’t like the way it’s coded” it is not, IMHO, doing the right thing to replace it with a different SIP module that simply does not work the exact same way and that results in some things breaking then trying to force users to migrate.

I do realize this is more of an Asterisk thing not a FreePBX thing and kudos to FreePBX for not simply dropping chan_sip the moment the Asterisk developers decided they didn’t like chan_sip.

But you asked where the voodoo was and I’m telling you an area where it is. And I perfectly expect to be dumped on by the pjsip priests.


(Andrew) #5

That’s a tall order. I mean there are still issues that come up during conversions that may be unforeseen. Just be diligent in working through the fixes and report back to the community if you feel so inclined.

Also, chan_sip isn’t completely unsupported. It’s community supported :wink:


(Simon Telephonics) #6

PJSIP configuration is different in both Asterisk and FreePBX than chan_sip configuration.

There also may be adjustments to make on the endpoint.

I think the reason you are not seeing the kinds of “solutions” you hope to see is that in reality there is NOT a lot of gear that won’t work with PJSIP. In fact, just name one as an example. For the most part, it just comes down to configuring things correctly.

I’m not blaming you or anyone on this matter; the configuration is quite different, and the old-heads who have used chan_sip since the beginning are just a lot more familiar with it than with PJSIP.


(Itzik) #7

Hi James, thanks for posting about this.

I think that the community will start contributing much more once there is an easy understanding on how the “plumbing”, BMO, and getting a list of destinations etc, works in FreePBX.

I will give you some examples of what I thought of contributing, but I have no idea where to start.

  1. Reworking the inbound routes so we can easily detect and loopback an outgoing call if there’s a DID using something like GotoIf($[${DIALPLAN_EXISTS(from-did-direct-123456789,s,1)} = 1]?from-did-direct-123456789,s,1)
  2. Add a Noop in alllllllllll of FreePBX’s contexts as s,1 so we can do something like:
    [macro-hangupcall-custom]
    exten => s,1,Gosub(our-custom-stuff,s,1)
    So we can properly use all -custom includes.
  3. Create a “Destination Group” module which allows you to point a ton of objects to that group and then point that group to a single destination. It is very useful when you have a ton of objects pointing to your support queue but then you need to temporarily or permanently change them all to a different queue, so instead of going to each object and changing the destination, you will only change the Destination Group’s destination.
  4. Help out with migrating from Macro() to GoSub()

These are some examples that I remember now. There is definitely more…

Thank you


(TheJames) #8

This does go beyond the scope of what I am (trying to) do. I am working to be more developer focused.

I would like to see better code quality from internal and external developers

Also more contributions by way of features etc from external developers.
The best way to advance things that may not serve a commercial interest is to have it contributed by the community.