[Home]

Summary:ASTERISK-11906: [patch] MFC/R2 support for chan_zap
Reporter:Moises Silva (moy)Labels:
Date Opened:2008-04-24 01:31:29Date Closed:2009-03-16 15:39:44
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap_immediate_accept.patch
( 1) chan_zap-mfr2.patch
( 2) chan_zap-mfr2-april28.patch
( 3) libopenr2_immediate_accept.patch
( 4) libopenr2_venezuela_variant.patch
( 5) mfcr2-logs-seize_timeout.txt
( 6) signalling-digivoiceboard.txt
( 7) signalling-TE110P.txt
( 8) zapata.conf
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!).



****** STEPS TO REPRODUCE ******

This patch depends on OpenR2, the LGPL library I wrote to implement MFC/R2. Zaptel 1.4 trunk is required for the tone generation and main/dsp.c of Mark's branch http://svn.digium.com/svn/asterisk/team/markster/mfr2



****** ADDITIONAL INFORMATION ******

I was planning to put an SVN server up for the OpenR2 library but I'm lazy :-) , Mark offered me an SVN account at http://svncommunity.digium.com/, as soon as I have the account I will put the code there, in the meantime, for anyone interested , this is a link to the library: http://www.moythreads.com/libopenr2-04-24-2008.tar.gz

I will appreciate feedback.

Edit: moy has also created a branch for this work here -- http://svn.digium.com/svn/asterisk/team/moy/mfcr2
Comments:By: Moises Silva (moy) 2008-04-24 01:36:24

Ah, I forgot. The only tested R2 variant is México. I have some friends in Argentina and Brazil that will help me to give support for those 2 countries soon.

By: Moises Silva (moy) 2008-04-24 02:34:43

zapata.conf parameters:

signalling=mfcr2

; protocol variant
mfcr2_variant=mx

; get the ANI first (before DNIS)
mfcr2_get_ani_first=no

; max amount of ANI and DNIS
mfcr2_max_ani=10
mfcr2_max_dnis=4

; call category (may override using MFCR2_CATEGORY channel variable)
mfcr2_category=national_subscriber

; where to send the call debugging files if enabled
; the full directory will be /var/log/asterisk/mfcr2/<whatever>
mfcr2_logdir=span1

; OpenR2 logging level
mfcr2_logging=all

Available commands:

mfcr2 show channels (Show MFC/R2 channels details)
mfcr2 call files on|off (enable dump signaling debugging per call)
mfcr2 set debug <levels> (debugging MFC/R2 signaling)
mfcr2 set idle (reset the channel)
zap show channel <chan> (when R2 channel shows R2 data)



By: Humberto Figuera (korihor) 2008-04-24 03:14:33

Hi Moisés, great work!!!

I will help you with MFC/R2 VE (Venezuela) variant. I will do some test with one E1 this weekend.

By: viniciusfontes (viniciusfontes) 2008-04-24 07:16:26

I can help testing in Brazil. There is a board manufacturer called Digivoice that already supports MFC/R2 Mexico, Argentina and Brazil. All the drivers have their source code open, so you might want to take a look:

http://www.digivoice.com.br/suporte/files/channel/dgvchannel-0.9.9.tar.gz
http://www.digivoice.com.br/suporte/files/vlib/voicerlib-4.0.9.8.tar.gz

dgvchannel is an Asterisk channel driver that uses some functions in Voicerlib. I'm not a programmer, but I guess the MFC/R2 signalling is done in dgvchannel, while the lower-level stuff (E1, etc) is done in Voicerlib. But Voicerlib is only used for their own boards, since Digium cards use Zaptel for the lower-level stuff.

I believe this can help you a lot, since their drivers are already stable enough to use in production servers.



By: Russell Bryant (russell) 2008-04-24 08:53:33

Your library has both the GPL and LGPL in the root directory.  Can you clarify the licensing of the openr2 lib?

By: Russell Bryant (russell) 2008-04-24 10:10:35

I have verified that the library is licensed under the LGPL.  I had forgotten that when this is the case, you're supposed to include a copy of the GPL, as well.  Oops!

By: Moises Silva (moy) 2008-04-29 00:02:46

I have added a new patch that fixed a small compilation error when libss7 is present.

The svn repo for the library is at svn://libopenr2.org/openr2/trunk

Some instructions to install:

1. Get and install zaptel from the 1.4 branch. svn co http://svn.digium.com/svn/zaptel/branches/1.4

2. get the openr2 library: svn co svn://libopenr2.org/openr2/trunk openr2

3. Get spandsp, I know is GPL, but only the test case included with openr2 depends on spandsp, the library itself does not. Though Steve said to me spandsp is going LGPL soon. http://www.soft-switch.org/downloads/spandsp/spandsp-0.0.5pre1.tgz

4. Install openr2 with ./configure --prefix=/usr && make && make install

5. Get Asterisk from the MFR2 branch. svn co http://svn.digium.com/svn/asterisk/team/markster/mfr2 (this branch will soon include the R2 patch as well)

6. Download the patch from the bugtracker and patch Asterisk.

7. You cannot execute ./configure directly, you MUST first execute ./bootstrap.sh

8. Now you can ./configure --prefix=/usr && make && make install

In one of my early posts I showed the proper configuration in zapata.conf for R2 signalling. I just want to make clear that for debugging purposes, you should put in zapata.conf mfcr2_logging=all and enable all the debugging in /etc/asterisk/logger.conf

By: Moises Silva (moy) 2008-04-29 08:28:06

Ah, just checked the the spandsp license at the link I posted and guess what? is LGPL now :-)

By: Moises Silva (moy) 2008-04-29 08:45:59

it seems that spandsp package has a compilation error due to missing headers, I assume coppice will fix that soon, in the meantime this version works: http://www.soft-switch.org/downloads/spandsp/spandsp-0.0.4pre18.tgz

By: viniciusfontes (viniciusfontes) 2008-04-29 13:12:06

The BR variant works fine, there are just some minor bugs:

- In outbound calls, the most significant digit of ANI is stripped out. For example, if my CallerID is 1000, the other side receives 000.

- The call is answered immediately instead of signal RINGING. As soon as I dial, the softphone reports Connected instead of Ringing. The CLI shows the following:

[Apr 29 05:04:34]     -- Executing [01000@default:1] Dial("SIP/1000-b7a52168", "Zap/g1/1000,60") in new stack
[Apr 29 05:04:34]     -- Called g1/1000
[Apr 29 05:04:34]     -- Zap/1-1 answered SIP/1000-b7a52168


Note that there is no interval between the last two lines. There should be a line saying "Zap/1-1 is ringing" or something equivalent.

Inbound calls are working fine. Thanks for the great work Moisés!



By: Alexandre C Alencar (skarmeth) 2008-04-29 13:23:06

I am reporting sucess with OpenR2, Asterisk and Zaptel with Digium card. My setup bellow

Fedora GNU/Linux 8 64 bits
Dell Optiplex 745
Digium TE220 PCIe

Telco company Embratel

********** /etc/zaptel.conf **********

loadzone = br
defaultzone=br

span=1,1,0,cas,hdb3
cas=1-15:1101
cas=17-31:1101
dchan=16

********** /etc/asterisk/zapata.conf **********

[trunkgroups]

[channels]
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes

signalling=mfcr2
mfcr2_variant=br
mfcr2_get_ani_first=no
mfcr2_max_ani=20
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_logdir=span1
mfcr2_logging=all

context=embratel
channel => 1-15
channel => 17-31
group=0
callgroup=0
pickupgroup=0

********** /etc/asterisk/extensions.conf **********

[embratel]

exten => s,1,Answer()
exten => s,n,Playback(beep)
exten => s,n,Playback(beep)
exten => s,n,Playback(beep)
exten => s,n,Playback(beep)
exten => s,n,Playback(beep)
exten => s,n,Playback(beep)
exten => s,n,Playback(beep)
exten => s,n,Playback(beep)
exten => s,n,Hangup()

exten => _29[5-9]X,1,Answer()
exten => _29[5-9]X,2,Queue(suporte)
exten => _29[5-9]X,3,Playback(beep)
exten => _29[5-9]X,4,Hangup()

exten => _XXXXXXXX,1,Dial(Zap/g0/${EXTEN},,T)
exten => _XXXXXXXX,n,Congestion()
exten => _XXXXXXXX,n,Hangup()

exten => _0800.,1,Dial(Zap/g0/${EXTEN},,T)
exten => _0800.,n,Congestion()
exten => _0800.,n,Hangup()

exten => _85XX,1,Dial(SIP/${EXTEN},,T)
exten => _85XX,2,Congestion()
exten => _85XX,3,Hangup()

********** Asterisk Version **********
Asterisk SVN-markster-mfr2-r113008M built by skarmeth @ openr2box on a x86_64 running Linux on 2008-04-25 16:40:15 UTC

********** Zaptel Version **********

SVN-branch-1.4-r4196

********** OpenR2 Version **********

OpenR2 version: 0.1.1

If you use a RPM-based system, you can get a Spec file for OpenR2 at
http://people.debian-ce.org/skarmeth/arquivos/libopenr2.spec

By: Moises Silva (moy) 2008-04-29 15:58:04

callerid bug fixed in latest openr2 svn revision.

By: Moises Silva (moy) 2008-04-29 23:17:23

New branch created: http://svn.digium.com/svn/asterisk/team/moy/mfcr2

This will be the official branch to work in R2 support. I merged the changes from Mark's branch here for main/dsp.c and my patch for chan_zap is there too.

By: viniciusfontes (viniciusfontes) 2008-04-30 07:07:22

The option mfcr2_logging=all doesn't seem to generate logs on /var/log/asterisk/mfcr2, even when the directory exists.

Tested using the http://svn.digium.com/svn/asterisk/team/moy/mfcr2 branch.

By: viniciusfontes (viniciusfontes) 2008-04-30 08:01:55

A very common scenario is when you connect a two-span card to a PBX and a telco simultaneously, that way you can intercept both incoming and outgoing calls and change their routing, for example directing to a VoIP telco or a SIP phone.

In this case, you need to handle variable-lenght DNIS (from the PBX). In my test scenario I had two boxes: one with a TE110P card and another with a Digivoice board, both using MFC/R2.

Then I originated a call from the Digivoice board using DNIS 0215421047000 and ANI 5421047000. The call eventually went through, but only after a long time. Perhaps chan_zap ignored the end of DNIS tone?

I uploaded a dump of both signallings along with the zapata.conf file used. Both machines have their clocks synchronized to the same NTP host.



By: Moises Silva (moy) 2008-04-30 08:34:39

It seems the mfcr2_logging option is causing confusion, that is not supposed to generate logging in /var/log/asterisk/mfcr2, but just to generate normal Asterisk logging in the console or any file configured in logger.conf, call files generation in /var/log/asterisk/mfcr2/ is independent and enabled via the command line: mfcr2 call files on <channel number>, see the help in the CLI for more info.

Regarding the long time for the call to go thru, the thing is that R2 variants like México and Brazil seem to be very silly, they do not have a "End of DNIS" signal, but instead rely on the other end timing out. I just need to decrease the timeout. I will do some testing, update the SVN  repo for libopenr2 and let you know.

By: Moises Silva (moy) 2008-05-01 14:27:19

I just tested this with another provider in Mexico, Axtel. So far so good.

Vinicius also tested reducing the MF timer (currently hard coded) to fix his issue with variable length DNIS. It worked like a charm. I will make this timer configurable and update the SVN tree ASAP.

By: Moises Silva (moy) 2008-05-01 22:05:11

Fixed bug of missing "Ringing" state for the outgoing zap channel. Please update to latest revision and try again.

By: viniciusfontes (viniciusfontes) 2008-05-02 06:35:59

Tested the new revision, ringing indication works perfectly.

By: Moises Silva (moy) 2008-05-02 12:11:39

I added an option to make the MF timer configurable. All the parameters are now properly documented at configs/zapata.conf.sample, take a look there if you have any doubts.

By: Alexandre C Alencar (skarmeth) 2008-05-02 12:12:03

Fax test report

I can receive faxes send from/to faxes machines using lastest moy branch. Here is the setup:

Fax machine - ATA - Asterisk - chan_zap - openr2 - TE220B - PSTN - VB6060 - VoicerLib - DGV Channel - Asterisk - ATA - Fax machine

Thank's to Victor Yure taking the other side fax test

By: Alexandre C Alencar (skarmeth) 2008-05-02 12:44:12

Fax test report - POTS Lines to MFC-R2

I can receive faxes send from/to faxes machines using lastest moy branch. Here is the setup:

Fax machine - ATA - Asterisk - chan_zap - openr2 - TE220B - PSTN - Fax machine

Thank's to Victor Yure taking the other side fax test

By: Moises Silva (moy) 2008-05-02 17:14:56

korihor: are you ready to get venezuela variant? I need access to an E1 in Venezuela to see what needs to be tweaked. Send me an e-mail if you are still interested.

By: Alexandre C Alencar (skarmeth) 2008-05-02 19:44:13

Hi all, good night,

I write a simple tutorial in Portuguese to get a system up and running. If you can read portuguese (or use Google Translate), you can use it as reference. If you still have problems to get it working, go to #asterisk-br to get help

I hope to write an english and spanish version asap.

http://blog.alexandrealencar.net/2008/05/asterisk-com-mfcr2-openr2.html

By: Moises Silva (moy) 2008-05-02 19:55:20

Skarmeth: you can update your how-to to mention that spandsp is no longer required. If spandsp is present, r2test will be compiled, if spandsp is not present, then the library will be installed but no r2test program will be available.

Thanks!



By: Moises Silva (moy) 2008-05-05 14:13:21

libopenr2 update. --with-r2test is needed in case you want r2test binary, spandsp library and headers will be required when this option is specified.

I just fixed a bug this weekend where the calling party was not able to CANCEL an outgoing call, the outgoing channel would not hangup even when the caller hung up. Fixed in latest svn revision.

By: Ronald Chan (loloski) 2008-05-07 14:48:37

moy,

Yesterday i give this a whirl, on a test bed server on both digium/sangoma cards
it works well AFAIC, after few hours of intense testing.

Scenario:

     
UAC -> * -> R2 - R2 -> * -> SIP -> Cisco 5300 -> SIP -> UAC
           |     |---------- Sangoma
           |
           |--- Digium

Telco Philippines (Digium -> Bayantel Sangoma -> Globe Tel)

By: Moises Silva (moy) 2008-05-08 11:06:05

Tested in AMD 64 bit with success.

immediate=yes will result in falling into extension 's' just as having DNIS=0, but, DNIS=0 also skip DNIS retrieval resulting in faster call setup.

Loloski: which variant worked for phillipines? ITU?

By: Moises Silva (moy) 2008-05-09 00:44:25

new parameter added.

mfcr2_metering_pulse_timeout, read the docs in zapata.conf.sample for an explanation. This particularly helps to Argentina.

By: Ronald Chan (loloski) 2008-05-09 08:37:04

moy,

signalling=mfcr2

; protocol variant
mfcr2_variant=mx                  # Yes this works  


; get the ANI first (before DNIS)
mfcr2_get_ani_first=no

; max amount of ANI and DNIS
mfcr2_max_ani=12                   # This 2 parameter was assigned by telco
mfcr2_max_dnis=18                  # bayantel

Moy, I'm not really sure for specific ITU specs here, since i'm not really came from a telco background the ani and dnis number was provided by them :) sorry.

By: Moises Silva (moy) 2008-05-09 09:59:43

loloski:

I would like to make sure you are not going to have issues with your signaling by using the mx variant. Can you try using the itu variant?

mfcr2_variant=itu

And let me know?

If you have some time to chat I'd like to do so, contact me at moises.silva at gmail dot com using either google talk or MSN.



By: Michael Smith (asbestoshead) 2008-05-23 15:54:19

Hi, I'm having success with this patch in Ecuador with Pacifictel. The phone switch is an Ericsson.

