[Home]

Summary:ASTERISK-15965: [patch] Phone keeps ringing when hangup between 'NOTIFY' and 'Status: 180 Ringing'
Reporter:Ronald Derksen (ronaldderksen)Labels:
Date Opened:2010-04-16 04:49:07Date Closed:2010-09-13 11:21:37
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.patch
( 1) extensions.conf
( 2) myDebugLog
( 3) SIP_TRACE_thsgmbh.txt
( 4) sip.conf
Description:When I call my aastra SIP phone and hangup before the aastra phone sents back the 'Status: 180 Ringing' the phone keeps ringing 'forever'
This is what I see with tshark when I hangup right after I dialed the phone.

 0.000000 192.168.12.4 -> 192.168.12.100 SIP Request: NOTIFY sip:400@192.168.12.100:5060;transport=udp
 0.044154 192.168.12.100 -> 192.168.12.4 SIP Status: 200 OK
 0.351948 192.168.12.4 -> 192.168.12.100 SIP/SDP Request: INVITE sip:400@192.168.12.100:5060;transport=udp, with session description
 0.355715 192.168.12.4 -> 192.168.12.100 SIP Request: NOTIFY sip:400@192.168.12.100:5060;transport=udp
 0.525349 192.168.12.100 -> 192.168.12.4 SIP Status: 180 Ringing
 0.529074 192.168.12.100 -> 192.168.12.4 SIP Status: 200 OK

The aastra phone sents the 'Status: 180 Ringing' message after 529ms. That is a a big window. When I first play a message with 'Playback' application and the caller decides to hangup, the window of 529ms is too much. There is a big change people hangup in that 529ms.

I can also reproduce this with a polycom phone. But with polucom it is harder because it sents the 'Status: 180 Ringing' quicker (186 ms) I cannot reproduce this problem with a linksys phone. Linksys phone sents the 'Status: 180 Ringing' in 20ms.

A normal Dial -> ringing -> hangup looks like this (with aastra phone):

 0.000000 192.168.12.4 -> 192.168.12.100 SIP Request: NOTIFY sip:400@192.168.12.100:5060;transport=udp
 0.047770 192.168.12.100 -> 192.168.12.4 SIP Status: 200 OK
 0.331322 192.168.12.4 -> 192.168.12.100 SIP/SDP Request: INVITE sip:400@192.168.12.100:5060;transport=udp, with session description
 0.464797 192.168.12.100 -> 192.168.12.4 SIP Status: 180 Ringing
 2.822520 192.168.12.4 -> 192.168.12.100 SIP Request: NOTIFY sip:400@192.168.12.100:5060;transport=udp
 2.823327 192.168.12.4 -> 192.168.12.100 SIP Request: CANCEL sip:400@192.168.12.100:5060;transport=udp
 2.983367 192.168.12.100 -> 192.168.12.4 SIP Status: 200 OK
 2.986478 192.168.12.100 -> 192.168.12.4 SIP Status: 487 Request Terminated

So When I hangup after the phone ringed ones, I see that asterisk sents a 'CANCEL' message. I think this 'CANCEL' message also need to be sent when asterisk did not yet receive the 'Status: 180 Ringing' message.


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

Today I compiled asterisk 1.6.0 from svn. The problem is still there:

-sh-3.2$ svn info
Path: .
URL: http://svn.digium.com/svn/asterisk/branches/1.6.0
Repository Root: http://svn.digium.com/svn/asterisk
Repository UUID: f38db490-d61c-443f-a65b-d21fe96a405b
Revision: 257639
Node Kind: directory
Schedule: normal
Last Changed Author: tilghman
Last Changed Rev: 257592
Last Changed Date: 2010-04-15 23:33:14 +0200 (do, 15 apr 2010)
Comments:By: Paul Belanger (pabelanger) 2010-04-16 08:21:25

Are you able to test using 1.6.2 branch?  Also, please upload a full debug log (see below) and besure to enable debugs for the SIP channel driver.

