[asterisk-r2] mfcr2_metering_pulse_timeout no difference; outgoing calls being dropped

[Sebastian Peschko]

Thanks Moy.
The only problem I have now is that when I activate r2proto.conf with
'mfcr2_advanced_protocol_file=/usr/etc/r2proto.conf' the E1 no longer
works because I suspect that the settings in this file are not conform
with what we should have in Mexico. Can I comment out all other
parameters (which means it should take the 'mx' defaults) and just add
the 'timer.cas_persistance_check=100'?

-- 
Sebastian Peschko <speschko at gmail.com>

On Wed, 2011-05-11 at 10:54 -0400, Moises Silva wrote:
> On Wed, May 11, 2011 at 8:33 AM, Sebastian Peschko
> <speschko at gmail.com> wrote:
>         Moy,
>         question for you: Is there a general parameter in the mfcR2
>         where 'glitches' like the one here can be filtered or ignored?
>         For example: a change in signal (like in this case 0x04 to
>         0x00 to 0x04) in less than 50 or 100 milliseconds would not
>         make a change unless the new state is active for longer than
>         this number of ms.
>         
> 
> 
> You can try using the advanced protocol file. See sample for details,
> the advanced parameter is timers.cas_persistence_check=100
> 
> 
> 
> That will not react on CAS signals immediately, but wait 100ms, if the
> signal persist it will handle it, otherwise will ignore it (if the
> signal gets back to the previous state). I have not tested that
> parameter in a while but should still work.
> 
> Moises Silva
> Senior Software Engineer, Software Development Manager
> Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON
> L3R 9R6 Canada
> t. 1 905 474 1990 x128 | e. moy at sangoma.com
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20110511/d7aa547d/attachment.htm>