[asterisk-r2] ChanIsAvail locking R2 channel

Fri Aug 21 14:06:01 CDT 2009

Melcon, 

Suppose you have four E1, where span1 and span2 is assigned Group1;

Span3 is assigned Group2; and span4 is assigned group3;

So you have G1, G2, and G3 groups

Then you have “Transit Telecom” on G1,  “Embratel Telecom” on G2; and “Oi Telecom“ on G3;

For some destinations Transit is cheaper then Embratel, so you need these calls to go first to Transit then to Embratel.

Chanisavail can scan the tree groups (or even more if you have) and find the first available channel in this sequence. (G1 -> G2 -> G3) If there is a Transit channel available, it will be used for this destination; If Transit is unavailable, Embratel is the second choice; And Oi the last choice.

For others destinations, Embratel is cheaper, so you can scan the groups using another sequence (G2 -> G3 -> G1). If there is a free Embratel channel, it will be used now for this destination.

And so on for the others destination.

We use the chanisavail application as a complement for our LCR system, which determines in real time the groups sequence based on call price, time, date, destinations point of presence, long distance prefix and local prefix.

--

Prado

From: asterisk-r2-bounces at lists.digium.com [mailto:asterisk-r2-bounces at lists.digium.com] On Behalf Of Melcon Moraes
Sent: sexta-feira, 21 de agosto de 2009 14:55
To: asterisk-r2 at lists.digium.com
Subject: Re: [asterisk-r2] ChanIsAvail locking R2 channel

Just for the sake of curiosity, why exactly ChanIsAvail() is needed?

-
MM

On Fri, Aug 21, 2009 at 2:00 AM, Moises Silva <moises.silva at gmail.com> wrote:

I just uploaded a new patch for Asterisk: http://openr2.googlecode.com/files/openr2-asterisk-1.4.26.1.patch

The patch should fix the issue with CHANISAVAIL, however I have not tested it myself. Please test asap so I can upload a new one if the issue is still present.

The issue was fixed as well in Asterisk trunk and Asterisk 1.6.2 branch (which soon will have a new beta out).

OpenR2 1.2.0 will be released this weekend.

On Wed, Aug 19, 2009 at 10:59 AM, Moises Silva <moises.silva at gmail.com> wrote:

Hello Rafael,

I think it's a bug in chan_dahdi.c, I have not tested but checking what application CHANISAVAIL does, the code path seems like unexpected, when ast_request() is called I set mfcr2call=1 to reserve the channel, but in ast_hangup() I do not set mfcr2call=0 because the usual code path is ast_request() -> ast_call() -> ast_hangup() and at that point openr2 callbacks will report call end and I will set mfcr2call=0, but when just checking if the channel is avail, the call is never initiated and the mfcr2call=1 flag keeps set after ast_hangup().

This bug will be present in all patches for Asterisk and 1.6.2 as well. I will fix it tonight (or sooner if I have a chance) for 1.6.2, and create a new patch for 1.4 probably the weekend, or sooner if I can. 

On Wed, Aug 19, 2009 at 2:09 AM, Rafael Prado Rocchi <prado at practis.com.br> wrote:

Hi,
We are having problems with chanisavail.

Everytime we use chanisavail to check for channel availability, when using R2, the channel gets locked.
We tested with 1.4.22, 1.4.24 and 1.4.26, using OpenR2 release 209.

Chanisavail works fine if the E1 is ISDN
But chanisavail gives error and locks the channel if we configure the E1 as R2. Next run, it locks the second available channel and so, until we get all 30 channels locked. Then we have to restart.

All other applications and the asterisk itself is working fine with R2

Can anyone please test this and confirm this problem?

Here is a simple dialplan for testing:

exten => 123,1,noop( ---- TESTE CHANISVAIL ---- )
exten => 123,n,CHANISAVAIL(dahdi/g1)
exten => 123,n,NOOP(CHAN=${AVAILCHAN})
exten => 123,n,SET(CHAN=${CUT(AVAILCHAN||1)})
exten => 123,n,DIAL(${CHAN}/1234)
exten => 123,n,NOOP( STATUS = ${DIALSTATUS})

Thanks in advance,

Rafael Prado

PRACTIS - Comunicação & Tecnologia
Av Aquidaban, 766 - Conj 51        
CEP 13026-510, Campinas/SP - Brasil
http://www.practis.com.br

This message and any archive transmited may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Any views or opinions expressed in this email are solely those of the author and might not represent those of Practis. Although reasonable precautions have been taken by Practis to ensure no viruses are present in this email, the company cannot accept responsability for any loss or damage arising from the use of this email or it's attachments. Thank you for your cooperation.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-r2 mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-r2

-- 
Moises Silva
Software Developer
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada
t. 1 905 474 1990 x 128 | e. moy at sangoma.com

-- 
Moises Silva
Software Developer
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada
t. 1 905 474 1990 x 128 | e. moy at sangoma.com

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-r2 mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-r2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-r2/attachments/20090821/5444fc80/attachment.htm 