Call Forwarding Issue

FreePBX Providers
1

I have setup an inbound route that route incoming call to custom destination which is another SIP URI.

Below is my config:
[custom-dial-sip-uri]
exten => s,1,NoOp(Dialing External SIP URI)
exten => s,n,Dial(PJSIP/signalwire_sip,r)
exten => s,n,Hangup()

[signalwire_sip]
type = endpoint
context = from-internal
disallow = all
allow = ulaw
aors = signalwire_sip_aor

[signalwire_sip_aor]
type = aor
contact = sip:7axbb4xbxa12x11x--0@daily-7x4bbx4xbb12cx12-pinless-sip.dapp.signalwire.com

This configuration is fine but the issue is sometimes like 10% of the call have issue.
The call is successfully route but each end of the call cannot hear the sound from the other end.
What may the issue?

2

Are you behind NAT? If so have you set external media and signalling addresses?

Have you changed the RTP port range from the default?

Have you port forwarded that range in the router?

1 Like
3

Actually I am running FreePBX on AWS instance. And yes I set my public IP at External Address at NAT Settings.

The RTP Port Ranges is 10000 - 20000 and my instance allow UDP port 10000-2000 and 5060-5061 to be access by public.

4

You cannot just use a bare bones config without understanding the settings you are leaving out. All of the endpoint settings that deal with NAT are sent and all of their defaults are for a no-NAT setup.

direct_media default to yes, it should be no.
rtp_symmetric defaults to no and it should be yes
rewrite_contact defaults to no and it should be yes
force_rport defaults to yes, this is the only default that is correct for this use case.

You need to fix your trunk/extension endpoint configs so that it is setup to handle NAT properly.

5

direct_media is the only real likely problem setting here. The other ones are work rounds for peer systems that are behind NAT (not generally the case for providers) and do not compensate for that by doing the equivalent of Asterisk’s external signalling and media addresses and local networks. A provider who needs any of the remaining three should be avoided, as they don’t know how to configure their systems properly.

Setting them on is mainly harmless, which is why they tend to get set when not needed. However they can break some Cisco systems.

6

Note that I said trunk/extensions. The extensions will need it since this is in the cloud at AWS and NAT’d there. Since they are harmless on the trunk and I doubt the provider is using Cisco, this all should be fine.