[Home]

Summary:ASTERISK-11282: Incorrect SIP Notification after failed dialing attempt
Reporter:Jasper Siepkes (siepkes)Labels:
Date Opened:2008-01-23 05:28:30.000-0600Date Closed:2011-06-07 14:08:17
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Subscriptions
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterdebug_ph0001.txt
( 1) asterdebug_ph0002.txt
( 2) combined_coredebug5_sipdebug_V2.txt
( 3) combined_coredebug5_sipdebug_V3.txt
( 4) gxp2020debug.txt
( 5) show_subscriptions.txt
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.
Comments:By: Olle Johansson (oej) 2008-01-23 06:05:50.000-0600

I would like to see a combined debug log, with core set debug to 5, core set verbose to 5. Also at start, please issue "sip show subscriptions".

With one combined file, I can more easily follow the chain of events.
Thanks
/O
By: Jasper Siepkes (siepkes) 2008-01-23 06:54:24.000-0600

Thanks for the quick response!

I disconnected other phones and commented out their subscriptions in extensions.conf to get a less garbled/crowded debug log.

The attached debug log (combined_coredebug5_sipdebug.txt) is with 'core set debug 5' and 'sip set debug'. I also did a 'sip show subscriptions before and after dialing the non existing extension.

Hope this helps!
By: Olle Johansson (oej) 2008-01-23 06:56:37.000-0600

Please check logger.conf - there's a lot of logging missing. Make sure you enable debug logs. Thanks.
By: Jasper Siepkes (siepkes) 2008-01-23 07:13:21.000-0600

Sorry about that :-(

Here is the second attempt: combined_coredebug5_sipdebug_V2
By: Olle Johansson (oej) 2008-01-23 07:19:01.000-0600

I need a combined log file - this time it was ONLY the debug output... :-)

I need sip debug, core debug, core verbose - all of it. And "sip show subscriptions".

Please try again!
By: Jasper Siepkes (siepkes) 2008-01-23 07:51:09.000-0600

I think I got it right this time, only took me 3 times :-)

The show subscriptions seems to list the state of the phones OK.
By: Olle Johansson (oej) 2008-01-23 08:40:33.000-0600

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.
By: Olle Johansson (oej) 2008-02-03 09:40:35.000-0600

please test with latest 1.4 from svn. Thanks.
By: Jasper Siepkes (siepkes) 2008-02-06 03:36:46.000-0600

I'm a bit swamped with work right now. Ill test the fix ASAP, that will be tomorrow I hope.
By: Vladan Bato (vbato) 2008-02-16 11:33:43.000-0600

I have the same problem with asterisk 1.4.18 and GXP 2000 phones (various firmwares, including latest).

However this is not the only problem with BLFs that I noticed. The BLFs will often get stuck in the busy or ringing state. This happens frequently when I call a busy extension. The extension will be shown as ringing on the other phones and remain in that state even after it becomes Idle (according to 'core show hints' and 'sip show subscriptions'). Sometimes the BLFs for the calling extension will also remain stuck in the busy state. This however is not as repeatable as the problem reported by siepkes, as it doesn't happen always, and sometimes it happens only on some of the phones.

As it is, hints are unusable with Grandstream phones as they are too unreliable.
By: Jason Parker (jparker) 2008-04-01 18:08:27

1.4.18 was tagged before oej's comment on 02/03 requesting testing with the latest from svn.

Has anybody been able to do that?
By: Jasper Siepkes (siepkes) 2008-04-02 03:18:56

Sorry I didn't get back sooner, kinda fell of my todo list :-(

I did a test with 1.4.18.1 and some Grandstream phones and I'm unable to reproduce the problem, so it looks solved to me.
By: Joshua C. Colp (jcolp) 2008-04-02 11:33:24

Closed per reporter. Props to oej for fixing it.