[asterisk-bugs] [Asterisk 0012509]: [patch] MFC/R2 support for chan_zap

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12509 
====================================================================== 
Reported By:                moy
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12509
Category:                   Channels/chan_zap/NewFeature
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 114097 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             04-24-2008 01:31 CDT
Last Modified:              06-27-2008 03:57 CDT
====================================================================== 
Summary:                    [patch] MFC/R2 support for chan_zap
Description: 
Here we go. This is my first try to give R2 support to chan_zap. I'm sure I
am missing locks and/or features here and there but I have tested it
internally with success with a considerable amount of concurrent channels
(64). That's the best I can do with the hardware I currently have (more
coming!).


====================================================================== 

---------------------------------------------------------------------- 
 asbestoshead - 06-27-08 03:57  
---------------------------------------------------------------------- 
Hi Moy, I tested your new code during an alarm -- works great.


I do have one problem both with the old code and the new. We get "MF back
cycle timed out". When this happens, openr2 puts the channel back into IDLE
(tx bits 1001), but our telco stays in 0001. Further outbound and inbound
calls on this channel are not possible.

The workaround, which I've had to do once or twice a day when enough
channels get blocked, is to stop Asterisk so the lines go into BLOCKED on
our end, and then the telco's equipment slowly puts theirs back into IDLE
over the next 30 seconds or so, one line at a time.

I checked with the telco -- apparently after a timeout their equipment
expects us to go to BLOCKED (1101) for some time (don't know yet -- a few
seconds, a minute) before going to IDLE, so it knows the channel has reset.
Otherwise the channel stays in an "isolated" state. What do you think --
does this sound like something openr2 should do? Or maybe there should be
some way to manually put a line into BLOCKED without stopping Asterisk?

Here's a snip from the logs when the timeout happens, btw:

DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - ABCD Rx << 0x1
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - Bits changed
from 0x8 to 0x0
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - ABCD Tx >>
[SEIZE_ACK] 0xC
NOTICE[5317]: chan_zap.c:1290 in zt_r2_on_call_init: New MFC/R2 call
detected on chan 11.
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - Unhandled event
9
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - MF Rx << 2
[ON]
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - Getting DNIS
digit 2
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - DNIS so far: 2,
expected length: 7
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - Requesting next
DNIS with signal 0x31.
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - MF Tx >> 1
[ON]
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - MF Rx << 2
[OFF]
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - MF Tx >> 1
[OFF]
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - calling
callback on chan 11
WARNING[5317]: chan_zap.c:1473 in zt_r2_write_log: Chan 11 - MF back cycle
timed out!
ERROR[5317]: chan_zap.c:1476 in zt_r2_write_log: Chan 11 - Protocol error.
Reason = Multi Frequency Cycle Timeout, R2 State = Seize ACK Transmitted,
MF state = DNIS Request Transmitted, MF Group = Backward Group A
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - DNIS = 2, ANI =
, Last MF Signal =  
DEBUG[5317]: chan_zap.c:1482 in zt_r2_write_log: Chan 11 - ABCD Tx >>
[IDLE] 0x8
ERROR[5317]: chan_zap.c:1308 in zt_r2_on_protocol_error: MFC/R2 protocol
error on chan 11: Multi Frequency Cycle Timeout 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-27-08 03:57  asbestoshead   Note Added: 0089344                          
======================================================================