My dial plan is currently very simple: {1[2-9]xx[2-9]xxxxxx}
I am dialing full 11-digit numbers in same country/etc. and all goes to fast-busy. If I dial another ext. on the FreePBX, same thing (with modified dial plan).
I’ve tried changing all the NAT settings, but that did not seem to work.
When the HT resent the INVITE with the Authorization header, the packet was large enough to require fragmentation, which was not handled correctly somewhere in the path, such that the PBX never saw it.
Reduce the packet size by disabling unused codecs in the HT; try enabling only ulaw and alaw (A.K.A. PCMU and PCMA, or G711U and G711A).
The INVITE sent by the HT still shows all the codecs in the SDP. Your screenshot shows disabling the feature codes to select a particular codec, which is not relevant to this thread. You need to disable the codecs in the Preferred Vocoder section for the FXS port in question.
Thank you- I located the section and set as follows:
This seems to have done something as now there is a lot more action in the logs, it appears more like ‘normal’ outbound calls now-- but now instead of fast-busy, it’s just silence for about 15 seconds and then busy-tone. Dial failed due to trunk reporting BUSY– this is odd because my cell phone is definitely not busy and the trunk is not in use by anyone else.
The verbosity on pjsip set logger on will make for some time to go through and redact… these are the logs without it. Let me know if you need the full logs and what you think.
There are at least two problems remaining. First, SIPStation rejected the call. One possibility is they considered the caller ID invalid. Line 114 of the paste: -- Executing [s@macro-outbound-callerid:31] ExecIf("PJSIP/7155-000016d3", "1?Set(CALLERID(all)="Andy "<5555551212>)") in new stack
I assume that’s "Andy "<5555551212> from Outbound CID for extension 7155. I’m guessing that they require "Andy "<15555551212> or possibly "Andy "<+15555551212>
If changing that doesn’t let the call go through, we’ll need sip debug (it appears that the trunk is using chan_sip) to see what’s wrong.
The other issue is that the trunk played an error announcement in early media before ending the call, but the audio somehow didn’t properly get to the HT, which just played silence. Line 177 of the paste: > 0x7f13f817f4e0 -- Strict RTP switching source address to MY.PUB.LIC.IP:57227
So it appears that your router/firewall rewrote the RTP source port from 5004 to 57227 and possibly the RTP that Asterisk was presumably sending to port 57227 didn’t make it back to the HT.
Router/firewall make/model? Any VoIP-related settings? If it has a SIP ALG, try turning that off.
I changed the CID format to 1xxx and +1xxx but it did not have any effect. I matched the other extensions in my original format as those others are working fine.
What is the command to turn on chan_sip logging?
I’m using a pfSense firewall that does not have any SIP ALG settings. I have tried turning on 1:1 NAT, but that did not have any effect.
You want sip set debug on
in addition to pjsip set logger on
Also, take the log from /var/log/asterisk/full
instead of the console, so it includes timestamps.
Finally, please paste two logs: one for the failing call, and for comparison, one from a working extension at the same location calling the same number.
My first suspicion is that pfSense is not ‘hairpinning’ the RTP correctly. In the HT, for the FXS port(s) in question, try changing Primary SIP Server from the PBX hostname to the LAN IP address of the PBX. I am assuming that it’s 192.168.2.x, or at least is on a subnet that is non-NAT routed through the firewall.
If the above test succeeds but the change is incompatible with some other requirement, provide details.
If the test fails but with new symptoms, provide details.
If the test fails (no change in behavior), try calling 1 800 437 7950. If this also fails, paste a new log calling this number (you don’t have to redact it and I’m familiar with the timing). If this succeeds (and assuming that the failing call was to your mobile), I suspect that the mobile carrier rejected the call, possibly because of a (real or falsely detected) irregularity in the caller ID.
Please paste a new log of the simplest thing that fails.
First, try *43 (echo test, make sure that the HT dialplan allows it). Confirm from a working extension that echo test works as expected.
Next, a call from the HT to a working extension.
Next, a call to 18004377950.
Hi @Stewart1- I think my issues were some combination of several things.
I factory reset the ATA and re-set up the port with only changing the Vocoder settings and nothing else. Who knows what other settings I had altered from the default during all of my testing.
After this, I called the ANI number and it worked! I called my cell and it rang a couple times and went to a voicemail greeting (not my own) and I left a voicemail, but it never appeared on my phone. I would note that prior to the factory reset, I never got this far!
I had remembered you mentioned before that my mobile carrier might be rejecting the call. As a test, I changed the outbound CID number to something else and low and behold…my cell rang as expected!
I think I had just a combination of issues and I cannot thank you enough for taking the time to look over my logs and help a noob out!
