[asterisk-bugs] [JIRA] (ASTERISK-23897) [patch]Change in SETUP ACK handling (checking PI) in revision 413765 breaks working environments

[Richard Mudgett (JIRA)]

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

Richard Mudgett updated ASTERISK-23897:
---------------------------------------

    Status: Waiting for Feedback  (was: Open)

Can you please attach a "pri set debug on span x" capture of a failing call for posterity?

I assume that the outgoing SETUP does not contain any digits for the called number.

I was thinking of an alternate method that wouldn't require a compatibility option.  If the outgoing SETUP did not have any called digits then a received SETUP ACK would open the audio path for dialtone because of the Q.931 Section 5.1.3 you noted in your patch.

> [patch]Change in SETUP ACK handling (checking PI) in revision 413765 breaks working environments
> ------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-23897
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23897
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi
>    Affects Versions: 11.10.2
>         Environment: An Asterisk system interconnected with either MD110 release BC13 or Avaya Definity (release Unknown)
>            Reporter: Pavel Troller
>            Assignee: Pavel Troller
>         Attachments: pri.diff
>
>
> The change introduced in revision 413765 limits opening the media channel and sending the PROGRESS control frame only to cases, when the Progress Indication with value "Inband Info now available" is present in the SETUP ACK message. However, there are exchanges (like these mentioned in the "environment" section), which don't send this PI in SETUP ACK, but they send regular dial tone. Now the dial tone (and any subsequent audio information until some progress indication is received from the PBX) cannot be heard.
>   I understand, that the change was necessary to fix another problem, but it introduces this one, so from my point of view, it's a regression.
>   My proposed solution is to introduce a new config option. I've called it "alwayssendprogress" and it's a binary no/yes option. In the "no" status, it keeps the new behaviour in place. In the "yes" status, it restores the old one.
> A better naming is possible, any proposals are welcome.
>   The supplied patch was tested on current V11 SVN and it seems to be working as expected.



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