I installed Asterisk 13 on Debian 9, and I tried in several different ways to play an audio file and I call, asterisk answers but it doesn't play the file. Here is my extensions.conf:
[ivr1]
exten => s,1,NoOp(IVR1)
same => n,Answer
same => n,Read(/var/lib/asterisk/sounds/custom/welcome)
same => n,WaitExten(5)
exten => 6598,1,Goto(ivr1,s,1)
Asterisk shows:
-- Executing [6598#ivr1:1] Goto("SIP/user-cc-0000001c", "ivr1,s,1") in new stack
-- Goto (ivr1,s,1)
-- Executing [s#ivr1:1] NoOp("SIP/user-cc-0000001c", "IVR1") in new stack
-- Executing [s#ivr1:2] Answer("SIP/user-cc-0000001c", "") in new stack
-- Executing [s#ivr1:3] Read("SIP/user-cc-0000001c", "/var/lib/asterisk/sounds/custom/welcome") in new stack
-- User disconnected
I tried with 2 different SIP Clients and the sounds doesn't play. I tried with different codecs and still doesn't play.
Any ideas what could it be the problem?
Thanks
You should open rtp ports(default 10000-20000) in your firewall.
Also need ensure you have correct nat settings for your network type.
It seems you are using read function in a wrong way, it has to be something like this.
read(variable_name,sound_file)
please check link for further information
https://wiki.asterisk.org/wiki/display/AST/The+Read+Application
You should run a pcap at your client and on the asterisk server. Use wireshark to perform the capture. You should see signalling for the call setup and then the associate RTP. If you see RTP sent by asterisk and not received at your client then you have a firewall issue. You should be able to see the SDP in the SIP signalling to determine what ports are being requested by the client and asterisk. Compare that with your firewall settings. Generally speaking if your client is behind a NAT then you will need to make sure that comedia is enabled in asterisk (nat settings). You will also want to make sure to disable SIP ALG on your client-side firewall too.
This could be a NAT issue, so open your sip.conf and add the following on your peers
nat=yes ;for older asterisks versions
or
nat=force_rport,comedia ;for newer versions of asterisk
then on your CLI run sip reload
Related
I have a FreePBX 13 server set up with a SIP Trunk connection, however for some reason we are not getting the ring back tone for calls going out of the trunk connection.
I was able to implement a work around for this by placing the "Tr" options under "Asterisk Trunk Dial Options" to force Asterisk to produce the ring back tone for outbound calls.
However this only works while manually dialing from a soft-phone / VoIP Phone, when I try to launch a call via the Asterisk AMI "Originate" command we are not getting the ring back tone, even when the "r" option is set on the trunk. This is how the command I'm sending looks:
Action: Originate,
Channel: SIP/{extension},
Context: from-internal,
Exten: {phoneNumber},
Priority: 1,
Callerid: {callerId},
Timeout: 30000,
Async: yes
Any idea about what can I do to force the ring back tone?
This could be due to inband progress.
Try to add the following to your sip.conf
under [general] section,
prematuremedia=no
progressinband=yes
if you are using freepbx, then navigate to your trunk settings in the user interface and add the above 2 configs under the peer settings.
restart asterisk and try after that.
Launch Originate via Local/ channel call, if still not work, launch via custom context which answer first.
This is not an uncommon problem. Your ITSP is being lazy and either not providing or not forwarding RFC-complaince SIP 180/183 responses.
My usual solution is to put the local caller into an MOH state where the MOH is a ring tone, and then when the other end picks up, bridge the two calls.
This is kind of jarring, however, if the remote end is busy or is congested, since you go from "fake ring" to "real error tone". The other option is to reverse your dialing process ... call the remote end and then hook the local end, so that the local end doesn't need to hear ringing.
Of course, you can also reach out to your ITSP and tell them you need them to be RFC SIP 180/183 complaint.
I know the basics of Asterisk . When I go into the console by running the command asterisk -rvvv I see the following:
If you notice I first get a notice:
[Aug 24 19:14:43] NOTICE[5097][C-00000036]: chan_sip.c:25877
handle_request_invite: Call from '' (62.210.26.82:5079) to extension
'011972599166454' rejected because extension not found in context
'default'.
and then I get a warning and this happens every minute.
So my question is who is dailing extension 011972599166454 ? If I add:
[default]
exten => _X.66454,1,NoOp(Hanging up call)
same => n, Hangup
to my extensions.conf file this solves the problem. But why is someone making a call every minute? to open the NAT? Should I stop this?
I'd just ban the IP address with your firewall and forget it.
If you are curious, you can set sip set debug ip <ip> and check SIP headers, maybe you could find some info about callee in the headers.
Also you can trace the IP with whois and try to find admins' contact to discuss the issue.
This is scanning bot looking for free calls.
Just disable guest calling sip.conf: allowguest=no. Then any not authenticated connections will be ignored. It will help with new IPs also.
http://www.voip-info.org/wiki/view/Asterisk+sip+allowguest
It seems that this is an attempt of hacking...
Use Fail2Ban for blocking any suspected attempts to call.
I am a real beginner in asterisk, so please tolerate my question :)
I tried to configure asterisk for realtime and it is working fine for local sip calls. Now, I am trying to make the following test with dahdi calls:
I connected an analog phone to an FXS channel of my Digium card and tried to call this phone (exten 124) from a sip softphone (X-lite).
I get the following error:
-- Executing [124#from-sip:1] Dial("SIP/2000-00000004", "SIP/124")
[May 31 10:24:22] WARNING[5457]: chan_sip.c:5667 create_addr: Purely numeric hostname (124), and not a peer--rejecting
my extensions.conf:
[from-sip]
switch =>Realtime
[from-pstn]
exten => 124,1,Dial(DAHDI/3)
It seems that the dial is done using from-sip context not from-pstn context as required.
Anyone to advise or correct my understanding?
Thanks million
Zak
In Asterisk realtime and not realtime you can configure where to send calls from particular extension, this should be configured in "context"(for realtime check context column), so I believe in your case it is "from-sip". This means all calls from that extension will hit this context, you can't send one call from same extension to one context and other to another, all calls will hit "from-sip" context.
I have installed asterisk 11.5.1, and I have Bria on iPhone as the sip client. username/passwords are set in sip.conf, and the default dialplan (used by the clients) is
exten => _X.,1,Dial(SIP/${EXTEN},20)
exten => _X.,n,Hangup()
I have two iphones, say A and B, and I attached to the running asterisk with asterisk -rvvvv. When I hit 'Register' button from A, I see
Registered SIP 'A' at ww.xx.yy.zz:mmmm
message on the asterisk cli. When I hit 'Register' button from B, I see
Registered SIP 'B' at aa.bb.cc.dd:nnnn
Unregistered SIP 'B' <== HERE IS THE PROBLEM
although I do not hit Unregister from client B. Besides, B seems registered at the client. From now on, any call from B results in 'request timeout'. And if I call B from A, I see 'subscriber absent' message on the asterisk cli.
Why is asterisk unregistering client B? Any suggestion?
p.s.: I see the following error in asterisk cli:
chan_sip.c:3905 __sip_xmit: sip_xmit of 0x7f7df4027b00 (len 622) to aa.bb.cc.dd:nnnn returned -2: Interrupted system call
EDIT: My sip.conf file is as following
[myConf](!)
disallow=all
allow=g729
allow=gsm
allow=g723
allow=ulaw
allow=ilbc
directmedia=no
host=dynamic
dtmfmode=rfc2833
context=default
type=friend
transport=tls,tcp
qualify=4000
nat=force_rport,comedia
encryption=yes
[A](myConf)
secret=AAAA
[B](myConf)
secret=BBBB
I can't give you the exact solution but I can point to where it may can be the problem.
The documentated part of the code from where you hit the problem in chan_sip.c says
* \return length of transmitted message, XMIT_ERROR on know network failures -1 on other failures
In your case you fall on the other failures as Interrupted system call. That message led me to an open bug suspended due to lack of activity here. So my bid is that this error is more related to operating system than Asterisk itself.
My following question is, if you invert the order (first register B and then register A) is the last one who gets the error? If yes then you may start looking at the selinux or any other security tool that is killing the connection after is established. Otherwise you may need to update the bug and let the people from Asterisk fix the bug.
Let us know the result, is always nice to find posts with fixes :)
I think you need deal with NAT
http://www.voip-info.org/wiki/view/Asterisk+SIP+NAT+solutions
OR you have check that your B can got message from asterisk and answer it correctly. More info can be got using sip debug
asterisk -r
sip set debug on
I'm a newbie in Asterisk, so I'm gonna start with something simple.
I read some documentation and I've managed to do some basic config.
My Asterisk version is 1.6.2.9-2+squeeze10 (installed on Debian using apt-get) and changed ONLY sip.conf and extensions.conf.
My idea is to use it as a SIP client, connected to the Flowroute SIP server - but please see what's happening when I use console dial EXTEN...
sip.conf
[general]
register => 74770000:HIDDEN#sip.flowroute.com/s
registertimeout=20
context=default
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=no
subscribecontext=from-sip
[flowroute]
canreinvite=no
username=74770000
fromuser=74770000
secret=HIDDEN
context=default
type=friend
fromdomain=sip.flowroute.com
host=85.17.214.222
dtmfmode=rfc2833
disallow=all
allow=alaw
allow=ulaw
nat=yes
insecure=very
extensions.conf
[default]
exten => _XXXXXXXXXXXXXX,1,Dial(SIP/flowroute/${EXTEN})
;exten => _XXXXXXXXXXXXXX,2,Hangup
sip show users
loreen*CLI> sip show users
Username Secret Accountcode Def.Context ACL NAT
flowroute HIDDEN default No Always
sip show peers
loreen*CLI> sip show peers
Name/username Host Dyn Nat ACL Port Status
flowroute/74771200 85.17.214.227 N 5060 Unmonitored
1 sip peers [Monitored: 1 online, 0 offline Unmonitored: 0 online, 0 offline]
console dial EXTEN
loreen*CLI> console dial 00359891505054
[Jun 14 16:44:27] WARNING[14031]: chan_oss.c:486 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
[Jun 14 16:44:28] NOTICE[14031]: console_video.c:133 console_video_start: voice only, console video support not present
[Jun 14 16:44:28] WARNING[14033]: app_dial.c:1714 dial_exec_full: Skipping dialing interface 'SIP/flowroute/00359891505054' again since it has already been dialed
Unfortunately, Asterisk 1.6.2 was made end-of-life in april 2012, and it doesn't seem this feature is still supported, and using a sound card with Asterisk isn't the most common use-case.
Installing Asterisk from source is rather easy, and also rather clean (make uninstall will sufficiently clean it out). I highly recommend it, as it allows you to stay ahead of the game (with security and feature releases). Try it with ./configure and then make menuselect (you'll need ncurses libraries) for a really nice build interface.
While trying to test dial outbound calls on your SIP trunk (to test it's connectivity), I would recommend using the channel originate function at the CLI.
For help:
asterisk*CLI> core show help channel originate
A specific device and parameter string using your setup:
asterisk*CLI> channel originate SIP/flowroute/00359891505054 application Playback tt-monkeys
Note: This will play the sound of screaming monkeys to the called party!
Also -- if you're a smart phone user, it's rather convenient to have a softphone hooked up as an extension to test your trunks, new dialplans, etc. (Although I'll always do my initial tests with channel originate)
Lastly -- but equally importantly... I realize this is a test scenario, but... As you bring this forward; I'd avoid directly dialing your ITSP with the dialed extension from the [default] context. This could, if not otherwise configured properly, leave you open to toll-fraud via the fact that asterisk defaults call attempts to this context if the context is otherwise unknown.