Summary:	ASTERISK-13868: Asterisk shouldn't send dialog NOTIFY <state>early</state> until it receives a 1XX-non100 response from the callee
Reporter:	Iñaki Baz Castillo (ibc)	Labels:
Date Opened:	2009-03-31 10:52:57	Date Closed:	2011-07-26 14:13:44
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Subscriptions
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) NOTIFY_state_early_Wrong.txt
Description:	Escenario: 1) "CALLER" and "CALLEE" are users of the PROXY and exist as friend's in sip.conf with "host=PROXY". 2) Phone "SUBSCRIBER" is subscribed to dialog status of phone "CALLEE" in ASTERISK. 3) "CALLER" calls to "CALLEE" throught the PROXY. 4) PROXY routes the INVITE to ASTERISK. 5) Asterisk generates a NOTIFY for SUBSCRIBER with <state>early</state>  <--- WRONG ! 6) The PROXY receives the INVITE and returns 480 since CALLEE is not registered. 7) Asterisk then sends a NOTIFY <state>terminated</state> to SUBSCRIBER. Step 5 is wrong. According to RFC 4235, Asterisk *shouldn't* generate a NOTIFY <state>early</state> until it receives a provisional (non 100) response from the callee (so containing To_tag). In the above case, this means that Asterisk shouldn't send a NOTIFY to the subscriber since the callee didn't ring (it wasn't registered in the proxy in fact). I've tested and the behaviour of Asterisk is the *same* when using local SIP users instead of remote SIP users. Conclusion: Asterisk should send a dialog NOTIFY <state>early</state> just in the case it receives a 1XX non100 response from the callee: - If the user is local and is not registered, Asterisk shouldn't generate a NOTIFY. - If the user is local and *is* registered, but doesn't reply to the Asterisk INVITE (phone crash?), Asterisk shouldn't generate a NOTIFY. - If the callee is remote, Asterisk shouldn't generate a NOTIFY if it doesn't receive a provisional 1XX non100 response from the callee. I attach a SIP trace showing the above scenario and SIP flow.
Comments:	By: Iñaki Baz Castillo (ibc) 2009-04-23 11:39:25 No reply on this issue? By: Olle Johansson (oej) 2009-09-04 04:11:50 I just discovered this today, haven't spent much time on the tracker lately. You assume that we do things the RFC way, but we don't really. Our implementation is just using various messages to get the lamps to blink the way users want.  Because of the PBX layer that controls Asterisk we can't really follow the RFCs to every single letter. Having said that we have to try our best :-) This needs to be looked into to see if we're reacting to the wrong state change. We should not send notify in CALLING state, but in RING or PROCEEDING in asterisk-language. By: Leif Madsen (lmadsen) 2011-07-26 14:13:39.181-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions