|Summary:||ASTERISK-17800: Phones Ring Forever When Termination Signal Comes Shortly After Initiating Signal|
|Reporter:||M. Anderson (adv99)||Labels:|
|Date Opened:||2011-05-05 00:58:47||Date Closed:||2011-06-07 14:00:52|
|Description:||This bug causes phones to ring forever when you get a hang-up call, such as when someone dials the wrong number, or you receive a call from a mobile caller with spotty coverage (and whose call is immediately dropped after completing).|
The problem is relatively easy to duplicate:
1. Pick-up one extension.
2. Dial your own extension, another extension, or (preferably) a ring group, and press the send button/line button on the phone to initiate the call.
3. Wait between 50ms and 250ms (long enough for the call to get through to Asterisk, but before the call starts ringing on the receiving phones).
4. Terminate the call by pressing the disconnect button.
5. Each extension you called (Ring Group or Extension, as the case may be) will start ringing and continue ringing until each individual phone is answered. If you called a ring group, each phone must be individually answered, as answering one phone does not stop the ringing on the other phones.
If the problem doesn't occur the first time, try varying the timing slightly (or better yet, simulate the issue by sending the packets one after the other from a script).
The Asterisk logs show that everything worked fine, i.e. ringing state set, idle state set, but the phones (including phones made by Aastra, Siemens, and Grandstream) don't receive the signal terminating the call and so they keep ringing and ringing...
|Comments:||By: David Woolley (davidw) 2011-05-05 05:30:12|
1.4.x is no longer supported, except for security issues.
This is a duplicate report, although I don't have time to track down the original. The basic problem is that SIP UACs are not allowed to cancel a call until they have had an initial response from the UAS. Asterisk is realising that it cannot send the cancel, but failing to maintain the dialogue open and schedule a deferred cancel/bye.
(I commented on the original, which may help you find it.)
PS All SIP related reports should have sip debug and sip history output attached.