[asterisk-bugs] [Asterisk 0012509]: [patch] MFC/R2 support for chan_zap
noreply at bugs.digium.com
noreply at bugs.digium.com
Tue May 27 17:16:40 CDT 2008
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: 05-27-2008 17:16 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 - 05-27-08 17:16
----------------------------------------------------------------------
Thanks Moy, echo cancellation now works on inbound and outbound calls.
When I try to do something stupid, like dial my own number on the trunk, I
have a problem: the inbound channel never clears. I suspect I might get the
same problem if a legitimate call negotiation fails at the wrong time.
My MFC/R2 asterisk is acting as a media gateway for a 1.6.0 Asterisk on
the same machine. I think the 1.6 Asterisk is answering the call just as
the negotiation is failing, and chan_zap ends up answering the call after
it's already cleared. Take a look below -- I dial my own number on channel
1, the call is received on channel 21, and channel 21 never clears:
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - Attempting to make call
(ANI=42XXXXX0, DNIS=2XXXXX0, category=National Subscriber)
...
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - Sending DNIS digit 0
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - MF Tx >> 0 [ON]
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - ABCD Rx << 0x1
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - Bits changed from 0x8 to
0x0
...
chan_zap.c:1288 in zt_r2_on_call_init: New MFC/R2 call detected on chan
21.
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - Unhandled event 9
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - MF Rx << 2 [ON]
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - Getting DNIS digit 2
...
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - Requesting change to Group
II with signal 0x33
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - MF Tx >> 3 [ON]
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - MF Rx << 3 [ON]
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - MF Tx >> 0 [OFF]
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - MF Rx << 0 [OFF]
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - MF Tx >> 3 [OFF]
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - MF Rx << 1 [ON]
chan_zap.c:1314 in zt_r2_on_call_offered: MFC/R2 call offered on chan 21.
DNIS = 2XXXXX0, ANI = 4XXXXX0, Category = National Subscriber
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - MF Tx >> 1 [ON]
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - MF Rx << 3 [OFF]
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - Sending category National
Subscriber
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - MF Tx >> 1 [ON]
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - MF Rx << 1 [OFF]
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - MF Tx >> 1 [OFF]
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - MF Rx << 6 [ON]
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - MF Tx >> 1 [OFF]
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - MF Rx << 6 [OFF]
chan_zap.c:1469 in zt_r2_write_log: Chan 1 - Protocol error. Reason =
Invalid Multi Frequency Tone, R2 State = Seize ACK Received, MF state =
Category Transmitted, MF Group = Forward Group II
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - DNIS = 2599630, ANI =
42599630, Last MF Signal = 6
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - ABCD Tx >> [IDLE] 0x8
chan_zap.c:1304 in zt_r2_on_protocol_error: MFC/R2 protocol error on chan
1: Invalid Multi Frequency Tone
chan_zap.c:3704 in zt_hangup: disconnecting MFC/R2 call on chan 1
kernel: Unassigning channel 0/1!
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - ABCD Rx << 0x9
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - Bits changed from 0x0 to
0x8
chan_zap.c:1463 in zt_r2_write_log: Chan 21 - Far end disconnected.
Reason: Normal Clearing
chan_zap.c:1430 in zt_r2_on_call_disconnected: MFC/R2 call disconnected on
chan 21
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - ABCD Rx << 0x9
chan_zap.c:1475 in zt_r2_write_log: Chan 1 - Bits changed from 0xC to 0x8
chan_zap.c:1491 in zt_r2_on_line_idle: Far end unblocked on chan 1
chan_zap.c:1475 in zt_r2_write_log: Chan 21 - calling callback on chan 21
chan_zap.c:1370 in zt_r2_on_call_accepted: MFC/R2 call has been accepted
on chan 21
chan_zap.c:3950 in zt_answer: Accepting MFC/R2 call on chan 21
chan_zap.c:1466 in zt_r2_write_log: Chan 21 - Cannot answer call if the
call is not accepted first
At that point, Asterisk has channel 21 blocked, and the only way to
unblock it is "soft hangup zap/21-1".
gyeast*CLI> core show channels
Channel Location State Application(Data)
SIP/main-asterisk-00 (None) Up Bridged Call(Zap/21-1)
Zap/21-1 s at macro-callfrompstn Up
Dial(SIP/2XXXXX0 at main-asterisk
gyeast*CLI> soft hangup zap/5-1
I've also got some signalling problem between the two Asterisks that might
be making this more noticeable. My main (1.6) asterisk doesn't seem to send
BYE when a local extension hangs up on an inbound caller from the PSTN.
Normally the above call on Zap/21-1 would be disconnected because the main
Asterisk would send a proper hangup. However it should still be
disconnected I think, because the PSTN released the call on its end.
Issue History
Date Modified Username Field Change
======================================================================
05-27-08 17:16 asbestoshead Note Added: 0087397
======================================================================
More information about the asterisk-bugs
mailing list