[Home]

Summary:ASTERISK-03706: When call is destroyed, 487 "Request Cancelled" packets seem to cycle around for too long
Reporter:Serge Vecher (serge-v)Labels:
Date Opened:2005-03-18 22:06:27.000-0600Date Closed:2005-03-28 00:23:51.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sip_debug_100-101_487_request.txt
( 1) sip_debug_100-105_487_request.txt
( 2) sip_debug_bug3796_fixed.txt
Description:After a SIP call is destroyed, there seems to be an excess of 487 packets floating around for about 10-15 seconds after call destruction is scheduled. Under light call volume this is not a problem. However, in a scenario where many short-duration calls are placed-received over a period of time (typical receptionist situation) excessive traffic seems to cause a "denial of service" on a Cisco IP 7900 series phone with "486 Busy here" being bounced back from a Cisco phone. Not a problem if downgrading to previous CVS version(1 week ago).

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

Phones used -> Cisco 7940/60G (SIP7.3 firmware
Comments:By: Olle Johansson (oej) 2005-03-19 03:02:34.000-0600

Can you please run the two tests with the same devices and configurations on the devices? Seems like you have another configuration in the second test.

I can't find any difference in Asterisk's behaviour in these two tests. The difference is that we have two differently configured devices - one on 105 and one on 101 that we're talking with and they react in different ways.
--------------
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 192.168.1.14:5060;branch=z9hG4bK06a9afbc;rport
From: "Serge Vecher" <sip:105@192.168.1.14>;tag=as53ee269c

SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 192.168.1.14:5060;branch=z9hG4bK20969542;rport
From: "Serge Vecher (videophone)" <sip:101@192.168.1.14>;tag=as14d3c30f
By: Olle Johansson (oej) 2005-03-19 08:25:12.000-0600

Please check if the patch in ASTERISK-3705 solves the problem...
By: Serge Vecher (serge-v) 2005-03-19 11:33:11.000-0600

oej, I've included debugs from different devices to illustrate that it is not a multi-client issue.

Testing patch 3795 now.

serge
By: Serge Vecher (serge-v) 2005-03-19 12:57:22.000-0600

This fixed it as evidenced from debug. Fine work, Olle. Thank you!

Serge

edited on: 03-19-05 12:57
By: Olle Johansson (oej) 2005-03-19 15:15:44.000-0600

It's always easier to find the difference if you compare logs from the *same* device with different code. Extra log files with another device is also helpful, but you need two with the same device to judge which part is in error.

Anyway, thank you for your detailed report, it made it easier to spot the problem!

/O
By: Stavros K (kourakos) 2018-08-01 17:56:25.809-0500

This issue continues up to today.We are using asterisk 11 and 13 and it has the same behaviour. Where can i find the patch to see if it solves the problem?
By: Joshua C. Colp (jcolp) 2018-08-02 04:25:58.759-0500

[~kourakos] This issue is 13 years old, the change in question would have gone into the code at that time. If you are still having a problem then please open a new issue but be aware that chan_sip is community supported and there is no timeframe on when it would get looked into.