[Home]

Summary:ASTERISK-12734: [patch] mISDN rejects incoming calls
Reporter:Christian Pinedo (christian_pinedo)Labels:
Date Opened:2008-09-16 08:15:23Date Closed:2009-07-13 07:19:34
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_misdn
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) defer_channel_selection.patch.txt
( 1) isdn_lib.patch.txt
( 2) misdn.conf
Description:Asterisk seems to work well but sometimes per day calls from pstn are rejected and outgoing calls cann't be done also. This is the output of a rejected incoming call:

Tue Sep 16 09:58:11 2008: P[ 1]  channel with stid:0 for one second still in use!
Tue Sep 16 09:58:11 2008: P[ 1]  set_channel: bc->channel:0 channel:1
Tue Sep 16 09:58:11 2008: P[ 1]  I IND :NEW_CHANNEL oad:943336600 dad:943445807 pid:23 state:none
Tue Sep 16 09:58:11 2008: P[ 1]   --> channel:1 mode:TE cause:16 ocause:16 rad: cad:
Tue Sep 16 09:58:11 2008: P[ 1]   --> info_dad: onumplan:0 dnumplan:2 rnumplan:  cpnnumplan:0
Tue Sep 16 09:58:11 2008: P[ 1]   --> caps:Speech pi:0 keypad: sending_complete:1
Tue Sep 16 09:58:11 2008: P[ 1]  Chan not existing at the moment bc->l3id:20012 bc:0x81e0374 event:NEW_CHANNEL port:1 channel:1
Tue Sep 16 09:58:11 2008: P[ 1]  NO USERUESRINFO
Tue Sep 16 09:58:11 2008: P[ 1]   !! NO FREE CHAN IN STACK
Tue Sep 16 09:58:11 2008: P[ 1]  Requested Channel Already in Use releasing this call with cause 34!!!!
Tue Sep 16 09:58:11 2008: P[ 1]  I SEND:RELEASE_COMPLETE oad:943336600 dad:943445807 pid:23
Tue Sep 16 09:58:11 2008: P[ 1]   --> channel:0 mode:TE cause:16 ocause:34 rad: cad:
Tue Sep 16 09:58:11 2008: P[ 1]   --> info_dad: onumplan:0 dnumplan:2 rnumplan:  cpnnumplan:0
Tue Sep 16 09:58:11 2008: P[ 1]   --> caps:Speech pi:0 keypad: sending_complete:1
Tue Sep 16 09:58:11 2008: P[ 1]  $$$ CLEANUP CALLED pid:23
Tue Sep 16 09:58:11 2008: P[ 1]  couldn't handle event
Tue Sep 16 09:58:11 2008: P[ 1]  CC_RELEASE_COMPLETE|CONFIRM [TE]
Tue Sep 16 09:58:11 2008: P[ 1]  I IND :RELEASE_COMPLETE oad: dad: pid:23 state:none
Tue Sep 16 09:58:11 2008: P[ 1]   --> channel:0 mode:TE cause:16 ocause:34 rad: cad:
Tue Sep 16 09:58:11 2008: P[ 1]   --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
Tue Sep 16 09:58:11 2008: P[ 1]   --> caps:Speech pi:0 keypad: sending_complete:0
Tue Sep 16 09:58:11 2008: P[ 1]   --> no Ch, so we've already released.
Tue Sep 16 09:58:11 2008: P[ 0]  Cannot hangup chan, no ch
Tue Sep 16 09:58:11 2008: P[ 1]  release_chan: Ch not found!
Tue Sep 16 09:58:11 2008: P[ 1]  $$$ CLEANUP CALLED pid:23
Tue Sep 16 09:58:11 2008: P[ 1]  $$$ CLEANUP CALLED pid:23

It seems that mISDN has the Port 1 (first BRI) in a bad state and network tries to send a new incoming mail through this port. I have to exec "misdn restart port 1" to solve this situation. The rest of BRI links are free and network tries to send the calls always through port 1 because it thinks that is free. mISDN thinks that this port is already used and so all call are rejected.

Software versions:
Debian GNU/Linux 4.0
Kernel 2.6.18
Asterisk 1.4.21.2
Zaptel 1.4.11
mISDN and mISDNuser 1.1.7.2
Comments:By: crich (crich) 2008-09-17 03:04:09

can you please try the latest 1.4 - svn revision (or 1.4.22-rc5)
By: Christian Pinedo (christian_pinedo) 2008-09-17 04:13:35

