[Home]

Summary:ASTERISK-26992: chan_sip: Bell Canada Interop on Asterisk 13.15 fails due to no RTP on SDP sendrecv
Reporter:David Brillert (aragon)Labels:
Date Opened:2017-05-10 09:25:26Date Closed:2018-05-04 15:28:34
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:13.15.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Asterisk 13.15, CentOS6 x64Attachments:( 0) fail_with_rtp.pcapng
( 1) pass_with_rtp.pcapng
Description: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}

Comments:By: Asterisk Team (asteriskteam) 2017-05-10 09:25:27.673-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: David Brillert (aragon) 2017-05-10 09:28:03.415-0500

*13.15 trace call failure pcap
By: David Brillert (aragon) 2017-05-10 09:28:25.817-0500

11.25 call OK pcap
By: David Brillert (aragon) 2017-05-12 14:13:08.273-0500

Ugh...
I got this working by putting this into the global sip.conf file
'progressinband  =  yes'

Putting 'progressinband  =  yes' into the customer peer sip.conf file does not override the global file when 'progressinband  =  no' where the default setting is = no.

The sip.conf.sample file does not specify whether a custom peer setting will override the global file.  Therefore I don't know if this is a 1. bug  2. configuration issue or 3. documentation issue.
1. Should 'progressinband  =  yes' in a custom sip.conf file for peers override the global sip.conf file if the global = no? If it should override then this is a bug because the peer setting =yes did not work if the global sip.conf 'progressinband  =  no'
2. If a peer sip.conf peer file cannot override the global sip.conf file value than this could be considered a configuration issue; however
3. The sip.conf.sample file could explain that this is a global value and not adjustable per peer.

So which is it?
By: David Brillert (aragon) 2017-05-12 14:22:50.764-0500

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@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.
By: Rusty Newton (rnewton) 2017-05-15 20:09:17.160-0500

{quote}
The sip.conf.sample file does not specify whether a custom peer setting will override the global file. Therefore I don't know if this is a 1. bug 2. configuration issue or 3. documentation issue.
1. Should 'progressinband = yes' in a custom sip.conf file for peers override the global sip.conf file if the global = no? If it should override then this is a bug because the peer setting =yes did not work if the global sip.conf 'progressinband = no'
2. If a peer sip.conf peer file cannot override the global sip.conf file value than this could be considered a configuration issue; however
3. The sip.conf.sample file could explain that this is a global value and not adjustable per peer.
{quote}

I'm not sure. Though, I'm opening up this issue so that it is available for anyone to look into, as you have provided clear information on the situation. chan_sip has been under extended support for a while so note that the resolution time will depend on interest from community developers.