Hi,
I have started using Asterisk and FreePBX since two weeks and got most of it working.
But one problem is that I don’t get a ringback tone when calling from a cellphone to my PBX.
There is complete silence until I pick up the call.
The call is currently going through a ring group I have set up.
Here is a sngrep screenshot of the inbound call using Deutsche Telekom (Germany):
It seems that the PBX only sends 100 Trying without the 180 Ringing message?
The silence is because 183 Session Progress is sent and the audio stream does not include ringing, right?
This is everything I tried reading several forum posts:
First, I have set the Outbound Proxy to sip:tel.t-online:0 because forums suggested
using it because the SIP ALG of my router (Speedport Hybrid) reacts to it
and uses siproxd to proxy it correctly.
After that, outbound calls did not work, so I removed it again. Inbound calls did work but without the ringing.
Configuring “Singal RINGING” in the Inbound Route (on or off) did not work.
Inband Progress is enabled in the trunk.
The ring group has set “Send Progress” to No.
Setting the destination to an extension instead of a ring group does not ring either.
Another interesting thing is that when I am calling from my neighbor’s phone (same ISP),
the call is not ringing too but the call gets answers with silence and aborts after a few seconds.
However, in sngrep I haven’t seen any INVITE from this number, so no phone rings on my end.
Is there any configuration I haven’t done which prevents the ringing before the pickup?
And why does a call from another landline not come through, but from a cell-phone it does?
Possibly; you can check that by capturing traffic with tcpdump, moving the file to your PC, opening it in Wireshark and viewing or playing the RTP stream.
Confirm that the RTP is using the correct codec (probably alaw a.k.a. G.711a or PCMA) and is being sent to the correct IP address and port specified in the INVITE. Note that DT does support wideband for VoLTE calls so there may be some confusion here, if they are offering (and expecting) a codec that Asterisk is not configured to handle.
Another potential issue is that the Speedport may have rewritten the source port of the outgoing RTP packets and DT is rejecting them for that reason. Confirm that your RTP port range (UDP 10000-20000 by default) is forwarded in the Speedport to 192.168.2.103 .
A strangeness that may or may not be related to your issue is that the ACK comes from a different IP address, especially since that 217.10.79.9 resolves to sipgate.de. Is this PBX also configured for sipgate (or was it previously)?
If you still have trouble, at the Asterisk command prompt, type pjsip set logger on
make a test call in, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here. If you are too new to post links, just post the last 8 hex characters of the URL.
Or, if you want to include the RTP stream, capture the call with tcpdump, compress it to a .tgz and attach the file here. Or, you can just rename the .pcap to .tgz even though it isn’t.
I don’t hear this on my smartphone, but the communication after the pickup works without a problem.
I can hear my voice on both ends, so I don’t think it is really a port forwarding issue?
My port redirection looks like this:
I also find it strange that it uses G.722 here even if I have set the alaw codec as a higher priority:
I have seen the name of the channel “Telekom-859323-0000000” in the logs above these messages, but this trunk/route corresponds to another number I haven’t called. I don’t know if this is an issue, or if this is unrelated to the problem.
If you need anything else from the log, I can provide it for sure.
P.S.: I have sipgate configured but only as an outbound trunk and this IP did not appear in later test calls.
I am reasonably certain that the SIP ALG in the Speedport is not handling early media correctly. One possibility is that it simply doesn’t send RTP on the WAN until it receives some (your Wireshark capture shows that Telekom doesn’t send RTP until answer). Another is that it rewrites the source port number, causing Telekom to ignore the packets. Note that it did rewrite the source port for registration, which is why line 55 shows
I also noticed that the RTP player shows packets sent to port 7070 on the router, while the rewritten INVITE in the log on line 97 shows m=audio 7072 RTP/AVP 126 104 9 102 8 0 96 97
I guess that’s because these were different calls. If so, please don’t do that. If not, explain.
If you don’t need early media, just set Inband Progress to No and (with luck) Asterisk will send 180 Ringing and Telekom will play a proper ring tone to the caller. If not, that should be easier to debug.
If you do need early media, we somehow have to disable or bypass the ALG. Possibly, forwarding UDP port 5060 will do that, and if you want external extensions without VPN it will be needed anyway. Of course, you will need suitable firewall settings on the Pi (and you should probably change Port to Listen On from 5060 to an obscure value). Alternatively, as it appears that Telekom supports SIP over TCP on port 5060 and TLS on port 5061, you may find that the router doesn’t do ALG on TCP (many don’t). ALG over TLS is not possible, but is somewhat more hassle to set up.
Correctly distinguishing multiple trunks registering to the same server on the same provider is a tough problem. pjsip handles that with the Line parameter, but somehow it’s missing from your REGISTER requests, even though “Send Line in Registration” is on by default. If you turned this off because the ALG or Telekom chokes on it, you’re probably out of luck, but there are only rare cases where this matters, for example if the accounts belong to different departments and need to be billed separately.
You are right, this was a previous call in the screenshot because I haven’t got the PJSIP Debugging on at the right time. I didn’t notice that there were the different ports in the screen.
But the stream was the same. I will do this right next time.
I have solved this problem by disabling the Inband Progress on every trunk and not just one.
Somehow, it did not apply the whole setting when I did it for one number.
Additionally I achieved disabling the ALG and routing the whole traffic to another router, so the Speedport only acts like a modem. This solved every other communication problem I currently had.
