I have installed FreePbx on Virtual box.
Incoming Calls drop after 32 seconds.
I have searched all the posts and non seem to apply to my case, as it seems that there communication and it is not a NAT problem.
Logs:
Thanks in advance.
I have installed FreePbx on Virtual box.
Incoming Calls drop after 32 seconds.
I have searched all the posts and non seem to apply to my case, as it seems that there communication and it is not a NAT problem.
Logs:
Thanks in advance.
Youāve got very complicated routing on the incoming request, including a received parameter on a Route header, which I havenāt seen before, and am not sure about, but basically, Asterisk is trying to accept the call, by repeatedly sending 200 OK, but either the caller isnāt receiving these, or the Contact header address is not providing a valid way for the caller to get an ACK back to Asterisk.
Itās going to be a fault with NAT, firewalls, or the handling of Route/Record-Route and Via by the caller, their proxies, and any proxies on your side (e.g. in routers with SIP ALG enabled. Make sure that SIP Application Level Gateways, whatever they are actually called, are turned off in routers you control.
Also try and work out what the various addresses represent.
A long thread but Iām reasonably certain itās your situation:
I am not a SIP Expert, in fact I am trying to learn nowā¦
Looking at the logs myself, I see that although the contact in the INVITE is different than the Registration URI, Asterisk is sending the replies to the the Registration URI and NOT the contact URI in the INVITE.
Could that be the problem?
How do I fix that if it is?
Thanks
No, replies are sent back to the source (if rport on) or to the Via address (rport off). And, we know that FPL heard the 200 reply, because audio was working and thatās the only way it would know what port to send it to.
The Contact in INVITE is where subsequent requests in the dialog such as BYE should be sent.
What you been smokinā? An ACK acknowleges a response to a request, i.e. it is sent from the requester to the responder. So it is sent to a resource of the responder, usually defined by the Contact header in the response, modified by routing information. The Contact header in the INVITE specifies a resource of the requester.
Apologies. I meant response. A wrong contact header in the response here would explain the lack of of an ACK, but not a wrong one in the INVITE.
Depends on how you define āwrongā. pjsip is sending an unusual Contact header, i.e. one without a user part. Iām reasonably certain that this doesnāt violate any RFC, yet the Fibernetics server doesnāt process it correctly with the result that they donāt send an ACK.
So this could be fixed at the pjsip end by sending, e.g., sip:asterisk@ipaddress or sip:s@ipaddress instead of sip:ipaddress. Or, Fibernetics could fix it by accepting the unusual format. In the referenced thread, I outlined various ways either of these options could be accomplished. Unfortunately, several years have passed with no progress on this issue.
This is the setting you need and it looks like it is in Asterisk 21.0.0+, 20.5.0+, and 18.20.0+.
Wow, Iām impressed. The OP is on 18.16.0 so all he has to do is system updates (and set Contact User to his 1905 number if not already).
Hey Guys:
Before posting here I did the following:
After reading the last post I was very skeptic, but I decided to give it a try and add back the Contact User.
And so as I am making the call and following the logs, what a surprise: I couldnāt believe my eyes: an ACK !
Then the call went beyond the 32 seconds.
I had to test it 3 times in order to accept the fact that I am not dreaming.
Thank You Guys.
I almost gave up!
BTW:
Till now I had an older version of RasPbx running on a Beagle Bone board for probably over 5 years.
From time to time it would crash but I kept backup images.
~2 weeks ago it crashed again but I misplaced the backup.
So instead of trying to re-install the PBX on the board I decided to try run it on a VM and here I am.
Thanks again guys !
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.