[asterisk-bugs] [JIRA] (ASTERISK-23972) sip.conf progressinband=never does not mean 'never'.

[Steve Davies (JIRA)]

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

Steve Davies commented on ASTERISK-23972:
-----------------------------------------

Because this is a potentially significant behaviour change, it is perhaps not safe for a change in version 11, but I propose:

1) In sip_write(), do not pass the media unless we have either progressed beyond INV_EARLY_MEDIA, or we are in INV_EARLY_MEDIA state, and early media is both set-up and wanted. I have tested this quite widely in 1.6.x, 1.8.x and 11.x versions, as it helps resolve double-ringing on some buggy handsets.

2a) In sip_indicate(), if we see AST_CONTROL_PROGRESS, but SIP_PROG_INBAND_NEVER is set, send a 180 Ringing instead to avoid enabling early media.
2b) Alternatively, do we send the 183 but with no SDP??? Is that legal? If we send this, do we set SIP_PROGRESS_SENT, or SIP_RINGING? Given that SIP_PROGRESS_SENT implies early media...

Thoughts?

> sip.conf progressinband=never does not mean 'never'.
> ----------------------------------------------------
>
>                 Key: ASTERISK-23972
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23972
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.10.1
>            Reporter: Steve Davies
>            Severity: Minor
>
> My understanding of progressinband=never on a SIP device is that it will prevent inband progress if at all possible. The is a simple case I have found where this setting is defeated.
> If any one of the dialled target trunks sends a progress message (IAX progress / ISDN progress / SIP 183 Progress) Then this is passed unfiltered to the calling channel, This causes SIP_PROGRESS_SENT to be set, and progressinband is inferred, allowing unwanted early audio.
> This is causing a problem with my WebRTC testing as a '183 progress' followed by '200 OK' in a SIP conversation is converted to a 'pranswer' followed by an 'answer' in WebRTC terms and most WebRTC implementations do not yet handle that properly.



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