[WXC/VFX] Setting inband DTMF on incoming calls?

Forums › One New Zealand (including Vodafone, WxC, Farmside) › [WXC/VFX] Setting inband DTMF on incoming calls?

drain

9 posts

Wannabe Geek

#111531 6-Nov-2012 17:44

Hi.

I'm trying to set my VFX line to not detect incoming DTMF tones but give me raw audio instead. I've tried setting inband in sip.conf (Asterisk 1.6) and using the SIPdtmfMode function in the dial plan, but this only results in no DTMF at all. I guess this means that Asterisk is expecting inband but VFX is still sending rcf2833. (Note, I'm already forcing G711 codec.)

Anybody got any ideas? Perhaps my line needs to be manually forced to inband at the VFX end?

Cheers,
Adrian.

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#713136 6-Nov-2012 20:18

Why do you want to use inband DTMF?

Asterisk 1.6 is also a lame horse that deserves to be put down. There are numerous DTMF related issues with it that were never fully solved, not to mention all the other issues with it. My recommendation if you are using Asterisk is to use 1.8 unless you have a specific need for 1.4

TrendMicro

Best TrendMicro deals for antivirus and malware protection(affiliate link).

drain

9 posts

Wannabe Geek

#713326 7-Nov-2012 08:25

Basically, I want to be able to control when DTMF is detected and when it's not. I'm working on an application where incorrectly detected tones is a problem. Also, sometimes I want to record a call to wav, for diagnostic purposes, including DTMF audio.

It works great with an ATA because I can force the ATA's config to inband, but I can't see how to do that for my VFX line.

Yeah, I've been meaning to upgrade my Asterisk set-up, but haven't got around to it yet. It's a bit more effort than you might expect because I've made a couple of custom modifications, like a dial plan function to enable/disable the DSP processing for a channel (ie: turn off Asterisk's DTMF detection).

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#713361 7-Nov-2012 09:06

I still don't understand why you're wanting inband DTMF to your VoIP provider.

RFC2833 is essentially the standard for DTMF transmission in the VoIP world, and Asterisk can do inband <-> RFC2833 conversion as needed, ie to an analogue device

drain

9 posts

Wannabe Geek

#713784 7-Nov-2012 20:24

Hi sbiddle... let's just say that I'm trying to do something that's a little different, so standard rfc2833 isn't always suitable for me. For the most part it is, but there are occasions when it's not. For example, sometimes I have problems with the length of a DTMF tone being distorted, and sometimes I have problems with DTFM being incorrectly detected and interrupting the audio stream. So getting it inband gives me more control over exactly when I turn on DTMF detection and flexibility over how I do the detection.

As I say, I've been able to overcome my problems internally with careful configuration of an ATA (and some custom code), bit I'm having trouble migrating that to an external line.

Cheers,
Adrain.

ubergeeknz

3344 posts

Uber Geek

Trusted

Vocus

#713972 8-Nov-2012 09:41

I can tell you from experience you are going to run into all kinds of trouble trying to "force" anything and expect it to work reliably, unless you also own the other party equipment and have control of its configuration.

Most VoIP equipment these days will be set to only use RFC2833 DTMF because frankly, Inband DTMF is a nightmare (and more resource intensive on the receiving end).

Equipment that only supports Inband is the bane of every VoIP engineer's existence. (well, that, fax, and modems but don't get me started).

If you're trying to use a VoIP call for non voice or non standard, non IVR style DTMF data... you're probably trying to fit a round peg in a square hole. I wish you all the best, but I would also suggest that you rethink your application :)

drain

9 posts

Wannabe Geek

#714248 8-Nov-2012 16:57

Thanks for your advice ubergeeknz. You'd probably right with the whole round peg square hole thing, but I'd still like to give it a try all the same. Hey, if we don't try cool and interesting ideas, we'd never come up with anything new, right?

So, back to my original question… any idea how to set VFX to do inband DTMF?

ubergeeknz

3344 posts

Uber Geek

Trusted

Vocus

#714261 8-Nov-2012 17:15

drain: Thanks for your advice ubergeeknz. You'd probably right with the whole round peg square hole thing, but I'd still like to give it a try all the same. Hey, if we don't try cool and interesting ideas, we'd never come up with anything new, right?

So, back to my original question… any idea how to set VFX to do inband DTMF?

The best you can really do is set your end to not accept out-of-band DTMF.

What the caller's equipment does is up to that equipment.

Most VoIP carriers (pretty sure that VFX will be in the same boat) won't do any transcoding in the network, and DTMF is a function of the audio path (unless you're talking SIP INFO but I've not seen that used ever), not signalling, hence it's decided by SDP between the A and B party directly.

The negotiation is pretty much an "offer" and a "response" so you can't force another endpoint to use in-band if it doesn't allow it.

I hope that kind of explains it, and what I was getting at before. I suggest you have a look at some trace in wireshark and drill down into the SDP, and the RTP streams to learn a bit more about how RFC2833 works and is negotiated...

drain

9 posts

Wannabe Geek

#714862 9-Nov-2012 18:42

Thanks for the tips ubergeeknz... you've pointed me in the right direction, and I've discovered that VFX seems to be doing what I wanted all along! I haven't quite figured out what I'm doing differently or why it wasn't working for me before, but I'll keep looking into it. In the mean time, here's a progress report…

I used Asterisk's sip debug feature to look at the SDP simply because it was easier than installing Wireshark on the command line only VPS where my Asterisk lives. I found the offer for an incoming call is:
v=0
o=BroadWorks 15323120 1 IN IP4 58.28.20.150
s=-
c=IN IP4 58.28.20.150
t=0 0
m=audio 35636 RTP/AVP 8 0 18 100 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:100 NSE/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:100 192-193
a=fmtp:101 0-15
a=ptime:20
a=bsoft:1 image udptl t38
a=sendrecv

and with RFC2833 enabled, Asterisk's response is:
v=0
o=root 309127146 309127146 IN IP4 x.x.x.x
s=Asterisk PBX 1.6.2.6
c=IN IP4 x.x.x.x
t=0 0
m=audio 18102 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

As far as I can make out, the "telephone-event" is negotiating the RFC2833 channel. Now, when I set dtmfmode=inband in sip.conf for my VFX line peer definition, the response is:
v=0
o=root 541211575 541211575 IN IP4 x.x.x.x
s=Asterisk PBX 1.6.2.6
c=IN IP4 x.x.x.x
t=0 0
m=audio 12898 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

Note there's no "telephone-event" in this one. And when I disable Asterisk's DSP and use the "monitor" function to log the audio to file, I get the actual DTMF audio in the audio file. The waveforms look pretty clean, but under close inspection (both temporally and spectrally) it seems to be the real audio, rather than a regenerated tone.

So far so good!

mjb

996 posts

Ultimate Geek

Trusted

#714864 9-Nov-2012 18:47

drain: I used Asterisk's sip debug feature to look at the SDP simply because it was easier than installing Wireshark on the command line only VPS where my Asterisk lives.

Install tcpdump, and use:

tcpdump -w <outputfile> -i <interface> <filter>

Then copy your output file to your local machine and open with wireshark.

edit: you want to at least use the filter "not tcp port 22" !

contentsofsignaturemaysettleduringshipping

drain

9 posts

Wannabe Geek

#714874 9-Nov-2012 19:10

Thanks, that's a great tip. I didn't realise I could import the tcpdump output. I already have Wireshark on my Mac, so make's to too easy.