[asterisk-r2] chan_dahdi Trying to dial out in a non-idle channel (cas=0x0C)

[Josue _]

Solved!

 

The problem was the damn balun that converts from G.703 to RJ45

 

Telmex did sent a guy, and we had to use a different pair of coax to probe the line so I start suspecting that maybe somenthing where wrong with coax.

 

I just change it and voila, problem solved. For some reason the interface seemed fine (it was green) and the "cat" on /proc/zaptel/ also seemed fine like telco where blocking its end... really weird problem this balun.

 

Eitherwa problem is solved now.

 

Thank you for all your support.

 


 


Date: Sat, 28 Nov 2009 01:07:35 -0500
From: moises.silva at gmail.com
To: asterisk-r2 at lists.digium.com
Subject: Re: [asterisk-r2] chan_dahdi Trying to dial out in a non-idle channel (cas=0x0C)




And the output of the command chaged, for worse I guess :(




No exactly. Is actually worst to have 0x0C or any other hexadecimal value, because that means openr2 bit states got screwed somehow. So, it's "better" to have a consistent "BLOCKED".


Try using dahdi_tool or zttool, select the span and see what are the Rx bits. If the Rx bits are 1101, that means Telmex has blocked your line.


Between the time I sent my past e-mail and the time you replied, 2 hours elapsed, and was around 9pm Mexico City. Did telmex really sent a technician at that time? my guess is that when the technician was at your site (probably earlier) the line was OK but now is blocked. 
 

What changed:
TE_CLOCK       = 
was NORMAL now is MASTER



If this is a regular Telmex E1, this should be NORMAL, not MASTER, which is used when the other end clock is a slave to you.
 

TDMV_DCHAN      = 
was 0 now is 16



Not much difference. But 0 is preferred, otherwise, probably HDLC interrupts will be wasting resources.


 -- 
Moises Silva
Software Developer
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada
t. 1 905 474 1990 x 128 | e. moy at sangoma.com
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-r2/attachments/20091128/0de4750b/attachment.htm