zaptel.conf:

span=1,1,0,cas,hdb3
cas=1-15:1101
cas=17-31:1101
dchan=16

zapata.conf:

signalling=mfcr2
mfcr2_variant=itu
mfcr2_get_ani_first=no
mfcr2_max_ani=8
mfcr2_max_dnis=7
mfcr2_category=national_subscriber
mfcr2_logdir=span1
mfcr2_logging=all

By: Ronald Chan (loloski) 2008-05-24 08:22:56

moy,

Sorry for late reply, i got mixed up with my schedule, anyway setting mfcr2_variant=itu also work fine with my test setup, If we our lucky enough to convince our client's upper management, this will bring us to the next level of testing it even further on 8 E1 R2 Line on 2 * box, i know this is really a tough decision to make for them but who knows?

This is a david ang goliath match Meridian Option 11c vs Asterisk

will keep you up2date!!!

Best regards,

Ronald

By: Moises Silva (moy) 2008-05-26 00:46:39

Added echo cancel, this should fix your issue asbestoshead

Also merged with trunk revision 118253

By: Michael Smith (asbestoshead) 2008-05-26 13:35:44

For Pacifictel in Ecuador (see above, note 0087280) we weren't able to make calls to some long distance numbers. They were sending us a tone 6 at the end of DNIS. This sounds almost like the group C from Mexico stuff, but the telco says they aren't using group C, and the tone 6 just means "call accepted with charge".

They suggested reconfiguring the Ericsson switch to use CRLM -- this is an Ericsson-specific E1 variant that Google doesn't know anything about. With CRLM on their end, I had to switch the variant on our end from ITU to Brazil. Now we can place calls anywhere. There are a few things that are odd but not important:

- invalid numbers usually result in a tone 4 in reply to the last digit of DNIS (still in group A!). libopenr2 says "Invalid Multi Frequency Tone"
- For some busy numbers, we get a tone 2 (in group B) and libopenr2 says "Invalid Multi Frequency Tone". (For other busy numbers, the line is actually answered and a recording plays, "The number you have dialled is occupied".)

The telco says tone 2 means busy with special information and tone 3 means busy, but we haven't seen a tone 3 from them yet. It's not just openr2 that gets confused. Even the landlines and cellphones here have trouble with these tone 4 and tone 2 numbers -- they tend to play ringback and busy at the same time.

By: Michael Smith (asbestoshead) 2008-05-27 17:16:38

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 = 2XXXXX0, ANI = 42XXXXX0, 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@macro-callfrompstn Up      Dial(SIP/2XXXXX0@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.



By: Moises Silva (moy) 2008-05-27 22:36:50

asbestoshead: thanks A LOT for the feedback. I will look into it this week and let you know when is fixed.

By: Moises Silva (moy) 2008-05-30 09:15:13

asbestoshead: Thanks a lot for the help investigating this issue. As we discussed by e-mail, openr2 now handles address complete and network busy tones when the call setup is still in Group A. I still need to investigate what is the proper action to take when Group B "send special info tone" is received.

I also updated Asterisk branch to properly hangup the call even when there is no owner associated yet. This will fix the issue in which the call would be leaved up  when clear forward is sent during call setup.

By: Michael Smith (asbestoshead) 2008-06-01 16:37:52

OK, I'm using the latest. openr2 trunk r24, mfcr2 asterisk branch r119205. Phone company is Pacifictel in Guayaquil, Ecuador. They are using an Ericsson switch in standard ITU mode (not CRLM anymore). Everything seems to be working.

One minor thing: openr2 installs into /usr/lib instead of /usr/lib64. I set --prefix=/usr in the arguments to ./configure, and I can tell configure knows what directory to use (I see references to "--libdir=/usr/lib64" in config.log), but when I run "make install", libtool installs the libraries to /usr/lib. Maybe it's an old version of ltmain.sh you've got in the tree?

zaptel.conf:

span=1,1,0,cas,hdb3
cas=1-15:1101
cas=17-31:1101
dchan=16

zapata.conf:

signalling=mfcr2
mfcr2_variant=itu
mfcr2_get_ani_first=no
mfcr2_max_ani=8
mfcr2_max_dnis=7
mfcr2_category=national_subscriber
mfcr2_logdir=span1
mfcr2_logging=all

context=from_e1_phonegroup
group=0
channel => 1-15
channel => 17-31

By: Alexandre C Alencar (skarmeth) 2008-06-02 07:10:25

Hi,

Try to set libdir as --libdir=/usr/lib64 in configure command-line and then run

sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool

Best Regards

By: Michael Smith (asbestoshead) 2008-06-04 12:58:06

Hi, I think there might be an issue with alarm clearing. If an alarm happens on a channel during a call, the channel gets put into an alarm state (p->inalarm!=0) and will never be used for outbound calls again. Incoming calls on that channel still work, but chan_zap will never place an outbound call on the channel.

It seems like sometimes (during calls?) the usual chan_zap zt_handle_event() gets zap alarms, and other times (between calls?) the openr2 code gets the alarm and handles it by passing it up to zt_r2_on_zap_alarm().

If a channel is in a call and an alarm happens, zt_handle_event() gets the alarm and sets p->inalarm.

Jun  2 11:00:29 gyeast asterisk[13449]: WARNING[14616]: chan_zap.c:4983 in zt_handle_event: Detected alarm on channel 12: Yellow Alarm
Jun  2 11:00:29 gyeast asterisk[13449]: DEBUG[14616]: chan_zap.c:3707 in zt_hangup: disconnecting MFC/R2 call on chan 12

When the alarm clears, zt_r2_on_zap_alarm() gets the notification but doesn't clear p->inalarm.

Jun  2 11:00:34 gyeast asterisk[13449]: DEBUG[14616]: chan_zap.c:1478 in zt_r2_write_log: Chan 12 - ZT_EVENT_ALARM | ZT_EVENT_NOALARM
Jun  2 11:00:34 gyeast asterisk[13449]: WARNING[14616]: chan_zap.c:1293 in zt_r2_on_zap_alarm: Zap alarm on chan 12.

We seem to have a couple of alarms a day where all channels go into alarm (yikes!). After a couple of days of that, there are no outbound channels anymore :) I guess the fix might be to have zt_r2_on_zap_alarm() set / clear p->inalarm.

By: Tito Garrido (titogarrido) 2008-06-05 09:37:54

Hi, I'm from Brazil.

I'm using the lastest snapshots and when I make an outbound call I'm having an erro:

 -- Zap/63-1 answered SIP/1000-0829de60
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1466 zt_r2_write_log: Chan 63 - Far end disconnected. Reason: Normal Clearing
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1430 zt_r2_on_call_disconnected: MFC/R2 call disconnected on chan 63
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 64
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 65
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 66
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 67
   -- Hungup 'Zap/63-1'
 == Spawn extension (zap, 35257073, 1) exited non-zero on 'SIP/1000-0829de60'
[Jun  5 07:12:07] ERROR[20143]: chan_zap.c:1472 zt_r2_write_log: Chan 63 - Protocol error. Reason = Invalid CAS, R2 State = Clear Forward Transmitted, MF state = MF Engine Off, MF Group = Forward Group II
[Jun  5 07:12:07] ERROR[20143]: chan_zap.c:1304 zt_r2_on_protocol_error: MFC/R2 protocol error on chan 63: Invalid CAS
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 64
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 65
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 66
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 67
[Jun  5 07:12:07] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 63
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 68
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 69
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 70
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 71
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 72
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 73
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 74
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 75
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 76
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1489 zt_r2_on_line_blocked: Far end blocked on chan 77
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 68
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 69
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 70
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 71
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 72
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 73
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 74
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 75
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unblocked on chan 76
[Jun  5 07:14:56] NOTICE[20143]: chan_zap.c:1494 zt_r2_on_line_idle: Far end unb

Meu zapata está configurado da seguinte forma:
[trunkgroups]

[channels]
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
signalling=mfcr2
mfcr2_variant=br
mfcr2_get_ani_first=no
mfcr2_max_ani=20
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_logdir=span1
mfcr2_logging=all
context=embratel
group=2
channel => 63-77
channel => 79-93
callgroup=2
pickupgroup=2