Today I'm trying Asterisk 1.4.18.1 in order to see if there's the same problem with a previous version of Asterisk/chan_misdn. If the error returns i will try svn version.
By: Christian Pinedo (christian_pinedo) 2008-09-19 03:09:51

Te bug also happens with Asterisk 1.4.18.1 but at the moment I don't know if it's a bug or a issue of the telco provider.

All the problems begin with a RELEASE_COMPLETE frame sent by the provider with CAUSE 44.

Thu Sep 18 13:35:14 2008: P[ 1]  $$$ CLEANUP CALLED pid:481
Thu Sep 18 13:35:14 2008: P[ 1]   --> l3id:1100eb
Thu Sep 18 13:35:14 2008: P[ 1]  **** Received CAUSE:44, so not cleaning up channel 2
Thu Sep 18 13:35:14 2008: P[ 1]   --> cause:44
Thu Sep 18 13:35:14 2008
P[ 1]  **** This channel is now no longer available,
please try to restart it with 'misdn send restart <port> <channel>'
Thu Sep 18 13:35:14 2008: P[ 1]   --> out_cause:44
Thu Sep 18 13:35:14 2008: P[ 1]   --> state:CLEANING
Thu Sep 18 13:35:14 2008: P[ 1]  Sending Restarts on this port.
Thu Sep 18 13:35:14 2008: P[ 1]   --> Channel: mISDN/0-u1169 hanguped new state:CLEANING
Thu Sep 18 13:35:14 2008: P[ 1]  Restarting and cleaning channel 2
Thu Sep 18 13:35:14 2008: P[ 1]  I SEND:RESTART oad: dad: pid:0
Thu Sep 18 13:35:14 2008: P[ 1]   --> channel:2 mode:TE cause:0 ocause:0 rad: cad:
Thu Sep 18 13:35:14 2008: P[ 1]   --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
Thu Sep 18 13:35:14 2008: P[ 1]   --> caps:Speech pi:0 keypad: sending_complete:0
Thu Sep 18 13:35:14 2008: P[ 1]  Restarting channel 2
Thu Sep 18 13:35:14 2008: P[ 1]  $$$ CLEANUP CALLED pid:481
Thu Sep 18 13:35:14 2008: P[ 1]  $$$ CLEANUP CALLED pid:481

Asterisk tries to restart the channel and I don't know if the telco should respond to this frame. In any case, then the provider tries to send incomming calls through this channel when it should use it (for example in this case as the Port 1 channel 1 is used the incoming call is send through the Port 1 channel 2, the problematic channel, instead of using Port 2 channel 1) and asterisk rejects them.

Thu Sep 18 13:35:14 2008: P[ 1]  I IND :NEW_CHANNEL oad:605776041 dad:943444070 pid:482 state:none
Thu Sep 18 13:35:14 2008: P[ 1]   --> channel:2 mode:TE cause:16 ocause:16 rad: cad:
Thu Sep 18 13:35:14 2008: P[ 1]   --> info_dad: onumplan:0 dnumplan:2 rnumplan:  cpnnumplan:0
Thu Sep 18 13:35:14 2008: P[ 1]   --> caps:Speech pi:0 keypad: sending_complete:1
Thu Sep 18 13:35:14 2008: P[ 1]  Chan not existing at the moment bc->l3id:20092 bc:0x81dbd04 event:NEW_CHANNEL port:1 channel:2
Thu Sep 18 13:35:14 2008: P[ 1]  NO USERUESRINFO
Thu Sep 18 13:35:14 2008: P[ 1]   !! NO FREE CHAN IN STACK
Thu Sep 18 13:35:14 2008: P[ 1]  Any Channel Requested, but we have no more!!
Thu Sep 18 13:35:14 2008: P[ 1]  I SEND:RELEASE_COMPLETE oad:605776041 dad:943444070 pid:482
Thu Sep 18 13:35:14 2008: P[ 1]   --> channel:2 mode:TE cause:16 ocause:34 rad: cad:
Thu Sep 18 13:35:14 2008: P[ 1]   --> info_dad: onumplan:0 dnumplan:2 rnumplan:  cpnnumplan:0
Thu Sep 18 13:35:14 2008: P[ 1]   --> caps:Speech pi:0 keypad: sending_complete:1
Thu Sep 18 13:35:14 2008: P[ 1]  $$$ CLEANUP CALLED pid:482
Thu Sep 18 13:35:14 2008: P[ 1]  couldn't handle event
Thu Sep 18 13:35:14 2008: P[ 1]  CC_RELEASE_COMPLETE|CONFIRM [TE]
Thu Sep 18 13:35:14 2008: P[ 1]  I IND :RELEASE_COMPLETE oad: dad: pid:482 state:none
Thu Sep 18 13:35:14 2008: P[ 1]   --> channel:0 mode:TE cause:16 ocause:34 rad: cad:
Thu Sep 18 13:35:14 2008: P[ 1]   --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
Thu Sep 18 13:35:14 2008: P[ 1]   --> caps:Speech pi:0 keypad: sending_complete:0
Thu Sep 18 13:35:14 2008: P[ 1]   --> no Ch, so we've already released.
Thu Sep 18 13:35:14 2008: P[ 0]  Cannot hangup chan, no ch
Thu Sep 18 13:35:14 2008: P[ 1]  release_chan: Ch not found!
Thu Sep 18 13:35:14 2008: P[ 1]  $$$ CLEANUP CALLED pid:482
Thu Sep 18 13:35:14 2008: P[ 1]  $$$ CLEANUP CALLED pid:482
Thu Sep 18 13:35:27 2008: P[ 1]  set_channel: bc->channel:0 channel:2

