[Home]

Summary:ASTERISK-12206: chan_zap not dropping inbound ISDN call.
Reporter:Nick Barnes (bcnit)Labels:
Date Opened:2008-06-16 11:48:45Date Closed:2008-06-20 09:23:29
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:With Asterisk 1.6.0beta9 and libpri 1.4.4:

We have a TE120P card in E1 configuration. When we recieve an incoming call from the telco, all is well until the caller hangs up. Asterisk fails to receive the hangup request until the telco forces the call to drop (cause -1) some time later. This has resulted in very long voicemail mesages full of "The other party has hung up" messages and other more serious problems.

The zaptel.conf and zapata.conf are shown below and are *exactly* the same as used at a working site running Asterisk 1.4.x. The telco and circuits are also the same at the working site as at the non-working site.


****** ADDITIONAL INFORMATION ******

[root@pbx09a asterisk]# cat /etc/zaptel.conf

loadzone = uk
defaultzone=uk

span=1,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16

[root@pbx09a asterisk]# cat /etc/asterisk/zapata.conf

[trunkgroups]

[channels]
;
switchtype=euroisdn
signalling=pri_cpe
usecallingpres=yes
pridialplan=unknown
prilocaldialplan=unknown
nationalprefix=0
internationalprefix=00
; Following seems to be obsolete, but left in just in case!
stripmsd=0
echocancel=yes
immediate=no
usecallerid=yes
callerid=asreceived
group=1
txgain=2
rxgain=-2
context=from-pstn
channel => 1-14
Comments:By: Nick Barnes (bcnit) 2008-06-17 04:58:12

I should add that when the caller hangs up, I do get a whole load of:

"RTCP SR transmission error, rtcp halted"

messages at the console.
By: Shaun Ruffell (sruffell) 2008-06-17 09:42:31

Would you please attach the output of dmesg when this occurs?
By: Nick Barnes (bcnit) 2008-06-17 10:06:50

There's nothing in dmesg relating to this event. Sorry!
By: Shaun Ruffell (sruffell) 2008-06-17 10:11:52

What is the complete asterisk / zaptel / libpri version at the working site compared to the non-working site?
By: Nick Barnes (bcnit) 2008-06-17 10:32:19

The site which works is on Asterisk 1.4.19.

Both sites have Zaptel 1.4.11 and libpri 1.4.4.

The problem occurs with Zaptel 1.4.10 also (on the Asterisk 1.6 site, but not the 1.4).
By: Tzafrir Cohen (tzafrir) 2008-06-18 03:46:50

The versions of asterisk and libpri have changed. Has the version of Zaptel changed?

Move to Asterisk/chan_zap or to libpri?
By: Shaun Ruffell (sruffell) 2008-06-18 14:31:48

Move this to Asterisk/chan_zap since it appears just changing asterisk from 1.4 to 1.6 and leaving libpri and zaptel the same is enough to change the behavior.
By: Joel Vandal (jvandal) 2008-06-19 07:22:16

Does this can be related to ticket PRI-30 ? We have similar problem only when using libpri 1.4.4 but all work perfectly using libpri 1.4.3.


By: Nick Barnes (bcnit) 2008-06-19 08:49:39

This sounds like exactly the same problem. I'll revert to libpri 1.4.3 and test. Can I suggest this is merged with ticket 12655?
By: Shaun Ruffell (sruffell) 2008-06-19 09:25:19

I put a relationship to PRI-30, but what is odd to me is that you don't see this problem with libpri 1.4.4. and asterisk 1.4.19, if I read the history correctly.


By: Nick Barnes (bcnit) 2008-06-19 09:31:27

You're right. That is strange. I'll double check.
By: Nick Barnes (bcnit) 2008-06-19 14:34:36

Hmmm. Downgraded to libpri 1.4.3 and still have the same problem.
By: Sebastian Damm (sdamm) 2008-06-20 03:20:53

I just stumbled over the same issue. Downgrading to libpri 1.4.3 fixes the issue for me with Asterisk 1.4.20.1 (and trunk 1.4 as well). You have to recompile asterisk (at least chan_zap or chan_dahdi), though.
By: Nick Barnes (bcnit) 2008-06-20 04:04:16

Scrap that 'not working' bit - sheer stupidity on my part - would help if I was on the right machine!!
By: Shaun Ruffell (sruffell) 2008-06-20 09:23:02

Ok...closing this as a duplicate of PRI-30