| Summary: | ASTERISK-07343: Sending CANCEL instead of a BYE | ||
| Reporter: | Irving Barr (irving_wp) | Labels: | |
| Date Opened: | 2006-07-15 09:53:53 | Date Closed: | 2011-06-07 14:08:11 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) sip_debug_bad_call.txt ( 1) sip_debug_good_call.txt | |
| Description: | When caller hangs up first, Asterisk issues a BYE in the call leg for the callee (correct behavior). When is the callee who hangs up first, Asterisk issues a CANCEL in the call leg of the caller, and since the caller doesn't wait a CANCEL in a established call, it keeps the call open. ****** ADDITIONAL INFORMATION ****** IT ONLY HAPPENS WHEN canreinvite=yes IS SET IN sip.conf. IF I SET canreinvite=no, THEN NO MATTERS WHO HANGS UP FIRST, THE CALL IS ENDED IN BOTH DIRECTIONS. | ||
| Comments: | By: Jason Parker (jparker) 2006-07-15 19:21:36 This is probably something oej would know more about, but in reading "the" RFC, it appears that the Nimbus SIP Server should be responding to the CANCEL with either a 200 (OK) or 481 (Transaction Does Not Exist), and it isn't doing so. By: Jason Parker (jparker) 2006-07-15 19:22:13 ping By: Irving Barr (irving_wp) 2006-07-16 21:08:01 In fact, the Nimbus SIP Server is actually the Asterisk Box (Nimbus is just an alias user-agent name) so that all SIP messages with user agent = Nimbus SIP Server are actually originated in the Asterisk Server. I hope this helps to understand the debugs better. What you state is all right, but I've seen that it depends on the client phones, e.g. some phones actually answer with a 481 whilst others just ignore the CANCEL and in both cases they keep the call established... agreed, the behavior of the clients is not the problem here :) By: Irving Barr (irving_wp) 2006-07-17 15:17:16 ok, it seems that the problem is fixed in version 1.2.10... :) Thanx! By: Jason Parker (jparker) 2006-07-17 15:41:54 Already fixed in 1.2.10. Next time when reporting a bug, please test against the latest svn revision for that branch. | ||