Zaptel.conf:
loadzone=br
defaultzone=br

span=1,1,0,cas,hdb3
cas=1-15:1101
dchan=16
cas=17-31:1101

span=2,1,0,cas,hdb3
cas=32-46:1101
dchan=47
cas=48-62:1101

span=3,1,0,cas,hdb3
cas=63-77:1101
dchan=78
cas=79-93:1101

span=4,1,0,cas,hdb3
cas=94-108:1101
dchan=109
cas=110-124:1101

It's a bug?

Thanks for the great work!

By: Moises Silva (moy) 2008-06-05 10:05:02

titogarrido: it seems like you have a faulty line there. Have you tried talking with telco support to see what they have to say? you just need to tell them that your line is being blocked once in a while.

asbestoshead: thanks a lot for the wonderful feedback again :), effectively I need to handle the inalarm state in the zap private structure, I will do so and update you when done. I believe you had a similar issue as the one titogarrido is having isn't it? a faulty line in Ecuador? did the telco fix that? or what did you do?

By: helio coelho junior (heliocoelhojr) 2008-06-05 19:24:26

Hi:

 I'm trying to take this version for a spin but I'm seeing the same issue that was reported by titogarrido.
 My E1 is from Oi/Telemar and all the setups I've seen so far are for Embratel's E1s. There's a difference between them because using unicall
Embratel is protocol variant br,20,4,8 and Telemar is br,20,20. But I'm not
an expert in the field... :)

The channels are recognized and asterisk is able to answer calls, but they soon hang up.

Here a snip from the logfile:

[Jun  5 21:13:12] NOTICE[18191] chan_zap.c: New MFC/R2 call detected on chan 14.
[Jun  5 21:13:15] NOTICE[18191] chan_zap.c: MFC/R2 call offered on chan 14. DNIS = 1500, ANI = 24222376006, Category = National Subscriber
[Jun  5 21:13:16] NOTICE[18191] chan_zap.c: MFC/R2 call has been accepted on chan 14
[Jun  5 21:13:28] NOTICE[18191] chan_zap.c: Far end unblocked on chan 29
[Jun  5 21:13:28] NOTICE[18191] chan_zap.c: Far end blocked on chan 29
[Jun  5 21:13:32] ERROR[18191] chan_zap.c: Chan 14 - Protocol error. Reason = Invalid CAS, R2 State = Clear Back Transmitted, MF state = MF Engine Off, MF Group = Backward Group B
[Jun  5 21:13:32] ERROR[18191] chan_zap.c: MFC/R2 protocol error on chan 14: Invalid CAS
[Jun  5 21:13:32] NOTICE[18191] chan_zap.c: New MFC/R2 call detected on chan 14.
[Jun  5 21:13:32] NOTICE[18191] chan_zap.c: Chan 14 - Far end disconnected. Reason: Normal Clearing
[Jun  5 21:13:32] NOTICE[18191] chan_zap.c: MFC/R2 call disconnected on chan 14
[Jun  5 21:13:32] NOTICE[18191] chan_zap.c: MFC/R2 call end on chan 14

nice work, congratulations.

Best Regards,
Helio.

By: Michael Smith (asbestoshead) 2008-06-06 08:01:46

titogarrido: It does seem like you might have a noisy line.

In my case the telco is running unbalanced E1 over coax from their digital switch to the closest CO to our building; into a balun to convert it into balanced twisted pair; into an SHDSL modem; over SHDSL and back to balanced E1 at our site; over a few metres of UTP into our Digium card. It's an unusual setup and it took a few tries to find a reliable balun. Until then we saw dozens of sync losses/recoveries per second during the day, and at night the lines would block and unblock themselves continually (noise on the CAS bits?). Maybe some of this applies to you.

By: Michael Smith (asbestoshead) 2008-06-06 08:09:57

heliocoelhojr: Almost seems like you also have a noisy line -- you hear audio no problem, and then the connection drops? By that point, the hard part is done (the MFC tones - ANI, DNIS, etc.), and it's just the simple CAS signalling, the four bits that  signal when to start, end and answer a call. If those are doing the wrong thing, you might have some noise on the line.

Maybe run zttool and watch the Tx / Rx bits on your span. When my line was noisy, the Rx bits kept toggling on and off for no good reason.

By: Alexandre C Alencar (skarmeth) 2008-06-06 11:33:54

Hi Helio,

As I can see, you come from Unicall installations. OpenR2 have a different protocol variant setup as show bellow (Moises, correct me if needed).