Asterisk also tries to send outgoing calls through this channel when Port 1 Channel 1 is used and these calls also cann't be carried out.

We have 7 bri in a misdn group but when one channel receives CAUSE 44 (incoming and outgoing) calls try to be done through this channel, they cann't be done and the upper channels (channels of 2, 3, 4, 5, 6, 7 BRI) are free and not used.
By: crich (crich) 2008-09-19 03:41:04

Yeah, that's a general problem. If one side thinks that a channel is in use and the other side thinks its free.. those kinds of calls can create blocking channels.

such a "deadlock" like channel will later on be used, because at least one side keeps thinking its free..

I wonder why the provider has sent us a Cause = 44, this should have to do with one of our setups earlier before.

You can try to use "method=standard_dec" so that chan_misdn starts choosing free channels from the upper ports.. hopefully the telco provider chooses free channels from the lower ports, that a collision is less likely.

also please let me know what happens if you try latest svn.
By: Christian Pinedo (christian_pinedo) 2008-09-19 03:59:59

In order to know the reason of the Cause = 44 yesterday I opened an issue with the telco and I sent logs to them. I hope to have some input these days (line problems, bad ISDN signalling, ...). I will tell you.

I will probe "method=standard_dec". I didn't know it exists because it doesn't appear in the misdn.conf example configuration file.

Regarding to try the lates svn code I don't know if I will be able to. The Asterisk server is "at production" and I wouldn't like to add more troubles.
By: crich (crich) 2008-09-19 08:35:08

i meant Asterisk 1.4 - svn
By: Christian Pinedo (christian_pinedo) 2008-09-19 09:47:06

Ok. I'll try it.

The Cause = 44 frames comes from Port 1. Today I have switch off the cable of the Port 1 and we have until now no errors. If it continues well the error could be related with the port 1 (line, cord, card, ...)

There is something that I don't understand. If Asterisk thinks that channel 2 of port 1 is unavailable but Network thinks it's available, it's clear that Network will try to use that port and Asterisk will refuse. But if I have defined a mISDN group and if I call through the group and Asterisk knows that the channel is unavailable, why do Asterisk/misdn try to use it? Could be similar to unavailability due to L2 being down that it's necessary to use misdn_check_l1l2 application?
By: Christian Pinedo (christian_pinedo) 2008-09-22 07:10:47

Asterisk 1.4-svn has the same problem, Network sends cause 44 RELEASE_COMPLETE frames and from that moment channel is "blocked".

Cause 44 frames cames also from other BRI ports like port 3, so it isn't something limited to port 1.

I have proved some things:
* "misdn send restart 3", didn't solve the problem
* "misdn send restart 3 1", (command that is raised automatically after receiving a cause 44 frame) didn't solve the problem
* "misdn restart port 3", SOLVED the problem.

In other place, "method=standard_dec" doesn't seem to work fine. Outgoing calls don't begin using 7th BRI, they use the initial BRIs. I will change the cable connections between B410P card and the telco's interface to get out outgoing calls through first interface of the first card and get the incomming calls beginning by the 4th interface of the first card (the second card has 3 BRI). Then I will can determine if the cause 44 frames are reduced and if they are related with conflict between incoming and outgoing calls trying to use the same channel.
By: Christian Pinedo (christian_pinedo) 2008-09-29 05:31:40

