[asterisk-users] DTMF issues in 1.4.19 with missing digits
Hello, all! Trying to figure out an issue with DTMF recognition with 1.4.19. This is somewhat similar to the issue described here: http://bugs.digium.com/view.php?id=11740, but it might be a different issue altogether. I have 1.4.19 running with TE212P on a US PRI. I'm sending digits 82322. Sometimes the digits are making it all in the asterisk, and sometimes some are missing. In the case when the digits are all caught, my DTMF log enteries are something like this: snip [May 2 14:48:56] DTMF[28649]: channel.c:2092 __ast_read: DTMF end '8' received on Zap/1-1, duration 0 ms [May 2 14:48:56] DTMF[28649]: channel.c:2144 __ast_read: DTMF end accepted without begin '8' on Zap/1-1 [May 2 14:48:56] DTMF[28649]: channel.c:2155 __ast_read: DTMF end passthrough '8' on Zap/1-1 [May 2 14:48:57] DTMF[28649]: channel.c:2092 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms [May 2 14:48:57] DTMF[28649]: channel.c:2144 __ast_read: DTMF end accepted without begin '2' on Zap/1-1 [May 2 14:48:57] DTMF[28649]: channel.c:2155 __ast_read: DTMF end passthrough '2' on Zap/1-1 [May 2 14:48:57] DTMF[28649]: channel.c:2092 __ast_read: DTMF end '3' received on Zap/1-1, duration 0 ms [May 2 14:48:57] DTMF[28649]: channel.c:2144 __ast_read: DTMF end accepted without begin '3' on Zap/1-1 [May 2 14:48:57] DTMF[28649]: channel.c:2155 __ast_read: DTMF end passthrough '3' on Zap/1-1 [May 2 14:48:58] DTMF[28649]: channel.c:2092 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms [May 2 14:48:58] DTMF[28649]: channel.c:2144 __ast_read: DTMF end accepted without begin '2' on Zap/1-1 [May 2 14:48:58] DTMF[28649]: channel.c:2155 __ast_read: DTMF end passthrough '2' on Zap/1-1 [May 2 14:48:58] DTMF[28649]: channel.c:2092 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms [May 2 14:48:58] DTMF[28649]: channel.c:2144 __ast_read: DTMF end accepted without begin '2' on Zap/1-1 [May 2 14:48:58] DTMF[28649]: channel.c:2155 __ast_read: DTMF end passthrough '2' on Zap/1-1 [May 2 14:48:59] DTMF[28649]: channel.c:2092 __ast_read: DTMF end '9' received on Zap/1-1, duration 0 ms [May 2 14:48:59] DTMF[28649]: channel.c:2144 __ast_read: DTMF end accepted without begin '9' on Zap/1-1 [May 2 14:48:59] DTMF[28649]: channel.c:2155 __ast_read: DTMF end passthrough '9' on Zap/1-1 [May 2 14:49:00] DTMF[28649]: channel.c:2092 __ast_read: DTMF end '9' received on Zap/1-1, duration 0 ms [May 2 14:49:00] DTMF[28649]: channel.c:2144 __ast_read: DTMF end accepted without begin '9' on Zap/1-1 [May 2 14:49:00] DTMF[28649]: channel.c:2155 __ast_read: DTMF end passthrough '9' on Zap/1-1 [May 2 14:49:00] DTMF[28649]: channel.c:2092 __ast_read: DTMF end '9' received on Zap/1-1, duration 0 ms [May 2 14:49:00] DTMF[28649]: channel.c:2144 __ast_read: DTMF end accepted without begin '9' on Zap/1-1 [May 2 14:49:00] DTMF[28649]: channel.c:2155 __ast_read: DTMF end passthrough '9' on Zap/1-1 [May 2 14:49:01] DTMF[28649]: channel.c:2092 __ast_read: DTMF end '9' received on Zap/1-1, duration 0 ms [May 2 14:49:01] DTMF[28649]: channel.c:2144 __ast_read: DTMF end accepted without begin '9' on Zap/1-1 [May 2 14:49:01] DTMF[28649]: channel.c:2155 __ast_read: DTMF end passthrough '9' on Zap/1-1 /snip In the case when digits are not fully recognized (one is missing), I get this: snip [May 2 14:36:16] DTMF[28461]: channel.c:2092 __ast_read: DTMF end '8' received on Zap/1-1, duration 0 ms [May 2 14:36:16] DTMF[28461]: channel.c:2128 __ast_read: DTMF begin emulation of '8' with duration 100 queued on Zap/1-1 [May 2 14:36:16] DTMF[28461]: channel.c:2092 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms [May 2 14:36:16] DTMF[28461]: channel.c:2098 __ast_read: DTMF end '2' put into dtmf queue on Zap/1-1 [May 2 14:36:16] DTMF[28461]: channel.c:2237 __ast_read: DTMF end emulation of '8' queued on Zap/1-1 [May 2 14:36:16] DTMF[28461]: channel.c:1961 __ast_read: DTMF begin emulation of '2' with duration 100 queued on Zap/1-1 [May 2 14:36:16] DTMF[28461]: channel.c:2092 __ast_read: DTMF end '3' received on Zap/1-1, duration 0 ms [May 2 14:36:16] DTMF[28461]: channel.c:2144 __ast_read: DTMF end accepted without begin '3' on Zap/1-1 [May 2 14:36:16] DTMF[28461]: channel.c:2155 __ast_read: DTMF end passthrough '3' on Zap/1-1 [May 2 14:36:17] DTMF[28461]: channel.c:2237 __ast_read: DTMF end emulation of '2' queued on Zap/1-1 [May 2 14:36:17] DTMF[28461]: channel.c:2092 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms [May 2 14:36:17] DTMF[28461]: channel.c:2144 __ast_read: DTMF end accepted without begin '2' on Zap/1-1 [May 2 14:36:17] DTMF[28461]: channel.c:2155 __ast_read: DTMF end passthrough '2' on Zap/1-1 [May 2 14:36:17] DTMF[28461]: channel.c:2092 __ast_read: DTMF end '9' received on Zap/1-1, duration 0 ms [May 2 14:36:17] DTMF[28461]: channel.c:2144 __ast_read: DTMF end accepted without begin '9' on Zap/1-1
[asterisk-users] cdr_pgsql and spool file
Hello, all! According to http://bugs.digium.com/view.php?id=4909, spool functionality was implemented in cdr_pgsql driver to be connection failure-resilient back in '05. This patch seems to have been merged in 1.2 branch, but in my 1.4.19 vanilla source, the code is absent from cdr_pgsql.c. Did this patch not get accepted into 1.4 tree or did it just get omitted? Does anyone know the reasoning for that? I think this is an excellent patch, and I'd love to see it in the 1.4 source tree. If it needs to be ported to the latest version, I'd love to help out if I can, otherwise, I'd like to put this on the wish list for intergrating. Regards, Mark. ___ -- 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] Busy (congestion) signal and cell phones
Hello, all! I've noticed a peculiar situation and I am hoping someone can shed some light on it for me. We have an Asterisk (1.4.18 ) box talking to the world via Zaptel on a PRI from a telco (USA). I have an extension that returns busy signal (fast-busy or regular busy) (using US tones). When I call from a landline or from another PBX, I get a busy signal, just like I expect. But when I call from a cell phone, the cell phone terminates the call as soon as connection is established. I've tested several cell phone models from different providers in the US. Same thing happens with calls coming from Gizmo. I manually changed the tones I send back (with Playtones) to mimic Austrian busy tone (picked the first one in the list from indications.conf) . Now, from the cell phone and Gizmo alike, I get busy tones. So, my questions is: why do cell phones and Gizmo both detect busy tones and terminate the call? Is that a standard behavior? Why don't landlines do that? Thank you in advance. Regards, Mark G. ___ -- 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] Busy (congestion) signal and cell phones
I'm in the US, so I was originally using the US tones. Looks like I'm getting a disconnect with both CONGESTION and BUSY. In fact, I wasn't actually using Congestion() and Busy(), I just did Playtones() for both of those. There is no reason to send PRI messages to cell phones, is there? The way I understand, they do frequency interpretation on the incoming tones, just like analog lines do voltage variations. So, to test that, I Playtones()'ed (Pardon my DialPlan-ish dialect) Austrian busy tones--and the cell phone actually played tones back to me. So, to me that means that cell phones look for frequency sequences that they recognize. Now, here's an interesting observation. If I take an analog phone and take it off hook and then call that number from a cell phone, I do hear a busy tone. Is that because analog equipment doesn't generate the exact tone sequence due to analog limitations? This is in addition to my original question. Regards, Mark. What country are you in?? Yes, it is common for cell phones to disconnect the call if they receive CONGESTION, but not BUSY. Horwich IT Services (Godwin Stewart) wrote: It *is* standard procedure for a cellphone to terminate a call immediately it discovers that the called number is busy. It will then, optionally, initiate its auto-redial function etc. -- Consulting for Asterisk, Polycom, Sangoma, Digium, Cisco, LAN, WAN, QoS, T-1, PRI, Frame Relay, Linux, and network design. Based near Birmingham, AL. Now accepting clients worldwide. ___ -- 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