Steeve Underwood Unicall protocol variant definition (http://www.soft-switch.org/unicall/installing-mfcr2.html)

   "<country code>,<maximum ANI digits>,<DNIS digits>[,<options>]"

Moises Silva OpenR2 protocol variant definition

; Line signalling
signalling=mfcr2

; Protocol variant
mfcr2_variant=br

; Get the ANI first (before DNIS)
; If set to yes get ANI first and the DNIS
; If set to no get DNIS and then ANI (same behavior as option 8 in Unicall)
mfcr2_get_ani_first=no

; Max amount of ANI and DNIS
mfcr2_max_ani=20
mfcr2_max_dnis=4

; Call category (may override using MFCR2_CATEGORY channel variable)
mfcr2_category=national_subscriber


Regards

By: Moises Silva (moy) 2008-06-08 23:37:04

heliocoelhojr and titogarrido:

Can you contact me via MSN or Google Talk? my info is at libopenr2.org

I'd like to take a closed look at your issues.

Thanks!

By: Moises Silva (moy) 2008-06-09 13:43:43

I discussed the issue with titogarrido via google talk and this is not a problem with the telco, he is not even connected to a telco but to a Unicall line. The issue looks pretty clear, it seems the other end (Asterisk/Unicall) blocked/unblocked the line, either because of an asterisk restart or some other reason. The issue only happened once.



By: Moises Silva (moy) 2008-06-19 09:13:43

asbestoshead:

The inalarm stuff is fixed. You need to snv update both Asterisk and openr2.

By: konsultex (konsultex) 2008-06-19 17:14:52

I posted this on the Trixbox forum but I think this may be a better place beause I think there may be an issue with the zap channel.

I am using Trixbox 2.6.1 (the name of the iso) which reports 2.6.0.7 on the management portal. I have a Sangoma A102 card connected to an E1 line using mfc/r2 in Brazil. In order to make this work I followed these instructions

http://libopenr2.org/ (very good!)

I upgraded Asterisk to 1.4.21 on this Trixbox using the patched version on the site above.

I am able to receive calls on the ZAP channel but I can not make them. I am using the defalt ZAP/g0 and 9_outside route. The log shows:

....
[Jun 19 19:09:15] VERBOSE[4739] logger.c: -- Executing [s@macro-dialout-trunk:20] Dial("SIP/5500-098a6ac8", "ZAP/g0/37739009|300|") in new stack
[Jun 19 19:09:15] WARNING[4739] app_dial.c: Unable to create channel of type 'ZAP' (cause 0 - Unknown)
[Jun 19 19:09:15] VERBOSE[4739] logger.c: == Everyone is busy/congested at this time (1:0/0/1)
[Jun 19 19:09:15] DEBUG[4739] app_macro.c: Executed application: Dial
....

My zapata.conf file looks like this:

[trunkgroups]

[channels]
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
hidecallerid=no
relaxdtmf=yes
rxgain=0.0
txgain=0.0
immediate=no
signalling=mfcr2
mfcr2_variant=br
mfcr2_gte_ani_first=no
mfcr2_max_ani=20
mfcr2_max_dnis=20
mfcr2_category=national_subscriber
mfcr2_logdir=span1
mfcr2_logging=all

;Sangoma A102 port 1 [slot:6 bus:4 span:1]
context=from-pstn
channel => 1-15
channel => 17-31
group=0
callgroup=0
pickupgroup=0

The E1 channles seem ok:

trixbox2*CLI> mfcr2 show channels
Chan Variant Max ANI Max DNIS ANI First Tx State Rx State
1 BR 20 20 No IDLE IDLE
2 BR 20 20 No IDLE IDLE
3 BR 20 20 No IDLE IDLE
4 BR 20 20 No IDLE IDLE
5 BR 20 20 No IDLE IDLE
6 BR 20 20 No IDLE IDLE
7 BR 20 20 No IDLE IDLE
8 BR 20 20 No IDLE IDLE
9 BR 20 20 No IDLE IDLE
10 BR 20 20 No IDLE IDLE
11 BR 20 20 No IDLE IDLE
12 BR 20 20 No IDLE IDLE
13 BR 20 20 No IDLE IDLE
14 BR 20 20 No IDLE IDLE
15 BR 20 20 No IDLE IDLE
17 BR 20 20 No IDLE IDLE
18 BR 20 20 No IDLE IDLE
19 BR 20 20 No IDLE IDLE
20 BR 20 20 No IDLE IDLE
21 BR 20 20 No IDLE IDLE
22 BR 20 20 No IDLE IDLE
23 BR 20 20 No IDLE IDLE
24 BR 20 20 No IDLE IDLE
25 BR 20 20 No IDLE IDLE
26 BR 20 20 No IDLE IDLE
27 BR 20 20 No IDLE IDLE
28 BR 20 20 No IDLE IDLE
29 BR 20 20 No IDLE IDLE
30 BR 20 20 No IDLE IDLE
31 BR 20 20 No IDLE IDLE
trixbox2*CLI>

Does anything look obviously wrong with this? Any ideas, please?

Thanks.

By: Michael Smith (asbestoshead) 2008-06-19 19:35:02

Hi konsultex, try moving your "group=0" above the "channel =>" lines in zapata.conf. All of the settings have to come before the channel lines.

By: konsultex (konsultex) 2008-06-19 22:50:58

Right, that is a very good idea, thanks. I will try it tomorrow. Telefonica decided to block the lines for the day since they don't want to enable them if we have an open technical issue. I also noticed a typo in "mfcr2_gte_ani_first" but that probably does not cause this problem.

By: konsultex (konsultex) 2008-06-19 22:53:52

I want to add that I copied most of zapata.conf from here: http://blog.alexandrealencar.net/2008/05/asterisk-com-mfcr2-openr2.html so maybe that example does not work because it has group= after the channel numbers.

By: konsultex (konsultex) 2008-06-20 07:25:33

I want to report that with the zapata.conf change openr2 works for me for a Telefonica (Brazil) E1 line with "R2 Digital" signaling and a Sangoma A102 card. I still have to do stress testing and I will report any problems that may come up. Thanks to all the people involved in this.

By: Alexandre C Alencar (skarmeth) 2008-06-20 08:45:22

Hi all,

konsultex I updated the post, thank's for pointing it out.

http://blog.alexandrealencar.net/2008/05/asterisk-com-mfcr2-openr2.html

Best Regards

By: Michael Smith (asbestoshead) 2008-06-27 03:57:15

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. Once in a while 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



By: Moises Silva (moy) 2008-06-27 08:41:31

asbestoshead: I'd like first to know why the MF timeout is happening. What do you have in mfcr2_mfback_timeout parameter in zapata.conf? You may want to try something like 2000 and see if the MF timeout error goes away, it seems your telco may be quite slow.

Now, regarding the behavior on protocol timeout, I can certainly go to BLOCK and then do IDLE, but before doing that I'd like you to ask them exactly how much time do they expect us to stay in blocked before going to idle.

Putting a line to blocked manually sounds something reasonable and something I think may be useful sometimes, so I will add that.

By: Moises Silva (moy) 2008-06-30 23:13:49

asbestoshead: added command "mfcr2 set blocked" to manually set to BLOCKED a line. You need to update openr2 and mfcr2 asterisk branch

I will analyze further your issue with the protocol error and post results here later.

By: Michael Smith (asbestoshead) 2008-07-01 08:05:08

Hi Moy, thanks a lot, you rock.

The telco couldn't tell me for sure how long to block the line so I'll have to figure it out experimentally next time I have broken lines.

It seems I don't get broken lines every time I have a timeout. I had 13 MF back timeouts yesterday, all of them on incoming calls, and no broken lines.

I'll bump my timeout up to 2000ms (but it's close to that now, default setting, 1500ms).

By: Moises Silva (moy) 2008-07-01 08:18:16

asbestoshead: if you want to force a MF back timeout to experiment, you can put the MF back timer to 50ms, that surely will break it :)

You can also try to increment it to avoid the MF back timeout to 8000 then. If 8000 still gives errors, there's definitely something else going on there. If 8000  seems to fix it let me know to increment the default.

By: Michael Smith (asbestoshead) 2008-07-02 17:00:35

Oh, my script to check for broken lines was broken -- I had tons. With a timeout of 8000 ms I still get timeouts.

Now I've got a cron job to find broken lines (rxbits == 1 when txbits == 9) and block them each for five seconds using "mfcr2 set blocked", then idle them with "mfcr2 set idle". It looks like it actually takes only two seconds to get the lines back. Works pretty well, thanks a lot.

When the lines come back I see this error, but it's benign:

ERROR[11292]: chan_zap.c:1476 in zt_r2_write_log: Chan 28 - Protocol error. Reason = Invalid R2 state, R2 State = *Unknown*, MF state = MF Engine Off, MF Group = No Group

By: Moises Silva (moy) 2008-07-02 19:57:22

asbestoshead: Do you have call logs for those timeouts?

By: Moises Silva (moy) 2008-07-09 08:28:01

I just fixed a couple of nasty bugs that you might be facing.

1. Sometimes outgoing calls would be dropped even when more lines are available, due to a race condition between incoming and outgoing calls.

2. Command "mfcr2 set blocked" sometimes lead to protocol error because openr2 was mishandling the blocking signal.

A new feature added is the parameter mfcr2_call_files=yes|no in zapata.conf, the directory mfcr2_logdir will be automatically created (even recursively), so you don't have to worry anymore of making sure it exists.

Update to the latest SVN openr2 and Asterisk MFC/R2 branches please.

By: Humberto Figuera (korihor) 2008-07-15 15:15:46

Hi moy, libopenr2_venezuela_variant.patch is the implementation of venezuela variant for libopenr2. I has tested it on Cantv, Movilnet and Movistar telco's in Venezuela.

Most variants of MFC/R2 offer a way to go directly to the call accepted state, bypassing the use of group B and II tones. How do I do this?

Thanks, great job :)

By: Moises Silva (moy) 2008-07-15 15:54:16

korihor: thanks for the patch :)

Regarding by-passing B/II signals, I already added half-support for that, I accept that from the forward side, but not yet send it from the backward. We need to add some simple code for a new option in zapata.conf, something like immediate_accept=yes|no and then a new API to openr2 like openr2_set_immediate_accept(r2context, 1|0); then openr2 will send the proper signal to by-pass the GB/II stuff. You can take a look at src/r2proto.c, I named this signal as mf_ga_tones.address_complete_charge_setup, we just need to send that signal on variants that support when the new API openr2_set_immediate_accept is used to configure the context.

You have 2 options.

1. Either you wait for me to add it, I expect to have some time this weekend to do so.

2. Add it yourself and send me a patch. However, if the patch covers things in chan_zap.c you will need to sign Digium's disclaimer.

Thanks!



By: Humberto Figuera (korihor) 2008-07-16 13:02:33

Hi moy, I uploaded the patches chan_zap_immediate_accept.patch and libopenr2_immediate_accept.patch that should be enough to implement the "immediate accept" feature.

By: Moises Silva (moy) 2008-07-18 00:09:33

Thanks korihor!, integrated in last revisions of openr2 and Asterisk branches (1.6, 1.4 and 1.2)

By: Nicolas Corrarello (ncorrare) 2008-08-04 13:32:22

For compatibility with a Panasonic TDA-200, (at least here in Argentina) add:
in
/etc/asterisk/zapata.conf
mfcr2_variant=ar
mfcr2_advanced_protocol_file=/etc/asterisk/r2proto-ar.conf
mfcr2_immediate_accept=yes

