hice las pruebas, quite el cancelador de eco y ademas el mfcr2_get_ani_first=yes. ejo el log de la ultima llamada donde tuve el problema<div><br></div><div><div>[Jan 26 11:22:21] VERBOSE[6072] chan_dahdi.c: MFC/R2 call has been accepted on forward channel 1</div>
<div>[Jan 26 11:22:33] DEBUG[6072] chan_dahdi.c: bits changed in chan 1</div><div>[Jan 26 11:22:33] DEBUG[6072] chan_dahdi.c: Chan 1 - Bits changed from 0x0C to 0x04</div><div>[Jan 26 11:22:33] DEBUG[6072] chan_dahdi.c: Chan 1 - CAS Rx << [ANSWER] 0x04</div>
<div>[Jan 26 11:22:33] VERBOSE[6072] chan_dahdi.c: MFC/R2 call has been answered on channel 1</div><div>[Jan 26 11:23:57] DEBUG[6072] chan_dahdi.c: bits changed in chan 1</div><div>[Jan 26 11:23:57] DEBUG[6072] chan_dahdi.c: Chan 1 - Bits changed from 0x04 to 0x0C</div>
<div>[Jan 26 11:23:57] DEBUG[6072] chan_dahdi.c: Chan 1 - CAS Rx << [CLEAR BACK] 0x0C</div><div>[Jan 26 11:23:57] VERBOSE[6072] chan_dahdi.c: Chan 1 - Far end disconnected. Reason: Normal Clearing</div><div>[Jan 26 11:23:57] VERBOSE[6072] chan_dahdi.c: MFC/R2 call disconnected on channel 1</div>
<div>[Jan 26 11:23:57] DEBUG[6072] chan_dahdi.c: disconnecting MFC/R2 call on chan 1</div><div>[Jan 26 11:23:57] DEBUG[6072] chan_dahdi.c: ast cause 16 resulted in openr2 cause 6/Normal Clearing</div><div>[Jan 26 11:23:57] DEBUG[6072] chan_dahdi.c: Chan 1 - CAS Tx >> [CLEAR FORWARD] 0x08</div>
<div>[Jan 26 11:23:57] DEBUG[6072] chan_dahdi.c: Chan 1 - CAS Raw Tx >> 0x09</div><div>[Jan 26 11:23:57] VERBOSE[6072] chan_dahdi.c: -- Hungup 'DAHDI/1-1'</div><div>[Jan 26 11:23:57] DEBUG[6002] chan_dahdi.c: Chan 1 - Bits changed from 0x0C to 0x08</div>
<div>[Jan 26 11:23:57] DEBUG[6002] chan_dahdi.c: Chan 1 - CAS Rx << [IDLE] 0x08</div><div>[Jan 26 11:23:57] DEBUG[6002] chan_dahdi.c: Chan 1 - Call ended</div><div>[Jan 26 11:23:57] DEBUG[6002] chan_dahdi.c: Chan 1 - CAS Tx >> [IDLE] 0x08</div>
<div>[Jan 26 11:23:57] DEBUG[6002] chan_dahdi.c: Chan 1 - CAS Raw Tx >> 0x09</div><div>[Jan 26 11:23:57] VERBOSE[6002] chan_dahdi.c: MFC/R2 call end on channel 1</div></div><div><br></div><div>resalto que la señal de chan_dahdi.c: Chan 1 - CAS Rx << [CLEAR BACK] 0x0C se recibe solo cuando efectivamente el otro extremo cuelga, por lo que veo el intercambio de CAS continua. aun cuando la linea queda en silencio, luego que me da el problema ya mencionado. me dan los siguientes errores cuando intento marcar de nuevo</div>
<div><br></div><div>Chan 1 - Protocol error. Reason = Seize Timeout, R2 State = Seize Transmitted, MF state = MF Engine Off, MF Group = </div><div><br></div><div>por unos dos minutos, es como un delay en liberar el canal aunque en el "mfcr2 show channels" lo veo en Idle</div>
<div><br><br><div class="gmail_quote">2011/1/26 <span dir="ltr"><<a href="mailto:ettore.pelliccioni@techniclite.com">ettore.pelliccioni@techniclite.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hola, no parece ser problema de las interrupciones, tambien me inclinaria por la trama, aunque a nivel de servidor no reporta errores, trata de solicitarles que conecten un analizador de protocolo r2 , como el pa41 a ver si se observa algo mas.<br>
<br>
Trata de enviar el log de r2 de una llamada con problemas (para ver la seÑalizacion)<br>
<br>
Unas flechas que probaria seria:<br>
<br>
Desactivar la cancelacion de eco.<br>
Activar el mfcr2_get_ani_first=yes<br>
<br>
Saludos.<br>
<div class="im">tentamente,<br>
Ing. Ettore Eliseo Pelliccioni Monrroy <br>
<br>
Tlf.:+58.212.7626555<br>
Móvil:+58.414.1111330<br>
Skype:ettore.pelliccioni<br>
eMail/msn: <a href="mailto:ettore.pelliccioni@techniclite.com">ettore.pelliccioni@techniclite.com</a><br>
Web site: <a href="http://www.techniclite.com" target="_blank">www.techniclite.com</a><br>
<br>
<br>
This message may contain confidential information or privileged material, and is intended only for the individual(s) named. If you are not in the named address you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.<br>
E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. <br>
<br>
-----Original Message-----<br>
From: jam <<a href="mailto:johans.a@gmail.com">johans.a@gmail.com</a>><br>
Sender: <a href="mailto:asterisk-r2-bounces@lists.digium.com">asterisk-r2-bounces@lists.digium.com</a><br>
</div><div><div></div><div class="h5">Date: Wed, 26 Jan 2011 09:19:09<br>
To: <<a href="mailto:asterisk-r2@lists.digium.com">asterisk-r2@lists.digium.com</a>><br>
Reply-To: <a href="mailto:asterisk-r2@lists.digium.com">asterisk-r2@lists.digium.com</a><br>
Subject: Re: [asterisk-r2] OpenR2, Digitel Venezuela, Ruido en las llamadas<br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">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" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">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" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-r2</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>ADS. Johans Angulo.<br>CCNA CSC011350315<br>Telf. 04245440910<br>
</div>