Running latest version of FreePBX 15 (2104-1)
Our SIP Trunk provider is sending an invite but the freepbx replying a “100 Trying”
After 32 seconds the call was cut. This is only happening on inbound call. Outbound call is working fine.
Our FreePBX are connected directly to our provider’s router so there is no NAT or Firewall in between.
Our Trunk Provider saying that they are not receiving a 180 ring response.
I’m using PJSIP.
SIP Trunk Invite:
This is the FreePBX Response:
In Asterisk SIP Settings, confirm that External Address and Local Networks are correctly set.
Based on what you have told us so far, Local Networks should be
10.0.0.0 / 8
However, if you have a second NIC with a different private address for your phones and/or for connecting to the internet, you should have additional entries for those.
If you change any of these settings, you must restart (not just reload) Asterisk.
If you still have trouble, paste the complete SIP trace (not just the incoming INVITE) for a failing call at pastebin.freepbx.org and post the link here. Please do not post textual data as an image.
It’s the additional responses, in particular the 200 OK, that would help troubleshoot the problem.
Hi Stewart1, sorry for posting the textual data as an image.
My new account is not allowing me to paste links and I’m not aware yet that the forum has its own pastebin.
Here is the Call Flow History.
Below of it is the details of each entry.
FreePBX LAN IP (eth0): 192.168.10.11
FreePBX SIP Trunk IP (eth1): 10.11.11.11
FreePBX SIP Trunk Gateway IP (eth1): 10.11.11.10
SIP Server: 10.10.10.14
Media IP: 10.10.10.14 and 10.10.10.13
eth0 is the default route since it is connected to internet.
eth1 is the one directly connected to trunk provider’s router.
The network 10.10.10.0/24 is routed to eth1
PJSip Trunk Configuration (This is the only changes I made aside from default settings):
Asterisk Trunk Dial Options: Tr
SIP Server: 10.10.10.14
SIP Server Port: 5060
DTMF Mode: Inband
Client URI: sip:10.10.10.14:5060
Server URI: sip:10.11.11.11:5060
Match (Permit): 10.10.10.13, 10.10.10.14
Inband Progress: Yes
Rewrite Contact: Yes
Codecs: ulaw, alaw and g729
Asterisk SIP Settings:
Local Networks: 10.11.11.0/24
RTP Port Ranges: 10000 - 50000
RTP Timeout: 90
RTP Hold Timeout: 300
RTP Keep Alive: 10
SIP Settings [chan_pjsip]:
Allow Transport Reload: Yes
Keep Alive Interval: 20
Signal RINGING: Yes
Please let me know if you need more info.
Your OP says “Not Sending ACK”. However, the SIP trace shows ACK is being received by pjsip but apparently not recognized, so it retransmits the 200 OK, the gateway sends another ACK, etc., until the call is disconnected after 32 seconds for lack of response.
Unfortunately, I don’t know why pjsip didn’t ‘like’ the ACK. On (for example) lines 177 and 178 there are two Content-Length headers. This is apparently a bug on the provider’s side and is not valid SIP, but it is not obvious why a robust SIP stack should reject it, especially because the incoming INVITE has both the Content-Length and Content-Type headers duplicated, and pjsip accepted that just fine.
Further confusing the issue, I made a test call to Truelogic and kept the call up for well over 32 seconds by repeatedly entering invalid extension numbers, and the call did not drop. Have you fixed the problem, was my call (from +1 775 xxx xxxx) answered by another system, or is the trouble intermittent?
If you are still having problems, at the Asterisk command prompt type
pjsip set logger on
make a failing incoming call, paste the Asterisk log (not the console log) for the call and post the link. The Asterisk log should contain both the dial plan flow and the SIP trace intermixed and with luck there will be an error from pjsip about a problem with the ACK.
Thank you for calling our number that’s lead me to recheck our CDR.
I noticed that all incoming call with caller id that start with + was hang up after 32 seconds.
All caller id that has no + kept the call over 32 seconds like the one you did.
I confirmed it by calling from US and skype number.
The + sign on caller id only started when our trunk provider replaced their router connected to our pbx.
I already informed them to remove the + on all caller id of incoming call.
As requested here is the Asterisk Log that contain both the dial plan flow and the SIP trace.
The chan_pjsip module does not currently support tel URIs, so the ACK is being dropped due to that.
This means better to stick with chan_sip for now so it will work.
Is there any workaround for this on pjsip?
Nothing within PJSIP, no. Noone has implemented support for tel URIs.
can you please show me what’s that tel URIs and its format.
Our trunk provider already remove the “+” on caller id and incoming calls was now working well.
It’s in the From header:
Non-tel would be like:
From: <sip:[email protected]>;tag=V6VlHHpA
Got it. Thank you very much.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.