Elastix with BT Featureline Commands

stirlingit

Joined
Nov 24, 2010
Messages
2
Likes
0
Points
0
#1
Hello,

I am moving our phone system to Elastix and have got pretty much everything hammered down apart from the ability for Elastix to send BT featureline codes. e.g. #21# to cancel call divert, etc.

Every time I use the # key it just drops to call ended.

I am using a Wildcard TDM400P with 2 FXO and 2 FXS modules and have two BT featurelines plugged into the FXOs.

Outgoing and incoming calls are all fine, just immediate call end when using the # key.

Thanks in advance.

Stu
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#2
In "General Settings" -> "dialing options" you will note that t and T intercept the line when a # is detected, the call is not terminated but dial-tone is returned so you can transfer the call, eliminAte any t's in the dialing command as appropriate.
 

stirlingit

Joined
Nov 24, 2010
Messages
2
Likes
0
Points
0
#3
Hello,

The dialing options did have "tr" in the general settings.

Have removed the "t" then the "r" still get "call ended" once I press the hash key.

Anywhere else I have to look for "t"s?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#4
you might want to try disabling

## In-Call Asterisk Blind Transfer

on the feature codes page, but that would generally indicate the old double dtmf bug, make sure you are using the right dtmfmode , G711 (dahdi trunks) can only use inband

add dtmf notices to the admin account in manager.conf:-

read = dtmf,system,call,log,verbose,command,agent,user

and tail -f /var/log/asterisk/full as you dial the code.

always restart asterisk and dahdi when doing this sort of stuff, "just in case"
 

franklin

Joined
Oct 22, 2010
Messages
254
Likes
0
Points
0
#5
Hi dicko. Having an issue with DTMF. Here is my scenario. I have three boxes. Two behind a firewall with the standard port forwards and sip_nat.conf set properly. One is in the DMZ for testing purposes only. The DMZ box will pass DTMF to a specific 877#'s IVR. The two boxes behind their individual firewalls will not. All boxes running 1.6. All with latest yum updates. All are virtually identical loads. All talk on the same SIP trunk. All use rfc2833 and from-internal in the ext. I've run tail -f /var/log/asterisk/full and when I press the digits when the call is connected there is no output on the tail, on the "good" call or the "bad."

I've tried putting rfc2388=compensate in sip_general_custom, as suggested by someone else here. I even tried it in sip_nat.conf. No luck. Any ideas?

My provider says that on the good call they are seeing an immediate connection. on the bad call there is some kind of ringback. We even tried spoofing and using the outbound CID of the good pbx on the outbound CID of the bad, and the bad was still bad, with the ringback.

Thanks very much.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#6
If you added the DTMF to the logger conf file (and restarted it)

then


tail -f /var/log/asterisk/full|grep DTMF

"should" give you something like the following:-



