A user recently notified me that whenever they attempt to dial into a conference call at another company, the phone call would get dropped after 5 seconds or so. They also indicated that when the same number is called using a cell phone, there were no issues. I found the following entries in log file.
[May 4 11:58:20] VERBOSE[24063] app_dial.c: -- DAHDI/1-1 is ringing
[May 4 11:58:20] VERBOSE[24063] app_dial.c: -- DAHDI/1-1 answered SIP/145-00000005
[May 4 11:58:24] WARNING[24063] rtp.c: Don't know how to represent 'f'
[May 4 11:58:24] VERBOSE[24063] chan_dahdi.c: -- Redirecting DAHDI/1-1 to fax extension
[May 4 11:58:24] VERBOSE[24063] pbx.c: -- Executing [h#macro-dialout-trunk:1] Macro("SIP/145-00000005", "hangupcall,") in new stack
[May 4 11:58:24] VERBOSE[24063] pbx.c: -- Executing [s#macro-hangupcall:1] GotoIf("SIP/145-00000005", "1?theend") in new stack
I have not been able to determine a solution. Any insight or suggestions on solving this problem are appreciated.
(Using FreePBX v2.9; Asterisk v1.6.2.15.1; CentOS 5.5 (Final); Sangoma A102)
Try add into file
/etc/asterisk/sip_general_custom.conf
faxdetect=no
Also tried modiying chan_dahdi.conf, but that did not work.
Final solution was to modify these settings (changing from YES to NO) in /etc/wanrouter/wanpipe1.conf
TDMV_HW_DTMF = NO # YES: receive dtmf events from hardware
TDMV_HW_FAX_DETECT = NO # YES: receive fax 1100hz events from hardware
Related
I am having an issue/trying to make something work within Asterisk. I have a trunk to an Ascom Nurse call system and there is a basic function to dial from a handheld device into a patient room. I am able to establish the call from Asterisk to the nurse call server. The nurse call server sends a Refer message
to a different address on the same subnet but Asterisk cannot find that device. If I manually type a dialplan to route calls to that device it does connect but the system could have many addresses and it would be impossible to tell what address and dial number would be in the Refer message
Asterik 10.2.87.201
Ascom 10.2.87.1
Refer Message refer-to: sip:V1003B0G65605773L0#10.2.87.11
I need to be able to have Asterisk transfer to that ext and domain dynamically.
This is a working example with a dialplan telling the system to manually send to the 10.2.87.11 address
exten => _VX.,n,Dial(SIP/${EXTEN}#10.2.87.11)
-- Executing [201*65609848#default:2] Dial("SIP/1341-000001cd", "SIP/T6/201*65609848") in new stack
== Using SIP RTP CoS mark 5
-- Called SIP/T6/201*65609848
> 0x7fba38016560 -- Strict RTP learning after remote address set to: 10.2.87.1:8766
-- SIP/T6-000001ce answered SIP/1341-000001cd
-- Channel SIP/T6-000001ce joined 'simple_bridge' basic-bridge <07b9ccbf-138d-423b-87cf-ad6c41336591>
-- Channel SIP/1341-000001cd joined 'simple_bridge' basic-bridge <07b9ccbf-138d-423b-87cf-ad6c41336591>
> Bridge 07b9ccbf-138d-423b-87cf-ad6c41336591: switching from simple_bridge technology to native_rtp
> Locally RTP bridged 'SIP/1341-000001cd' and 'SIP/T6-000001ce' in stack
> 0x7fb9c017aa00 -- Strict RTP learning after remote address set to: 192.168.21.82:16734
> Locally RTP bridged 'SIP/1341-000001cd' and 'SIP/T6-000001ce' in stack
> 0x7fb9c017aa00 -- Strict RTP switching to RTP target address 192.168.21.82:16734 as source
> Locally RTP bridged 'SIP/1341-000001cd' and 'SIP/T6-000001ce' in stack
-- Channel SIP/T6-000001ce left 'native_rtp' basic-bridge <07b9ccbf-138d-423b-87cf-ad6c41336591>
> Bridge 07b9ccbf-138d-423b-87cf-ad6c41336591: switching from native_rtp technology to simple_bridge
-- Channel SIP/1341-000001cd left 'simple_bridge' basic-bridge <07b9ccbf-138d-423b-87cf-ad6c41336591>
-- Executing [V1003B0G65609848L0#default:1] NoOp("SIP/1341-000001cd", "V1003B0G65609848L0") in new stack
-- Executing [V1003B0G65609848L0#default:2] Dial("SIP/1341-000001cd", "SIP/V1003B0G65609848L0#10.2.87.11") in new stack
== Using SIP RTP CoS mark 5
-- Called SIP/V1003B0G65609848L0#10.2.87.11
> 0x7fb9c017aa00 -- Strict RTP learning complete - Locking on source address 192.168.21.82:16734
> 0x7fba3802cb80 -- Strict RTP learning after remote address set to: 10.2.87.11:5012
-- SIP/10.2.87.11-000001cf answered SIP/1341-000001cd
-- Channel SIP/10.2.87.11-000001cf joined 'simple_bridge' basic-bridge <149e09d8-7d19-46fb-9135-43ffa33862e1>
-- Channel SIP/1341-000001cd joined 'simple_bridge' basic-bridge <149e09d8-7d19-46fb-9135-43ffa33862e1>
> Bridge 149e09d8-7d19-46fb-9135-43ffa33862e1: switching from simple_bridge technology to native_rtp
> Locally RTP bridged 'SIP/1341-000001cd' and 'SIP/10.2.87.11-000001cf' in stack
> 0x7fba3802cb80 -- Strict RTP switching to RTP target address 10.2.87.11:5012 as source
> 0x7fba3802cb80 -- Strict RTP learning complete - Locking on source address 10.2.87.11:5012
-- Channel SIP/1341-000001cd left 'native_rtp' basic-bridge <149e09d8-7d19-46fb-9135-43ffa33862e1>
-- Channel SIP/10.2.87.11-000001cf left 'native_rtp' basic-bridge <149e09d8-7d19-46fb-9135-43ffa33862e1>
== Spawn extension (default, V1003B0G65609848L0, 2) exited non-zero on 'SIP/1341-000001cd'
Not working when using a Transfer dialplan
> 0x7fb9c017aa00 -- Strict RTP learning after remote address set to: 192.168.21.82:16766
-- Executing [201*65609851#default:1] NoOp("SIP/1341-000001de", "201*65609851") in new stack
-- Executing [201*65609851#default:2] Dial("SIP/1341-000001de", "SIP/T6/201*65609851") in new stack
== Using SIP RTP CoS mark 5
-- Called SIP/T6/201*65609851
> 0x7fba4001ebf0 -- Strict RTP learning after remote address set to: 10.2.87.1:8766
-- SIP/T6-000001df answered SIP/1341-000001de
-- Channel SIP/T6-000001df joined 'simple_bridge' basic-bridge <9b4ac0b8-3bcf-4ef3-862a-46b36a7cddab>
-- Channel SIP/1341-000001de joined 'simple_bridge' basic-bridge <9b4ac0b8-3bcf-4ef3-862a-46b36a7cddab>
> Bridge 9b4ac0b8-3bcf-4ef3-862a-46b36a7cddab: switching from simple_bridge technology to native_rtp
> Locally RTP bridged 'SIP/1341-000001de' and 'SIP/T6-000001df' in stack
> 0x7fb9c017aa00 -- Strict RTP learning after remote address set to: 192.168.21.82:16766
> Locally RTP bridged 'SIP/1341-000001de' and 'SIP/T6-000001df' in stack
> 0x7fb9c017aa00 -- Strict RTP switching to RTP target address 192.168.21.82:16766 as source
> Locally RTP bridged 'SIP/1341-000001de' and 'SIP/T6-000001df' in stack
-- Channel SIP/T6-000001df left 'native_rtp' basic-bridge <9b4ac0b8-3bcf-4ef3-862a-46b36a7cddab>
> Bridge 9b4ac0b8-3bcf-4ef3-862a-46b36a7cddab: switching from native_rtp technology to simple_bridge
-- Channel SIP/1341-000001de left 'simple_bridge' basic-bridge <9b4ac0b8-3bcf-4ef3-862a-46b36a7cddab>
-- Executing [V1003B0G65609851L0#default:1] NoOp("SIP/1341-000001de", "V1003B0G65609851L0") in new stack
-- Executing [V1003B0G65609851L0#default:2] Transfer("SIP/1341-000001de", "SIP/V1003B0G65609851L0") in new stack
== Using SIP RTP CoS mark 5
> 0x7fb9c0174940 -- Strict RTP learning after remote address set to: 192.168.21.82:16770
-- Executing [V1003B0G65609851L0#default:1] NoOp("SIP/1341-000001e0", "V1003B0G65609851L0") in new stack
-- Executing [V1003B0G65609851L0#default:2] Transfer("SIP/1341-000001e0", "SIP/V1003B0G65609851L0") in new stack
-- Auto fallthrough, channel 'SIP/1341-000001e0' status is 'UNKNOWN'
== Using SIP RTP CoS mark 5
> 0x7fb9c0174940 -- Strict RTP learning after remote address set to: 192.168.21.82:16770
-- Executing [V1003B0G65609851L0#default:1] NoOp("SIP/1341-000001e1", "V1003B0G65609851L0") in new stack
-- Executing [V1003B0G65609851L0#default:2] Transfer("SIP/1341-000001e1", "SIP/V1003B0G65609851L0") in new stack
-- Auto fallthrough, channel 'SIP/1341-000001e1' status is 'UNKNOWN'
== Using SIP RTP CoS mark 5
> 0x7fb9c0174940 -- Strict RTP learning after remote address set to: 192.168.21.82:16770
-- Executing [V1003B0G65609851L0#default:1] NoOp("SIP/1341-000001e2", "V1003B0G65609851L0") in new stack
-- Executing [V1003B0G65609851L0#default:2] Transfer("SIP/1341-000001e2", "SIP/V1003B0G65609851L0") in new stack
-- Auto fallthrough, channel 'SIP/1341-000001e2' status is 'UNKNOWN'
> 0x7fb9c0174940 -- Strict RTP learning after remote address set to: 192.168.21.82:16770
-- Auto fallthrough, channel 'SIP/1341-000001de' status is 'ANSWER'
In short I need the last example to dynamically send to the domain in the refer message.
Thank you for you help
I am not sure if this is correct but I got this to work by creating users for all the devices I needed to communicate to and adjusting my extensions.conf
exten => _VX.,n,Dial(SIP/${EXTEN}#${SIPDOMAIN})
fullname = 10.2.87.10
secret =
hasvoicemail = no
host = 10.2.87.10
userqphone = yes
qualify = no
hassip = yes
hasiax = no
callwaiting = yes
context = default
when I restart Asterisk and connect to the Asterisk console with a
asterisk -rv
Asterisk is spitting thousands of
WARNING[4695]: chan_dahdi.c:12320 do_monitor: Read failed with -1: Invalid argument
after some minutes of this crazy spitting of messages it quits with a
*CLI>
Disconnected from Asterisk server
Asterisk cleanly ending (0).
Executing last minute cleanups
a dmesg shows:
[ 3561.591539] asterisk[4695]: segfault at b3150fec ip b73a4b8d sp b3150ff0 error 6 in libc-2.19.so[b7334000+1a8000]
I have no idea how to deal with this and find no similar error anywhere.
I am using a Digium TDM410P telephony card with 2 FXO and two FXS interfaces.
Dahdi linux driver < 2.10.0.1 is incompatible with linux kernel 3.16+
See complete problem description and fix in Asterisk Jira:
https://issues.asterisk.org/jira/browse/DAHLIN-340
I am trying to make a outgoing from an asterisk pbx using .call file but every time .call file is moved in outgoing folder my cli shows
[Jun 16 15:38:12] NOTICE[30435]: pbx_spool.c:372 attempt_thread: Call failed to go through, reason (1) Hangup
[Jun 16 15:38:12] NOTICE[30435]: pbx_spool.c:375 attempt_thread: Queued call to DAHDI/g0/09716927126 expired without completion after 0 attempts
-- Span 1: Channel 0/1 got hangup request, cause 16
-- Hungup 'DAHDI/i1/09711590094-103a'
[Jun 16 15:38:17] NOTICE[30434]: pbx_spool.c:372 attempt_thread: Call failed to go through, reason (1) Hangup
[Jun 16 15:38:17] NOTICE[30434]: pbx_spool.c:375 attempt_thread: Queued call to DAHDI/g0/09711590094 expired without completion after 0 attempts
-- Attempting call on DAHDI/g0/09711590094 for 4759509#outgoing1:1 (Retry 1)
-- Attempting call on DAHDI/g0/09716927126 for 4759509#outgoing1:1 (Retry 1)
-- Requested transfer capability: 0x00 - SPEECH
-- Requested transfer capability: 0x00 - SPEECH
-- Span 1: Channel 0/2 got hangup request, cause 31
-- Hungup 'DAHDI/i1/09716927126-103d'
my .call file
Channel: DAHDI/g0/09711590094
MaxRetries: 1
RetryTime: 600
WaitTime: 30
Context: outgoing1
Extension: 10
Priority: 1
The call could not be connected.Anybody knows what would be the possible reason for that?
Thanks in advance
This error mean you can't call as requested via dahdi/g0
Very likly you have configure correctly your dahdi card.
Asterisk 1.4.21.2 under uClinux on an ATCOM IP01. (EDIT: as an aside, I don't think it's possible to upgrade Asterisk to a newer version thatn 1.4 on uClinux, but if anyone knows a way, I'd be interested to know. But I don't think the issue is version-specific.)
The featuremap in features.conf is as follows, but pressing keys during a call has no effect.
[featuremap]
blindxfer => *# ; Blind transfer (default is #)
disconnect => ***0 ; Disconnect (default is *)
;automon => *1 ; One Touch Record a.k.a. Touch Monitor
atxfer => *0 ; Attended transfer
;parkcall => #72 ; Park call (one step parking)
The CLI shows that the configured featuremap has taken effect:
IP0x*CLI> feature show channels
No feature channels in use
IP0x*CLI> feature show
Builtin Feature Default Current
--------------- ------- -------
Pickup *8 *8
Blind Transfer # *#
Attended Transfer *0
One Touch Monitor
Disconnect Call * ***0
Park Call
Dynamic Feature Default Current
--------------- ------- -------
(none)
Call parking
------------
Parking extension : 700
Parking context : parkedcalls
Parked call extensions: 701-750
Various different phones in use (Grandstream BT-200, Panasonic KX-TGP500, X-Lite 4), but always same problem. All phones configured to use rfc2833, which is Asterisk's default DTMF mode; also tried explicitly setting dtmfmode=rfc2833 in sip.conf.
No keys pressed during a call ever get any response from Asterisk. The * and # keys are always recognized by Asterisk when not in a call (in the dialplan, or during voicemail).
If DTMF logging is turned on using full => verbose,debug,dtmf or full => verbose,error,warning,dtmf, no DTMF entries appear in the log despite hitting numerous keys during a call.
What could the problem be?
EDIT: additional info now follows, showing the Dial command used in the dialplan.
EDIT: I've found the issue still occurs without using that ael macro, simply by having exten=261,1,Dial(SIP/261) in extensions.conf. So I've removed the ael from the question to declutter it.
I've now tried adding canreinvite = no and relaxdtmf=yes in sip.conf, but the issue remains.
I've also now found that DTMF logging does happen during a call on a ZAP channel (as opposed to the SIP channels I tried before). But the DTMF still doesn't trigger the features. Example DTMF log follows.
[May 22 08:25:46] DTMF[474]: channel.c:2191 __ast_read: DTMF begin '*' received on SIP/251-01354004
[May 22 08:25:46] DTMF[474]: channel.c:2201 __ast_read: DTMF begin passthrough '*' on SIP/251-01354004
[May 22 08:25:46] DTMF[474]: channel.c:2116 __ast_read: DTMF end '*' received on SIP/251-01354004, duration 180 ms
[May 22 08:25:46] DTMF[474]: channel.c:2163 __ast_read: DTMF end accepted with begin '*' on SIP/251-01354004
[May 22 08:25:46] DTMF[474]: channel.c:2179 __ast_read: DTMF end passthrough '*' on SIP/251-01354004
[May 22 08:25:46] DTMF[474]: channel.c:2191 __ast_read: DTMF begin '*' received on SIP/251-01354004
[May 22 08:25:46] DTMF[474]: channel.c:2201 __ast_read: DTMF begin passthrough '*' on SIP/251-01354004
[May 22 08:25:46] DTMF[474]: channel.c:2116 __ast_read: DTMF end '*' received on SIP/251-01354004, duration 160 ms
[May 22 08:25:46] DTMF[474]: channel.c:2163 __ast_read: DTMF end accepted with begin '*' on SIP/251-01354004
[May 22 08:25:46] DTMF[474]: channel.c:2179 __ast_read: DTMF end passthrough '*' on SIP/251-01354004
[May 22 08:25:46] DTMF[474]: channel.c:2191 __ast_read: DTMF begin '*' received on SIP/251-01354004
[May 22 08:25:46] DTMF[474]: channel.c:2201 __ast_read: DTMF begin passthrough '*' on SIP/251-01354004
[May 22 08:25:47] DTMF[474]: channel.c:2116 __ast_read: DTMF end '*' received on SIP/251-01354004, duration 140 ms
[May 22 08:25:47] DTMF[474]: channel.c:2163 __ast_read: DTMF end accepted with begin '*' on SIP/251-01354004
[May 22 08:25:47] DTMF[474]: channel.c:2179 __ast_read: DTMF end passthrough '*' on SIP/251-01354004
[May 22 08:25:47] DTMF[474]: channel.c:2191 __ast_read: DTMF begin '0' received on SIP/251-01354004
[May 22 08:25:47] DTMF[474]: channel.c:2201 __ast_read: DTMF begin passthrough '0' on SIP/251-01354004
[May 22 08:25:47] DTMF[474]: channel.c:2116 __ast_read: DTMF end '0' received on SIP/251-01354004, duration 280 ms
[May 22 08:25:47] DTMF[474]: channel.c:2163 __ast_read: DTMF end accepted with begin '0' on SIP/251-01354004
[May 22 08:25:47] DTMF[474]: channel.c:2179 __ast_read: DTMF end passthrough '0' on SIP/251-01354004
IP0x*CLI>
Finally cracked this.
It's true that setting canreinvite=no does prevent the SIP phones from negotiating a direct connection between themselves after Asterisk's initially established the call, so keeps Asterisk in the media path (and thus aware of any DTMF they send).
But even so, for Asterisk to actually respond to the DTMF and invoke the configured transfer features, you must explicitly enable transfers, on a per-call basis, by passing the T and/or t options as Dial command parameters.
Newer versions of features.conf draw attention to this:
;atxfer => *2 ; Attended transfer -- Make sure to set the T and/or t option in the Dial() or Queue() app call!
So the fix was, I had to change my AEL code to add the T and/or t parameters wherever the code uses the Dial command.
The only remaining puzzle I was then left with was how to abort an attended transfer; for example if there was no reply, making it tedious to wait for the timeout, or the transfer had started to go to voicemail, potentially making it desirable to return to the other party instead. By experimentation, I eventually found that the feature for using a keypress to disconnect a call also works to abort a transfer:
;disconnect => *0 ; Disconnect (default is *)
Newer versions of features.conf contain an expanded comment, though not one related to transfers:
;disconnect => *0 ; Disconnect (default is *) -- Make sure to set the H and/or h option in the Dial() or Queue() app call!
What I discovered is that even without passing the H and/or h parameters to the Dial command, the disconnect feature can be used to abort an attended transfer. And there's no conflict between this and passing the H and/or h options to the Dial command: if you want to do this and use the feature for any kind of disconnect, it remains effective for aborting transfers without disconnecting the whole call (although using something other than the default of * may then become necessary, since any sequences starting * will now instead cut off the call!).
The Dial command in my AEL code for outgoing calls on Zap/1 is now:
Dial(Zap/1/${number},,T);
And all transfer functionality is now working fine.
I am Novice in asterisk I installed Asterisk but now when I calling with telephony call cannot
come into asterisk &
I config ed Outgoing call bat call cannot out asterisk when I write(asterisk -vvvvvr)
& I calling with outdoor display for me
-- Executing [09396464991#DLPN_Main:1] Macro("SIP/6001-00000000", "trunkdial -failover-0.3,DAHDI/g2/09396464991,DAHDI/g1/09396464991,trunk_1,trunk_1") in newstack
-- Executing [s#macro-trunkdial-failover-0.3:1] GotoIf("SIP/6001-00000000","0?1-fmsetcid,1") in new stack
-- Executing [s#macro-trunkdial-failover-0.3:2] GotoIf("SIP/6001-00000000","0?1-setgbobname,1") in new stack
-- Executing [s#macro-trunkdial-failover-0.3:3] Set("SIP/6001-00000000", "CALLERID(num)=6001") in new stack
-- Executing [s#macro-trunkdial-failover-0.3:4] Set("SIP/6001-00000000", "CALLERID(all)=") in new stack
-- Executing [s#macro-trunkdial-failover-0.3:5] GotoIf("SIP/6001-00000000","0?1-dial,1") in new stack
-- Executing [s#macro-trunkdial-failover-0.3:6] Set("SIP/6001-00000000", "CALLERID(all)=") in new stack
-- Executing [s#macro-trunkdial-failover-0.3:7] Set("SIP/6001-00000000", "CALLERID(all)=") in new stack
-- Executing [s#macro-trunkdial-failover-0.3:8] Goto("SIP/6001-00000000", "1-dial,1") in new stack
-- Goto (macro-trunkdial-failover-0.3,1-dial,1)
-- Executing [1-dial#macro-trunkdial-failover-0.3:1] Dial("SIP/6001-00000000:", "DAHDI/g2/09396464991") in new stack
[Mar 10 13:40:04] **WARNING[2106]: channel.c:5627 ast_request: No channel type registered for 'DAHDI'**
[Mar 10 13:40:04] WARNING[2106]: app_dial.c:2274 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 66 - Channel not implemented)== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1-dial#macro-trunkdial-failover-0.3:2] GotoIf("SIP/6001-00000000", "20 > 0?1-CHANUNAVAIL,1:1-out,1") in new stack
-- Goto (macro-trunkdial-failover-0.3,1-CHANUNAVAIL,1)
-- Executing [1-CHANUNAVAIL#macro-trunkdial-failover-0.3:1] Dial("SIP/6001-00000000", "DAHDI/g1/09396464991") in new stack [Mar 10 13:40:04] WARNING[2106]: channel.c:5627 ast_request: No channel type registered for 'DAHDI'
**[Mar 10 13:40:04] WARNING[2106]: app_dial.c:2274 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 66 - Channel not implemented)== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1-CHANUNAVAIL#macro-trunkdial-failover-0.3:2] Hangup("SIP/6001-00000000", "") in new stack**== Spawn extension (macro-trunkdial-failover-0.3, 1-CHANUNAVAIL, 2) exited non-zero on 'SIP/6001-00000000' in macro 'trunkdial-failover-0.3'== Spawn extension (DLPN_Main, 09396464991, 1) exited non-zero on 'SIP/6001-00
1) First check your dahdi config is present and it is ok. Use following to check it
dahdi_cfg -vvvv
2) check that your asterisk have pri/dahdi support.