asterisk users - May 2006 - Bristuffed Asterisk: Hangup problems

Hello,

I have a problem with the Bristuffed version of Asterisk. I have tried
Bristuff-0.3.0-pre-1m,n,o,p (Asterisk 1.2.6 to 1.2.7.1) but they all have
the same problem it seems:

The setup:

A machine with a single hfc-s PCI BRI adapter running Gentoo 2.6.15.
Asterisk 1.2.0 (BRIstuffed-0.3.0-PRE-1) installed and working perfectly.
Grandstream gxp-2000 as a SIP phone, and a normal mobile phoneaccount to
test the ISDN connection to the outside world.


I try to upgrade the above setup to a newer version of Bristuff (to test if
the CDR problem is solved) so I download a new bristuff and install it. The
installation seems to go OK, the zaptel and zaphfc modules load with no
problems at all. But when I hang up a call, the line is not totally
disconnected. For instance: When I call from my internal SIP phone to the
mobile, and I hangup the SIP phone while the other side hasn't picked up,
the mobile phone keeps on ringing. Or if I call from the outside to the SIP
phone, and hang up the mobile phone after a conversation, the SIP connection
to Asterisk is still there. Or the other way around: When I have a
conversation from the SIP phone to the mobile phone, and I hang up the SIP
phone, the connection to the mobile phone is still there.

I have tried a clean install of Asterisk+Bristuff as well as an upgrade from
the working Asterisk 1.2.0, but it gives me the same problem.

The only really strange thing I find in the logs that might have to do
something with this is the following line on the verbosed console:
chan_zap.c:8498 zt_pri_error: 1 updating callstate, peercallstate 2 to 1


my zaptel.conf:
---------------------
loadzone = nl
defaultzone=nl

span=1,1,3,ccs,ami
bchan=1-2
dchan=3
-------------------


and my zapata.conf:
-------------------
[channels]
language=nl
context=inbound
switchtype=euroisdn
pridialplan=dynamic
prilocaldialplan=local
internationalprefix = 00
nationalprefix = 0
signalling=bri_cpe_ptmp

rxwink=300
usecallerid=yes
cidsignalling=dtmf
cidstart=ring
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes

echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
rxgain=4.0
txgain=0.0

group=1
callgroup=1
pickupgroup=1
immediate=no

callerid=asreceived
busydetect=yes
busycount=8
busypattern=500,500

channel => 1-2
-------------------


I also made a full log and a console log of this problem. They can be found
at:

http://www.borndgtl.cistron.nl/consolelog.txt

http://www.borndgtl.cistron.nl/fulllog.txt



Anyone has an idea where to look for a solution for this problem?

Thanks!

Jeroen Zwarts
Born Digital
the Netherlands

On 5/9/06, Jeroen Zwarts <bdjeroen@xs4all.nl>
wrote:
> I have a problem with the Bristuffed version of Asterisk. I have tried
> Bristuff-0.3.0-pre-1m,n,o,p (Asterisk 1.2.6 to 1.2.7.1) but they all have
> the same problem it seems:
Hi Jeroen, any progress made yet? I noticed I'm experiencing the same
problem. I wonder if every bristuff user has this issue or it has
something to do with the zapata configuration..

cheers

There is a lot of junk in your zapata.conf that you do not need, as it 
relates to analogue lines.  This might be causing confusion?

Here is my config for a BT ISDN2e line here in UK.  I don't think I have 
the problems you report.

;TE mode - for ISDN line
nocid=Unavailable
withheldcid=Withheld
Language=en
usecallerid=yes
pridialplan=unknown
prilocaldialplan=unknown
nationalprefix=0
internationalprefix=00
switchtype = euroisdn
signalling = bri_cpe_ptmp
echocancel=yes
echocancelwhenbridged=no
immediate=no
overlapdial=yes
group = 1
context=isdn-in
callgroup=1
channel => 1-2


Rgds
Tim

Jeroen Zwarts wrote:
>Hello,
>
>I have a problem with the Bristuffed version of Asterisk. I have tried
>Bristuff-0.3.0-pre-1m,n,o,p (Asterisk 1.2.6 to 1.2.7.1) but they all have
>the same problem it seems:
>
>The setup:
>
>A machine with a single hfc-s PCI BRI adapter running Gentoo 2.6.15.
>Asterisk 1.2.0 (BRIstuffed-0.3.0-PRE-1) installed and working perfectly.
>Grandstream gxp-2000 as a SIP phone, and a normal mobile phoneaccount to
>test the ISDN connection to the outside world.
>
>
>I try to upgrade the above setup to a newer version of Bristuff (to test if
>the CDR problem is solved) so I download a new bristuff and install it. The
>installation seems to go OK, the zaptel and zaphfc modules load with no
>problems at all. But when I hang up a call, the line is not totally
>disconnected. For instance: When I call from my internal SIP phone to the
>mobile, and I hangup the SIP phone while the other side hasn't picked
up,
>the mobile phone keeps on ringing. Or if I call from the outside to the SIP
>phone, and hang up the mobile phone after a conversation, the SIP connection
>to Asterisk is still there. Or the other way around: When I have a
>conversation from the SIP phone to the mobile phone, and I hang up the SIP
>phone, the connection to the mobile phone is still there.
>
>I have tried a clean install of Asterisk+Bristuff as well as an upgrade from
>the working Asterisk 1.2.0, but it gives me the same problem.
>
>The only really strange thing I find in the logs that might have to do
>something with this is the following line on the verbosed console:
>chan_zap.c:8498 zt_pri_error: 1 updating callstate, peercallstate 2 to 1
>
>
>my zaptel.conf:
>---------------------
>loadzone = nl
>defaultzone=nl
>
>span=1,1,3,ccs,ami
>bchan=1-2
>dchan=3
>-------------------
>
>
>and my zapata.conf:
>-------------------
>[channels]
>language=nl
>context=inbound
>switchtype=euroisdn
>pridialplan=dynamic
>prilocaldialplan=local
>internationalprefix = 00
>nationalprefix = 0
>signalling=bri_cpe_ptmp
>
>rxwink=300
>usecallerid=yes
>cidsignalling=dtmf
>cidstart=ring
>hidecallerid=no
>callwaiting=yes
>usecallingpres=yes
>callwaitingcallerid=yes
>threewaycalling=yes
>transfer=yes
>cancallforward=yes
>callreturn=yes
>
>echocancel=yes
>echocancelwhenbridged=yes
>echotraining=yes
>rxgain=4.0
>txgain=0.0
>
>group=1
>callgroup=1
>pickupgroup=1
>immediate=no
>
>callerid=asreceived
>busydetect=yes
>busycount=8
>busypattern=500,500
>
>channel => 1-2
>-------------------
>
>
>I also made a full log and a console log of this problem. They can be found
>at:
>
>http://www.borndgtl.cistron.nl/consolelog.txt
>
>http://www.borndgtl.cistron.nl/fulllog.txt
>
>
>
>Anyone has an idea where to look for a solution for this problem?
>
>Thanks!
>
>Jeroen Zwarts
>Born Digital
>the Netherlands
>
>_______________________________________________
>--Bandwidth and Colocation provided by Easynews.com --
>
>Asterisk-Users mailing list
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>  
>

On Mon, 2006-05-15 at 17:40 -0300, Gustavo Souza Queiroz
wrote:
> 
> Hello, 
> I?m have a CCM 3.3 and Asterisk in my LAN. 
> I need connect my Asterisk in my CCM 3.3. 
> You can a help me? 
I hate to say it, but your best bet is to upgrade to CCm 4.0 and use
SIP..  It is a free cisco upgrade assuming you have a valid contract.

Without that as an option, I found the ooh323 channel to be the most
stable of the available ones for basic call flows..  I am pretty sure it
is included in the distribution, you just have to tell it to make it.

-Greg

Jeroen Zwarts wrote:
> 
> The only really strange thing I find in the logs that might have to do
> something with this is the following line on the verbosed console:
> chan_zap.c:8498 zt_pri_error: 1 updating callstate, peercallstate 2 to 1
> 
We had the exact same problem. It started happening for us starting at 
the 'k' release of bristuff (i mailed a msg on it in february i think 
to junghanns).

So, the 'i' release worked fine, while 'k' has the problem as
described.

A quick diff of 'i' vs. 'k' showed me this (among other things):

diff -U0 -r -x '*.o' -x '*.so' 
bristuff-0.3.0-PRE-1i/libpri-1.2.2/q931.c 
bristuff-0.3.0-PRE-1k/libpri-1.2.2/q931.c
--- bristuff-0.3.0-PRE-1i/libpri-1.2.2/q931.c   2006-05-17 
19:54:51.000000000 +0200
+++ bristuff-0.3.0-PRE-1k/libpri-1.2.2/q931.c   2006-05-17 
20:04:07.000000000 +0200
@@ -4428,3 +4428,3 @@
-               if (c->ourcallstate != c->sugcallstate) {
-                   pri_error(pri, "updating callstate, ourcallstate 
%d to %d\n", c->ourcallstate, c->sugcallstate);
-                   c->ourcallstate = c->sugcallstate;
+               if (c->peercallstate != c->sugcallstate) {
+                   pri_error(pri, "updating callstate, peercallstate 
%d to %d\n", c->peercallstate, c->sugcallstate);
+                   c->peercallstate = c->sugcallstate;

This was such a close match, that i reversed that change in the 'k' 
release and voila! problem disappeared.
Now, i have no clue what kind of side-effects this has, if any, nor if 
this is the proper solution, but it made the problem disappear for us.

I haven't tried to apply the same to later bristuff releases (all 
releases up to 'p' give us the same hangup problem)

Hope this helps.

marcel

----- Original Message ----- 
  From: Eberhard M?ller 
  To: asterisk-users@lists.digium.com 
  Sent: Thursday, June 01, 2006 7:58 PM
  Subject: [Asterisk-Users] Re: Bristuffed Asterisk: Hangup problems


  Hi,
  i have nearly the same problem. But I took the lastest Bristuff from Junghans
at 26th of may. So an in my q931 it is changed to ourcallstate.
  But the hangup problem don't disappear!! I got a quadbri, configured with
point to pint, beauce my NTBA ist configured to ptp too. When i configure that
to ptmp i always get dchan down and TEI requests.
  The problem that i have, my calls to the public network are not cleared(OK it
takes for about 30 seconds) . And when I make a new call to the public network I
get the message that you described before!
  I make a call into the public network to my mobile an i hear it ring, than i
clear the call on my sipphone and I see at the asterisk hungup Zap 1 1 bat my
mobile rings again and again.

  So thats my problem!!
  Thanks in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20060602/933a69cb/attachment.htm

Ok that was my fault. I read the diff in the wrong way!! I found the
"ourcallstate" and thought that was the right way. But I have to patch
in the "peercallstate".
Thanks a lot.
Ebse
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20060602/d6c52efd/attachment.htm