[Home]

Summary:ASTERISK-07599: [patch] Pickup not working properly after upgrade to 1.2.11, always assuming SLINEAR
Reporter:Alvaro Palma (alvaro_palma_aste)Labels:
Date Opened:2006-08-24 14:38:13Date Closed:2006-09-09 15:26:49
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/CodecInterface
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) channel.c.patch.rdl
( 1) log_asterisk_1_2_10.txt
( 2) log_asterisk_1_2_11.txt
Description:I upgraded my installation from 1.2.10 to 1.2.11 and now, if I have this situation:

Phone A: Codec GSM
Phone B: Codec G726
Phone C: Codec G726

If Phone A calls to Phone B and Phone C tries to pickup the call dialing *8, I get an endless burst of:

WARNING[21235]: chan_sip.c:2561 sip_write: Asked to transmit frame type 64, while native formats is 8 (read/write = 64/64)

in the console, and crack noise on the phones. Also tested using G729 in B and C (with the proper license installed, of course).

But, if A uses ALAW instead of GSM, it works fine, or if A, B and C uses the same codec. I downgraded to 1.2.10 and the problem vanished.

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

sip.conf:

[A]
type=friend
username=A
secret=AAAAAA
callerid="A"
disallow=all
allow=gsm
host=dynamic
callgroup=1
pickupgroup=1
context=outgoing_full

[B]
type=friend
username=B
secret=BBBBBB
callerid="B"
disallow=all
allow=g726
host=dynamic
callgroup=1
pickupgroup=1
context=outgoing_full

[C]
type=friend
username=C
secret=CCCCCC
callerid="C"
allow=g726
host=dynamic
callgroup=1
pickupgroup=1
context=outgoing_full
Comments:By: Serge Vecher (serge-v) 2006-08-24 15:02:57

Can you please follow these instructions and produce a log of a call, one with 1.2.11 and another with 1.2.10?:
1) Prepare test environment (reduce the ammount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterik.
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Save complete console log to file and _attach_ said file to the bug.
By: Alvaro Palma (alvaro_palma_aste) 2006-08-24 16:32:20

Ok, files added. The test I made was:

From phone named as 6528516 (with codec GSM enabled), I made a call to extension 18 (6528518), which has G726 enabled. From extension 19 (6528519), I picked up that call. In 1.2.10, it worked fine, but in 1.2.11, I only get the warning and a lot of noise.

The main difference I get from the logs is that, in 1.2.10, all three UA's get the message:

DEBUG[24045]: channel.c:2376 set_format: Set channel SIP/XXXXXXX-ZZZZZZZZ to read format slin
DEBUG[24045]: channel.c:2376 set_format: Set channel SIP/XXXXXXX-ZZZZZZZZ to write format slin

while in 1.2.11, this message is only sent to the first two legs in the call (16 and 18 in this case), not to the third phone trying to pick up the call. See lines 255 to 258 in log_1_2_11 v/s lines 252 to 255 and 694, 699 to 702 in log_1_2_10.
By: Chris Kleeman (ckleeman) 2006-08-24 19:00:35

Updated the other day for other issues got this today.

hundreds of lines of
"Aug 24 16:28:45 WARNING[8009]: chan_sip.c:2561 sip_write: Asked to transmit frame type 64, while native formats is 2 (read/write = 64/64)"

and the ocasional

"Aug 24 16:28:45 WARNING[7910]: app_meetme.c:1524 conf_run: Unable to write frame to channel: No such file or directory"
By: Michael Neuhauser (mneuhauser) 2006-08-25 08:12:21

I'm getting the same warning messages but when using a web-dialer (which uses the 'originate' manager command) after an upgrade to 1.2.11. I think an optimization in channel.c:set_format() which terminates the function early if the desired formats are already active is to blame. At least the warning messages went away after I disabled the new code in set_format(). I am talking about this piece of code in set_format():
if ((*rawformat == native) && (*format == fmt)) {
/* the channel is already in these formats, so nothing to do */
ast_mutex_unlock(&chan->lock);
return 0;
}
Disabling it (#if 0 ... #endif) makes the warnings go away.

(Before anyone can ask: no, I do not have a disclaimer on file, I only submit small fixes that do not require one.)
By: Serge Vecher (serge-v) 2006-08-25 09:03:58

hmmm, interesting ... so this was related to commit in r38347.

Alvaro_palma_aste: can you please confirm that removing that code makes the warnings go away?
By: Alvaro Palma (alvaro_palma_aste) 2006-08-25 09:15:23

Confirmed, the change corrected the problem, now works!!!
By: rdlang (rdlang) 2006-08-28 16:25:49

I should diff the orig with the new file, not vice versa... please ignore channel.c.patch :) I seem to be unable to delete it

I think the patch to correct this is in the attatched file channel.c.patch.rdl. The only thing that seems to be forgotten, is to check the direction to determine if ast_mutex_unlock(&chan->lock) should be called. I fixed this with a simple modification to the original check, wich was never reached because of the early exit. I will test this tomorrow to confirm, as have the same problem.
By: Serge Vecher (serge-v) 2006-08-29 16:34:59

alvaro_palma_aste: can you please try rdlang's patch ...
By: rdlang (rdlang) 2006-08-29 17:55:02

don't try it, my suggested patch seems to cause deadlocks. I have played around with the code, but can't seem to find a good solution.
By: Tony Mountifield (softins) 2006-09-05 11:04:45

I've just posted ASTERISK-7679 (before I saw this one), which looks like it's the same bug: set_format() in channel.c


By: Joshua C. Colp (jcolp) 2006-09-09 15:26:48

Fixed in 1.2 as of revision 42600 and trunk as of revision 42601.