How to implement the PJSIP “Line” feature in new Freepbx 17

FreePBX Configuration
1

Dear all in oldest freepbx we had an option under pjsip trunks adavanced config named

Send Line in Registration

Immagine 2025-01-08 095223

this option was for adding line=yes in pjsip.registration.conf like this

[PORTO]
type=registration
transport=0.0.0.0-udp
outbound_auth=PORTO
retry_interval=60
fatal_retry_interval=0
forbidden_retry_interval=10
max_retries=1000
expiration=3600
auth_rejection_permanent=no
line=yes
endpoint=PORTO
contact_user=XXXXXXXX
server_uri=sip:sip.vivavox.it:5060
client_uri=sip:[email protected]:5060

but in freepbx 17 is now missing

Immagine 2025-01-08 101447
Immagine 2025-01-08 101447693×489 23.6 KB

any way to apply this again? This was usefull when we had multiple trunks against the same provider IP with different credentials like is doing the EHIWEB italian provider

2

so if I switch to asterisk 20 from 21(that I suppose is the default one for freepbx 17) the option appears again and fixed my issue, I tried with asterisk 22 and had the same issue, pheraps only solution is reverting to 20

3

From an Asterisk perspective that option exists in those newer ones, so FreePBX version checking logic may not be handling the case. An issue should be filed to resolve that[1].

[1] Issues · FreePBX/issue-tracker · GitHub

4

Just for the record, this was filed at: [bug]: Missing PJSIP "send line in registration" in freepbx 17 and asterisk 22 · Issue #613 · FreePBX/issue-tracker · GitHub

1 Like
5

Yes I filled the bug myself and seems that will be fixed in core v17.0.18.10 (actual is core v17.0.18.9)

6

I’m a little concerned with the fact this was done without a branch/PR related to the ticket so it could be tracked properly.

@kgupta We need to have uniformed processes and methods. Not just throwing commits into the main branch with no real tracking/documenting of it.

7

Ahh, code got merged as a part of release process , instead of independent commit so agreed to have proper independent code commit with issue link/description, however module.xml shows jira#.

8

What release process? That commit is the only part of (and triggered) the release. It was changed, committed and released.

9

“release process” → module release process i.e. update the module.xml , increment module release version , tag the same.

Ideally that fix commit should have been an independent commit with PR and then module release commit (i.e. module.xml + tagging module release). As this fix was quick one so by mistake went into one single commit.