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

Wed May 11 07:33:59 CDT 2011

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.
-- 
Sebastian Peschko <speschko at gmail.com>

On Tue, 2011-05-10 at 23:48 -0400, Moises Silva wrote:

> Currently openr2 does not handle metering pulses with forced release
> but only with clear backward signal. 
> 
> 
> 
> Some code changes are needed to handle metering pulses with forced
> release. I could possibly add them sometime in June (I will be doing
> some other Asterisk work then).
> 
> 
> 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
> 
> 
> 
> On Tue, May 10, 2011 at 8:47 PM, Sebastian Peschko
> <speschko at gmail.com> wrote:
> 
>         We have the problem that Telmex (mfcr2_variant=MX) is dropping
>         outgoing calls because the E1 receives a 0x00 (Forced Release)
>         and 20 to 30 ms afterwards is back to 0x04 (Connect) which
>         causes a Protocol error and drops the call seeing that the R2
>         protocoll reacts with a Clear Forwrd and ends the call. This
>         happens at random intervals anywhere from 5 sec to 3 minutes
>         into the outgoing call. It is caused by something similar to
>         the "metering pulse" which we are trying to eliminate by using
>         the variable "mfcr2_metering_pulse_timeout=100" which is
>         longer than the 30ms that the pulse usually takes but the
>         effect stays the same with 'mfcr2_metering_pulse_timeout=-1'
>         or 'mfcr2_metering_pulse_timeout=100' or
>         'mfcr2_metering_pulse_timeout=450'. It looks like openR2
>         does'nt do what this parameter sais it does.
>         
>         We have tested with Wanrouter v3.5.20, Dahdi 2.4.1.2, Asterisk
>         1.6.2.16.2 and 1.8.3.3, openR2 1.3.1.
>         
>         Can anyone tell us what we need to do to avoid the calls being
>         hung up due to the 30ms change in state from 0x04 to 0x00 and
>         back to 0x04??
>         
>         Attached a snipped section of the protocol:
>         
>         [16:50:26:924] [Thread: 3072629648] [Chan 21] - MF Tx >> 1
>         [OFF]
>         [16:50:27:024] [Thread: 3072629648] [Chan 21] - MF Rx << 1
>         [OFF]
>         [16:50:27:024] [Thread: 3072629648] [Chan 21] - scheduled
>         timer id 3 (r2_answer)
>         [16:50:34:609] [Thread: 3072629648] [Chan 21] - Bits changed
>         from 0x0C to 0x04
>         [16:50:34:609] [Thread: 3072629648] [Chan 21] - CAS Rx <<
>         [ANSWER] 0x04
>         This is where the call is connected corectly
>         [16:50:34:609] [Thread: 3072629648] [Chan 21] - Attempting to
>         cancel timer timer 3
>         [16:50:34:609] [Thread: 3072629648] [Chan 21] - timer id 3
>         found, cancelling it now
>         [16:50:34:609] [Thread: 3072629648] [Chan 21] - Attempting to
>         cancel timer timer 0
>         [16:50:34:609] [Thread: 3072629648] [Chan 21] - Cannot cancel
>         timer 0
>         [16:51:14:988] [Thread: 3072629648] [Chan 21] - Bits changed
>         from 0x04 to 0x00
>         This is where at a random time the Rx changes from 0x04 to
>         0x00
>         [16:51:14:988] [Thread: 3072629648] [Chan 21] - CAS Rx <<
>         [FORCED RELEASE] 0x00
>         [16:51:14:988] [Thread: 3072629648] [Chan 21] - Far end
>         disconnected. Reason: Forced Release
>         [16:51:15:008] [Thread: 3072629648] [Chan 21] - Attempting to
>         cancel timer timer 0
>         [16:51:15:008] [Thread: 3072629648] [Chan 21] - Cannot cancel
>         timer 0
>         [16:51:15:008] [Thread: 3072629648] [Chan 21] - CAS Tx >>
>         [CLEAR FORWARD] 0x08                                       
>         [16:51:15:008] [Thread: 3072629648] [Chan 21] - CAS Raw Tx >>
>         0x09
>         [16:51:15:009] [Thread: 3076316048] [Chan 21] - Bits changed
>         from 0x00 to 0x04
>         This where 20ms later the state is returned from 0x00 to 0x04
>         but seeing that we have
>         [16:51:15:009] [Thread: 3076316048] [Chan 21] - CAS Rx <<
>         [0x04] 0x04
>         already processed the Forced Release we send a Clear Forward
>         releasing the call.
>         [16:51:15:009] [Thread: 3076316048] [Chan 21] - Protocol
>         error. Reason = Invalid CAS, R2 State = Clear Forward
>         Transmitted, MF state = MF Engine Off, MF Group = Forward
>         Group II, CAS = 0x04
>         DNIS = 57280170, ANI = , MF = 0x20
>         [16:51:15:009] [Thread: 3076316048] [Chan 21] - Attempting to
>         cancel timer timer 0
>         [16:51:15:009] [Thread: 3076316048] [Chan 21] - Cannot cancel
>         timer 0
>         
>         
>         -- 
>         Sebastian Peschko <speschko at gmail.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/20110511/b327809c/attachment-0001.htm>