Re: [asterisk-users] DTMF is not working occasionally over IAX Trunk
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)
Re: [asterisk-users] DTMF is not working occasionally over IAX Trunk
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 Srajkum...@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 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] DTMF is not working occasionally over IAX Trunk
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 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
