[asterisk-bugs] [JIRA] (ASTERISK-30499) inband_progress not honored with ivr/direct accept

[Jørgen H (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-30499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261807#comment-261807 ] 

Jørgen H commented on ASTERISK-30499:
-------------------------------------

I see.
I'm not sure about the need for an additional option just for this behaviour since it is due to a third party regression bug. Im not familiar with the need for such an option in generally.
I expect the third party/commercial provider to deploy a bugfix, but due to the size of this company it will probably take a while
If they have not fixed it within some time I can continue with this issue at Github.


> inband_progress not honored with ivr/direct accept
> --------------------------------------------------
>
>                 Key: ASTERISK-30499
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30499
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 20.2.0
>         Environment: Linux x64
>            Reporter: Jørgen H
>            Assignee: Jørgen H
>
> According to 20.2 documentation, setting inband_progress=no on the other partys endpoint should prevent Asterisk from sending "183 Session Progress" to it.
> It is however sent, and at least if Asterisk picks up the call directly using IVR/audio file playback
> Editing line 1678 in channels/chan_pjsip.c
> changing case AST_CONTROL_PROGRESS
> by adding 
> if (channel->session->endpoint->inband_progress && ast_channel_state(ast) != AST_STATE_UP)
>   response_code = 183;
> solves the problem, but I'm not sure if this breaks something else.
> The reason for us not sending 183 is that there is a new bug in the SIP implementation of a commercial provider causing race condition and hangup triggered by 183.



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