|Summary:||ASTERISK-19223: Called party keeps ringing until calling party has send a cancel|
|Reporter:||Frank-Michael Wittig (cpuvampier)||Labels:||asterisk|
|Date Opened:||2012-01-20 07:03:51.000-0600||Date Closed:||2012-03-01 19:01:19.000-0600|
|Environment:||Ubuntu 10.04 64Bit Kernel 2.6.38-11-generic. Dell PowerEdge R410 4GB Dualcore I7 Sangoma Voicetime USB Sip<->Sip only||Attachments:||( 0) ASTERISK-19223.patch|
( 1) called.png
( 2) caller.png
( 3) cli-log.txt
( 4) debug.log
( 5) dump1.pcap
( 6) extensions.conf
( 7) sip.conf
|Description:||The calling (#21) party dial the called party (#20) and before the call is fully set, the calling party "hang up" cancel the call.|
Both channel's keep alive, no cancel is sent to called party. If no timeout is set, it will run endless.
This issue is watched on SIP channels, only. It makes no diffrent if it's goes thru or executed over Local channels.
|Comments:||By: Frank-Michael Wittig (cpuvampier) 2012-01-20 07:32:18.275-0600|
This behavior will only occure 1 time of 40-60 calls.
By: David Woolley (davidw) 2012-01-26 05:37:51.976-0600
This sounds like a duplicate, from quite some time ago.
By: David Woolley (davidw) 2012-01-27 06:37:58.148-0600
ASTERISK-15965 is the one that I was thinking of.
By: Frank-Michael Wittig (cpuvampier) 2012-01-27 08:09:01.284-0600
Hi David and thanks,
i've read 15965, and i am not shure if this is quite the same issue.
In my point of view, there is no delayed response and in any case in 900msec it's possible to hang up.
I try this to reproduce with some other Phones to make sure that isn't a firmeware issue (can be).
Same thing with Aastra RFP, Aastra 57 and with my Yealink Phones.
A timeout for dialing is to 60sec.
By: Mark Michelson (mmichelson) 2012-02-02 15:53:35.199-0600
I'm attempting to get this issue fixed, but I'm having difficulty doing so with the information provided.
I want the following, if you can provide it:
1. Provide the SIP configuration settings for the two parties involved in the call, plus the general settings.
2. Collect debugging from a working canceled call and a broken canceled call. Here are instructions on how to get debugging information: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
The thing that strikes me as odd in your pcap is that Asterisk sends a 180 response to phone 21 and then immediately sends a 183 response. Does phone 20 send media to Asterisk after the phone sends its 180? In cases where calls are canceled successfully, do you see the same thing occur?
I tried using 126.96.36.199 and made probably around 100 calls and could not make this happen.
By: Mark Michelson (mmichelson) 2012-02-27 10:17:45.383-0600
I'm closing this issue because I cannot reproduce it and the reporter has not provided requested feedback.
By: Frank-Michael Wittig (cpuvampier) 2012-02-27 16:25:33.849-0600
Sorry for my late response.
Now i have attached the debug.log Call start's at Feb 27 23:13:44 and auto terminated due timeout in dail command to Feb 27 23:14:40
By: Frank-Michael Wittig (cpuvampier) 2012-02-27 16:31:21.629-0600
Please take a look again, if you can reproduce this error.
By: Mark Michelson (mmichelson) 2012-02-28 13:09:18.486-0600
Thanks very much. I'm having a look now and will let you know what I find.
By: Mark Michelson (mmichelson) 2012-02-28 15:51:56.776-0600
It appears that the issue may have something to do with the "progressinband" setting. The thing that sticks out as odd on the failed CANCEL is this:
[Feb 27 23:13:42] DEBUG channel.c: Scheduling timer at (0 requested / 0 actual) timer ticks per second
[Feb 27 23:13:42] DEBUG res_timing_timerfd.c: Avoiding read on disarmed timerfd 31
[Feb 27 23:13:42] DEBUG res_timing_timerfd.c: Expected to acknowledge 1 ticks but got 0 instead
Unfortunately, I've not been able to reproduce the issue because apparently my test machine will not load res_timer_timingfd.so because of a failed check when attempting to load the module.
By: Mark Michelson (mmichelson) 2012-02-28 16:31:51.300-0600
Okay, after upgrading my system to a newer kernel, I have now reproduced the issue. This will make it *significantly* easier to try to fix.
By: Frank-Michael Wittig (cpuvampier) 2012-02-28 17:17:51.801-0600
Thank you, Mark.
I've doubted myself a little, because the problem in relative terms "rarely" occurs and I had already some effortless to record debug.
So, it does this mean that the res_timing_timerfd module loses the assignment ?
By: Mark Michelson (mmichelson) 2012-02-29 13:49:16.082-0600
I am attaching ASTERISK-19223.patch to this issue. I have confirmed that for me this fixes the issue. Please try it out.
In addition, I have posted this patch on review board at https://reviewboard.asterisk.org/r/1779/
By: Frank-Michael Wittig (cpuvampier) 2012-03-31 07:47:59.470-0500
Can you please add this patch into the next release ?
It will not only occure in 188.8.131.52.