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

Wed May 11 07:27:23 CDT 2011

Thanks Moy. 
Is there any quick (and dirty) workaround I could apply now until this
gets into production? (I could imagine changing the Clearback (0x0C) to
Forced (0x00) in the code somewhere). We obviously are extremely
affected and Telmex is (as usual) not really helpful in getting this
solved from their end even though we have been putting pressure on them
daily to get this issue solved.

Thanks for your fantastic support as always!

-- 
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/5a87216e/attachment.htm>