I don't see in the logs any RESTART ACKNOWLEDGE that should be sent by the network and only then Asterisk should restart the channel/port. It seems that Asterisk restarts the channel immediately sent RESTART frame without waiting the acknowledge. I don't know anything about ISDN but could this produce inconsistencies between network and asterisk?
By: crich (crich) 2008-09-29 06:10:24

Are you talking about the initial RESTART Procedure from chan_mISDN?

chan_mISDN sends out RESTART Messages when it is loaded, because asterisk could have been crashed earlier and therefore there could be some inconsistency between chan_mISDN and the network.

The network shall then send us RESTART_ACKNOWLEDGES, but i think they are caught by the L3 layer of the mISDN kernel modules, that's why you don't see them in the misdn debug.

The only way to get a "real" trace of the situation is to use the mISDN_debugtool, with that you can create a wireshark readable trace. If you like to try this see how it works on www.misdn.org.
By: Christian Pinedo (christian_pinedo) 2008-09-29 06:53:03

No. I was talking about the RESTART message sent automatically after receiving a cause:44 RELEASE COMPLETE.

I talked with telco and they think that cause 44 is sent because the requested channel for the outgoing call is going to be used by the network for an incoming call (although network haven't still sent the SETUP message). We think so because the outgoing call is refused with cause 44 and then immediately, in the same second, an incoming call is proceeded by the same port. This incoming call is rejected by chan_misdn because it thinks the channel is not available. Between these rejected calls there is a RESTART request sent by Asterisk.

I will try mISDNdebugtool to see RESTART and RESTART ACKNOWLEDGE messages. Thanks.
By: Jasper Siepkes (siepkes) 2008-10-03 09:51:01

I can confirm this issue with the following setup:

Telco: KPN
Debian Etch Linux: 2.6.18-6-686 #1 SMP i686 GNU/Linux
Asterisk Version: 1.4.21.2
zaptel: 1.4.9.2
mISDN(user): 1.1.3
By: crich (crich) 2008-10-06 10:11:15

Christian_Pinedo:

This is exactly the problematic situation. I have once debugged it with the debugtool and could see that the 2 SETUPs where so closely in time, that both stacks (NT and TE) thought this channel was free..
By: Ricardo Peironcely (rpr) 2008-10-24 04:20:41

I can confirm this issue too.

Telco: Telefonica de España
OpenSuSE 10.3 2.6.23.17-default #3 SMP
Asterisk  1.4.21.2
Zaptel 1.4.11
mISDN 1.1.8

Thu Oct 23 04:18:22 2008: P[ 1]  channel with stid:0 for one second still in use!
Thu Oct 23 04:18:22 2008: P[ 1]  Requested Channel Already in Use releasing this call with cause 34!!!!
Thu Oct 23 04:18:22 2008: P[ 1]  couldn't handle event
Thu Oct 23 04:18:22 2008: P[ 1]  CC_RELEASE_COMPLETE|CONFIRM [TE]
By: Jon Bonilla (manwe) 2008-10-28 04:54:02

Confirmed in two other installations:

Telco: Telefónica España
Debian 4.0
Asterisk 1.4.21.1
Zaptel 1.4.11
mISDN 1.1.7.2
By: Christian Pinedo (christian_pinedo) 2008-10-28 06:17:58

I'm running mISDNdebugtool in the server to capture ISDN packets but I'm not having the problem again. It would be nice if you can use the mISDNdebugtool in your buggy installations.

This is my theory. When network rejects a call with cause 44, mISDN sends RESTART and reinits the port. I cann't see any RESTART ACKNOWLEDGE send by the network in logs of mISDN (so to be sure it's interesting to use mISDNdebugtool as proposed crich). The port should be reinited only after receiving the RESTART ACKNOWLEDGE. I think mISDN could be reinitting the port without the ACKNOWLEDGE of the network (this could cause inconsistencies between network and mISDN). If mISDN accepts a rejected call with cause 44 without trying RESTART and releasing state, perhaps the following incoming calls from the network would be processed fine in the port.
By: Giannis Kontogounis (tsampouros) 2008-10-28 15:32:14

I am having this issue since I upgraded asterisk from 1.4.18 to 1.4.22-rc5 and mISDN from 1.1.6 to 1.1.7, keeping configuration same, in a 2xBRI port installation.
Blocks BRI port 2-3 times per day and rejects incoming calls on that port.

Asterisk: 1.4.22-rc5
mISDN: (1_1_7_2) revision ($Revision: 1.40 $)
(Telco: Greece OTE, Worked fine with previous asterisk version, no port blocked during 5 months)

It seems misdn sends channel RESTART but does not seem to work the way it is sent.
The proposed channel restart 'misdn send restart <port> <channel>' does not seem to work when port is blocked and throws cause 34, I figured the only way to restart port is by sending 'misdn restart port <port>'.

Mon Oct 27 00:00:06 2008: P[ 0]  -- mISDN Channel Driver Registered --
Mon Oct 27 10:34:35 2008: P[ 2]  GOT IGNORE SETUP
Mon Oct 27 10:34:35 2008: P[ 2]  CC_RELEASE_COMPLETE|CONFIRM [TE]
Mon Oct 27 10:36:45 2008: P[ 2]  GOT IGNORE SETUP
Mon Oct 27 10:36:45 2008: P[ 2]  CC_RELEASE_COMPLETE|CONFIRM [TE]
Mon Oct 27 10:45:19 2008: P[ 2]  **** Received CAUSE:44, so not cleaning up channel 1
Mon Oct 27 10:45:19 2008: P[ 2]  **** This channel is now no longer available,
please try to restart it with 'misdn send restart <port> <channel>'
Mon Oct 27 10:45:19 2008: P[ 2]  Sending Restarts on this port.
Mon Oct 27 10:45:19 2008: P[ 2]  Restarting and cleaning channel 1
Mon Oct 27 10:45:19 2008: P[ 2]  Restarting channel 1
Mon Oct 27 11:02:43 2008: P[ 2]  Requested Channel Already in Use releasing this call with cause 34!!!!
Mon Oct 27 11:02:43 2008: P[ 2]  couldn't handle event
Mon Oct 27 11:02:43 2008: P[ 2]  CC_RELEASE_COMPLETE|CONFIRM [TE]
Mon Oct 27 11:04:12 2008: P[ 2]  Requested Channel Already in Use releasing this call with cause 34!!!!
Mon Oct 27 11:04:12 2008: P[ 2]  couldn't handle event


By: owlnebula (owlnebula) 2008-11-13 22:36:00.000-0600

I can confirm this issue too.

Telco: China Telecom
CentOS5 2.6.18.92
server: HP 350
Asterisk 1.4.21.2
Zaptel 1.4.11
mISDN 1.1.8

Fri Nov  7 12:51:04 2008: P[ 1]  channel with stid:0 for one second still in use!
Fri Nov  7 12:51:04 2008: P[ 1]  Requested Channel Already in Use releasing this call with cause 34!!!!
Fri Nov  7 12:51:04 2008: P[ 1]  couldn't handle event
Fri Nov  7 12:51:04 2008: P[ 1]  CC_RELEASE_COMPLETE|CONFIRM [TE]
By: Jon Bonilla (manwe) 2008-11-18 05:07:10.000-0600

Another one.
Telco: Euskaltel
Debian Etch
server HP 320 g5
Asterisk 1.4.21.1
Zaptel 1.4.11
mISDN 1.1.7.2

P[ 1] channel with stid:0 for one second still in use!
P[ 1] Requested Channel Already in Use releasing this call with cause 34!!!!
P[ 1] couldn't handle event
P[ 1] CC_RELEASE_COMPLETE|CONFIRM [TE]
   -- Remote UNIX connection disconnected
P[ 1] channel with stid:0 for one second still in use!
P[ 1] Requested Channel Already in Use releasing this call with cause 34!!!!
P[ 1] couldn't handle event
P[ 1] CC_RELEASE_COMPLETE|CONFIRM [TE]
By: crich (crich) 2008-11-20 03:25:16.000-0600

I was thinking a lot about this issue and came to the conclusion, that chan_mISDN is not using good values for the channel Information Element.

There are 3 Possibilities to propose a channel in a SETUP Message in ISDN:

1) Propose a channel exclusively
2) Propose a channel, but accepting alternatives
3) Propose no channel at all (Any Channel)

chan_mISDN implements the following:

NT-Mode: Channel-Mode 1) is used everytime
TE-Mode (PTP): Channel-Mode 1) is used everytime
TE-Mode (PMP): Channel-Mode 3) is used everytime

The problem here is that channel Mode 1) is also used by the telco switches, so when chan_mISDN exclusively requests a channel too, it might collide with the Providers channel Selection.

A much better way to select a channel would be Mode 2 and 3 in TE Mode and Mode 1 in NT Mode. Then the NT would be the final Master for the channel selection and collisions wouldn't happen at all.

