[asterisk-bugs] [JIRA] Updated: (ASTERISK-20204) Asterisk not rejecting call setup on CIC that is down

Richard Mudgett (JIRA) noreply at issues.asterisk.org
Wed Oct 3 17:12:27 CDT 2012


     [ https://issues.asterisk.org/jira/browse/ASTERISK-20204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Mudgett updated ASTERISK-20204:
---------------------------------------

    Attachment: jira_asterisk_20204_v1.8.patch

[^jira_asterisk_20204_v1.8.patch] should release the call with congestion if the requested circuit is unavailable.

Please test.

> Asterisk not rejecting call setup on CIC that is down
> -----------------------------------------------------
>
>                 Key: ASTERISK-20204
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20204
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi/SS7
>    Affects Versions: 1.8.11.1
>         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: Richard Mudgett
>         Attachments: AsteriskConfigs_digium-info_20120808.tar.gz, jira_asterisk_20204_v1.8.patch
>
>
> 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