Summary: | ASTERISK-20204: Asterisk not rejecting call setup on CIC that is down | ||
Reporter: | Tuan Le (supertle) | Labels: | |
Date Opened: | 2012-08-08 12:35:15 | Date Closed: | 2012-11-08 15:16:21.000-0600 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Channels/chan_dahdi/SS7 |
Versions: | 1.8.11.1 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Linux localhost.localdomain 2.6.32-220.13.1.el6.x86_64 #1 SMP Tue Apr 17 23:56:34 BST 2012 x86_64 x86_64 x86_64 GNU/Linux | Attachments: | ( 0) AsteriskConfigs_digium-info_20120808.tar.gz ( 1) jira_asterisk_20204_v1.8.patch |
Description: | See call trace below. Its a linkset with 2 E1s configured but only 1 E1 connected. Asterisk receives a call setup (IAM) message from far-end Siemens switch on a CIC that is on the disconnected E1. Asterisk does not reject the call but signals back to accept the call and continues to setup the call. Asterisk then procedures to send audio out on that CIC on the down E1. The logical thing to do is to remove the E1s or have the other side be smarter about requesting call setup on a CIC that itself knows to be down but we have no control of the other side and E1s do go down so we need to be able to reject the call if Asterisk knows about it so at least the other side will reject the call as well. Right now the call completes ok but with no audio b/c of the obvious wrong CIC. {noformat} 1 62 No No No Idle No [1] Unhandled optional parameter 0x31 'Propagation Delay Counter' [1] [[1] 0x0 [1] 0x0 [1] ] [1] Unhandled optional parameter 0x39 'Parameter Compatibility Information' [1] [[1] 0x31 [1] 0xc0 [1] 0x3d [1] 0xc0 [1] ] -- Accepting call to '202850305' on CIC 33 -- Executing [202850305@from-siemens:1] DumpChan("DAHDI/34-1", "") in new stack {noformat} CIC 33 is on Span 2 and it is NOT PLUGGED IN but Asterisk allows the call to go thru instead of rejecting the call setup. {noformat} localhost*CLI> dahdi show status Description Alarms IRQ bpviol CRC Fra Codi Options LBO T4XXP (PCI) Card 0 Span 1 OK 0 0 0 CCS HDB3 0 db (CSU)/0-133 feet (DSX-1) T4XXP (PCI) Card 0 Span 2 RED 0 0 0 CCS HDB3 0 db (CSU)/0-133 feet (DSX-1) T4XXP (PCI) Card 0 Span 3 RED 0 0 0 CCS HDB3 0 db (CSU)/0-133 feet (DSX-1) T4XXP (PCI) Card 0 Span 4 RED 0 0 0 CCS HDB3 0 db (CSU)/0-133 feet (DSX-1) {noformat} {noformat} localhost*CLI> ss7 show channels link Chan Lcl Rem Call SS7 Channel set Chan Idle Blk Blk Level Call Name 1 2 Yes No No Idle No 1 3 Yes No No Idle No 1 4 Yes No No Idle No 1 5 Yes No No Idle No 1 6 Yes No No Idle No 1 7 Yes No No Idle No 1 8 Yes No No Idle No 1 9 Yes No No Idle No 1 10 Yes No No Idle No 1 11 Yes No No Idle No 1 12 Yes No No Idle No 1 13 Yes No No Idle No 1 14 Yes No No Idle No 1 15 Yes No No Idle No 1 16 Yes No No Idle No 1 17 Yes No No Idle No 1 18 Yes No No Idle No 1 19 Yes No No Idle No 1 20 Yes No No Idle No 1 21 Yes No No Idle No 1 22 Yes No No Idle No 1 23 Yes No No Idle No 1 24 Yes No No Idle No 1 25 Yes No No Idle No 1 26 Yes No No Idle No 1 27 Yes No No Idle No 1 28 Yes No No Idle No 1 29 Yes No No Idle No 1 30 Yes No No Idle No 1 31 Yes No No Idle No 1 32 No No No Idle No 1 33 No No No Idle No 1 34 No No No Connect Yes DAHDI/34-1 1 35 No No No Idle No 1 36 No No No Idle No 1 37 No No No Idle No 1 38 No No No Idle No 1 39 No No No Idle No 1 40 No No No Idle No 1 41 No No No Idle No 1 42 No No No Idle No 1 43 No No No Idle No 1 44 No No No Idle No 1 45 No No No Idle No 1 46 No No No Idle No 1 47 No No No Idle No 1 48 No No No Idle No 1 49 No No No Idle No 1 50 No No No Idle No 1 51 No No No Idle No 1 52 No No No Idle No 1 53 No No No Idle No 1 54 No No No Idle No 1 55 No No No Idle No 1 56 No No No Idle No 1 57 No No No Idle No 1 58 No No No Idle No 1 59 No No No Idle No 1 60 No No No Idle No 1 61 No No No Idle No 1 62 No No No Idle No {noformat} | ||
Comments: | By: Richard Mudgett (rmudgett) 2012-08-08 14:01:05.741-0500 The decision to accept the call is not made in libss7. It is done in asterisk. Moving this issue to the ASTERISK project. By: Richard Mudgett (rmudgett) 2012-10-03 17:12:14.927-0500 [^jira_asterisk_20204_v1.8.patch] should release the call with congestion if the requested circuit is unavailable. Please test. By: Tuan Le (tuanle55) 2012-10-04 10:05:29.651-0500 Patch applied but please be patient for any update or if any. This system will be going into production to peer with the Siemens switch and its very difficult to do any further interop testing them. By: Richard Mudgett (rmudgett) 2012-10-24 11:34:40.990-0500 It's been nearly three weeks. Any news on how well the patch is working for you? |