[asterisk-bugs] [JIRA] (ASTERISK-26992) chan_sip: Bell Canada Interop on Asterisk 13.15 fails due to no RTP on SDP sendrecv

[David Brillert (JIRA)]

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

David Brillert commented on ASTERISK-26992:
-------------------------------------------

Or perhaps this commit changed some default behavior in the 183 early progress SDP RTP response from Asterisk...

{noformat}
2014-07-17 21:17 +0000 [r418832-418870]  Matthew Jordan <mjordan at digium.com>


        * channels/chan_sip.c, UPGRADE.txt: chan_sip: Make
          progressinband=never really mean 'never' progressinband=never in
          sip.conf is easily defeated if an onward trunk sends a progress
          indication of its own. This is almost certain to happen if the
          onward trunk is ISDN or IAX as these technologies send a progress
          indication even if early media is not required. This progress
          message is passed to the caller, and causes the "never" option to
          be rather badly named. This patch changes the behaviour of this
          setting in the following ways: 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. This helps resolve double-ringing on some buggy
          handsets. 2) In sip_indicate(), if we see AST_CONTROL_PROGRESS,
          but SIP_PROG_INBAND_NEVER is set, send a 180 Ringing instead to
          avoid implicitly enabling early media. Avoid sending double ring
          indications. NOTE: the meaning of the SIP_PROGRESS_SENT flag
          changes slightly in this patch to also encapsulate the fact that
          a channel has *sent or received* a 183 Progress indication. This
          makes the updated code in sip_write() much more simple. Review:
          https://reviewboard.asterisk.org/r/3700 ASTERISK-23972 #close
          Reported by: Steve Davies patches:
          inband_never_present_early_media2 uploaded by Steve Davies
          (License 5012)
{noformat}

Regardless it is pretty clear that the per peer setting does not override the global setting after much testing.

> chan_sip: Bell Canada Interop on Asterisk 13.15 fails due to no RTP on SDP sendrecv
> -----------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26992
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26992
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 13.15.0
>         Environment: Asterisk 13.15, CentOS6 x64
>            Reporter: David Brillert
>         Attachments: fail with rtp.pcapng, pass with rtp.pcapng
>
>
> I have been working to complete Bell Canada interop testing with Bell Canada and Asterisk 13.15 but the interop does not pass due to outgoing call setup failure.  When using 11.25 the test case does not fail.  Since 11.25 is no longer maintained I am trying to complete the interop with *13
> I ran tests and pcaps using both versions to diagnose where the RTP is failing.
> Because the 183 session in progress message SDP has sendrecv Bell expects RTP from Asterisk.
> The passed test case is using Asterisk 11.25 and Asterisk is sending RTP in response to sendrecv. In the Asterisk 13.15 failure Asterisk does not send RTP after the sendrecv.
> Two traces are attached:
> 1. Asterisk 11.25 'pass with rtp.pcapng' where RTP is established after the sendrecv and the call completes OK.
> 2. Asterisk 13.15 'fail with rtp.pcapng' where RTP is not established after the sendrecv and the call fails.
> I have tried multiple setting in sip.conf including progressinband=yes and no and never without any improvement.
> sip.conf
> {noformat}
> transport       =  udp
> icesupport      =  no
> nat             =  no
> directmedia     =  yes
> insecure        =  port,invite
> disallowed_methods =  UPDATE
> session-timers  =  accept
> session-expires =  1800
> session-minse   =  90
> session-refresher =  uac
> encryption      =  no
> qualify         =  yes
> qualifyfreq     =  60
> disallow        =  all
> allow           =  ulaw
> {noformat}



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