and in /etc/asterisk/r2proto-ar.conf

mf_gb_tones.accept_call_with_charge=1

By: Evandro César Arruda (ecarruda) 2008-08-23 23:23:08

Hi Moy,

First I like to give to you congratulations about this wonderful project.

In Brazil we are limited to the use of Digivoice Board, and this generate several problems, crashs in asterisk, versions of Hardware very diferent and unstable, bad support and echo, echo, echo, echo.

I like to Report my experiences on ezVoice Telecom ( Oficial Digium Partner in Brazil ) with OpenR2.

I tested With TE110, TE120 and TE440 With Two diference Hardwares  Xeon and Core2Duo ( Motherboard's Intel ).

With Xeon I and my Team tested OpenR2 with Stress Call Test using 2xTE120 and other moment 2xTE110 with Cross E1 Cable, wonderful and full sucess.

I Tested With 2 Xeon Machines and One TE120 per Machine, one side Embratel E1-R2 Calling and other site Telefonica E1-R2 Answering, with full sucesss, 90 minutes with +/- 6.500 calls Recording with MixMonitor, fully sucess.

With Core2Duo We are using for test with TE440P, we are using 2 ports, one ISDN from CTBC Telecom and on Other port Embratel R2, very good, running very nice, but sometimes my lines ring for people using psth outside company and in Asterisk don't receive anywere and don't call to out using Zap channels, but restart now solves this problem.

In this Weekend i relized tests With Core2Duo and 2(two) TE110P boards on the same machine with E1 Cross Cable, in 8 hours i completed 3.500 calls using scrint with random times and recoring on the 60 channels,  but after +/- 30 minutes, 30 channels ( g1 15 +  g2 15 ) stoped work, after 8 hours all channels stoped and on asterisk I retrieve this log:

   -- Executing [failed@rec-r2:1] Answer("OutgoingSpoolFailed", "") in new stack
 == Spawn extension (rec-r2, failed, 1) exited non-zero on 'OutgoingSpoolFailed'
   -- Executing [h@rec-r2:1] Hangup("OutgoingSpoolFailed", "") in new stack
 == Spawn extension (rec-r2, h, 1) exited non-zero on 'OutgoingSpoolFailed'
 == Parsing '/etc/asterisk/manager.conf': Found
[Aug 24 01:14:06] DEBUG[20143]: chan_zap.c:918 zt_r2_get_channel_category: no MFC/R2 category specified for chan Zap/1-1, using default National Subscriber
[Aug 24 01:14:14] ERROR[20143]: chan_zap.c:959 zt_r2_on_protocol_error: MFC/R2 protocol error on chan 1: Seize Timeout
[Aug 24 01:14:14] DEBUG[20143]: chan_zap.c:3005 zt_hangup: disconnecting MFC/R2 call on chan 1
   -- Hungup 'Zap/1-1'

Curious on mfcr2 show channels

17 BR      20      4        No        No               CLEAR FO SEIZE AC
 18 BR      20      4        No        No               CLEAR FO SEIZE AC
 19 BR      20      4        No        No               CLEAR FO SEIZE AC
 20 BR      20      4        No        No               CLEAR FO ANSWER  
 21 BR      20      4        No        No               CLEAR FO SEIZE AC
 22 BR      20      4        No        No               CLEAR FO SEIZE AC
 23 BR      20      4        No        No               CLEAR FO ANSWER  
 24 BR      20      4        No        No               CLEAR FO SEIZE AC
 25 BR      20      4        No        No               CLEAR FO CLEAR BA
 26 BR      20      4        No        No               CLEAR FO SEIZE AC
 27 BR      20      4        No        No               CLEAR FO CLEAR BA
 28 BR      20      4        No        No               CLEAR FO SEIZE AC
 29 BR      20      4        No        No               CLEAR FO SEIZE AC
 30 BR      20      4        No        No               CLEAR FO ANSWER  
 31 BR      20      4        No        No               CLEAR FO SEIZE AC

If you need more logs, dumps or detailed informations i give to you with great pleasure.

Tks



By: Moises Silva (moy) 2008-08-25 01:58:28

ecarruda: thanks for testing! :)

As of the protocol errors. You seem to have 2 issues.

The first one is reported as a "seize timeout", which means the other side did not  attended our request for starting a call. I cannot think of a good reason for that to happen. For that error I require the call logs (see mfcr2_call_files configuration in zapata.conf/chan_dahdi.conf)

The second error is much more easier to fix. Brazilian MFC/R2 variant handles a "Forced Release" that I have not seen in any other country, I have a patch for that and I will try to include it this Tuesday.

Along with the patch for "Forced Release" for Brazil, I plan to merge all the changes from Asterisk trunk, including chan_dahdi changes, which means, openr2 will work now with chan_dahdi in 1.6 and not chan_zap, do you have a problem testing with DAHDI instead?



By: Evandro César Arruda (ecarruda) 2008-08-25 06:57:45

Moy,

Thanks you for the excelente development process and for your atention and your speed answer, let's go.

First I'm fully available to help you with tests in various differente scenes.

I'm sending tow calls log, if you need more informaion or debugs, please tell me, this log i get on 32 minutes of call, 30 channes go out and return "seize timeout", 15 per E1, with 2 machines with 1 e1 peer machine I don't get this error, with ISDN in this machine test with 2 E1 and Cross E1 Cable don't get this error two ( just for explanation )

The second question, i'm waiting for your patch, I don't have problem to test DAHDI in my lab, i can do all tests you need to help in OpenR2 development, if you like to send patch to me, i apply in zaptel version two for testing and i test DAHDI when you commit on SVN.

Moy, You tell to me about first error ( in Brazil force clear necessary ) but this tests i'm using Cross E1 Cable in the same machine two cards and in the same asterisk, Brazilian problems not applied to this, correct? But corretion to "unique" ehheh Brazilian problem is very interessant and i have various scene and R2 lines to test it to you.

My contacts:
Mail: evandro@ezvoice.com.br
Gtalk: ecarruda@gmail.com

LOGS:

[01:42:50:836] [Thread: 3004103600] [Chan 26] - Call started at Sun Aug 24 01:42:50 2008 on chan 26
[01:42:50:836] [Thread: 3004103600] [Chan 26] - ABCD Tx >> [SEIZE] 0x00
[01:42:50:837] [Thread: 3004103600] [Chan 26] - ABCD Raw Tx >> 0x01
[01:42:58:855] [Thread: 3004103600] [Chan 26] - calling callback on chan 26
[01:42:58:855] [Thread: 3004103600] [Chan 26] - Seize Timeout Expired!
[01:42:58:855] [Thread: 3004103600] [Chan 26] - Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF state = MF Engine Off, MF Group = Forward MF init
[01:42:58:855] [Thread: 3004103600] [Chan 26] - DNIS = 87, ANI = , Last MF Signal =  


[01:51:07:578] [Thread: 3010771888] [Chan 51] - Call started at Sun Aug 24 01:51:07 2008 on chan 51
[01:51:07:578] [Thread: 3010771888] [Chan 51] - ABCD Tx >> [SEIZE] 0x00
[01:51:07:578] [Thread: 3010771888] [Chan 51] - ABCD Raw Tx >> 0x01
[01:51:15:597] [Thread: 3010771888] [Chan 51] - calling callback on chan 51
[01:51:15:597] [Thread: 3010771888] [Chan 51] - Seize Timeout Expired!
[01:51:15:597] [Thread: 3010771888] [Chan 51] - Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF state = MF Engine Off, MF Group = Forward MF init
[01:51:15:597] [Thread: 3010771888] [Chan 51] - DNIS = 459, ANI = , Last MF Signal =  

Thanks a lot,
Evandro.



By: Caio Begotti (caio1982) 2008-08-25 09:12:34

Olá ecarruda, would you mind attaching these logs as actual files to this ticket and deleting these long comments? It's better to read and does not pollute the comments area, the current scrolling is pretty long. Thanks :)

By: Evandro César Arruda (ecarruda) 2008-08-25 12:03:44

