[asterisk-bugs] [Asterisk 0014793]: Asterisk shouldn't send dialog NOTIFY <state>early</state> until it receives a 1XX-non100 response from the callee

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14793 
====================================================================== 
Reported By:                ibc
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14793
Category:                   Channels/chan_sip/Subscriptions
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Target Version:             1.4.27
Asterisk Version:           1.4.23 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-31 10:52 CDT
Last Modified:              2009-09-04 04:11 CDT
====================================================================== 
Summary:                    Asterisk shouldn't send dialog NOTIFY
<state>early</state> until it receives a 1XX-non100 response from the callee
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0110219) oej (manager) - 2009-09-04 04:11
 https://issues.asterisk.org/view.php?id=14793#c110219 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-04 04:11 oej            Note Added: 0110219                          
======================================================================