---
http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt
By: Ronald Derksen (ronaldderksen) 2010-04-16 14:31:55

I installed asterisk 1.6.2 from svn and the problem is still there I attached the requested debug information.

-sh-3.2$ svn info
Path: .
URL: http://svn.digium.com/svn/asterisk/branches/1.6.2
Repository Root: http://svn.digium.com/svn/asterisk
Repository UUID: f38db490-d61c-443f-a65b-d21fe96a405b
Revision: 257641
Node Kind: directory
Schedule: normal
Last Changed Author: tilghman
Last Changed Rev: 257597
Last Changed Date: 2010-04-15 23:34:11 +0200 (do, 15 apr 2010)
By: Paul Belanger (pabelanger) 2010-04-16 15:08:27

Testing now.  But possibly related to ASTERISK-15876?
By: Paul Belanger (pabelanger) 2010-04-16 15:20:05

Mind attaching your sip.conf?
By: Ronald Derksen (ronaldderksen) 2010-04-16 15:57:38

My previous sip.conf was rather complicated. I did (after making backup)

rm -rf /etc/asterisk
make samples # In svn source tree

After make samples I only changed the attached sip.conf and extensions.conf. The rest is untouched. The problem still exists.
By: Leif Madsen (lmadsen) 2010-04-19 13:25:38

Could be related to ASTERISK-15876. I've marked it as such for now unless we determine that is not the case.

What are we expected Asterisk to do or send to cause this to not happen? This is sounding like an issue with the phone itself though isn't it? Or is Asterisk not sending a CANCEL or something after the INVITE to cause the phone to realize the call has been cancelled?
By: Ronald Derksen (ronaldderksen) 2010-04-19 15:20:59

It is somehow related to aastra phones. An aastra phone does not answer very quickly with the 'Ringing' status. Is there a minimum time to respond on INVITE?
I was not able to reproduce this problem wit a linksys phone. Linksys phone sent the 'Ringing' much faster to asterisk. I measured this with tshark.

My guess is that asterisk does NOT sent a CANCEL message after INVITE if it did not yet receive a 'Ringing' message back. Why CANCEL a phone that is not ringing? In some cases people can hangup milliseconds after the INVITE. This can happen if you do a playback command followed by a Dial command. If people decide to hangup after hearing the playback, they might hangup during the Dial command and thus milliseconds after INVITE. That is my guess of what is happening. In the first 6 lines of thshark output, there is NO CANCEL message sent to the phone. I hangup right after hearing a playback(beep). I used beep for easy timing when to hangup.


By: Leif Madsen (lmadsen) 2010-04-19 15:37:06

Which kind of brings me back around to my point of...

"What do you expect Asterisk to do to solve this issue?"

Sounds like a bug with the firmware on your Aastra phone, and not an issue in Asterisk.
By: Paul Belanger (pabelanger) 2010-04-19 15:44:44

If I'm reading the trace properly (I'm no expert so mileage may vary), asterisk does tell the 2nd channel (ringing Aastra) to hangup, you can see the schedule for destruction, but because Asterisk sent the INVITE, it has to wait possible events related to the invite.
By: Ronald Derksen (ronaldderksen) 2010-04-19 16:01:26

I think this is an asterisk bug because in my opinion, there is always a possibility to hangup right after INVITE. Networks can have delay. If you have a wifi phone connected over the internet to an asterisk server, you might even have bigger delays.

If it is the case that asterisk does not sent a CANCEL when it not yet received a Ringing. Then asterisk is doing something wrong, it might get the Ringing later. It is not good to say with my phone the time window between INVITE and Ringing is small so it will never happen. Sooner or later it will happen.

If there is a change something 'bad' might happen, it needs to be avoided. If 2 processes wants to do something that can not run simultaneous , you need something to prevent them to run on the same time. Like lockfiles or semaphores. Even when the execution time is only 1 millisecond.
By: Ronald Derksen (ronaldderksen) 2010-04-19 16:05:58

I posted 2 traces. In the first one there is no CANCEL. After 0.529074 seconds there is no network traffic any more and the phone rings 'forever'.

In the second trace I hangup later and I see that the CANCEL is sent and the phone stops ringing.
By: Ronald Derksen (ronaldderksen) 2010-04-28 09:59:06

Is there any news on this topic?
By: Leif Madsen (lmadsen) 2010-04-28 10:49:35

I'm Acknowledging this issue because there probably isn't anything further you can submit at this time. A developer will look at this as soon as time, resources, and priority become sufficient. Thanks!
By: David Woolley (davidw) 2010-04-28 10:51:21

It would be a protocol violation for Asterisk to send a CANCEL before receiving any response - Asterisk appears to be correct, in that respect:  

  If no provisional response has been received, the CANCEL request MUST
  NOT be sent; rather, the client MUST wait for the arrival of a
  provisional response before sending the request.  If the original
....
     If it was allowed to send the CANCEL before receiving a response
     for the previous request, the server could receive the CANCEL
     before the original request.


RFC 3261 Section 9.1

I'd need to look more carefully to see whether it should retry the invites until it does get a response.  The other side should send a response promptly, in any case, using 100 Trying if it cannot do better.

I think there could be a bug, but it is not a failure to send CANCEL immediately, but rather a failure to hold onto the channel until it gets a response, then send a CANCEL, or BYE, depending on the response.

"I posted 2 traces. In the first one there is no CANCEL. After 0.529074 seconds there is no network traffic any more and the phone rings 'forever'."

The problem is that there is network traffic, a 180 Ringing, then repeated 200 OK's.  If there had been no network traffic, Asterisk would have been at fault to send a CANCEL.

Incidentally, the NOTIFY'a are not part of the INVITE sequence and are irrelevant.
By: David Woolley (davidw) 2010-04-28 11:43:40

For info, ASTERISK-12829 seems to be to remove the bug you are trying to introduce.

A quick look at 1.6.1.0 suggests it does make an attempt to defer the hangup and send CANCEL or BYE, as appropriate.  I don't know if that is mis-implemented, or if it is not in 1.6.0.x.

It does definitely stop resending INVITEs, which looks naughty to me.  It does it by faking a condition, which may well result in unintended side effects.
By: Michael Cramer (micc) 2010-05-27 00:16:35

Did the patch from 0013626 ever make it into a current branch? I am running 1.6.1.20 now and have seen this problem on 1.6.1.19 for sure. I have about 50 customers on this box and most customers with aastra phones see the infinite ringing problem about once a month. It looks like the patch form 0013626 may fix the problem, but is it safe to apply that patch in production? I would think it would be already in 1.6.1 branch if it was deemed safe and solved the problem. I can do some testing with my production machine on weekends pretty safely. If that patch just needs more testing let me know.
By: Ronald Derksen (ronaldderksen) 2010-05-27 02:12:55