[2010-12-22 16:09:08] DTMF[14224] channel.c: DTMF end passthrough '7' on SIP/3457-00007a8e
[2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF begin '8' received on SIP/3457-00007a8e
[2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF begin passthrough '8' on SIP/3457-00007a8e
[2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF end '8' received on SIP/3457-00007a8e, duration 150 ms
[2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF end accepted with begin '8' on SIP/3457-00007a8e
[2010-12-22 16:09:09] DTMF[14224] channel.c: DTMF end passthrough '8' on SIP/3457-00007a8e
[2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF begin '9' received on SIP/3457-00007a8e
[2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF begin passthrough '9' on SIP/3457-00007a8e
[2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF end '9' received on SIP/3457-00007a8e, duration 140 ms
[2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF end accepted with begin '9' on SIP/3457-00007a8e
[2010-12-22 16:09:10] DTMF[14224] channel.c: DTMF end passthrough '9' on SIP/3457-00007a8e
[2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF begin '*' received on SIP/3457-00007a8e
[2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF begin passthrough '*' on SIP/3457-00007a8e
[2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF end '*' received on SIP/3457-00007a8e, duration 150 ms
[2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF end accepted with begin '*' on SIP/3457-00007a8e
[2010-12-22 16:09:12] DTMF[14224] channel.c: DTMF end passthrough '*' on SIP/3457-00007a8e
[2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF begin '0' received on SIP/3457-00007a8e
[2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF begin passthrough '0' on SIP/3457-00007a8e
[2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF end '0' received on SIP/3457-00007a8e, duration 180 ms
[2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF end accepted with begin '0' on SIP/3457-00007a8e
[2010-12-22 16:09:14] DTMF[14224] channel.c: DTMF end passthrough '0' on SIP/3457-00007a8e
[2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF begin '#' received on SIP/3457-00007a8e
[2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF begin passthrough '#' on SIP/3457-00007a8e
[2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF end '#' received on SIP/3457-00007a8e, duration 160 ms
[2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF end accepted with begin '#' on SIP/3457-00007a8e
[2010-12-22 16:09:15] DTMF[14224] channel.c: DTMF end passthrough '#' on SIP/3457-00007a8e


as you press each button (you will hear the dtmf on the far end (with usually a delay for * and # as incall signaling is processed and thus delayed.

the nature of the logged output will vary as you change between the various dtmfmode's , but there should always be a trace

diagnostically, inbound calls to your system (IVR navigation voicemail etc.) should also show the dtmf events.

Once you get the logger to behave, perhaps it will become apparent either, it's just not there, or it's being misinterpreted. The LandBased Telco's VERY rarely need any modificatioon of how DTMF works, sometimes the VSP's just need a good kick in the arse.
 

franklin

Joined
Oct 22, 2010
Messages
254
Likes
0
Points
0
#7

franklin

Joined
Oct 22, 2010
Messages
254
Likes
0
Points
0
#8
dicko, please take a look at the output of my tail. You'll notice about 13 lines down I get a pesky "begin ignored" return, and then "emulation." Is this my box telling me it got no acknowledgment from the other side? Why does it do this? My other identical 1.6 box does not get this, as evidenced by the same output labeled "begin good call." I expect to hear back from my VSP, who has a ticket open with the carrier, tomorrow. But if you could throw any of your thoughts out I would be grateful. Thanks.


Begin bad call
Dec 22 22:16:09] DTMF[31906] channel.c: DTMF begin '6' received on SIP/2001-00000292
[Dec 22 22:16:09] DTMF[31906] channel.c: DTMF begin passthrough '6' on SIP/2001-00000292
[Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end '6' received on SIP/2001-00000292, duration 250 ms
[Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end accepted with begin '6' on SIP/2001-00000292
[Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end passthrough '6' on SIP/2001-00000292
[Dec 22 22:16:09] DTMF[31906] channel.c: DTMF begin '0' received on SIP/2001-00000292
[Dec 22 22:16:09] DTMF[31906] channel.c: DTMF begin passthrough '0' on SIP/2001-00000292
[Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end '0' received on SIP/2001-00000292, duration 260 ms
[Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end accepted with begin '0' on SIP/2001-00000292
[Dec 22 22:16:09] DTMF[31906] channel.c: DTMF end passthrough '0' on SIP/2001-00000292
[Dec 22 22:16:09] DTMF[4315] channel.c: DTMF begin '0' received on SIP/2001-00000292
[Dec 22 22:16:09] DTMF[4315] channel.c: DTMF begin ignored '0' on SIP/2001-00000292
[Dec 22 22:16:10] DTMF[31906] channel.c: DTMF end '0' received on SIP/2001-00000292, duration 260 ms
[Dec 22 22:16:10] DTMF[31906] channel.c: DTMF begin emulation of '0' with duration 260 queued on SIP/2001-00000292
[Dec 22 22:16:10] DTMF[31906] channel.c: DTMF end emulation of '0' queued on SIP/2001-00000292
[Dec 22 22:16:10] DTMF[4315] channel.c: DTMF begin '5' received on SIP/2001-00000292
[Dec 22 22:16:10] DTMF[4315] channel.c: DTMF begin ignored '5' on SIP/2001-00000292
[Dec 22 22:16:10] DTMF[4315] channel.c: DTMF end '5' received on SIP/2001-00000292, duration 260 ms
[Dec 22 22:16:10] DTMF[4315] channel.c: DTMF end passthrough '5' on SIP/2001-00000292
[Dec 22 22:16:10] DTMF[31906] channel.c: DTMF end '5' received on SIP/2001-00000292, duration 260 ms
[Dec 22 22:16:10] DTMF[31906] channel.c: DTMF begin emulation of '5' with duration 260 queued on SIP/2001-00000292
[Dec 22 22:16:10] DTMF[31906] channel.c: DTMF end emulation of '5' queued on SIP/2001-00000292
[Dec 22 22:16:11] DTMF[4315] channel.c: DTMF begin '4' received on SIP/2001-00000292
[Dec 22 22:16:11] DTMF[4315] channel.c: DTMF begin ignored '4' on SIP/2001-00000292
[Dec 22 22:16:11] DTMF[31906] channel.c: DTMF end '4' received on SIP/2001-00000292, duration 300 ms
[Dec 22 22:16:11] DTMF[31906] channel.c: DTMF begin emulation of '4' with duration 300 queued on SIP/2001-00000292
[Dec 22 22:16:11] DTMF[31906] channel.c: DTMF end emulation of '4' queued on SIP/2001-00000292
[Dec 22 22:16:11] DTMF[4315] channel.c: DTMF begin '5' received on SIP/2001-00000292
[Dec 22 22:16:11] DTMF[4315] channel.c: DTMF begin ignored '5' on SIP/2001-00000292
[Dec 22 22:16:11] DTMF[31906] channel.c: DTMF end '5' received on SIP/2001-00000292, duration 310 ms
[Dec 22 22:16:11] DTMF[31906] channel.c: DTMF begin emulation of '5' with duration 310 queued on SIP/2001-00000292
[Dec 22 22:16:12] DTMF[31906] channel.c: DTMF end emulation of '5' queued on SIP/2001-00000292
[Dec 22 22:16:12] DTMF[4315] channel.c: DTMF begin '#' received on SIP/2001-00000292
[Dec 22 22:16:12] DTMF[4315] channel.c: DTMF begin ignored '#' on SIP/2001-00000292
[Dec 22 22:16:12] DTMF[31906] channel.c: DTMF end '#' received on SIP/2001-00000292, duration 330 ms
[Dec 22 22:16:12] DTMF[31906] channel.c: DTMF begin emulation of '#' with duration 330 queued on SIP/2001-00000292
[Dec 22 22:16:13] DTMF[31906] channel.c: DTMF end emulation of '#' queued on SIP/2001-00000292

Begin good call

tail -f /var/log/asterisk/full|grep DTMF
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF begin '6' received on SIP/2003-00000063
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF begin passthrough '6' on SIP/2003-00000063
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end '6' received on SIP/2003-00000063, duration 240 ms
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end accepted with begin '6' on SIP/2003-00000063
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end passthrough '6' on SIP/2003-00000063
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF begin '0' received on SIP/2003-00000063
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF begin passthrough '0' on SIP/2003-00000063
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end '0' received on SIP/2003-00000063, duration 290 ms
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end accepted with begin '0' on SIP/2003-00000063
[Dec 22 22:14:04] DTMF[19631] channel.c: DTMF end passthrough '0' on SIP/2003-00000063
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF begin '0' received on SIP/2003-00000063
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF begin passthrough '0' on SIP/2003-00000063
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end '0' received on SIP/2003-00000063, duration 270 ms
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end accepted with begin '0' on SIP/2003-00000063
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end passthrough '0' on SIP/2003-00000063
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF begin '0' received on SIP/2003-00000063
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF begin passthrough '0' on SIP/2003-00000063
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end '0' received on SIP/2003-00000063, duration 280 ms
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end accepted with begin '0' on SIP/2003-00000063
[Dec 22 22:14:05] DTMF[19631] channel.c: DTMF end passthrough '0' on SIP/2003-00000063
[Dec 22 22:14:06] DTMF[19631] channel.c: DTMF begin '5' received on SIP/2003-00000063
[Dec 22 22:14:06] DTMF[19631] channel.c: DTMF begin passthrough '5' on SIP/2003-00000063
[Dec 22 22:14:06] DTMF[19631] channel.c: DTMF end '5' received on SIP/2003-00000063, duration 260 ms
[Dec 22 22:14:06] DTMF[19631] channel.c: DTMF end accepted with begin '5' on SIP/2003-00000063
[Dec 22 22:14:06] DTMF[19631] channel.c: DTMF end passthrough '5' on SIP/2003-00000063
[Dec 22 22:14:06] DTMF[6869] channel.c: DTMF begin '4' received on SIP/2003-00000063
[Dec 22 22:14:06] DTMF[6869] channel.c: DTMF begin ignored '4' on SIP/2003-00000063
[Dec 22 22:14:06] DTMF[19631] channel.c: DTMF end '4' received on SIP/2003-00000063, duration 250 ms
[Dec 22 22:14:06] DTMF[19631] channel.c: DTMF begin emulation of '4' with duration 250 queued on SIP/2003-00000063
[Dec 22 22:14:07] DTMF[19631] channel.c: DTMF begin '5' received on SIP/2003-00000063
[Dec 22 22:14:07] DTMF[19631] channel.c: DTMF begin ignored '5' on SIP/2003-00000063
[Dec 22 22:14:07] DTMF[19631] channel.c: DTMF end emulation of '4' queued on SIP/2003-00000063
[Dec 22 22:14:07] DTMF[19631] channel.c: DTMF end '5' received on SIP/2003-00000063, duration 320 ms
[Dec 22 22:14:07] DTMF[19631] channel.c: DTMF begin emulation of '5' with duration 320 queued on SIP/2003-00000063
[Dec 22 22:14:07] DTMF[19631] channel.c: DTMF end emulation of '5' queued on SIP/2003-00000063
[Dec 22 22:14:08] DTMF[19631] channel.c: DTMF begin '#' received on SIP/2003-00000063
[Dec 22 22:14:08] DTMF[19631] channel.c: DTMF begin passthrough '#' on SIP/2003-00000063
[Dec 22 22:14:08] DTMF[19631] channel.c: DTMF end '#' received on SIP/2003-00000063, duration 300 ms
[Dec 22 22:14:08] DTMF[19631] channel.c: DTMF end accepted with begin '#' on SIP/2003-00000063
[Dec 22 22:14:08] DTMF[19631] channel.c: DTMF end passthrough '#' on SIP/2003-00000063
 

franklin

Joined
Oct 22, 2010
Messages
254
Likes
0
Points
0
#9
found it in etc/asterisk. Please disregard. But it you have any ideas on why the ignore...?
 

franklin

Joined
Oct 22, 2010
Messages
254
Likes
0
Points
0
#10
This is solved. I started by telling my XLite to send only in-band. It worked. Then I figured that I could do the same with my Polycom phones. in the admin guide 322 you find some parameters for dtmf. One of them:
tone.dtmf.rfc2833Control 0 or 1 1 If set to 1, the phone will indicate a
preference for encoding DTMF through
RFC 2833 format in its Session
Description Protocol (SDP) offers by
showing support for the phone-event
payload type; this does not affect SDP
answers, these will always honor the
DTMF format present in the offer since
the phone has native support for RFC
2833.

I set it to 0. Long conversation with my carrier. They all have settings for DTMF. Long story short, this is the only thing that worked in my scenario with my Polycom phones.

Thanks for any help given. Merry Christmas, dicko!
 

franklin

Joined
Oct 22, 2010
Messages
254
Likes
0
Points
0
#11
dicko, I'm at a wall. When I set tone.dtmf.rfc2833Control to 0 in my Polycom sip.cfg, access to the IVR works. I have tone.dtmf.viaRtp set to 1, so I am sending the dtmf in the rtp stream.

But this disables the *1 call record toggle. It simply won't work any longer. I've tried all the dtmfmodes in my ext. Set it to auto, info, and rfc2833. Here is a log, if is comes out formatted properly:

sip.cfg= mask 0, viartp 1, rfc2833ctrl 0
866# *1 call toggle
info y n
auto n y but *1 starts a new recording every time/cannot start/stop
rfc2833 y n

sip.cfg= mask 0, viartp 0, rfc2833crtl 0
info n n
auto n n
rfc2833 n n

0 1 1
info y n
auto n y but *1 starts a new recording every time
rfc2833 n y but *1 starts a new recording every time

1 0 1
info n n
auto n n
rfc2833 n n
 

franklin

Joined
Oct 22, 2010
Messages
254
Likes
0
Points
0
#12
Dear users, If you are having trouble with dtmf issues, I believe I have earned a graduate degree in the study. Perhaps not a master's or phd, but if you read my posts you will find my trials and tribulations. In the end, it was EWT that saved me, thank you to you know who for the default direction -- RTFM. The answer came from B.1.4 GoTalk. I just kept trying shit till it worked. Still strange one 1.6 box works without this in the Trunk and the other requires it...


Setting tone.dtmf.rfc2833Control="0" certainly made the remote IVR respond. But it made my IVR on my Elastix box stop responding. I could no longer dial directly into 5000 for my conference bridge. So what I did is set my extensions to rfc2833, and included dtmfmode=inband in my SIP trunk. All works, and I am going to sleep.
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,902
Messages
130,887
Members
17,565
Latest member
omarmenichetti
Top