DTMF nightmare ..... :)

Ok Just before telling about the server migration that I have completed this week there was another interesting thing happen to me and one of my colleague in sydney office as he got a problem with DTMF recognition on one of his IVR system.

we have asterisk based VPBX systems for our business customers so the problem was with one of these VPBX (virtual PBX)

concept of VPBX is very simple as you familiar with Virtual machines Virtual OSs and etc ...

Idea is to share one asterisk server instance among different people with different contexts.

It's really easily to visualize asterisk as the core is designed and more flexible to have visualization.

Ok that's enough about virtualizations .. bla bla bla......... :)

The incident was, that my friend was stuck in a place were he allowed people who dialed in to VPBX main IVR were able to dial the internal extension from the IVR, problem was that when he was tested from SIP - to SIP everything worked fine as it is, But he got the problem when he got incoming calls from the PSTN (more likely a SIP gateway)

he had a WaitExten after a Background(announcement) to allow people to key in internal extension (4 digit). But the problem was that after first DTMF received no other sequential DTMF tones were recognized by asterisk.

By the time, I was readying to migrate one of our server which we have hosted voicemail/ teleconferencing services to upgrade the server OS to lenny. It was a etch box , But now it is not :)

While I was preparing for this my buddy came and told about the problem he was having.
So I was also tested But couldn't figure out WTF :) is wrong with asterisk.

As he told he has tried all available dtmf methods which supported by asterisk as inband,rfc2833,info,auto

But non of these made no change to the problem.

Ok I also looked at the problem here'n there for the first two days as I had other things in my mind about the server migration.

On third day I decided to dive in to the deep of this DTMF hazel. It's becoming a nightmare for both of us since we couldn't rectify the issue.

Ok before going in to dive I'll explain what each dtmf method and how the things works in asterisk world :)

DTMF stands for Dual Tone Multi Frequency. Its kind a way how we send digits while we are in a telephone call.

In analog world we most of the time use `inband` that means without any special encoding DTMF tones were send as normal audio tones within a audio call.

with SIP we use RTP for media transmissions so for codecs like g711u/a which are loose-less , means that compression/decompression has almost zero effect on original data we can use inband as tones were not get destroyed by codec.

But codecs like g729a/b has to use different technique like rfc2833 or sip info in order to transmit DTMF reliably. Now lets see what the hell is this rfc28833 is all about.

rfc2833 is an out of band technique used to send DMTF tones by encoding them into special information. SIP INFO is also an outband technique where DMTF tones are transmitted via SIP INFO packets.



Ok Now lets get down to how we figure out this DTMF problem that we encountered with asterisk server.

Ok as the first thing I looked at sip.conf and found that there were multiple `peer` entries to the same ip which was our sip server ip address.

asterisk used `peer` or `friend` entities in SIP to authenticate sip calls. If you have a `peer` asterisk will try to match against the ip address of the incoming call from that `peer`. If you have a `friend` entity asterisk will authenticate against digest credentials (username/password)


Ok the problem was here that since there were multiple `peer` entries to the same ip so asterisk used the first in the list to match. Therefore changing other `peers` attributes like `dtmfmode` has no effect.

So I figured this out by doing a sip debug peer ip_address and observer asterisk CLI when an incoming call hits the dialplan.
Here we go asterisk pops out and saying that it found peer entry for ip with bla bla bla and match against the first peer entry in its list.

It's like follow,

[peer1]
ip=x.x.x.x

[peer2]
ip=x.x.x.x

[peer3]
ip=y.y.y.y


If you check both peer1 and peer2 has same ip address and when you do a sip show peers you'll most probably see peer2 as the first sip peer with ip x.x.x.x
So changes made to peer1 has no effect.

This was the problem. I changed the dtmf mode to rfc2833 in the peer that asterisk matches for an incoming call and it solved the problem. it is always better to used an outband technique to transmit DTMF tones as inband is very unreliable even though we use g711u/a.


So thats about the DTMF nightmare me and my partner faced lol :D :D


I have spend two more days on server migration work as the old server config was puzzled up by the previous guy who worked on it.

I had to spend many hours to figure out which are linked where with that server before doing the migration. Any how it was completed by Friday and old server was upgraded to lenny by sysadmins.

Hmmmmmm... too much for today so I'm gonna stop for now.

catch ya soooooooooooooooooooooooon...................

Sick of Sniffing.......

Well Its been about more than week since my last post , and haven't get a time last weekend to write down something in here.

Last week I had an interesting Idea on implementing a tool for our support engineers for them to troubleshoot voip related stuff.

The Idea was to provide what will happen to a SIP call which will originate / terminate from or to our network.

Before, they tend to come to me and hazzel and saying there's something wrong with this and that service, and All I do to figure out any call routing issue is to do a ngrep at the sip server and see WTF is going on :)

Being after sometime, I thought shouldn't I allow my colleges to see for them selves whats actually happening at our voip network for a call. :D

So I wrote a simple perl/cgi script which ngrep the interface for about 1 minute and showing the call trace in a higher level interface.

ngrep -pqrtW byline string_for_search

I had following challenges when I was working on this.

Problem
1.) There's no option to us to run ngrep for a specified time.

Solution
I used the timeout utility in linux to timeout the ngrep command after running it for about 1 minute.


Problem
2.) ngrep can only be run by root , but the script that I wrote is executed by apache means www-data in debian. So www-data can't open network interface card in promiscuous mode means can't execute ngrep.

Solution
I used `sudo` and allow www-data execute ngrep with root privilege.

"/etc/sudoers"

www-data ALL = NOPASSWD:/usr/bin/ngrep,/usr/bin/timeout

This allowed Apache to execute the commands that i used in my cgi script.


It was quite interesting and support guys get start use the tool before they come to me :)


I got some more stuff to share But feels sleepy now So I'll stop for the moment, I'll have my next post about a server migration that I did this week.. sigh.......................