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

[Rusty Newton (JIRA)]

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

Rusty Newton commented on ASTERISK-23972:
-----------------------------------------

{quote}
Thoughts?
{quote}
[~one47] Go ahead and put the patch up on review board, following the [Code Review|https://wiki.asterisk.org/wiki/display/AST/Code+Review] process. Then folks can comment on the patch overall or line by line.

Thanks!

> [patch]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
>         Attachments: inband_never_prevent_early_media, inband_never_prevent_early_media2
>
>
> 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)