[asterisk-bugs] [JIRA] Updated: (SS7-55) Asterisk not rejecting call setup on CIC that is down
Richard Mudgett (JIRA)
noreply at issues.asterisk.org
Wed Aug 8 13:54:07 CDT 2012
[ https://issues.asterisk.org/jira/browse/SS7-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Mudgett updated SS7-55:
-------------------------------
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 at 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}
was:
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.
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 at from-siemens:1] DumpChan("DAHDI/34-1", "") in new stack
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.
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)
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
> Asterisk not rejecting call setup on CIC that is down
> -----------------------------------------------------
>
> Key: SS7-55
> URL: https://issues.asterisk.org/jira/browse/SS7-55
> Project: LibSS7
> Issue Type: Bug
> Security Level: None
> Components: General
> 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
> Reporter: Tuan Le
> Assignee: mattf
> Attachments: AsteriskConfigs_digium-info_20120808.tar.gz
>
>
> 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 at 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}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list