[asterisk-bugs] [Asterisk 0011821]: Incorrect SIP Notification after failed dialing attempt

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11821 
====================================================================== 
Reported By:                siepkes
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11821
Category:                   Channels/chan_sip/Subscriptions
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-23-2008 05:28 CST
Last Modified:              01-23-2008 08:40 CST
====================================================================== 
Summary:                    Incorrect SIP Notification after failed dialing
attempt
Description: 
I'm currently doing some experimenting with a couple of Grandstreams GXP
2020 loaded with the latest firmware (1.1.5.15) and Asterisk 1.4.17 and I
noticed something odd. 

If an extension dials a non existing number like 99 for example the BLF
status on all other phones remains BUSY even tough the calling extension
has become IDLE again after the failed dial attempt.

For some reason in my case it always seems to happen when I dial a 2 digit
or more non existing number. It doesn't happen with an 1 digit number.

BLF LED State: - Asterisk Message:
GREEN - Extension Changed 201 new state Idle for Notify User siepkes
RED - Extension Changed 201 new state InUse for Notify User siepkes
RED - Extension Changed 201 new state Idle for Notify User siepkes

However if i put the everything in debugmode and look at the logs I see
that the phones receive a flood of SIP Dialog state confirmed after the SIP
Dialog state terminated which causes the phones to turn the BLF red again.

Other then that the BLF's work fine. This is how they are configured in
extensions.conf:

[BLF_Group_1]
exten => 201,hint,${PH0001}
exten => 202,hint,${PH0002}
exten => 203,hint,${PH0003}
exten => 204,hint,${PH0004}
exten => 205,hint,${PH0005}
exten => 206,hint,${PH0006}
exten => 207,hint,${PH0007}
exten => 208,hint,${PH0008}
exten => 211,hint,${PH0009}

I have attached the SIP debug trace from extension 207 (PH0001) registered
with SIP/siepkes and extension 201 (PH0002) registered with SIP/sipsma. 201
makes a dial attempt to 99, which fails. 207 has the wrong status of 201
afterwards. Also attached is the debug from the Grandstream phone 207.

I'm not sure why the Retransmitting (which causes this behavior imho) is
occurring since Asterisk does seem to receive OK's for the SIP messages.
====================================================================== 

---------------------------------------------------------------------- 
 oej - 01-23-08 08:40  
---------------------------------------------------------------------- 
Ok, this is the same bug that we already have in other bug reports. We send
several NOTIFYs and the phone actually responds with 200OK, but we
retransmit the previous notify that indicated an open line. We should not
at that time do that. I need to research this anyway, but this is a
duplicate bug report that will be closed.

Thanks for all your patience and information, it really helps. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-23-08 08:40  oej            Note Added: 0081089                          
======================================================================