[Home]

Summary:ASTERISK-03871: ALERTING not being sent for inbound PRI calls
Reporter:Steve Hanselman (shanselman)Labels:
Date Opened:2005-04-05 12:09:18Date Closed:2008-01-15 15:33:50.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) trace.txt
( 1) trace2.txt
( 2) trace3.txt
( 3) zap-proceeding.diff
Description:When a call is received Asterisk does not pass back the ALERTING status, the calling party just hears a dead line (and a very large number are just ringing off as they think the call has not been made).

Our config is Telco->Asterisk(TE410)->OtherPBX

OtherPBX does send an ALERTING back to Asterisk, Asterisk does not pass it on (although it did, but we cannot be sure when this last was)

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

Here's the trace, span 1 is the Telco, Span 2 is the other PBX.  This is the same inbound call monitored seperately on each span, PBX first (where you can see the ALERTING).

Linux3*CLI> pri debug span 2
Enabled debugging on span 2
Linux3*CLI>
Linux3*CLI>
Linux3*CLI>
-- Making new call for cr 32786
> Protocol Discriminator: Q.931 (8)  len=37
> Call Ref: len= 2 (reference 18/0x12) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a3]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                              Ext: 1  User information layer 1: A-Law (35)
> [18 03 a1 83 81]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 1 ]
> [6c 0d 21 83 30 37 39 37 33 37 35 30 39 39 33]
> Calling Number (len=15) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation allowed of network provided number (3) '07973750993' ]
> [70 04 c1 31 31 31]
> Called Number (len= 6) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '111' ]
> [a1]*CLI>
> Sending Complete (len= 1)
< Protocol Discriminator: Q.931 (8)  len=10
< Call Ref: len= 2 (reference 18/0x12) (Terminator)
< Message type: CALL PROCEEDING (2)
< [18 03 a9 83 81]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 1  Channel: 1 ]
-- Processing IE 24 (cs0, Channel Identification)
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 18/0x12) (Terminator)
< Message type: ALERTING (1)
Apr  5 18:00:42 WARNING[28575]: app_dial.c:511 wait_for_answer: Unable to forward frame
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Call Delivered, peerstate Call Received
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 18/0x12) (Originator)
> Message type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 18/0x12) (Terminator)
< Message type: RELEASE (77)
< [08 02 80 90]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
<                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Processing IE 8 (cs0, Cause)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 18/0x12) (Originator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
Linux3*CLI> pri no debug span 2
Disabled debugging on span 2
Linux3*CLI> pri debug span 1
Enabled debugging on span 1
< Protocol Discriminator: Q.931 (8)  len=41
< Call Ref: len= 2 (reference 5338/0x14DA) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a3]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                              Ext: 1  User information layer 1: A-Law (35)
< [18 03 a1 83 82]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 1  Channel: 2 ]
< [1e 02 84 81]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the remote user (4)
<                               Ext: 1  Progress Description: Call is not end-to-end ISDN; further call progress information may be
available inband. (1) ]
< [6c 0d 00 83 30 37 39 37 33 37 35 30 39 39 33]
< Calling Number (len=15) [ Ext: 0  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)
<                           Presentation: Presentation allowed of network provided number (3) '07973750993' ]
< [70 04 a1 31 31 31]
< Called Number (len= 6) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '111' ]
< [a1]
< Sending Complete (len= 1)
-- Making new call for cr 5338
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 30 (cs0, Progress Indicator)
-- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number)
-- Processing IE 161 (cs0, Sending Complete)
> Protocol Discriminator: Q.931 (8)  len=10
> Call Ref: len= 2 (reference 5338/0x14DA) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 82]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 2 ]
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 5338/0x14DA) (Originator)
< Message type: DISCONNECT (69)
< [08 02 80 90]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
<                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Processing IE 8 (cs0, Cause)
Apr  5 18:01:07 WARNING[29630]: app_dial.c:511 wait_for_answer: Unable to forward frame
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 5338/0x14DA) (Terminator)
> Message type: RELEASE (77)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 5338/0x14DA) (Originator)
< Message type: RELEASE COMPLETE (90)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
Comments:By: Mark Spencer (markster) 2005-04-05 14:47:52

Fixed in CVS head.
By: Steve Hanselman (shanselman) 2005-04-06 02:56:16

Still not resolved, what have you changed and where so I can check that this has been updated in CVS?
By: Steve Hanselman (shanselman) 2005-04-06 03:01:56

