[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1

[Jeff LaCoursiere]

On Sat, 10 Jan 2009, Tzafrir Cohen wrote:

>
> No idea, but the driver is much more aware of the specifics. So maybe
> their driver has extra debugging information for that case.
>
> For starters, have you enabled full debugging in Asterisk? Make sure you
> log 'debug' and set debug to at least 5 . chan_zap / chan_dahdi will at
> least tell you what was the immediate case for the hangup:
>
> * signal from Zaptel (kernel)
> * Some sort of decision of chan_zap
> * Something from the SIP channel
> * Something completely different
>

I turned debugging on to level 10 and have been accumulating logs at the 
speed of light all morning ;)  I haven't trapped the "dropped call" yet, 
but I have been peaking at individual calls to see what extra information 
is available.  For example an outbound call from a SIP extension to a long 
distance number ended like this:

[Jan 12 10:26:22] DEBUG[18302] chan_zap.c: Exception on 9, channel 1
[Jan 12 10:26:22] DEBUG[18302] chan_zap.c: Got event On hook(1) on channel 
1 (index 0)
[Jan 12 10:26:22] VERBOSE[18302] logger.c:     -- Stopped music on hold on 
Zap/1-1
[Jan 12 10:26:22] DEBUG[18302] channel.c: Set channel Zap/1-1 to write 
format ulaw
[Jan 12 10:26:22] DEBUG[18302] channel.c: Scheduling timer at 0 sample 
intervals
[Jan 12 10:26:22] DEBUG[18302] channel.c: Didn't get a frame from channel: 
Zap/1-1
[Jan 12 10:26:22] DEBUG[18302] channel.c: Bridge stops bridging channels 
SIP/2530-b71f9bc8 and Zap/1-1
[Jan 12 10:26:22] DEBUG[18302] channel.c: Hanging up channel 'Zap/1-1'

Would you interpret this as the remote end hanging up first, and the 
Sangoma card detecting the hangup and destroying the bridge?

(looks like someone left this poor guy on hold for six minutes, actually, 
and he finally gave up!)

Thanks,

j