FreePBX 12.0.1beta27: pjsip config not applied (written to file)

Beta Program Issues
1

Hi,

I am new to FreePBX and because I wanted to use Asterisk 12 and the new FreePBX Features, I installed the Beta to a fresh CentOS 6.5 openVZ Container. I use FreePBX 12.0.1beta27 with all modules up to date.

I gave a try to the new pjsip stack, but had problems. I created the extension 31 and added it to a phone. But Asterisk always told

res_pjsip/pjsip_distributor.c:246 log_unidentified_request: Request from '"31" <sip:31@xxx>' failed for 'yyyy:3072' (callid: 4F...95) - No matching endpoint found

After some time I had a look into the /etc/asterisk/pjsip* files and realized the config is not applied (pjsip.endpoint.conf 0Byte).

I crawled through the code and the config should be written in /var/www/html/admin/modules/core/functions.inc/PJSip.class.php but the public function writeConfig($conf) { (Line 207) gets an empy variable. Eight lines above there is the call:

$conf = $this->FreePBX->Hooks->processHooks($conf);

Before this call config is fine, after it, it is empty. Config files are written if I comment this out.
Did some more investigations and found this code in /var/www/html/admin/libraries/BMO/Hooks.class.php

110         public function processHooks($data=null) {
111                 $this->activemods = $this->FreePBX->Modules->getActiveModules();
112                 $hooks = $this->getAllHooks();
113                 $o = debug_backtrace();
114                 $callingMethod = !empty($o[1]['function']) ? $o[1]['function'] : '';
115                 $callingClass = !empty($o[1]['class']) ? $o[1]['class'] : '';
116                 $data = array();

$conf is $data. $data is fine till line 115. But then it is overwritten with an empty array. Why?? So an empty array is returned to PJClass.php and everything goes wrong. Is there a reason for this or do I miss something?

Now I am thinking about what to do:

  • do a temporaray workaround in source code till the bug is fixed
  • abstain from pjsip and use the old chan_sip instead
  • use stable at all instead of the beta

I know it is a beta, but I am really wondering if there are more of these major bugs. pjsip is the default (listens on 5060) but does not work at all.

Regards
Martin

2

Thanx a lot for this workaround! I confirm the same behavior and glad you’ve investigated problem.

3

I know it is a beta, but I am really wondering if there are more of these major bugs. pjsip is the default (listens on 5060) but does not work at all.

I have moved to pjsip driver and it workes well for me.

4

I have no tested workaround :slight_smile:
What did you do? I see two quick-and-dirty possibilites:

  • Miss the hooks and remove the processHooks() line in PJSipClass.php
  • Remove the $data = array(); line and look what happens.

I think/hope someone thaught something when he inserted this line. I think I will a have look into the repository if I can read something from the commit message.

I know the pjsip generally works in the meaning that my phone can register. But I think there could be much more major bugs like this and probably not everytime so simple to find.
Looked around in the developers corner and it seems this project uses “beta” as something like “nightly”. So I am not sure if it would be clever to really use this beta.

5

The bug came into four days ago with commit 0aa16dd:
code.freepbx.org/changelog/FreePBX_Framework?cs=0aa16dd4d820967b29f4d3de281411ae2a90cb53
(sorry, I am not allowed to do paste a real link)

I think

116                 if( is_null( $data) ) {
117                         $data = array();
118                 }

should do the trick.

6

I was speaking about problem that had been investigating. There were no need to do it by myself.
I commented out this line as temporary workaround:

$conf = $this->FreePBX->Hooks->processHooks($conf);

It’s been tested for now, but it looks well =)

7

This way you will loose all hook functionality (I do not know if there is some). Better change BMO/Hooks.class.php like suggested above.

8

Done. Thank you again =)

9

Could you please make a pull request? It would be great if you made it!

10

I will do so later…

11

By the way, the more elegant way is to replace function definition:

/**
 * Process all cached hooks
 * @param {mixed} $data=null Data to send to the hook
 */
public function processHooks($data=array()) {
12

You are absolutely right, I pushed your version and opened the pull request:
http://git.freepbx.org/projects/FREEPBX/repos/framework/pull-requests/5/overview

13

All code submissions must have a signed CSA. I can’t accept or even look at your patch until you fill that out.

http://wiki.freepbx.org/display/DC/Code+License+Agreement

BTW: Thanks to both of you for your work this morning!

14

Things slip in. It happens. I want to say “its beta” but that doesn’t matter. No one noticed because I haven’t changed any of my pjsip endpoints in a week so the files are the same still for me. There are always bugs in any code. In the next few weeks we will be slowing down development on 12 and moving to 13 so 12 will get more stable simply by being bug fixes only.

That said, I am very confident in the total code structure but without help from the community to be constantly testing these things it becomes hard to always catch the bugs.

On another note, in 12 we’ve finally implemented unit testing every time a module is published. So what I’m going to do now is go write some unit tests out for pjsip and chan sip so this won’t ever happen again. (or at least I can say 99% sure)

Those two things are positive steps forward.

Also there shouldn’t be any more major bugs, aside from any outstanding GPG issues which I am still working through

Update:
I just realized that I would have never run into this issue. It comes down to a priority loading event in PHP whereas sometimes it will load modules in different orders on different systems. For me PJSIP was loaded in an order that allowed the extensions to be written out, therefore I never had an issue. On your OpenVZ container it’s loading in a completely different order causing you problems. This is why community involvement and participation is so important.

1 Like
17

After going through everything I determined that this “bug” was caused by an unpublished version of core, meaning the version of core that is now published had the fix to remove processHooks() as the functionality that core is expecting is different.

The patch that was provided also broke things as it was returning the parameter it was getting passed, the variable $data, and then returned variable $data causing other issues. The default parameter $data of processHooks() needs to be null, not array as it’s actually a mixed variable, not always an array (in the case of said malfunction it was a string).

So that being said the fixes/solutions are outlined below:

Core 12.0.1beta7
Framework 12.0.1beta29