The only change in libpri is q931.c to 1.123 which is merely to handle CALLER_RETURNED_TO_ISDN which is not related to this.
Also chan_zap has some advice of charges changes, again, not related.
By: Paul Cadach (pcadach) 2005-04-06 03:35:39

Reminder sent to PCadach, shanselman

Looks like all fine at chan_zap and app_dial. libpri isn't verified, but I'll look at it shortly. Could to _attach_ call trace with both "pri debug span 1" and "pri debug span 2" enabled, and "set verbose 3" too (to see debugging messages from chan_zap)?
By: Steve Hanselman (shanselman) 2005-04-06 03:42:44

Trace as requested.
By: Steve Hanselman (shanselman) 2005-04-06 04:19:37

Trace2 contains the chan_zap debug for this call from the diag logs, looking to see whether there are any other useful parts to attach.
By: Steve Hanselman (shanselman) 2005-04-06 04:24:34

Trace 3 is the entire sequence from the debug log, I'm just about to look into the code that thinks there are extra digits and defers the ring.
I'd suspect that something has been changed around the code for overlap dialling as one of our PRI's is overlap and the other not.
By: Paul Cadach (pcadach) 2005-04-06 07:05:07

Looks like you shouldn't use 'w' option when call goes from PSTN (when overlap dialing isn't supported by both parties).
By: Steve Hanselman (shanselman) 2005-04-06 12:22:26

The w option was added for us to get around another problem, I;ll have to look back on Mantis and see what it is, any idea when the change took place that changed the effect as up until a month ago it was fine.
By: Paul Cadach (pcadach) 2005-04-06 12:35:03

Looks like I found a solution. Patch will be available shortly.
By: Paul Cadach (pcadach) 2005-04-06 12:47:23

Could you tell us switch types you uses for both spans (/etc/asterisk/zapata.conf, parameter "switchtype")?
By: Paul Cadach (pcadach) 2005-04-06 14:34:53

IMHO this patch should help a little (if called party sent us PROCEEDING message then we have left from address collection state and no overlap dialing is possible).
By: Steve Hanselman (shanselman) 2005-04-06 14:35:34

Both are EuroISDN
By: Steve Hanselman (shanselman) 2005-04-06 15:13:29

The bug (or rather the latest CVS) has fixed the alerting.

Thanks
By: Mark Spencer (markster) 2005-04-06 15:15:48

Fixed in CVS
By: Steve Hanselman (shanselman) 2005-04-06 15:16:26

Sorry, knackered, I meant the latest CVS containing the patch ZZzzzzzz!!!!
By: Paul Cadach (pcadach) 2005-04-06 15:17:16

Could you locate what exactly (latest CVS or attached patch) fixes this bug?
By: Steve Hanselman (shanselman) 2005-04-07 04:10:55

The latest CVS resolved the aleerting issue, I didn't apply the patch, however the latest CVS has reversed the effects of mantis fix 1857, which I'll reopen.
By: Steve Hanselman (shanselman) 2005-04-07 05:07:30

Yes, I'm checking on the libpri changes and I've reopened the original bug on this, can you close this one as the alerting is now sent.
By: Paul Cadach (pcadach) 2005-04-07 05:11:25

Fixed by Mark's changes in CVS. Patch wasn't applied to fix this.
By: Russell Bryant (russell) 2005-05-09 21:33:53

fixed in 1.0
By: Digium Subversion (svnbot) 2008-01-15 15:30:51.000-0600

Repository: asterisk
Revision: 5411

U   trunk/channels/chan_zap.c

------------------------------------------------------------------------
r5411 | markster | 2008-01-15 15:30:51 -0600 (Tue, 15 Jan 2008) | 2 lines

Alerting *can* be sent after proceeding (bug ASTERISK-3871)

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

http://svn.digium.com/view/asterisk?view=rev&revision=5411
By: Digium Subversion (svnbot) 2008-01-15 15:33:50.000-0600

Repository: asterisk
Revision: 5614

U   branches/v1-0/CHANGES
U   branches/v1-0/channels/chan_zap.c

------------------------------------------------------------------------
r5614 | russell | 2008-01-15 15:33:49 -0600 (Tue, 15 Jan 2008) | 2 lines

allow ALERTING even after PROCEEDING (bug ASTERISK-3871)

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

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