Hello,
I am struggling to configure a RCS-RDS SIP Trunk on a freePBX installation.
After a lot of tinkering I managed to have working incoming calls but the outgoing calls always fail with “All circuits are busy now.”
I’m not sure if the settings I received from RCS-RDS are incomplete, or if there is some issue with my config so I will appreciate any help from you guys.
Thank you,
Kreathor
Just a guess:
Try setting From User to the same value you have in Username, and From Domain to the same value you have in SIP Server.
If no luck, at the Asterisk command prompt type
pjsip set logger on
make a failing test call, paste the Asterisk log for the call at pastebin.com and post the link here.
Call a number you don’t have to redact, such as a local McDonald’s.
Thanks for your reply Stewart. I already have the “From User” and “From Domain” fields configured the way you mentioned.
Here is the link to the log on pastebin: Outbound Call Log
Aditional information:
My SIP Provider (RCS-RDS) doesn’t require REGISTER. Instead, they use proxy authentication with username/password on each invite.
Log line 229 shows that calling on the trunk was attempted, however no INVITE was sent.
Line 244 shows that no circuit was available, but the details of why that decision was made are not present.
Some useful detail may have been in the Asterisk log ( /var/log/asterisk/full ), but it appears that you pasted from the console or other source that was missing some info.
In any case, check that the trunk shows Avail in Reports → Asterisk Info → Peers. If not, find out why, for example, no response to the qualify (OPTIONS) sent. Also check that the trunk is enabled and (if using registration for incoming) that it is registered ok.
Also, I noticed that the extension is on a 192.168.99.x subnet but the PBX is on 172.25.2.x.
Please explain the networking setup. Is any NAT involved? A virtual machine not using bridged neworking?
The trunk doesn’t respond to the qualify requests. I understand that this is expected, as it doesn’t need to REGISTER but it uses authentication (user/pass) on each INVITE.
Yes, the log I provided was copied from the console. I will try again later today and paste the full log.
The network configuration is the following:
Site A
Here are the settings RCS-RDS gave me (translated from romanian):
IP PBX:192.168.54.222 (private IP without internet access)
NM : 255.255.255.252
GW : 192.168.54.221
5 communication channels
numbers = 350733006 = main number;
username = 350733006
password = xxxxxxxxxxx
domain = sip.rcs-rds.ro
proxy - sip.rcs-rds.ro
DNS - 82.76.7.30, 82.76.7.26
82.76.7.30 and 82.76.7.26 are accessible only via gw:192.168.54.221.
The REGISTER method is not mandatory, but on each INVITE it is required to use Proxy Authentication with username and password.
The identity is transmitted via the “From” header. If the “From” header’s content is different than the main number, the identity of the call will be automatically changed to the main number (350733006)
You must have VAD off and comfort noise activated, so when there is no RTP in both ways, the call is automatically closed after 60 seconds (if the PBX have those options)
You must have the codec G711 A-law enabled
The gateway (192.168.54.221) and the DIGI SIP servers (82.76.7.26 and 82.76.7.30) must respond to icmp requests
You are conflating several different things here. As far as REGISTER is concerned, it only relates to incoming calls, and does not pre-authenticate outgoing INVITEs; those need the same authentication as does the REGISTER (which might be none, although that isn’t common). Qualify is allow the system to know that outgoing calls will fail, without having to try them, although it can serve a secondary purpose of keeping dynamic rules lilve in a firewall or NAT device. It is not something that is applicably if and only if you are using REGISTER, although when using REGISTER, it is more likely that you are behind dynamic router rules, and the secondary purposes come into play.
Thank you all for your replies.
This is the log of the same call from yesterday, copied from the /var/log/asterisk/full file.
@david55 I don’t know why I thought that REGISTER and Qualify are directly related. After reading your post I changed Qualify to 60 (it was 0) but the issue with the outgoing calls remains.
I am relatively new to this field (I only configured a Grandstream PBX a while ago but that went smoothly). It seems that I underestimated the complexity of configuring a FreePBX system.
If Qualify Frequency was set to 0 when you made the logged call, there must have been some other reason why the trunk appeared unavailable. Are there any Reachable / Unreachable messages in the log about this trunk?
However, I believe it is very unlikely that the server (to which an outgoing INVITE would be sent) does not respond to OPTIONS. One possibility is that the request went out through the wrong interface. Another is that the Via header contains the wrong source address.
What address(es) does sip.rcs-rds.ro resolve to? Can you ping it from the PBX?
Every DNS server replies with it’s own IP address, which is to be expected as per RDS instructions, so even if one server is down the DNS query will always return the IP of the one that is online.
root@freepbx:~# dig sip.rcs-rds.ro
; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> sip.rcs-rds.ro
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36844
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;sip.rcs-rds.ro. IN A
;; ANSWER SECTION:
sip.rcs-rds.ro. 0 IN A 82.76.7.30
root@freepbx:~# ping sip.rcs-rds.ro
PING sip.rcs-rds.ro (82.76.7.30) 56(84) bytes of data.
64 bytes from sip.rcs-rds.ro (82.76.7.30): icmp_seq=1 ttl=62 time=9.50 ms
64 bytes from sip.rcs-rds.ro (82.76.7.30): icmp_seq=2 ttl=62 time=10.2 ms
root@freepbx:~# traceroute sip.rcs-rds.ro
traceroute to sip.rcs-rds.ro (82.76.7.30), 30 hops max, 60 byte packets
1 192.168.54.221 (192.168.54.221) 0.859 ms 0.693 ms 0.641 ms
2 rds.pri.adv-h.rdsnet.ro (82.76.7.29) 9.555 ms 10.462 ms 10.411 ms
3 sip.rcs-rds.ro (82.76.7.30) 10.350 ms 10.287 ms 10.241 ms
The route also looks good, going via the GW of the SIP interface (192.168.54.221)
With pjsip logger on, you should see OPTIONS requests in the Asterisk log. If so, post or paste one, with any replies.
It seems to me that they are abusing DNS here. All the name servers should serve the same zone file, and whilst 0 is a permitted value in the TTL field, in the zone file, it is rather anti-social, as it forces end to lookups every time the domain name is used.
The 0 TTL would be ineffective with chan_sip, as it doesn’t repeat DNS lookups, and I’m not sure that chan_pjsip, does a DNS lookup as soon as the record expires. I think caching servers often deliberately apply a grace period beyond the official TTL.
I’d note that FreePBX distributions install a caching name server, which is wasted if the service provider tries to defeat caching.
Having the only working DNS server also be the one that handles normal traffic doesn’t seem to be a resilient way of doing things
Thanks David, it looks like this is the problem. I replaced sip.rcs-rds.ro with 82.76.7.30 in the trunk configuration (“SIP Server” and “Outbound Proxy”) and now I can see the INVITE in the logs and the response from the server. But now I get a “Dialed number is not in service” error. In the reply from the server, I can see something like this:
[2025-09-18 08:58:29] VERBOSE[7259] res_pjsip_logger.c: <— Received SIP response (423 bytes) from UDP:82.76.7.30:5060 —>
SIP/2.0 484 Address Incomplete
Address incomplete means the dialled number is too short, but otherwise well formed.
Pastebin’s current policies on how to handle people who won’t give them total tracking rights mean I no longer look at logs on their site. The equivalent service run for freepbx.org still works.
Outbound Proxy should either be be left blank (it’s the same as SIP Server) or formatted as
sip:82.76.7.30\;lr\;hide
Note backslash semicolon in two places.
Thanks Stewart. I had it formatted as “sip:82.76.7.30;lr” missing the backslash and without the “hide” part. I added the "" and now IT WORKS.
Is it possible to make it work by using the FQDN?
I don’t want to lock the connection to just one of the two servers.
Tough problem. AFAICT, a TTL of 0, although not recommended, is permitted by the DNS RFCs, meaning that the value should not be cached. So it appears that the DNS manager in FreePBX has a bug. While you could track down the details and report the bug, that seems like a lot of work.
A simple solution is to set up two trunks, one for each address, and list them both in your Outbound Route(s).
Another option is to create a domain name that resolves to both addresses (but has a non-zero TTL) and use it in Outbound Proxy, leaving SIP Server set to sip.rcs-rds.ro .
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.