[asterisk-r2] ayuda mfcr2 cantv venezuela
Duilmer Camacho
dcamacho at wtfe.com
Wed May 11 14:21:27 CDT 2011
Estimado Domingo.
El problema con tu saliente es que es R2dtmf. Cantv tiene variantes
dependiente de la central telefónica. Yo te recomiendo que llames a cantv y
le digas que quieres un R2 puro. Como es el caso del entrante es por eso que
te funciona. No hay una sola configuración de CANTV para E1 saliente pues
varia de central en central.
Para poder configurar el dtmfR2 vas a necesitar un analizador de protocolo.
Saludos
World Tel Fax Electronics C. A.
Ing. Duilmer Camacho
Ing. De Proyectos
Dcamacho at wtfe.com
tel: +58-212-9077326
fax: +58-212-9760193
cel: +58-0412-2514012
http://www.wtfe.com
-----Mensaje original-----
De: asterisk-r2-bounces at lists.digium.com
[mailto:asterisk-r2-bounces at lists.digium.com] En nombre de
asterisk-r2-request at lists.digium.com
Enviado el: Martes, 10 de Mayo de 2011 11:31 p.m.
Para: asterisk-r2 at lists.digium.com
Asunto: asterisk-r2 Digest, Vol 33, Issue 3
Send asterisk-r2 mailing list submissions to
asterisk-r2 at lists.digium.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.digium.com/mailman/listinfo/asterisk-r2
or, via email, send a message with subject or body 'help' to
asterisk-r2-request at lists.digium.com
You can reach the person managing the list at
asterisk-r2-owner at lists.digium.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of asterisk-r2 digest..."
Today's Topics:
1. ayuda mfcr2 cantv venezuela (Gil Quijada Domingo Enrique)
2. mfcr2_metering_pulse_timeout no difference; outgoing calls
being dropped (Sebastian Peschko)
3. Re: mfcr2_metering_pulse_timeout no difference; outgoing
calls being dropped (Moises Silva)
4. Re: mfcr2_metering_pulse_timeout no difference; outgoing
calls being dropped (Anton Krall)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 May 2011 17:50:56 -0430 (VET)
From: Gil Quijada Domingo Enrique <domingogil at an.gob.ve>
Subject: [asterisk-r2] ayuda mfcr2 cantv venezuela
To: asterisk-r2 at lists.digium.com
Message-ID: <830933551.9517.1305066056559.JavaMail.root at Correo>
Content-Type: text/plain; charset=utf-8
Buenas tardes lista, estamos haciendo una implementaci?n de asterisk 1.8
sobre lineas e1 de la empresa cantv, pero resulta que configuramos los e1
entrantes y salientes, los entrantes funcionan perfectamente pero con los
canales salientes, tenemos el siquiente problema:
[10:55:13:741] [Thread: 2937060208] [Chan 63] - Protocol error. Reason =
Invalid Multi Frequency Tone, R2 State = Seize ACK Received, MF state = DNIS
Digit Transmitted, MF Group = Forward Group I, CAS = 0x0C
DNIS = 04166219450, ANI = , MF = 0x46
anexo configuraci?n del chan_dahdi
[channels]
echocanceller=yes
echocancelwhenbridged=yes
;################################### Entrantes
############################################
group=2
echocancel=yes
context= e1-incoming
Channel => 1-15,17-31,32-46,48-62
signalling=mfcr2
mfcr2_variant=ve
mfcr2_dtmf_detection=1
mfcr2_dtmf_dialing=1
mfcr2_get_ani_first=yes
mfcr2_immediate_accept=yes
mfcr2_max_ani=10
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_skip_category=yes
mfcr2_logdir=cantv
mfcr2_logging=all
mfcr2_mfback_timeout=-1
mfcr2_call_files=yes
;################################# Salientes
#############################################
group=1
echocancel=yes
context= e1-out
Channel => 63-77,79-93,94-108,110-124
mfcr2_variant=ve
signalling=mfcr2
mfcr2_dtmf_detection=1
mfcr2_dtmf_dialing=1
mfcr2_get_ani_first=no
mfcr2_immediate_accept=yes
mfcr2_max_ani=10
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_skip_category=yes
mfcr2_logdir=cantv
mfcr2_logging=all
mfcr2_mfback_timeout=-1
mfcr2_call_files=yes
cualquier informaci?n q me puedes aportar, seria de gran utilidad, de
antemano te agradezco todo lo que puedas hacer
--
Ing. Domingo gil
Asamblea Nacional
Direcci?n de Tecnolog?a de Informaci?n
Divisi?n de Soporte T?cnico
Tlfs. 409-79-18
M?vil. 0416-621-94-50
0412-3500-140
--
Ing. Domingo gil
Asamblea Nacional
Direcci?n de Tecnolog?a de Informaci?n
Divisi?n de Soporte T?cnico
Tlfs. 409-79-18
M?vil. 0416-621-94-50
0412-3500-140
--
Ing. Domingo gil
Asamblea Nacional
Direcci?n de Tecnolog?a de Informaci?n
Divisi?n de Soporte T?cnico
Tlfs. 409-79-18
M?vil. 0416-621-94-50
0412-3500-140
------------------------------
Message: 2
Date: Tue, 10 May 2011 19:47:37 -0500
From: Sebastian Peschko <speschko at gmail.com>
Subject: [asterisk-r2] mfcr2_metering_pulse_timeout no difference;
outgoing calls being dropped
To: asterisk-r2 at lists.digium.com
Message-ID: <1305074857.3338.30.camel at webmaster-laptop>
Content-Type: text/plain; charset="utf-8"
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-r2/attachments/20110510/244f61f7
/attachment-0001.htm>
------------------------------
Message: 3
Date: Tue, 10 May 2011 23:48:09 -0400
From: Moises Silva <moises.silva at gmail.com>
Subject: Re: [asterisk-r2] mfcr2_metering_pulse_timeout no difference;
outgoing calls being dropped
To: speschko at gmail.com, asterisk-r2 at lists.digium.com
Message-ID: <BANLkTimmDJ5gcOzUY21kd0-EbFz5t6LeAg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/20110510/1f75af7b
/attachment-0001.htm>
------------------------------
Message: 4
Date: Tue, 10 May 2011 22:59:57 -0500
From: Anton Krall <antonkrall at gmail.com>
Subject: Re: [asterisk-r2] mfcr2_metering_pulse_timeout no difference;
outgoing calls being dropped
To: asterisk-r2 at lists.digium.com
Message-ID: <A1938DBA-A0FE-4EE2-9A2C-F5765026EE26 at gmail.com>
Content-Type: text/plain; charset="us-ascii"
I havent experienced this but anybody else from MX having this issues with
telmex?
On 10/05/2011, at 22:48, 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
>
> --
> _____________________________________________________________________
> -- 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/20110510/426e2a03
/attachment.htm>
------------------------------
_______________________________________________
--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
End of asterisk-r2 Digest, Vol 33, Issue 3
******************************************
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the asterisk-r2
mailing list