[Bristuff-users] Problem

[François Delawarde]

Hello Tzafrir, and thanks for rapid answer.

Tzafrir Cohen wrote:
> On Mon, Dec 03, 2007 at 05:49:18PM +0100, François Delawarde wrote:
>   
>> Hello again,
>>
>> I have a small problem using bristuff-0.4.0-test4-xr3 on Asterisk 1.4.13 
>> and zaptel 1.4.6, with a phonicEQ four port BRI card (qozap driver) 
>> plugged in Spanish RDSI lines (ISDN).
>>
>> I more or less randomly (sometimes 3 times a day, sometimes once per 
>> week) get messages like these on a span (usually with span 1 or 3, that 
>> are more used, but it sometimes happens with others as well):
>> [Dec  3 15:49:06] VERBOSE[8677] logger.c:   == Primary D-Channel on span 
>> 1 down
>>     
>
> You use PtP rather than PtMP signalling. Bristuff's chan_zap does not
> supress that message for ptp spans. Not sure why. Having the span down
> most of the time is common with many BRI providers. Maybe also when
> ptp is used.
>
>   

Thanks for suggestion, I had signalling=bri_cpe, and changed it to 
signalling=bri_cpe_ptmp, I'll check if it works better.

>> When I try to make a call through the "downed" span, I get this, which 
>> sound kind of logical when a span is down:
>> [Dec  3 15:53:40] WARNING[14889] app_dial.c: Unable to create channel of 
>> type 'ZAP' (cause 34 - Circuit/channel congestion)
>>
>> Meanwhile, I still get incoming calls from that span!!, 
>>     
>
> When calls come in, is the span temporarily up?
>   

All I know is that at some point the span was showing Up again in "pri 
show spans" (at least until I restarted), but the problem was not 
disappearing (I only had incoming calls from the span). The server is in 
production, so lots of calls and it  might perfectly be that there were 
incoming calls every time I checked that.

> Seems so from the information below.
>
> One very silly guess: try having 'pridialplan=unknown' in zapata.conf .
> Or perperly set up internationalprefix, nationalprefix, etc. This is
> something that can cause outgoing calls to fail.
>   

I have pridialplan=local, nationalprefix=0 and internationalprefix=00, 
and it worked so far. I will test changing those after checking if 
changing signalling to ptmp works or not.


>   
>> and I can still 
>> make calls to other spans without problems. Restarting Asterisk (no need 
>> to reload qozap) makes everything work again, until next time....
>>
>> I tried the intensive debug, which showed me some timeouts at those 
>> moments on t203 and/or t200 timers, restarting the span without success. 
>> The only weird thing was a window value of "-1/7" on "pri show span", 
>> while the other spans have "0/7":
>> *CLI> pri show span 1
>> Primary D-channel: 3
>> Status: Provisioned, Up, Active
>> Switchtype: EuroISDN
>> Type: CPE
>> Window Length: -1/7
>> Sentrej: 0
>> SolicitFbit: 0
>> Retrans: 0
>> Busy: 0
>> Overlap Dial: -1
>> T200 Timer: 1000
>> T203 Timer: 10000
>> T305 Timer: 30000
>> T308 Timer: 4000
>> T309 Timer: -1
>> T313 Timer: 4000
>> N200 Counter: 3
>>
>> I really don't know what's happening (actually, I don't even know what a 
>> "Window Length" is...), but I could use some help to find a cure or at 
>> least some workaround (right know, if HANGUPCAUSE is 34 I just "restart 
>> when convenient"....).
>>     

Is that "Window Length" at -1 an issue at all?

Thanks,
François.