To implement this mechanism a lot of work has to be done in the isdn_lib.c where chan_mISDN implements the cannel selection. The places where the functions find_free_chan_in_stack() and empty_chan_in_stack() are called and the channel IE decoding/coding function calls are affected.

I won't be able to handle this in a quick timeframe :/
By: Ricardo Peironcely (rpr) 2008-11-21 20:05:27.000-0600

Workaround while the base problem is solved:

I'm running Simple Event Correlator (http://kodu.neti.ee/~risto/sec/) monitorin misdn.log to restart port when error occurs.

file asteriskMisdnChannelBlocked.conf:

  type=SingleWithSuppress
  ptype=RegExp
  pattern=\S+\s+\S+\s+\d+\s+\S+\s+\S+\s+P\[\s+(\d)\]\s+Requested Channel Already in Use
  desc=$0
  action=shellcmd /usr/sbin/asterisk -r -x "misdn restart port $1"
  window=20

run sec:
  /usr/bin/perl -w /usr/local/bin/sec.pl -conf=asteriskMisdnChannelBlocked.conf -input=/var/log/asterisk/misdn.log
By: Giannis Kontogounis (tsampouros) 2008-11-22 03:21:30.000-0600

Changed back to mISDN 1.1.6 from 1.1.7 and problem is eliminated.

mISDN now restarts the port and does not throw "Requested Channel Already in Use releasing this call with cause 34!!!!" message. Incoming calls are not blocked.

Thu Nov 20 20:55:52 2008: P[ 2]  CC_RELEASE_COMPLETE|CONFIRM [TE]
Fri Nov 21 12:17:49 2008: P[ 2]  **** Received CAUSE:44, so not cleaning up channel 1
Fri Nov 21 12:17:49 2008: P[ 2]  **** This channel is now no longer available,
please try to restart it with 'misdn send restart <port> <channel>'
Fri Nov 21 12:17:49 2008: P[ 2]  Sending Restarts on this port.
Fri Nov 21 12:17:49 2008: P[ 2]  Restarting and cleaning channel 1
Fri Nov 21 12:17:49 2008: P[ 2]  Restarting channel 1
Fri Nov 21 12:19:58 2008: P[ 2]  Any Channel Requested, but we have no more!!
Fri Nov 21 12:19:58 2008: P[ 2]  couldn't handle event
Fri Nov 21 12:19:58 2008: P[ 2]  CC_RELEASE_COMPLETE|CONFIRM [TE]
By: Christian Pinedo (christian_pinedo) 2008-11-27 05:07:15.000-0600

tsampouros, have you changed the asterisk version? Until now I though that the problem was more related to chan_misdn than to misdn.
By: Jasper Siepkes (siepkes) 2008-11-27 05:15:36.000-0600

I can not confirm tsampouros' report.

I'm using the latest mISDN version with no problems with Asterisk 1.4.17. However if I upgrade Asterisk the problems as described in this bug report start to surface. Downgrading mISDN has no effect for me whatsoever. So IMHO the problem is indeed more related to chan_misdn.
By: Giannis Kontogounis (tsampouros) 2008-11-27 16:48:23.000-0600

You are right, I forgot to mention that I also downgraded to asterisk 1.4.18 from 1.4.22.
I thought that it had to do with misdn but it seems to be related to chan_misdn version from what you have tested.
By: owlnebula (owlnebula) 2008-11-30 06:57:43.000-0600

my fixed implement.
this bug is bring on deadlock, lt appears to me that...

