[Home]

Summary:ASTERISK-06514: duplicate in-band call progress information (duplicate ring tone)
Reporter:John Lange (johnlange)Labels:
Date Opened:2006-03-09 14:22:57.000-0600Date Closed:2008-01-15 17:33:18.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) pridebug.txt
( 1) sipdebug.txt
Description:When outbound calls are placed from Asterisk via a Zap channel connected to a T1/PRI, Asterisk is generating the audible progress indication (ringing sound) even though that audio is already coming in over the PRI channel. This results in 2 overlapping audible ringing sounds causing a strange "warble" in the sound the calling party hears.


****** ADDITIONAL INFORMATION ******

This seems to be related to this bug: 0005979 which was closed without mention as to why.

As the configs and console output are short I hope you don't mind me just pasting them here. The pri & sip debugs are attached.

--- zapata.conf ---
[channels]
faxdetect=incoming
immediate=no
switchtype=national
; Telco Side
echocancel=yes
echocancelwhenbridged=no
echotraining=yes
rxgain=0
txgain=-8
group = 1
context=epicpri
signalling=pri_cpe
channel => 1-23

--- zaptel.conf ---
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24

--- extensions.conf ---
[pri_out]
exten => _NXXXXXX,1,Dial(ZAP/g1/${EXTEN}) ; outbound 7 digit calls

--- console output ----

   -- Executing Dial("SIP/2048850872x3-2c81", "ZAP/g1/7916118") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called g1/7916118
   -- Zap/1-1 is proceeding passing it to SIP/2048850872x3-2c81
   -- Zap/1-1 is ringing
   -- Hungup 'Zap/1-1'
 == Spawn extension (openit, 7916118, 1) exited non-zero on 'SIP/2048850872x3-2c81'
Comments:By: John Lange (johnlange) 2006-03-09 14:27:34.000-0600

Is it just me or is there no way to edit an issue once it has been submitted?  

This was not for SVN-trunk but for v1.2.3. We have no way to test against anything else because this is a production system and we don't have spare PRIs and T1 cards. I will also test with 1.2.5 as soon as we can schedule an upgrade.
By: John Lange (johnlange) 2006-03-16 11:17:33.000-0600

This bug can possibly be closed. The solution which seems to work is to set progressinband=no in the [general] section of sip.conf.

Though the documentation seems to indicate "no" is the default, that appears to be not the case in 1.2.x.

If there are more or new options for progressinband, or if the defaults have changed that should be noted in the sip.sample.conf or elsewhere in the documentation.
By: Olle Johansson (oej) 2006-03-16 11:56:53.000-0600

"never" seems to be the default in 1.2. Which documentation says "no" ?

sip.conf has "never" as the setting. Does not clearly state that though.
By: Olle Johansson (oej) 2006-03-16 12:00:09.000-0600

Added a clarification to sip.conf.sample.

Thanks for reporting this issue.
By: John Lange (johnlange) 2006-03-16 13:40:09.000-0600

Sorry for being a pest and re-opening this issue but I believe there is still something wrong here.

If you set progressinband=never or you don't set anything and let it default, then you do in fact get inband progress (dual ring sound). If you set it to "yes" or "no" then you do NOT get the dual ring sound.

There is something wrong around Line 2641 of chan_sip.c but I can't get my head around the logic. The "never" setting actually seems to be more like a "forceoutofband=yes" because it does not stop the inband audio and it also forces outofband even if the signal has already been sent.

So from what I can see "never" actually still allows the inband audio through but also forces asterisk to repeatedly send "180 ringing" even if its already been sent.

In any case, at Line 11662 there is an obvious error where it picks up the config settings:

       else if (strcasecmp(v->value, "never"))
               ast_set_flag(flags, SIP_PROG_INBAND_NO);

This should be ->

       else if (strcasecmp(v->value, "no"))
               ast_set_flag(flags, SIP_PROG_INBAND_NO);
By: Olle Johansson (oej) 2006-03-16 13:52:02.000-0600

I looked at those line as well. Notice the missing ! in front of strcasecmp? :-)

It sets NO if it's *NOT* yes or never.

The progressinband code is messy and unclear, agreed. Can you please search the bug tracker for old bug reports in this regard and find some references and old discussions? If we can try to summarize those and understand what was desired, we can improve documentation and also check if it works as expected or if there's indeed a bug or undocumented feature :-) somewhere.

Thanks for your research into this matter!
By: John Lange (johnlange) 2006-03-16 14:13:37.000-0600

You are of course correct. My apologies, I forgot in C that it returns zero for a match. Thanks for your patience and for taking a look at this issue.

Ok, how about this then for the settings portion of the code:

--- chan_sip.c.1.2.5    2006-03-16 14:03:18.000000000 -0600
+++ chan_sip.c  2006-03-16 14:09:15.000000000 -0600
@@ -11659,8 +11659,14 @@
               ast_clear_flag(flags, SIP_PROG_INBAND);
               if (ast_true(v->value))
                       ast_set_flag(flags, SIP_PROG_INBAND_YES);
-               else if (strcasecmp(v->value, "never"))
+               else if (!strcasecmp(v->value, "no"))
                       ast_set_flag(flags, SIP_PROG_INBAND_NO);
+               else if (!strcasecmp(v->value, "never"))
+                       ast_set_flag(flags, SIP_PROG_INBAND_NEVER);
+               else {
+                       ast_log(LOG_WARNING, "Unknown progressinband mode '%s' on line %d, defaulting to never\n", v->value, v->lineno);
+                       ast_set_flag(flags, SIP_PROG_INBAND_NEVER);
+               }
       } else if (!strcasecmp(v->name, "allowguest")) {
#ifdef OSP_SUPPORT
               if (!strcasecmp(v->value, "osp"))


---

I'll also do more research in the coming week when I get a few moments to see what else I can discover. BTW, I do have a disclaimer on file.
By: Ron Wellsted (rjwellsted) 2006-03-22 10:46:08.000-0600

Just to note that I can confirm this bug in 1.2.5 on a EuroISDN PRI in the UK.

A workaround (at least for me) is to set progressinband=no

Using Cisco CP-7960 with SIP FW 8.2/7.5


By: Joshua C. Colp (jcolp) 2006-03-22 11:56:13.000-0600

Okay so you place a call and your telco provides inband progress at the start, but afterwards switches to out of band signalling with a ringing indication. They then still provide inband progress, so your end device mixes the audio together? Interesting. What's the SIP device out of curiosity?
By: ianplain (ianplain) 2006-04-08 03:19:39

Hi. I can confirm that this also affects IAX as well as SIP. I am using aastra SIP sets and Diax softphones. On both Im getting Dual ringing. Is progressinband=no valid for iax.conf as well?


By: Joshua C. Colp (jcolp) 2006-04-15 19:10:37

No, progressinband=no is not a valid option for chan_iax2.
By: Joshua C. Colp (jcolp) 2006-04-15 19:11:33

Since reporter did not respond to my original questions, I am closing this for now. If you return with the information please feel free to open this again.
By: Digium Subversion (svnbot) 2008-01-15 17:33:18.000-0600

Repository: asterisk
Revision: 13239

U   branches/1.2/configs/sip.conf.sample

------------------------------------------------------------------------
r13239 | oej | 2008-01-15 17:33:18 -0600 (Tue, 15 Jan 2008) | 2 lines

Issue ASTERISK-6514 - clarify progressinband default setting

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=13239