I have installed the new FreePbx 17 as a replacement for FreePbx 13. Unfortunately, I can’t make an incoming call correctly. Terminates after 32 s. Outgoing call is OK. I also read the last forum from 2024, checked NAT, sipalg, IP, log and didn’t come up with anything. The operator (CZ) has a problem with pjsip, he has an older version of Asterisk. Does anyone have any idea where to look, what to adjust? Thank you P.
Run sngrep on your command line, initiate a call, open up the invite that displays on the screen when the call is initiated (arrow down to it and hit enter). Keep the call going until it ends after 32 seconds. Take a screenshot. Arrow down to the first 200 OK, take a screenshot making sure to show the text on the the right. Share both here. In simple terms, the 200 OK is not receiving an ACK. The SIP standard is to tear down the call of no ACK is received after 32 seconds.
Thanks for the ideas, I would rule out NAT problems. FreePbx is only for public IP and does not work with the Operator’s SIP trunk. On its side is Asterisk A2billing version 1.4 - it’s not a typo. Version 1 dot 4. FreePbx 16, which I have had for a year, still coped with it - it has chan_sip, but Version 17 only pjsip. P.
Also, about 200 OK and ACK, my colleague looked at it and there really is no confirmation. There is a mismatch with Asterisk versions 17 and 1.4. We are wondering what to do about it?
I am repairing FreePbx 17 asterisk 22 and A2billing asterisk 1.4, so the difference is almost 20 years.
Explain what you mean by there is no confirmation. Did you run sngrep for the inbound call and there’s an ACK for the 200 OK
OK, I’ll get some info from my colleague
If there is no ACK being sent from the far end, that needs fixing there. Otherwise you need to find where, in the network, it gets lost.
Although Asterisk 1.4 is really ancient, ACK to final response is so basic to SIP that it wouldn’t have got broken, and chan_pjsip will definitely have been tested against chan_sip.
I did get a similar problem, for me the problem was in the trunk, some parameters with timers behind them waited too long between each moment they say they were alive to the trunk server I have changed thoses parameters :
Qualify Frequency : 30
Thanks for the idea, unfortunately it still behaves the same way, the call ends after 32 seconds.
qualify frequency is a workaround for problems with local routers expiring temporary forwarding and firewall rules. The value used would depend on the local router, but it always better to use static rules, so that there is no need to refresh learned ones.
The relevant side effect is that it generates frequent outgoing network traffic, so causes routers to reset the timeouts on dynamic rules for the destination. It is a side effect, not the primary purpose, which is early detection of loss of outbound connectivity.
Hello colleagues, unfortunately I learned that my old Asterisk 1.8 does not support pjsip. It is only supported by Asterisk from version 12. I found the info on perplexity.ai . I will have to negotiate with the operator about changing the main exchange. Thank you for your written ideas. P.
For information for everyone who will have a similar problem, I am sending info from a colleague who solved it.
"Regarding the trunk, after much searching, adding:
TRUNKS [TrunkA] :: Edit PJSIP Trunk → Advanced → Contact User: asterisk
words ‘asterisk’, which previous versions did themselves. I don’t know, it’s so stupid. 
With the FreePBX16, I would assume that you still have trunks defined on chan_sip, because there the double combination chan_sip|pjsip was still possible."…
So thank you public smart heads and good luck with FreePBX. Peter
p.s. The AI was wrong.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.