[asterisk-bugs] [JIRA] (ASTERISK-29518) sig_analog: FCG_CAMA fails to signal ANI spill when using MF signaling

[Joshua C. Colp (JIRA)]

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

Work on ASTERISK-29518 started by Sarah Autumn.

> sig_analog: FCG_CAMA fails to signal ANI spill when using MF signaling
> ----------------------------------------------------------------------
>
>                 Key: ASTERISK-29518
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29518
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi
>    Affects Versions: 11.25.3, 12.8.2, 13.38.2, 14.7.8, 15.7.4, 16.19.0, 17.9.3, 18.5.0
>         Environment: N/A
>            Reporter: Sarah Autumn
>            Assignee: Sarah Autumn
>            Severity: Major
>
> A failure occurs when using FGC_CAMA in conjunction with MF signaling and ANI. The main problem is that after the initial MF called-number spill, Asterisk never winks back to the originating side, so the calling number spill is not started.  This appears to be a logic error in the switch-case block, where line 1931 and below can't be reached when p->sig is ANALOG_SIG_FGC_CAMAMF.
> Several smaller issues will also be addressed by the patch I am submitting, and all revolve around how asterisk handles ANI in the context of FGC_CAMA / FGC_CAMAMF:
> - Delay before ANI wink was unnecessarily long, and should be made configurable in chan_dahdi.conf.
> - The number of ANI INFO digits should be user-configurable. Different implementations of ANI will send a different number of INFO digits as part of the ANI spill. If the number of digits we expect is different than the number sent, the ANI spill and the callerID will be mutilated.
> - The ANI digit timeout should be configurable. 10 seconds is unnecessarily long, particularly with switches that implement ANI-B. When ANI identification fails, these switches will send a KP+1 or KP+2, with no ST pulse to indicate a failure. With Asterisk's existing 10 second timeout, the caller has to wait a full 10 seconds for call handling to resume. Making this configurable leaves the choice up to the user.
> - ANI-D uses ST, STP, ST2P and ST3P to differentiate between call dispositions. Asterisk should accept and store any of the above start pulses, and make them available as a channel variable for use in the dialplan.
> - Finally, there are specific console messages in Feature Group B and Feature Group C that are vague regarding the exact nature of the failure. These messages should be made clearer so the user can better understand the error and how to fix it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)