[Home]

Summary:ASTERISK-16964: Asterisk does not send release message when channel requested during SETUP gets changed during Procedding Message from TELCO
Reporter:destiny6628 (destiny6628)Labels:
Date Opened:2010-11-16 01:47:40.000-0600Date Closed:2011-04-04 11:18:01
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) UK.txt
Description:Hi,

We are using Asterisk 1.4.36 / dahdi-linux-2.3.0.1 / dahdi-tool-2.3.0 / libpri 1.4.10 with Digium Pri cards 4 PORT and 2 PORT respectively with hardware echo cancellation supported.

I will try to describe issue to the best of my ability out here so that we can come to any sort of resolution on this, as I am sure there would many others facing same issue.

Description :

I am working with a TELCO PROVIDER known as BT in UK where i have ISDN30e lines from there where TEI is static.

During Call Initiation from Dialer Server Channel picked up from Server would be X and sent across the ISDN LINE towards TELCO.

Now in return to that SETUP there would be a CALL PROCEDDING Message send back by TELCO on a different channel which was there during the SET UP MESSAGE.

Unfortunately when this happens the channel on which CALL PROCEDDING was sent back, was already BUSY.

Now at this instant as per my understanding ideally Asterisk shall release channel and call shall get hangup but instead of this Call remains ON and gets established on a another channel which was in CALL PROCEDDING but as CHANNEL has changed there would be no audio at all.

Please find the PRI LOGS ATTACHED in the description


Comments:By: destiny6628 (destiny6628) 2010-11-24 08:32:44.000-0600

Any update on this?? This has been a major issue as far as i understand in operations.
By: destiny6628 (destiny6628) 2010-11-25 06:03:19.000-0600

Any solution ?
By: Birger "WIMPy" Harzenetter (wimpy) 2010-11-25 06:14:08.000-0600

Solution to what? Did you experience any problems with the shown call?
(Assuming it was one call; the relevant bits are missing)

The signaling looks pretty normal to me.
The error message bout being unable to change channel appears in a position where it should already have happened.
So probably it's trying to do so twice, which is not good, but wouldn't necessarily lead to any undesired effects other than that message.

Actually I see a "peerstate Connect Request" on the hangup which looks wrong.


By: destiny6628 (destiny6628) 2010-12-06 02:15:17.000-0600

@wimpy : In case you originate a Call to Telco on channel X, it is assumed that you will receive a response back on the same channel X only from TELCO in the signalling not Y.

Also if we get the request back on channel Y and if channel Y is already busy on another call then only issues related to NO RTP ( No voice call ) comes on the Agents Terminal.

So is this channel shifting and response of Asterisk to channel shifting in case shifted channel is already busy on call is normal??
By: Leif Madsen (lmadsen) 2010-12-06 13:21:40.000-0600

I'll acknowledge this issue because I don't know what else I can ask for.

Perhaps an intense PRI debug from the Asterisk console along with debug level logging would be useful.
By: Birger "WIMPy" Harzenetter (wimpy) 2010-12-06 15:05:58.000-0600

Ok, you didn't tell us that you had no audio.

I have tried to force the situation and test.
I did not find any problems. The call worked on the reselected channel.
That was done using svn versions of all parts.

So I suggest you try the latest libpri and see if that still happens.

There have been two differences with my setup however:
1. I used a BRI as I can only simulate PRI with dahdi and I'm not sure if I can get it to force reselection, but that shouldn't make a difference.
2. I have the changed cahnel in a SETUP ACK. No idea how to get rid of that. This might make a difference.
By: destiny6628 (destiny6628) 2010-12-18 03:11:33.000-0600

Sure, will upload the pri intense debug logs asap
By: Digium Subversion (svnbot) 2011-04-04 10:49:32

Repository: asterisk
Revision: 312573

U   branches/1.4/channels/chan_dahdi.c
U   branches/1.4/configure
U   branches/1.4/configure.ac
U   branches/1.4/include/asterisk/autoconfig.h.in

------------------------------------------------------------------------
r312573 | rmudgett | 2011-04-04 10:49:32 -0500 (Mon, 04 Apr 2011) | 38 lines

Issues with ISDN calls changing B channels during call negotiations.

The handling of the PROCEEDING message was not using the correct call
structure if the B channel was changed.  (The same for PROGRESS.) The call
was also not hungup if the new B channel is not provisioned or is busy.

* Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING,
PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are
using the correct structure and B channel.  If there is any problem with
the operations then the call is now hungup with an appropriate cause code.

* Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the
correct structure by looking for the call and not using the channel ID.
NOTIFY is an exception with versions of libpri before v1.4.11 because a
call pointer is not available for Asterisk to use.

* Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find
the correct structure by looking for the call and not using the channel
ID.

(closes issue ASTERISK-16964)
Reported by: destiny6628
Tested by: rmudgett
JIRA SWP-2620

(closes issue ASTERISK-16892)
Reported by: destiny6628
Tested by: rmudgett
JIRA SWP-2924

(closes issue ASTERISK-17120)
Reported by: jpokorny
JIRA SWP-2929

JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.)
JIRA DAHDI-406
JIRA LIBPRI-33 (Stuck resetting flag likely fixed)

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

http://svn.digium.com/view/asterisk?view=rev&revision=312573
By: Digium Subversion (svnbot) 2011-04-04 11:00:04

Repository: asterisk
Revision: 312574

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_dahdi.c
U   branches/1.6.2/configure
U   branches/1.6.2/configure.ac
U   branches/1.6.2/include/asterisk/autoconfig.h.in