Hi Caio,

Tks for the tip, You are correct, Sorry people,
I thought people not want to post log in attachment's with licensed files.

Moy,

The logs steel in Attachment: mfcr2-logs-seize_timeout.txt

Tks,
Evandro

By: Evandro César Arruda (ecarruda) 2008-08-28 07:15:20

Hy Moy,

How are you? I hope you are fine.

One more problem for us, i think this is more complex.

I was using Core2Duo for tests with One TE4xxp ( 4 E1 ports ), Port 1: ISDN Ctbc Telecom, Port 2: R2 Embratel and this OK, in this night we changed this Quad-Span by 2 Te110P, now i have one big problem....

In Rando times but with interval < 10 minutes i have this error in all R2 ports:

[Aug 28 09:18:14] DEBUG[4343]: chan_zap.c:1152 zt_r2_write_log: Chan 32 - Alarm Raised
[Aug 28 09:18:14] WARNING[4343]: chan_zap.c:948 zt_r2_on_hardware_alarm: Zap alarm on chan 32.
.....
[Aug 28 09:18:14] DEBUG[4344]: chan_zap.c:1152 zt_r2_write_log: Chan 62 - Alarm Raised
[Aug 28 09:18:14] WARNING[4344]: chan_zap.c:948 zt_r2_on_hardware_alarm: Zap alarm on chan 62.


Alter 2~5 seconds I receive in all ports:
[Aug 28 09:18:14] DEBUG[4343]: chan_zap.c:1152 zt_r2_write_log: Chan 32 - Alarm Cleared
[Aug 28 09:18:14] WARNING[4343]: chan_zap.c:948 zt_r2_on_hardware_alarm: Zap alarm on chan 32.
....
[Aug 28 09:18:14] DEBUG[4344]: chan_zap.c:1152 zt_r2_write_log: Chan 62 - Alarm Cleared
[Aug 28 09:18:14] WARNING[4344]: chan_zap.c:948 zt_r2_on_hardware_alarm: Zap alarm on chan 62.


If you need more information or logs, contact me.

Tks,
Evandro

By: Evandro César Arruda (ecarruda) 2008-08-28 11:07:00

Moy,

I solved alarm/cleared error just disabling timing source from second span card ( R2 ), but with two ISDN lines it´s don´t necessary.

Incomplete timming source implementation, normal error with r2 or just configuration adjust Moy?

If you need my help, contact me.

Thanks a lot,
Evandro.

By: Raúl Torres-Duque (rtorresduque) 2008-09-19 14:51:55

Hi, Moisés:
we are currently working with a Sangoma card w/echo cancellation and we can't get it to work:
We followed the OpenR2 and mfcr2 instructions but when changing the signalling to mfcr2 we lost mfcr2 commands. This are our current conf files:
ZAPTEL.CONF
# Autogenerated by /usr/local/sbin/sangoma/setup-sangoma -- do not hand edit
# Zaptel Channels Configurations (zaptel.conf)
#
loadzone=us
defaultzone=us

#Sangoma A101 port 1 [slot:0 bus:17 span:1] <wanpipe1>
span=1,1,0,ccs,hdb3
bchan=1-15,17-31
hardhdlc=16
-------------------------------------------------------
ZAPATA.CONF
[trunkgroups]
[channels]
language=en
context=inbound
switchtype=euroisdn
pridialplan=unknown
prilocaldialplan=unknown
resetinterval=3600
overlapdial=no
priindication=outofband

pritimer=>t200,1000
pritimer=>t203,10000
pritimer=>t305,30000
pritimer=>t308,4000
pritimer=>t313,4000

facilityenable=no

signalling=mfcr2

toneduration=200
usecallerid=yes
hidecallerid=no
callwaiting=yes
restrictcid=no
usecallingpres=yes
callwaitingcallerid=no
threewaycalling=no
transfer=no
canpark=no
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=yes
relaxdtmf=yes
rxgain=0
txgain=0
immediate=no
musiconhold=default

group=0
callgroup=1
pickupgroup=1
immediate=no
context=from-pstn
channel => 1-15,17-31
-----------------------------------------------

We already tried signalling=mfcr2 (but we loose mfcr2) and cas instead of ccs but with no success.

Any help is welcome.

THX

Raúl

By: Moises Silva (moy) 2008-09-19 15:13:16

rtorresduque thanks for testing, I appreciate it.

However, what you provide is not useful at all. You don't even mention (or at least I could not see any evidence of it), of what is failing. If you don't even get working the "mfcr2" commands, then IS A FACT, you did something wrong. I'd like to avoid using this bug tracker as a "support" forum. Please write to the asterisk-users mailing list to provide detailed steps of what you did and where did you download the sources and how you installed them. In the subject of your e-mail to the mailing list, specify MFC/R2 or OpenR2, so I can easily spot them.

Additionally I don't even see in your configuration that you provided mfcr2_variant=<whatever>, proof that you did not read the documentation included with my branch in configs/zapata.conf.sample in the MFC/R2 section.

I will see with Digium if we can get an asterisk-mfcr2 mailing list or something, given that the volume of support questions is growing fast, here and in my e-mail. I will let you know here if such mailing list gets created.

By: Moises Silva (moy) 2008-10-02 19:29:16

asterisk-r2 mailing list got created, anyone interested in OpenR2 development or support for OpenR2, Unicall or any R2 solution can post their questions there.

By: ptorres (ptorres) 2008-10-09 15:40:58

We have been testing too with very good results for about 20+ days on 2 servers ,
TE405 we had 4 E1 working fine all with R2 until our client asked to switch 2 of them to ISDN , after tweaking the timing sources it seemed to work fine for a while,
however this one trunk -still R2- started to show a problem similar to ecarruda last post... on irregular intervals we can see ( sometimes as short as 4 seconds to about 1 minute )

chan_zap.c:1152 zt_r2_write_log: Chan 32 - Alarm Raised
chan_zap.c:948 zt_r2_on_hardware_alarm: Zap alarm on chan 32.
for all channels simultaneously for that 'span' and then alarms are cleared almost instantly...

All incoming calls are terminated, 'InAlarm=1' is set for all channels and never cleared until restart ( dialing out fails with CHANISUNAVAIL )

We changed the timing source to 1 for this span (changing the others to 2,3,4 )
this went away but one of the isdns won't sync anymore

any ideas ? , or what did ecarruda mean by 'disabling timing source'  ?

By: Evandro César Arruda (ecarruda) 2008-10-09 16:48:47

PTores,

I has this problem, but, don't have in all scenes, just with specify boards and hardware.

My sugestion is; Disable Clock for OpenR2 ports and enable timing source on ISDN ports, test this and report to us.

For exemple: ( 4 ports -> 2 ISDN and 2 R2 )
span=1,1,0 -> ISDN
span=2,2,0 -> ISDN
span=3,0,0 -> R2
span=4,0,0 -> R2

I sugest disable span reset on zapata.conf too. I have many servers on customers running OpenR2 and ISDN pri today, and I have cases when i need to disable r2 clock from Telecom and have case when i don't need this, test your case.

If you need more help sent new message to bugs or to my email posted in old messages.

Evandro



By: ptorres (ptorres) 2008-10-09 17:33:17

Thanks for answering, I just saw your response after we played a bit with the clock settings but eventually swapped trunks

before :
span=1,1,0 -> ISDN A
span=2,2,0 -> R2   B
span=3,3,0 -> ISDN C
span=4,4,0 -> R2   D

after :
span=1,1,0 -> R2   B
span=2,2,0 -> ISDN A
span=3,3,0 -> ISDN C
span=4,4,0 -> R2   D

everything looks fine so far...

By: Leif Madsen (lmadsen) 2008-12-11 15:43:30.000-0600

I'm updating this status to Ready For Testing because it looks like there are quite a few people who say this is working for them!

Hopefully with a bit more feedback moy can finish up the last remaining issues and this can be merged.

However, I have to ask a question: is this currently working against chan_dahdi? As you may be aware, chan_zap no longer exists in trunk, which is where this new feature would be going.

Thanks!

