<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
Moy,<BR>
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.<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
Sebastian Peschko <<A HREF="mailto:speschko@gmail.com">speschko@gmail.com</A>><BR>
<BR>
</TD>
</TR>
</TABLE>
On Tue, 2011-05-10 at 23:48 -0400, Moises Silva wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
Currently openr2 does not handle metering pulses with forced release but only with clear backward signal.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
Moises Silva<BR>
Senior Software Engineer, Software Development Manager<BR>
Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON L3R 9R6 Canada<BR>
t. 1 905 474 1990 x128 | e. <A HREF="mailto:moy@sangoma.com">moy@sangoma.com</A><BR>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
On Tue, May 10, 2011 at 8:47 PM, Sebastian Peschko <<A HREF="mailto:speschko@gmail.com">speschko@gmail.com</A>> wrote:
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
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.<BR>
<BR>
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.<BR>
<BR>
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??<BR>
<BR>
Attached a snipped section of the protocol:<BR>
<BR>
[16:50:26:924] [Thread: 3072629648] [Chan 21] - MF Tx >> 1 [OFF]<BR>
[16:50:27:024] [Thread: 3072629648] [Chan 21] - MF Rx << 1 [OFF]<BR>
[16:50:27:024] [Thread: 3072629648] [Chan 21] - scheduled timer id 3 (r2_answer)<BR>
[16:50:34:609] [Thread: 3072629648] [Chan 21] - Bits changed from 0x0C to 0x04<BR>
[16:50:34:609] [Thread: 3072629648] [Chan 21] - CAS Rx << [ANSWER] 0x04 This is where the call is connected corectly<BR>
[16:50:34:609] [Thread: 3072629648] [Chan 21] - Attempting to cancel timer timer 3<BR>
[16:50:34:609] [Thread: 3072629648] [Chan 21] - timer id 3 found, cancelling it now<BR>
[16:50:34:609] [Thread: 3072629648] [Chan 21] - Attempting to cancel timer timer 0<BR>
[16:50:34:609] [Thread: 3072629648] [Chan 21] - Cannot cancel timer 0<BR>
[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<BR>
[16:51:14:988] [Thread: 3072629648] [Chan 21] - CAS Rx << [FORCED RELEASE] 0x00<BR>
[16:51:14:988] [Thread: 3072629648] [Chan 21] - Far end disconnected. Reason: Forced Release<BR>
[16:51:15:008] [Thread: 3072629648] [Chan 21] - Attempting to cancel timer timer 0<BR>
[16:51:15:008] [Thread: 3072629648] [Chan 21] - Cannot cancel timer 0<BR>
[16:51:15:008] [Thread: 3072629648] [Chan 21] - CAS Tx >> [CLEAR FORWARD] 0x08 <BR>
[16:51:15:008] [Thread: 3072629648] [Chan 21] - CAS Raw Tx >> 0x09<BR>
[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<BR>
[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.<BR>
[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<BR>
DNIS = 57280170, ANI = , MF = 0x20<BR>
[16:51:15:009] [Thread: 3076316048] [Chan 21] - Attempting to cancel timer timer 0<BR>
[16:51:15:009] [Thread: 3076316048] [Chan 21] - Cannot cancel timer 0<BR>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
Sebastian Peschko <<A HREF="mailto:speschko@gmail.com">speschko@gmail.com</A>><BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
--<BR>
_____________________________________________________________________<BR>
-- Bandwidth and Colocation Provided by <A HREF="http://www.api-digital.com">http://www.api-digital.com</A> --<BR>
<BR>
asterisk-r2 mailing list<BR>
To UNSUBSCRIBE or update options visit:<BR>
<A HREF="http://lists.digium.com/mailman/listinfo/asterisk-r2">http://lists.digium.com/mailman/listinfo/asterisk-r2</A>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
</BODY>
</HTML>