[asterisk-users] DTMF is not working occasionally over IAX Trunk

[Rajkumar S]

Hi all,

Did some more digging in. I changed the trunk from IAX to SIP and
still there are not much difference. So I guess it's not an IAX
problem. I have enabled DTMF logging and captured the DTMF logs for
two servers. (A: where E1 card is connected asterisk-1.4.25,
dahdi-linux-2.1.0.4) and B (v1.6.0.9) where IVR is running.

I have just pressed * 3 3 but to my untrained eyes it seems asterisk
is seeing * * 3 3 3

logs in A:


<< [ TYPE: Control (4) SUBCLASS: Answer (4) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: DTMF Begin (12) SUBCLASS: * (42) ] [DAHDI/37-1]
>> [ TYPE: DTMF Begin (12) SUBCLASS: * (42) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: DTMF End (1) SUBCLASS: * (42) ] [DAHDI/37-1]
>> [ TYPE: DTMF End (1) SUBCLASS: * (42) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: DTMF Begin (12) SUBCLASS: 3 (51) ] [DAHDI/37-1]
>> [ TYPE: DTMF Begin (12) SUBCLASS: 3 (51) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: DTMF End (1) SUBCLASS: 3 (51) ] [DAHDI/37-1]
>> [ TYPE: DTMF End (1) SUBCLASS: 3 (51) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: DTMF Begin (12) SUBCLASS: 3 (51) ] [DAHDI/37-1]
>> [ TYPE: DTMF Begin (12) SUBCLASS: 3 (51) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: DTMF End (1) SUBCLASS: 3 (51) ] [DAHDI/37-1]
>> [ TYPE: DTMF End (1) SUBCLASS: 3 (51) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: DTMF Begin (12) SUBCLASS: 3 (51) ] [DAHDI/37-1]
>> [ TYPE: DTMF Begin (12) SUBCLASS: 3 (51) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/37-1]
<< [ TYPE: DTMF End (1) SUBCLASS: 3 (51) ] [DAHDI/37-1]
>> [ TYPE: DTMF End (1) SUBCLASS: 3 (51) ] [SIP/a16-in1-081af4c8]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-081af4c8]


logs in B:

Over the SIP channel it seems B is getting * 3 3 3

<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: DTMF End (1) SUBCLASS: * (42) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: DTMF End (1) SUBCLASS: 3 (51) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: DTMF End (1) SUBCLASS: 3 (51) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: DTMF End (1) SUBCLASS: 3 (51) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/a16-in1-09815028]

Why is that the astersik in A is seeing wrong DTMF sequences? Why
there is an apparent difference in what is seen in A and B ?

Any help to isolate this issue and resolve it would be very much appreciated.

raj

On Mon, Jul 6, 2009 at 11:14 AM, Rajkumar S<rajkumars at gmail.com> wrote:
> Hi,
>
> The servers B & C are running in a virtual machine (linux kvm) and
> uses ztdummy for timing. Server A has a digium card. I am not sure if
> this is the cause of the problems I am facing.
>
> raj
>
>
> On Fri, Jul 3, 2009 at 7:16 PM, Rajkumar S<rajkumars at gmail.com> wrote:
>> Hello,
>>
>> I have a 3 server asterisk configuration where one asterisk (say A) (v
>> 1.4.25) has a digium card connected to E1 from which calls are routed
>> to another asterisk server  (B) (1.6.0.9) over IAX trunk from which
>> calls get routed to third server (C) (1.6.0.9) again via IAX trunk.
>> SIP clients are connected to third server. A is the PSTN termination
>> server, B runs the menu and AGI and C is where SIP clients connect.
>> SIP clients can also dial outside and call goes like C -> B -> A ->
>> PSTN.
>>
>> An IVR is implemented in B. extensions.conf looks like:
>>
>> exten => s, 1, SET(MENUFLOW=s)
>> exten => s, n, Background(welcome)
>> exten => s, n, WaitExten(30)
>> exten => *, 1, Goto(menu-language,s,1)
>>
>> like this it goes couple of menus deep. A typical sequence is like * 3
>> 2. Some times Background will continue to play even when I press *. It
>> will go through. Some other times as soon as I press * 3 it will go to
>> menu option of * 3 3. ie the 3 is repeated.
>>
>> I never had this problem on A. So I can rule out the DTMF problem in
>> E1. So this has to be some thing with the way E1 is getting
>> transmitted over IAX trunk.
>>
>> My iax.conf in A is like:
>>
>> [general]
>> bindport = 4569
>> bindaddr = 0.0.0.0
>> disallow=all
>> allow=ulaw
>> allow=alaw
>> allow=gsm
>> jitterbuffer=no
>> forcejitterbuffer=no
>>
>> [ccsrv-a16-in1]
>> type=peer
>> host=192.168.79.177
>> auth=plaintext
>> secret=password
>> username=a16-in1
>> qualify=yes
>> trunk=yes
>>
>>
>> and in B
>>
>> [general]
>> bindport = 4569
>> bindaddr = 0.0.0.0
>> disallow=all
>> allow=ulaw
>> jitterbuffer=no
>> forcejitterbuffer=no
>> transfer = no
>>
>> [a16-in1]
>> type=user
>> auth=plaintext
>> secret=password
>> context=inbound-calls
>> qualify=yes
>> trunk=yes
>>
>> I have also posted another mail with calls not terminated with same
>> IAX trunk. I am not sure of they are related, but any help to resolve
>> this would be very helpful
>>
>> with regards
>>
>> raj
>>
>