chan_misdn.c:
static void update_name(struct ast_channel *tmp, int port, int c)
{
...
/*****************************************************/
ast_string_field_build(tmp, name, "%s/%d-%d",
misdn_type, port,c) ; /*, glob_channel++);*/

***the modified is to avoid the chan->name changed in this session.

isdn_lib.c:
static int find_free_chan_in_stack(struct misdn_stack *stack, struct misdn_bchannel *bc, int channel, int dec)
{
'''
/******************************************************/
channel--;
bnums=stack->pri?stack->b_num:stack->b_num-1;
if( channel < 0 && !dec ){
dec = 1;
}
***the modified is to set the E1 outgoing to task from last solt.

expect perfection implement.
By: Martin Vit (festr) 2009-01-26 04:59:31.000-0600

I'm confirming this issue on some installations. Using mISDN 1.1.8 and asterisks 1.4.21 and 1.4.22.

On the same installation it starts from upgrading Asterisk 1.2 to 1.4  and mISDN 1.1.6 to 1.1.8.

mISDN log: **** Received CAUSE:44, so not cleaning up channel 1

The probability of this error rises on peaks.
By: crich (crich) 2009-02-05 04:30:14.000-0600

I was thinking that a very simple fix, could be that we send out SETUPs only with the "ANY CHANNEL" B-Channel Identification Info Element. This could possibly resolve the occurence of a cause:44.

Please try the above patch, if this works i would make the channel-id selection configurable.
By: Martin Vit (festr) 2009-02-05 06:01:46.000-0600

i've looked at the patch and if I understand it right, you are extending IF check to stack->pri which is releated to ISDN30 equipments? How this affects ISDN2? (I did not mentioned that I've issues on ISDN2 (HFC PCI) cards.
By: Jasper Siepkes (siepkes) 2009-02-05 06:08:18.000-0600

For completeness sake: I'm also experiencing this issue with ISDN2 (Digium B410P PCI Card - Quad ISDN2) in TE modus.
By: crich (crich) 2009-02-05 07:24:47.000-0600

This patch is intended to change the behaviour in the ISDN2 (BRI) case.  We simply request "Any Channel" when we're NOT PRI. this should avoid SETUP collisions with the same channel id.
By: Martin Vit (festr) 2009-02-05 07:42:24.000-0600

ok, so for testers: te_choose_channel must be no, right?

Also, is there way how to not block channel/port when receive 44? Because if this is temporary there is no way how to automatically reset port. We have to check it in periods and reset port manually. Or am I wrong?

edit: i've recompiled with patch and uploaded on one production system. It can take week to proove it helped.


By: crich (crich) 2009-02-05 08:32:19.000-0600

right te_choose_channel needs to be no (and is no as default), there is no unblock for channels yet (if you done take "misdn restart port" into account).
By: crich (crich) 2009-02-13 14:25:40.000-0600

any news on this? did the fix help you?
By: Martin Vit (festr) 2009-02-13 15:52:44.000-0600

I've not seen NO FREE chan since 02-05-2009 but please, let this open for another week, because on our systems this issue occurs sometimes every day but sometimes after several days.

Christian_Pinedo: have you tried the patch?
By: crich (crich) 2009-02-20 05:15:46.000-0600

festr, did it happen again? If not and if no other harm happened, i think the patch is not harmful at all. I've tested this one at some of our customers machines and it seems to work, so i think it's safe to commit it.
By: Martin Vit (festr) 2009-02-20 06:48:35.000-0600

Ok, it is 2 weeks and system is without single non free chan. It works. Thanks Crich!
By: Jasper Siepkes (siepkes) 2009-02-20 06:52:38.000-0600

Same here, no problems whatsoever.

I only tested it for a couple of days but with my setup it usually didn't take more then a day for the error to surface.
By: Thomas Stein (himbeere) 2009-03-17 02:03:22

Uhm. Patch not included in 1.4.24 release?
By: Digium Subversion (svnbot) 2009-03-30 15:38:12

Repository: asterisk
Revision: 185120

U   branches/1.4/channels/misdn/isdn_lib.c

------------------------------------------------------------------------
r185120 | rmudgett | 2009-03-30 15:38:11 -0500 (Mon, 30 Mar 2009) | 19 lines

Make chan_misdn BRI TE side normally defer channel selection to the NT side.

Channel allocation collisions are not handled by chan_misdn very well.
This patch simply avoids the problem for BRI only.

For PRI, allocation collisions are still possible but less likely since
there are simply more channels available and each end could use a different
allocation strategy.

misdn.conf options available:
te_choose_channel - Use to force the TE side to allocate channels.
method - Specify the channel allocation strategy.

(closes issue ASTERISK-12734)
Reported by: Christian_Pinedo
Patches:
     isdn_lib.patch.txt uploaded by crich
Tested by: crich, siepkes, festr

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=185120
By: Digium Subversion (svnbot) 2009-03-30 15:41:25

Repository: asterisk
Revision: 185122

_U  trunk/
U   trunk/channels/misdn/isdn_lib.c

------------------------------------------------------------------------
r185122 | rmudgett | 2009-03-30 15:41:25 -0500 (Mon, 30 Mar 2009) | 26 lines

Merged revisions 185120 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r185120 | rmudgett | 2009-03-30 15:38:11 -0500 (Mon, 30 Mar 2009) | 19 lines
 
 Make chan_misdn BRI TE side normally defer channel selection to the NT side.
 
 Channel allocation collisions are not handled by chan_misdn very well.
 This patch simply avoids the problem for BRI only.
 
 For PRI, allocation collisions are still possible but less likely since
 there are simply more channels available and each end could use a different
 allocation strategy.
 
 misdn.conf options available:
 te_choose_channel - Use to force the TE side to allocate channels.
 method - Specify the channel allocation strategy.
 
 (closes issue ASTERISK-12734)
 Reported by: Christian_Pinedo
 Patches:
       isdn_lib.patch.txt uploaded by crich
 Tested by: crich, siepkes, festr
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=185122
By: Digium Subversion (svnbot) 2009-03-30 15:46:24

Repository: asterisk
Revision: 185124

_U  branches/1.6.0/
U   branches/1.6.0/channels/misdn/isdn_lib.c

------------------------------------------------------------------------
r185124 | rmudgett | 2009-03-30 15:46:24 -0500 (Mon, 30 Mar 2009) | 33 lines

Merged revisions 185122 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r185122 | rmudgett | 2009-03-30 15:41:24 -0500 (Mon, 30 Mar 2009) | 26 lines
 
 Merged revisions 185120 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r185120 | rmudgett | 2009-03-30 15:38:11 -0500 (Mon, 30 Mar 2009) | 19 lines
   
   Make chan_misdn BRI TE side normally defer channel selection to the NT side.
   
   Channel allocation collisions are not handled by chan_misdn very well.
   This patch simply avoids the problem for BRI only.
   
   For PRI, allocation collisions are still possible but less likely since
   there are simply more channels available and each end could use a different
   allocation strategy.
   
   misdn.conf options available:
   te_choose_channel - Use to force the TE side to allocate channels.
   method - Specify the channel allocation strategy.
   
   (closes issue ASTERISK-12734)
   Reported by: Christian_Pinedo
   Patches:
         isdn_lib.patch.txt uploaded by crich
   Tested by: crich, siepkes, festr
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=185124
By: Digium Subversion (svnbot) 2009-03-30 15:50:01

Repository: asterisk
Revision: 185126

_U  branches/1.6.1/
U   branches/1.6.1/channels/misdn/isdn_lib.c

------------------------------------------------------------------------
r185126 | rmudgett | 2009-03-30 15:50:01 -0500 (Mon, 30 Mar 2009) | 33 lines

Merged revisions 185122 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r185122 | rmudgett | 2009-03-30 15:41:24 -0500 (Mon, 30 Mar 2009) | 26 lines
 
 Merged revisions 185120 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r185120 | rmudgett | 2009-03-30 15:38:11 -0500 (Mon, 30 Mar 2009) | 19 lines
   
   Make chan_misdn BRI TE side normally defer channel selection to the NT side.
   
   Channel allocation collisions are not handled by chan_misdn very well.
   This patch simply avoids the problem for BRI only.
   
   For PRI, allocation collisions are still possible but less likely since
   there are simply more channels available and each end could use a different
   allocation strategy.
   
   misdn.conf options available:
   te_choose_channel - Use to force the TE side to allocate channels.
   method - Specify the channel allocation strategy.
   
   (closes issue ASTERISK-12734)
   Reported by: Christian_Pinedo
   Patches:
         isdn_lib.patch.txt uploaded by crich
   Tested by: crich, siepkes, festr
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=185126
By: Digium Subversion (svnbot) 2009-03-30 15:52:07

Repository: asterisk
Revision: 185128

_U  branches/1.6.2/
U   branches/1.6.2/channels/misdn/isdn_lib.c

------------------------------------------------------------------------
r185128 | rmudgett | 2009-03-30 15:52:07 -0500 (Mon, 30 Mar 2009) | 33 lines

Merged revisions 185122 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r185122 | rmudgett | 2009-03-30 15:41:24 -0500 (Mon, 30 Mar 2009) | 26 lines
 
 Merged revisions 185120 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r185120 | rmudgett | 2009-03-30 15:38:11 -0500 (Mon, 30 Mar 2009) | 19 lines
   
   Make chan_misdn BRI TE side normally defer channel selection to the NT side.
   
   Channel allocation collisions are not handled by chan_misdn very well.
   This patch simply avoids the problem for BRI only.
   
   For PRI, allocation collisions are still possible but less likely since
   there are simply more channels available and each end could use a different
   allocation strategy.
   
   misdn.conf options available:
   te_choose_channel - Use to force the TE side to allocate channels.
   method - Specify the channel allocation strategy.
   
   (closes issue ASTERISK-12734)
   Reported by: Christian_Pinedo
   Patches:
         isdn_lib.patch.txt uploaded by crich
   Tested by: crich, siepkes, festr
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=185128