Doesn’t look to me like you have an outbound route with that number scheme. Try setting up an outbound route with NXXNXXXXXX as the outbound match string.
Also, double check your trunks using Asterisk Info and make sure your trunks are registered and working.
For outbound calls on SignalWire, the destination number must be formatted as e.g. 150xxxxxxxx or +150xxxxxxxx. Likewise, the caller ID you send must be formatted as e.g. 16033264791 or +16033264791. SignalWire will only allow you to send a caller ID that is a purchased or verified DID on their system.
On incoming, both the caller ID and the DID will be formatted beginning with +1 (for calls from US to US). Your trunk context and/or Inbound Route must take that into account.
Thanks Cynjut & Stewart
sorry for late reply.
You made my day . The problem was with the outbound CID. I thought in dialplan i’ve added 1 (prepend) and 10 digits rule but it was not working . After adding 1 and 10 digits DID in outbound CID it worked . outbound call is working but did not check NAT for voice, I hope so it is working . I’ll also check the inbound call .
really appreciated you guys for this help .
call is going and incoming to my DID number ( and then to my extension) but there is issue of nat i can hear caller voice but they can not hear me . Can you please guide me in this regard. I’ll be thankful to you. let me share log/information with you.
outbound rule
+1NXXNXXXXXX
sip setting (outbound) host=xxxxxxxf.sip.signalwire.com fromdomain=xxxxxxxf.sip.signalwire.com
port=5061
transport=tls
qualify=yes
username=Fuxxxxxxxx
fromuser=Fuxxxxxxxx
secret=passwordxxxx
dtmfmode=rfc2833
nat=no
type=peer
canreinvite=no
insecure=port,invite
context=from-trunk
disallow=all
allow=ulaw&alaw&opus&gsm
sip setting inbound
tls://Fuxxxxxxxx:passwordxxx:[email protected]:5061/617xxx
where 617xxxx is my DID & CID
Logs are here.
[2019-08-02 14:54:24] VERBOSE[10905][C-00000008] pbx.c: Executing [s@func-apply-sipheaders:2] Set(“SIP/xxxxx.sip.signalwire.com-0000000f”, “TECH=SIP”) in new stack
[2019-08-02 14:54:24] VERBOSE[10905][C-00000008] pbx.c: Executing [s@func-apply-sipheaders:3] Set(“SIP/xxxxxx.sip.signalwire.com-0000000f”, “SIPHEADERKEYS=”) in new stack
[2019-08-02 14:54:24] VERBOSE[10905][C-00000008] pbx.c: Executing [s@func-apply-sipheaders:4] While(“SIP/odunet-fe80eab6e78f.sip.signalwire.com-0000000f”, “0”) in new stack
[2019-08-02 14:54:24] VERBOSE[10905][C-00000008] app_while.c: Jumping to priority 10
[2019-08-02 14:54:24] VERBOSE[10905][C-00000008] pbx.c: Executing [s@func-apply-sipheaders:11] Return(“SIP/xxxxx.sip.signalwire.com-0000000f”, “”) in new stack
[2019-08-02 14:54:24] VERBOSE[10905][C-00000008] app_stack.c: Spawn extension (from-trunk, 5082988825, 1) exited non-zero on ‘SIP/xxxxxf.sip.signalwire.com-0000000f’
[2019-08-02 14:54:24] VERBOSE[10905][C-00000008] app_stack.c: SIP/odunet-fe80eab6e78f.sip.signalwire.com-0000000f Internal Gosub(func-apply-sipheaders,s,1(2)) complete GOSUB_RETVAL=
[2019-08-02 14:54:24] VERBOSE[10905][C-00000008] app_dial.c: Called SIP/odunet-fe80eab6e78f.sip.signalwire.com/+15xxxxxxxx
[2019-08-02 14:54:26] VERBOSE[10905][C-00000008] app_dial.c: SIP/xxxxx.sip.signalwire.com-0000000f is making progress passing it to SIP/4004-0000000e
[2019-08-02 14:54:29] VERBOSE[10905][C-00000008] app_dial.c: SIP/odunet-fe80eab6e78f.sip.signalwire.com-0000000f answered SIP/4004-0000000e
[2019-08-02 14:54:29] VERBOSE[10906][C-00000008] bridge_channel.c: Channel SIP/odunet-fe80eab6e78f.sip.signalwire.com-0000000f joined ‘simple_bridge’ basic-bridge <05dd0499-a1b3-4e47-a129-4674f7f66a8a>
[2019-08-02 14:54:29] VERBOSE[10905][C-00000008] bridge_channel.c: Channel SIP/4004-0000000e joined ‘simple_bridge’ basic-bridge <05dd0499-a1b3-4e47-a129-4674f7f66a8a>
[2019-08-02 14:54:37] VERBOSE[10906][C-00000008] bridge_channel.c: Channel SIP/odunet-fe80eab6e78f.sip.signalwire.com-0000000f left ‘simple_bridge’ basic-bridge <05dd0499-a1b3-4e47-a129-4674f7f66a8a>
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] bridge_channel.c: Channel SIP/4004-0000000e left ‘simple_bridge’ basic-bridge <05dd0499-a1b3-4e47-a129-4674f7f66a8a>
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] app_macro.c: Spawn extension (macro-dialout-trunk, s, 25) exited non-zero on ‘SIP/4004-0000000e’ in macro ‘dialout-trunk’
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx.c: Spawn extension (from-internal, 50xxxxxx, 9) exited non-zero on ‘SIP/4004-0000000e’
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx.c: Executing [h@from-internal:1] Macro(“SIP/4004-0000000e”, “hangupcall”) in new stack
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx.c: Executing [s@macro-hangupcall:1] GotoIf(“SIP/4004-0000000e”, “1?theend”) in new stack
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx_builtins.c: Goto (macro-hangupcall,s,3)
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx.c: Executing [s@macro-hangupcall:3] ExecIf(“SIP/4004-0000000e”, “0?Set(CDR(recordingfile)=)”) in new stack
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx.c: Executing [s@macro-hangupcall:4] NoOp(“SIP/4004-0000000e”, "SIP/xxxxxxxx.sip.signalwire.com-0000000f montior file= ") in new stack
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx.c: Executing [s@macro-hangupcall:5] GotoIf(“SIP/4004-0000000e”, “1?skipagi”) in new stack
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx_builtins.c: Goto (macro-hangupcall,s,7)
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx.c: Executing [s@macro-hangupcall:7] Hangup(“SIP/4004-0000000e”, “”) in new stack
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] app_macro.c: Spawn extension (macro-hangupcall, s, 7) exited non-zero on ‘SIP/4004-0000000e’ in macro ‘hangupcall’
[2019-08-02 14:54:37] VERBOSE[10905][C-00000008] pbx.c: Spawn extension (from-internal, h, 1) exited non-zero on ‘SIP/4004-0000000e’
where 4004 my phone extension & I’m using TLS port 5061 and SSLv2 and I think all are ok regarding certificate on server and softphone.
Please guide me where i’m making mistake.
thanks.
We know that It’s NAT issue but how to resolve this issue. keepalive=yes( in sip oubound setting) and keepalive=1 in sip setting. nat = yes in sip outbound & codec are also OK . which setting of NAT I’m missing . i’ll really appreciate you if you resolve NAT problem . thanks .
I’m very confused. You are describing an incoming call but posted a log of an outgoing call. Your extension 4004 seems to be in Pakistan but you have a system with US dialing patterns. You talk about NAT but have not mentioned what is NATted.
What country are you in? What country is the PBX in? Cloud or on-site? If on-site and behind NAT, post make and model. Is extension on the same LAN as the PBX? If not, post router make/model.
Does *43 echo test work ok? Do calls between extensions work ok? On an outbound call, is it the extension user or the remote party that can’t hear?
thanks Stewart
Actually i forgot to mention that i work for USA company office remotely. Freepbx IPPBX is deployed on cloud and iptables are configured to allow voice traffic tcp udp tls ports 5060, 5090 , 5061 and 5062 . sorry i just sent you logs incomplete but can provide you if you want . extension is registered with my IP PBX (cloud) on port 5061 with tls and encryption enabled. rtp rangs 10000-32767 are allowed on my soft phone microsip as well as on IP PBX. In VPC GCP cloud firewall rules allowed " all 0.0.0.0" so there is no problem of ports and ips.
However i fixed this issue by enabling DTMF Signalling “auto” in PBX extension [my extension 4004] .
I also checked the echo test , thanks for telling me that test it also confirmed that my headphone mic was not working.
Thanks Stewar and others, appreciated for the help.
Probably not, but IMO it’s not completely implausible. It’s conceivable that Asterisk was passing RTP between the channels without decryption and/or decoding (matched codecs, etc.), which for some reason was not working in one direction. The ‘auto’ setting might have selected inband, forcing Asterisk to decrypt and decode the RTP so it could listen for DTMF, changing the type of bridging to something that passes audio both ways.
If the OP were my customer (rule #1: the customer is always right), I’d first ask him to confirm that reverting DTMF signaling causes the problem to return, then test whether recording the call (which also forces decryption and decoding) ‘fixes’ the issue.
This century plus old adage has been debunked numerous times over the last century and it no longer applies in this day and age overall. Why? Because customers can be dishonest when they think it will give them an advantage. You know how many times I’ve gotten equipment back because the customer complained “It just died and we need a new one” only to take the thing apart and find water or other types of damage to the system. How many times they have claimed one thing and then I discover it’s the absolute opposite.
Would you ask why there is no encryption=yes to enable SRTP? Is this just supposed to be just the transport under TLS and the RTP not encrypted? If auto/inband is the magic answer (which I don’t think it is) then are you going to confirm with them that opus and gsm are out the door? Narrow band codecs can’t be used. It has to be alaw/ulaw for inband DTMF to work.
More importantly, and something I never understand isn’t done more, where is the debug?! Why hasn’t anyone asked for a SIP trace/debug of this call to check the actual signalling/media of the call? Either before the change or after the change?! How can any one say what the issue really is and confirm how changing the DTMF setting (a setting that controls how Asterisk sends DTMF to the endpoint/device) made the RTP just magically work.
This could be a false positive and the audio being there has nothing to do with the DTMF setting and this will happen again.
You can see what the original issue was, if the RTP was being sent encrypted, what codecs were used, etc. etc. etc.
You can see the difference after the DTMF mode was changed. Was it the actual cause of it or did something different happen?
Most importantly, you would see the call from both the device to Asterisk and Asterisk to Signalwire. Which could expose an issue at the Asterisk level with the two channels trying to bridge the audio between them. Or something on the actual endpoint side that could have caused this.
