[asterisk-r2] ChanIsAvail locking R2 channel

Fri Aug 21 14:07:07 CDT 2009

Prado, Thanks for the explanation.

Moy, I think pretty much the same. I think that ChanIsAvailable makes more
sense for analog ports.

-
MM

On Fri, Aug 21, 2009 at 3:46 PM, Moises Silva <moises.silva at gmail.com>wrote:

> I have never really understood the usage of that dial plan app, between
> checking availability and using it the channel may become busy anyways, but
> I suppose there's ppl who can live with that little chance of the channel
> being taken while they try to use it.
>
>
> On Fri, Aug 21, 2009 at 1:55 PM, Melcon Moraes <melcon at gmail.com> wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> --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
>
> _______________________________________________
> --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/315386f0/attachment.htm 