I did not check if reversing patch for 0013626 makes the problem disappear. I guess it does. But reversing that patch violates the SIP RFC (Don't know the number). It is not allowed to sent a CANCEL when not yet received anything from phone.

I guess the best way to fix this is. When a channel is hung up and you still receive a 'RINGING' or 'TRYING' then sent a 'CANCEL' or 'BYE' to the phone.


By: David Woolley (davidw) 2010-05-27 05:56:32

I gave the RFC reference a few comments up.
By: David Woolley (davidw) 2010-05-27 06:05:28

Applying the patch doesn't fix the problem.  Removing it may make it appear to work better for you, but would make Asterisk violate a MUST clause in the SIP protocol specification!

What Asterisk should probably be doing is keeping the CANCEL pending, and probably continuing to try and set up the call, until it gets either a non-final response, in which case it should send the CANCEL, or a final one, in which case it should send a BYE.  If the first response from the phone is Ringing, this means there will be, at least, a short burst of ringing, if Asterisk is to comply with the RFC.

Those changes are of at least medium complexity, because this bit of the protocol involves a state machine, rather than an OS thread, controlling the sequencing of operations.

(I seem to remember, from my first reading, that CANCEL is fire and forget, which means a lost CANCEL would leave the phone ringing, so it might be OK to not retransmit the INVITE, if there is no initial response, and simply time out the dialoge, on the basis that the whole CANCEL process is not resillient in SIP.)

PS The patch is in 1.6.1.0, so will certainly be in 1.6.1.20.


By: Michael Cramer (micc) 2010-05-31 04:52:35

Ok, that makes sense now. So if I reversed the patch I would possibly cause problems with other devices, right? How bad would that be? Is asterisk continuing to send the invite after they hung up? It seems like the phone has a problem timing out because it continues to ring forever from what I have heard from my customers. Asterisk wouldn't continue to send an invite for a channel that was hung up for hours after. I've only heard of this happening on Aastra phones. I wonder if I should ask them to put some kind of timeout so the phone can't ever be stuck in ringing state forever.

Doing it the right way you mentioned is not something I'm comfortable attempting as my first patch to chan_sip. I'll certainly take a look around that code and see what it would take if I have some extra time. There should already be some sort of state machine structures that I could add a new state to I would think.
By: Joel Vandal (jvandal) 2010-06-08 14:58:48

I also have this issue using Snom 300 phone. This problem is present on 1.4.32 but when testing with Asterisk 1.4.21.2 (very old), we do not have this issue.

I will try to do more debug next week.
By: Michael Cramer (micc) 2010-07-07 19:12:07

I've reversed the patch and the problem seems to be even worse now. I'm running 1.6.2.8. This is becoming a major problem for a lot of our customers. Also we have one customer which this problem occurs at least once a day but only when someone is on the phone already. I'll be getting a trace for this one soon, the others only see the problem once a week now, but used to be about once a month. I'm going to re apply the patch tonight or tomorrow because it seems to be worse without it.

Is there anything else I can try that would be a hack for now that would at least alleviate the problem until it can be fixed the right way?
By: Stefan Schmidt (schmidts) 2010-07-08 03:56:20

i have tested this and get the same result with asterisk 1.6.2.9 and a linksys spa941 even with the short timeout they have.
invite to phone
call is hung up
getting the 100 trying and 180 ringing and no response from asterisk and phone keeps ringing
By: Ronald Derksen (ronaldderksen) 2010-07-08 04:03:02

It looks like more and more people have this problem. I hope this can be fixed soon.
By: David Woolley (davidw) 2010-07-08 05:38:59

ronaldderksen: this cannot be "fixed" by sending CANCEL before an initial response, as that would be a direct breach of the SIP protocol.  If there is a problem in Asterisk it is that it doesn't keep the cancel pending and then send CANCEL or BYE depending on the first response it gets.  I would say that is a medium complexity change, so it is most likely to get done if one of the people who have the problem submit code for it.
By: Ronald Derksen (ronaldderksen) 2010-07-08 05:57:53

I know, this cannot be fixed by sending a cancel before asterisk received anything back from client. That violates RFC.
If asterisk sends an INVITE and within a few miliseconds asterisk decides it does not want to continue with the INVITE, asterisk should wait for possible responses on the original INVITE and act upon that response.

I just hope that an asterisk developer can fix this the right way.
By: Stefan Schmidt (schmidts) 2010-07-08 07:00:23

this is how you can reproduce it:

exten => _X.,1,Set(TIMEOUT(absolute)=0.03)
exten => _X.,n,Dial(SIP/phoneA,10)
exten => _X.,n,Hangup

maybe you have to try another/shorter timeout value but for me this works with linksys phones to reproduce it.
By: rsw686 (rsw686) 2010-07-08 07:09:59

I've experienced this happening when ringing around 50 SIP phones in a ring group. If somebody answers it immediately some of phones will just continue ringing.
By: Stefan Schmidt (schmidts) 2010-07-08 09:59:15

plz have a look a the patch i´ve made for SVN checkout auf 1.6.2 Rev 274727

i know its not a beautifull code, but it does what it should do.

when a 100 trying or 180 ringing comes in and have no owner, the channel has allready gone, so i send a cancel and destroy these channels.
By: David Woolley (davidw) 2010-07-08 10:37:12

It's going to be a protocol violation, although maybe tolerable as a short term workaround.

However, for a start you have failed to consider that the first response might be 183 or 200, and there are a lot more other possible responses.  1xx responses require CANCEL, but 2xx responses require ACK and BYE.

I'm not sure of the life history of a sip_pvt structure.  Are you relying on its not being deleted when the CANCEL fails.  If so, it should be possible to do it properly, by setting a CANCEL/BYE needed flag.  If not, is one really created transiently for an unmatched response, and if so, does your code ensure that it is not purged immediately.

From when I first looked at this, I got the impression that CANCEL was fire and forget, i.e. there is no ACK for it, so you cannot send it reliably, although maybe my memory is playing tricks.
By: David Woolley (davidw) 2010-07-08 10:38:27

If there is any risk of this getting committed, you need to comment it to explain its limitations.
By: Stefan Schmidt (schmidts) 2010-07-08 12:58:52

its just a point to start solving this problem. as far as i understand the rfc there is no violation with this solution cause:
'If it was allowed to send the CANCEL before receiving a response
     for the previous request, the server could receive the CANCEL
     before the original request.'
The Cancel is send after the previous request creates a response (100 trying, or 180 ringin) and before a final response comes (183,>2xx)

the cancel only will be send when a 100 or 180 response comes in where no owner channel could be found which only could happens when the channel is allready gone. And thats why i could not set a cancel/bye flag cause there is no channel.

the first respond could be a 183 or 200 but these methods are allready checked in asterisk. so if there is a 183 or 2xx response normally a 483 call leg doesnt exist is the response in this case.
a 100 trying or 180 ringing cause nothing even if the channel exists.
Cancel messages doesnt need an ACK, a 487 (Request terminated) could be the response.
By: David Woolley (davidw) 2010-07-08 13:30:35

Something is wrong if 183 is faulted, but not 180.  In any case, you cannot respond with responses to responses!  The only possible response to a response is ACK or CANCEL, and then only for certain methods.

I might be wrong a about the reliability of CANCEL, but the acknowledgment is 200 or 481.  The 487 response is optional and is to the original INVITE.

The possibility that one might think of a no such leg response, would imply the sip_pvt is being created in response to the response.  If it is stray responses should be handled according to the following rules, i.e. discarded; if not you can do this handling properly by remembering the cancel pending state for the dialogue.  (Asterisk is a UA.)

RFC 3261
  If there are any client transactions in existence, the client
  transport uses the matching procedures of Section 17.1.3 to attempt
  to match the response to an existing transaction.  If there is a
  match, the response MUST be passed to that transaction.  Otherwise,
  the response MUST be passed to the core (whether it be stateless
  proxy, stateful proxy, or UA) for further processing.  Handling of
  these "stray" responses is dependent on the core (a proxy will
  forward them, while a UA will discard, for example).

I.e. responding to an unmatched response is a protocol error.
By: Stefan Schmidt (schmidts) 2010-07-08 14:21:52

sorry i´ve missunderstand you.

now i see what you mean and you are right. a cancel to an invite will get a 487 which causes an ACK and a 200 OK back from the client.
i see the 487 from the client, but then the same problem as with the 180 happens, the call leg doesnt exist and nothing happens.

so my patch is just a workaround to stop the phones ringing but its wrong :(

thanks for your explanation david.
back to start ;)
By: Ronald Derksen (ronaldderksen) 2010-07-08 15:07:52

schmidts,

I am going to try your patch tomorrow.
By: Ronald Derksen (ronaldderksen) 2010-07-09 07:47:51

The patch does not work for me. If a use tshark to monitor network traffic between asterisk server (192.168.12.25) and linksys telephone (192.168.12.110) I see the cancel:

 0.000000 192.168.12.25 -> 192.168.12.110 SIP/SDP Request: INVITE sip:410@192.168.12.110:5060, with session description
 0.014692 192.168.12.110 -> 192.168.12.25 SIP Status: 100 Trying
 0.029666 192.168.12.25 -> 192.168.12.110 SIP Request: CANCEL sip:410@192.168.12.110:5060
 0.060139 192.168.12.110 -> 192.168.12.25 SIP Status: 481 Call Leg/Transaction Does Not Exist
 0.085770 192.168.12.110 -> 192.168.12.25 SIP Status: 180 Ringing

But it looks like the linksys telephone does not accept the cancel.

When I try this with my aastra phone, I do not see the cancel. The aastra does not sent a 'trying' message.
By: Ronald Derksen (ronaldderksen) 2010-08-18 06:53:33

I am just wondering if an asterisk developer is going to fix this problem. This problem is very annoying for our customer.
By: Paul Belanger (pabelanger) 2010-08-18 07:52:25

The issue is in the queue, and once a development resource becomes available.  However, if this issue is business critical I would suggest hiring a developer to fix the issue.
By: Ronald Derksen (ronaldderksen) 2010-08-18 08:00:59

The problem is not business critical, it is just very annoying that you get a dead line after picking up a telephone.

Can we hire asterisk developers from Digium to fix this? If so can you give price details?
By: Tan Tuerel (thsgmbh) 2010-08-19 15:31:03

It seems NOT to be related only to Aastra phones.
I have the same problems with Snom 320, Snom 360, Nokia E52 and Cisco 7940.
We have about 70 Extensions and the whole day, many phones in our company are ringing endless. That's absolutely annoying!!!
I can reproduce this issue on EVERY phone model when i call a number and immediately cancel the call before the other phone is ringing.(snom->cisco,nokia->cisco,snom->snom...)
By: David Woolley (davidw) 2010-08-20 04:58:19

pabelanger:  Could I suggest that this is reverted to "feedback", as the candidate fix is reported not to work, but no full SIP debug information has been provided for the failure of the patched version.

thsgmbh:  Have you tried the proposed patch?  If so, are you able to provide SIP debug information for it?

Note though, that the basic problem is already understood - the remaining problem is how to fix it properly.  The problem is that Asterisk is not sending a deferred CANCEL when it is not allowed to send an immediate one.  Sending a deferred CANCEL would stop the phone ringing, but the nature of SIP means it may ring for a short time, as the cancel cannot be issued until the phone has made some response.

I personally have no say in the prioritisation of applying fixes, but to some extent it depends on when Asterisk users with the ability to make code changes find a problem worthwhile to fix.  There is no contractual obligation to fix anything in the open source version of Asterisk, unless you take out an explicit contract with someone for that purpose.
By: Ronald Derksen (ronaldderksen) 2010-08-20 05:13:07

The patch I tried was not a 'candidate fix', it was a hack that violates RFC. For that reason no full debug is needed.

I don't think this bug should be reverted to 'feedback'
By: David Woolley (davidw) 2010-08-20 05:27:24

If it wasn't a candidate fix, or as soon as it was confirmed that it would never work, it should have been reverted to "acknowledged".

My original suggestion of a protocol violation really related to it giving the wrong response to an unsolicited input.  I believe it was intended as an incomplete solution that produced a valid protocol sequence in the specific case in question, although as noted in my original comment, I don't think it was ever going to work.

"confirmed" generally means that there is a patch that, at first sight, removes the bug.
By: Ronald Derksen (ronaldderksen) 2010-08-20 05:37:47

"confirmed" means that the bug report is confirmed as a bug. The availability of a 'patch' is not relevant for status "confirmed".
By: Tan Tuerel (thsgmbh) 2010-08-20 12:39:44

davidw: Patch does not work for me... See attached SIP_TRACE_thsgmbh.txt.
By: Tan Tuerel (thsgmbh) 2010-08-24 06:33:16

I've tested the patch again in our local voip network with snome phones and it seems to resolve the problem!?!
By: Stefan Schmidt (schmidts) 2010-08-24 06:36:28

there is allready a review request for this problem:
https://reviewboard.asterisk.org/r/870/
i´ve allready tried this patch, with the timeout(absolute) setup to reproduce it, and it does what it should do.


By: Tan Tuerel (thsgmbh) 2010-08-26 07:25:01

After some days of testing, I can say that the patch does NOT resolve the problem.
It seems to be a little bit better, but if the call-cancel comes really (!!) short after the call, the phone still keeps ringing...
By: Stefan Schmidt (schmidts) 2010-08-26 08:33:00

what do you mean by really short? i´ve tested it with TIMEOUT(absolute)=0.003 which means 3ms, i dont think its possible to hang up by hand in 3ms and the patch as described in the reviewboard solves this problem.
By: Tan Tuerel (thsgmbh) 2010-08-26 08:55:01

Oh, I'm so sorry... I applied the patch uploaded here (chan_sip.patch).
I will try your short patch from reviewboard.
Is the other patch here also necessary?

Thanks a lot...
By: Stefan Schmidt (schmidts) 2010-08-26 09:02:06

nope, as said above my patch doesnt work!
try the one from reviewboard, it will help
By: Leif Madsen (lmadsen) 2010-08-31 15:24:52

Confirmed means there is a potential patch that is not a candidate for inclusion, but demonstrates an area of code that may need to be modified, or is a patch to be used for debugging. It does not indicate an issue is acknowledged as a real bug or not.

Only when something is moved to Ready for Testing is the patch a candidate for inclusion.

http://www.asterisk.org/doxygen/trunk/MantisWorkflow.html
By: Leif Madsen (lmadsen) 2010-09-07 15:19:09

Requested feedback after testing patch from reviewboard.
By: Michael Cramer (micc) 2010-09-08 00:20:22

Really just removing __sip_pretend_ack(p) is the solution here? I've just built it, I'll give it a try for a couple days and see how it works.
By: Tan Tuerel (thsgmbh) 2010-09-08 02:00:56

I applied the patch (installed asterisk from svn) 14 days ago and since that, the issue seems to be resolved!! No more endless ringing phones... absolutely perfect...

I was a little bit confused that such a small change could resolve the problem...
By: Ronald Derksen (ronaldderksen) 2010-09-08 02:27:53

I will test the review board patch tomorrow.
By: Tan Tuerel (thsgmbh) 2010-09-09 04:40:12

We have a new problem:

Some calls get randomly hangup after some seconds/minutes!? In the Log, you can only see a normal hangup??!!

Could this maybe caused by the above-mentioned patch??
By: Stefan Schmidt (schmidts) 2010-09-09 04:50:28

nope, cause this patch only is used if a cancel to a channel occurs. if the channel is allready up a bye would be send not a cancel.
By: Leif Madsen (lmadsen) 2010-09-09 08:28:21

thsgmbh: in which case you should file a separate issue for that
By: Ronald Derksen (ronaldderksen) 2010-09-11 15:30:47

My own asterisk installation is now running with the reviewboard patch for a couple of days. Until now I was not able to reproduce my problem any more. So far so good.
By: Leif Madsen (lmadsen) 2010-09-13 11:21:36

After speaking with dvossel and seeing that the patch on the reviewboard has fixed this, I'm closing this issue.

The patch on reviewboard was merged at revision r283693 into trunk, and from there merged to all the branches.

Any release created after that revision should have the fix already in it.