No, that’s the point of the “custom” files and sip_custom_post.conf is only for chan_sip, not chan_pjsip.
1 Like
I just tried making a new category inside the pjsip.endpoint_custom_post.conf file with the name as the number then adding (+) but asterisk ended up writing it as [100(+)] when it needs to be 100 so with the NewCat action anything infront of Cat-00000: gets put into the square brackets.
Its not to obvious to me but can i use the NewCat options. like possiblty the inherit to add the (+)?
inherit=“template[,…]”
Hmmm. It’s been 10 years since I wrote that code. I’m gonna have to refresh my memory.
TL;DR; Bad news I’m afraid. I don’t think there’s a way to do what you want to do using AMI with the FreePBX config file layout scheme. All is not lost however… Now that you now you can create files that update objects in the FreePBX controlled files without them being overwritten, you should be able to create those “custom” files offline and just scp them to /etc/asterisk and issue a reload either directly to Asterisk or via FreePBX. If you want the background on why the AMI route won’t currently work, read on…
Let’s say you want to add “qualify_frequency = 30” to an AOR named 100. You’d have to first add '[100](+type=aor)' to one of the “custom” config files…
There are two issues…
The first issue is that the code doesn’t recognize ‘+’ as “add to existing object” so specifying Newcat with ‘inherit="+type=aor"’ fails because there’s no template named ‘+type=aor’. Now you can fake this by first using Newcat to add a category named ‘+type=aor’ with ‘template’ in the options and you’d get this in the config file…
[+type=aor](!)
That template does nothing so it would be ignored by itself but hen you could call Newcat again to add a category named ‘100’ with options = ‘inherit="+type=aor"’ and you’d now have this in the config file…
[+type=aor](!)
[100](+type=aor)
In this case, the config parser would see the leading ‘+’ in [100](+type=aor) and correctly interpret it as “add to existing object” instead of "use a template named +type=aor.
Here’s where the second issue comes in though…
When you go to do an Append to category 100 in that custom file, the config parser will throw an error because it can’t find the base category 100 in that same file because the base object 100 is in the file that "#include"s this one. This isn’t an issue when the configs load because the config parser is starting with the top-level “pjsip.conf” file and following the includes. The code that reads individual files however doesn’t know anything about what files may have included the file you’re trying to read.
Ahk yea i feared it might end up being a case of maybe running some script independantly of the user creation processes that does a batch update of things, or like you said write them off line then scp them in.
It really feels like the proper way this whole thing should happen is that when i call the graphql addExtension on the FreePBX side I should be able to put in any of the properties asterisks recognises in any extension category. Right now its limited.
I wanna look into the whole possibility of figuring that out and submitting a pull request to FreePBX, but from the asterisks side of things would there be any bottle necks or issues, like for example asterisks no accepting the properties from FreePBX?
Ive done a little digging into the addExtension php code in FreePBX but havent followed it fully through to asterisk yet.
Also thank you for all your help thus far!
Asterisk doesn’t care how entries in the config files are added or modified as long as the config file is formatted correctly and the parameters specified for each object are correct for that object type. For instance, if you add an aor parameter to an endpoint and reload, you’ll get an error and all other changes (if any) to that endpoint will be ignored. If you restart asterisk, then that endpoint won’t load at all.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.