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

2009-07-06 Thread 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

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

2009-07-05 Thread Rajkumar S
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 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

2009-07-03 Thread Rajkumar S
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