[asterisk-bugs] [Asterisk 0010052]: NOTIFY race condition when state changes happen very fast
noreply at bugs.digium.com
noreply at bugs.digium.com
Sat Feb 23 05:04:24 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=10052
======================================================================
Reported By: raarts
Assigned To: oej
======================================================================
Project: Asterisk
Issue ID: 10052
Category: Channels/chan_sip/Registration
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
Asterisk Version: 1.2.19
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: Yes
Request Review:
======================================================================
Date Submitted: 06-25-2007 08:47 CDT
Last Modified: 02-23-2008 05:04 CST
======================================================================
Summary: NOTIFY race condition when state changes happen very
fast
Description:
This particular problem was encountered with SNOM360 phones, but it is not
specific to it.
What happens:
- SNOM has subscribed a LED to another phone
- SNOM user dials this other phone.
- dialplan adds an answer-after=0 SIP header.
- asterisk send INVITE to the other phone
- other phone send back RINGING, this is sent back to the SNOM as well
- asterisk send NOTIFY 'early' to the SNOM
- meanwhile, the other phone answers very quickly
- asterisk sends OK to INVITE to SNOM to indicate the other phone
has answered the line, and immediately after that, a NOTIFY 'confirmed'.
At this point in time the OK to the previous NOTIFY 'early' has not
been sent yet by the SNOM.
Now the system is confused, because the SNOM finally sends the OK
to the NOTIFY 'early', but asterisk is only expecting an OK to the
last sent NOTIFY, and starts retrying. See attached trace.
I think asterisk should not sent a new NOTIFY. I think ideally NOTIFY's
should be queued on a per-channel basis. Or should asterisk remember
earlier
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0011736 sip hung channels and UDP ports
related to 0011231 [patch] Many retransmits when chan_sip ...
======================================================================
----------------------------------------------------------------------
brainy - 02-23-08 05:04
----------------------------------------------------------------------
We still have problems with the lastest chan_sip and the LED's on the Snom
phones.
We have the following dialrule:
exten => 1,1,Dial(SIP/foo,5)
exten => 1,2,Dial(SIP/foo&SIP/bar)
When a call comes in, the LED for "SIP/foo" is blinking, which is correct.
After 5 seconds only the "SIP/bar" is blinking and the asterisk tells
something about that the devicestate for "SIP/foo" was changed to "Invalid"
and then to "Ringing" ... My guess is, thats because the status for
"SIP/foo" changes too fast from "Ringing" to "Idle" to "Ringing"
We're still using the "simple 3rd party patch" (removing the "else if" to
an "if") and it's working almost well for us.
But i would appreciate it if it's officially being fixed.
Thanks
Issue History
Date Modified Username Field Change
======================================================================
02-23-08 05:04 brainy Note Added: 0082802
======================================================================
More information about the asterisk-bugs
mailing list