By: Leif Madsen (lmadsen) 2008-12-11 15:45:01.000-0600

Added note to the description that mentions the branch created by moy so that people don't have to hunt for it in the comments.

By: Moises Silva (moy) 2008-12-11 16:31:09.000-0600

Hello blitzrage!

Yes, this is currently being worked against DAHDI. However, some people is using the 1.2 and 1.4 branches I provide, some others the trunk branch (which is where the latest development is being done on).

About 50% of the issues reported here are due to their misconfiguration in system.conf or chan_dahdi.conf and most likely the other 50% has been already solved since we have not had much failure reports in the last months, neither here or the asterisk-r2 mailing list.

Code review is already in place http://reviewboard.digium.com/r/40/

I hope this can be merged soon, I try to get it up-to-date with trunk once a week or so.

Thanks!

By: Yue Chen (ychen) 2009-01-07 05:47:54.000-0600

Hi Moy,

I am new to both Asterisk and Openr2 so forgive me in advance for lacking of enough background knowledge (I am trying hard to catch up ...). I am building a project involves single port HFC-E1 card. I started with Asterisk 1.6 mfcr2 branch and can build everything without problem. The E1 card came with mISDN driver and it was installed. The name of the driver is hfcmulti.

I did lspci and it give me the card physical information.

04:00.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-                            E1] (rev 01)

When I do a dahdi_hardware, the system tells me

driver should be 'cwain' but is actually 'hfcmulti'
pci:0000:04:00.0     cwain+       1397:30b1 HFC-E1 ISDN E1 card

Apparently something is wrong. If my understanding is right, I should not use mISDN driver since it does not play with zaptel and chan_zap. It only works with chan_misdn. The cwain driver is maintained by junghanns.net as part of bristuff package which support BRI and zaptel. But I am not sure this is right. Before digging into the unknowns, I want to ask for some directions here. Thanks for help.

Regards,

ychen

By: Leif Madsen (lmadsen) 2009-01-09 08:12:09.000-0600

Hey moy!

Any movement on this? Seems Russell has made some comments on reviewboard for you. Could you follow up with them?

Thanks!

By: Moises Silva (moy) 2009-01-09 17:08:06.000-0600

blitzrage! sorry for the lack of update. I just commited the changes Russell suggested and merged the latest trunk code.

By: Moises Silva (moy) 2009-01-09 17:10:45.000-0600

ychen: this is not the right place to request support. Please use the asterisk-users mailing list for that, or asterisk-r2 if this is an issue with R2 in my branch (which does not seem to be btw)

By: Leif Madsen (lmadsen) 2009-01-10 09:09:24.000-0600

moy: no problem! Thanks for following up!

By: Digium Subversion (svnbot) 2009-03-16 15:35:59

Repository: asterisk
Revision: 182355

U   trunk/CHANGES
U   trunk/CREDITS
U   trunk/channels/chan_dahdi.c
U   trunk/configs/chan_dahdi.conf.sample
U   trunk/configure
U   trunk/configure.ac
U   trunk/include/asterisk/autoconfig.h.in
U   trunk/makeopts.in

------------------------------------------------------------------------
r182355 | russell | 2009-03-16 15:35:58 -0500 (Mon, 16 Mar 2009) | 29 lines

Add MFC/R2 support for chan_dahdi.

This commit introduces official support for R2 signaling in chan_dahdi.  The
modifications to chan_dahdi, and the supporting library, LibOpenR2, were both
written by Moises Silva.

Many users are using this code, or a variant of it, in Asterisk 1.2, 1.4 and 1.6
in Brazil, M?\195?\169xico and Argentina. An unknown number of users (but at least 1)
are using it in each of the following countries: Colombia, Nepal, Thailand,
Venezuela, Per?\195?\186, and probably others.

To use this code, LibOpenR2 must be installed from http://www.libopenr2.org/.
Information about configuration can be found in configs/chan_dahdi.conf.sample.

The code committed is the most up to date version, which was being maintained
in svn/asterisk/team/moy/mfcr2/.

I would also like to include a Thank You to the many others that tested this
code beyond those listed in this commit message.  These are the names that I
could find in the mantis issue.

(closes issue ASTERISK-11906)
Reported by: moy
Patches:
     chan_zap-mfr2.patch uploaded by moy (license 222)
Tested by: moy, korihor, viniciusfontes, Skarmeth, loloski, asbestoshead, titogarrido, heliocoelhojr, konsultex, ncorrare, ecarruda, rtorresduque, PTorres, ychen

Review: http://reviewboard.digium.com/r/40/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=182355

By: Digium Subversion (svnbot) 2009-03-16 15:37:53

Repository: asterisk
Revision: 182356

_U  branches/1.6.0/

------------------------------------------------------------------------
r182356 | russell | 2009-03-16 15:37:53 -0500 (Mon, 16 Mar 2009) | 36 lines

Blocked revisions 182355 via svnmerge

........
r182355 | russell | 2009-03-16 15:35:58 -0500 (Mon, 16 Mar 2009) | 29 lines

Add MFC/R2 support for chan_dahdi.

This commit introduces official support for R2 signaling in chan_dahdi.  The
modifications to chan_dahdi, and the supporting library, LibOpenR2, were both
written by Moises Silva.

Many users are using this code, or a variant of it, in Asterisk 1.2, 1.4 and 1.6
in Brazil, M?\195?\169xico and Argentina. An unknown number of users (but at least 1)
are using it in each of the following countries: Colombia, Nepal, Thailand,
Venezuela, Per?\195?\186, and probably others.

To use this code, LibOpenR2 must be installed from http://www.libopenr2.org/.
Information about configuration can be found in configs/chan_dahdi.conf.sample.

The code committed is the most up to date version, which was being maintained
in svn/asterisk/team/moy/mfcr2/.

I would also like to include a Thank You to the many others that tested this
code beyond those listed in this commit message.  These are the names that I
could find in the mantis issue.

(closes issue ASTERISK-11906)
Reported by: moy
Patches:
     chan_zap-mfr2.patch uploaded by moy (license 222)
Tested by: moy, korihor, viniciusfontes, Skarmeth, loloski, asbestoshead, titogarrido, heliocoelhojr, konsultex, ncorrare, ecarruda, rtorresduque, PTorres, ychen

Review: http://reviewboard.digium.com/r/40/

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=182356

By: Digium Subversion (svnbot) 2009-03-16 15:39:35

Repository: asterisk
Revision: 182357

_U  branches/1.6.1/

------------------------------------------------------------------------
r182357 | russell | 2009-03-16 15:39:35 -0500 (Mon, 16 Mar 2009) | 36 lines

Blocked revisions 182355 via svnmerge

........
r182355 | russell | 2009-03-16 15:35:58 -0500 (Mon, 16 Mar 2009) | 29 lines

Add MFC/R2 support for chan_dahdi.

This commit introduces official support for R2 signaling in chan_dahdi.  The
modifications to chan_dahdi, and the supporting library, LibOpenR2, were both
written by Moises Silva.

Many users are using this code, or a variant of it, in Asterisk 1.2, 1.4 and 1.6
in Brazil, M?\195?\169xico and Argentina. An unknown number of users (but at least 1)
are using it in each of the following countries: Colombia, Nepal, Thailand,
Venezuela, Per?\195?\186, and probably others.

To use this code, LibOpenR2 must be installed from http://www.libopenr2.org/.
Information about configuration can be found in configs/chan_dahdi.conf.sample.

The code committed is the most up to date version, which was being maintained
in svn/asterisk/team/moy/mfcr2/.

I would also like to include a Thank You to the many others that tested this
code beyond those listed in this commit message.  These are the names that I
could find in the mantis issue.

(closes issue ASTERISK-11906)
Reported by: moy
Patches:
     chan_zap-mfr2.patch uploaded by moy (license 222)
Tested by: moy, korihor, viniciusfontes, Skarmeth, loloski, asbestoshead, titogarrido, heliocoelhojr, konsultex, ncorrare, ecarruda, rtorresduque, PTorres, ychen

Review: http://reviewboard.digium.com/r/40/

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=182357