------------------------------------------------------------------------
r312574 | rmudgett | 2011-04-04 11:00:04 -0500 (Mon, 04 Apr 2011) | 45 lines

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

........
 r312573 | rmudgett | 2011-04-04 10:49:30 -0500 (Mon, 04 Apr 2011) | 38 lines
 
 Issues with ISDN calls changing B channels during call negotiations.
 
 The handling of the PROCEEDING message was not using the correct call
 structure if the B channel was changed.  (The same for PROGRESS.) The call
 was also not hungup if the new B channel is not provisioned or is busy.
 
 * Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING,
 PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are
 using the correct structure and B channel.  If there is any problem with
 the operations then the call is now hungup with an appropriate cause code.
 
 * Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the
 correct structure by looking for the call and not using the channel ID.
 NOTIFY is an exception with versions of libpri before v1.4.11 because a
 call pointer is not available for Asterisk to use.
 
 * Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find
 the correct structure by looking for the call and not using the channel
 ID.
 
 (closes issue ASTERISK-16964)
 Reported by: destiny6628
 Tested by: rmudgett
 JIRA SWP-2620
 
 (closes issue ASTERISK-16892)
 Reported by: destiny6628
 Tested by: rmudgett
 JIRA SWP-2924
 
 (closes issue ASTERISK-17120)
 Reported by: jpokorny
 JIRA SWP-2929
 
 JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.)
 JIRA DAHDI-406
 JIRA LIBPRI-33 (Stuck resetting flag likely fixed)
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=312574
By: Digium Subversion (svnbot) 2011-04-04 11:10:52

Repository: asterisk
Revision: 312575

_U  branches/1.8/
U   branches/1.8/channels/chan_dahdi.c
U   branches/1.8/channels/sig_pri.c
U   branches/1.8/channels/sig_pri.h

------------------------------------------------------------------------
r312575 | rmudgett | 2011-04-04 11:10:51 -0500 (Mon, 04 Apr 2011) | 52 lines

Merged revisions 312574 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r312574 | rmudgett | 2011-04-04 11:00:02 -0500 (Mon, 04 Apr 2011) | 45 lines
 
 Merged revisions 312573 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r312573 | rmudgett | 2011-04-04 10:49:30 -0500 (Mon, 04 Apr 2011) | 38 lines
   
   Issues with ISDN calls changing B channels during call negotiations.
   
   The handling of the PROCEEDING message was not using the correct call
   structure if the B channel was changed.  (The same for PROGRESS.) The call
   was also not hungup if the new B channel is not provisioned or is busy.
   
   * Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING,
   PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are
   using the correct structure and B channel.  If there is any problem with
   the operations then the call is now hungup with an appropriate cause code.
   
   * Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the
   correct structure by looking for the call and not using the channel ID.
   NOTIFY is an exception with versions of libpri before v1.4.11 because a
   call pointer is not available for Asterisk to use.
   
   * Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find
   the correct structure by looking for the call and not using the channel
   ID.
   
   (closes issue ASTERISK-16964)
   Reported by: destiny6628
   Tested by: rmudgett
   JIRA SWP-2620
   
   (closes issue ASTERISK-16892)
   Reported by: destiny6628
   Tested by: rmudgett
   JIRA SWP-2924
   
   (closes issue ASTERISK-17120)
   Reported by: jpokorny
   JIRA SWP-2929
   
   JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.)
   JIRA DAHDI-406
   JIRA LIBPRI-33 (Stuck resetting flag likely fixed)
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=312575
By: Digium Subversion (svnbot) 2011-04-04 11:18:00

Repository: asterisk
Revision: 312579

_U  trunk/
U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_pri.c
U   trunk/channels/sig_pri.h

------------------------------------------------------------------------
r312579 | rmudgett | 2011-04-04 11:18:00 -0500 (Mon, 04 Apr 2011) | 59 lines

Merged revisions 312575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r312575 | rmudgett | 2011-04-04 11:10:50 -0500 (Mon, 04 Apr 2011) | 52 lines
 
 Merged revisions 312574 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r312574 | rmudgett | 2011-04-04 11:00:02 -0500 (Mon, 04 Apr 2011) | 45 lines
   
   Merged revisions 312573 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r312573 | rmudgett | 2011-04-04 10:49:30 -0500 (Mon, 04 Apr 2011) | 38 lines
     
     Issues with ISDN calls changing B channels during call negotiations.
     
     The handling of the PROCEEDING message was not using the correct call
     structure if the B channel was changed.  (The same for PROGRESS.) The call
     was also not hungup if the new B channel is not provisioned or is busy.
     
     * Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING,
     PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are
     using the correct structure and B channel.  If there is any problem with
     the operations then the call is now hungup with an appropriate cause code.
     
     * Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the
     correct structure by looking for the call and not using the channel ID.
     NOTIFY is an exception with versions of libpri before v1.4.11 because a
     call pointer is not available for Asterisk to use.
     
     * Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find
     the correct structure by looking for the call and not using the channel
     ID.
     
     (closes issue ASTERISK-16964)
     Reported by: destiny6628
     Tested by: rmudgett
     JIRA SWP-2620
     
     (closes issue ASTERISK-16892)
     Reported by: destiny6628
     Tested by: rmudgett
     JIRA SWP-2924
     
     (closes issue ASTERISK-17120)
     Reported by: jpokorny
     JIRA SWP-2929
     
     JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.)
     JIRA DAHDI-406
     JIRA LIBPRI-33 (Stuck resetting flag likely fixed)
   ........
 ................
................

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

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