jlumby Posted October 5, 2010 Report Share Posted October 5, 2010 I have been following the 4.2 releases to see when issues with BLFs will get fixed up. With the early releases of 4.2 I noticed that the BLFs on phones woulg get stuck in their first state. I then noticed that in later releases the issue got resolved for some phones such as Yealink, however Aastra still had the stuck BLF issue. Now with the latest release of 4.2.0.3950 the BLFs do not light at all on any of the phones I have tested. I did a packet capture, and noticed that the PBX responds to the subscribe with a "489 Bad Event" error. Please let me know if there are any builds in the near future that will clean this issue up. I am looking for a very nice stable version of 4 that I can recommend. The problem is I do not feel that V4 has accomplished that yet. I was very happy with the stability of 3.4.0.3202 however lack of DoS protection and some memory issues was it's only shortcoming. I feel like with version 4 these 2 shortcomings of V3 were fixed, however many new issues were introduced. Quote Link to comment Share on other sites More sharing options...
pbx support Posted October 5, 2010 Report Share Posted October 5, 2010 I have been following the 4.2 releases to see when issues with BLFs will get fixed up. With the early releases of 4.2 I noticed that the BLFs on phones woulg get stuck in their first state. I then noticed that in later releases the issue got resolved for some phones such as Yealink, however Aastra still had the stuck BLF issue. Now with the latest release of 4.2.0.3950 the BLFs do not light at all on any of the phones I have tested. I did a packet capture, and noticed that the PBX responds to the subscribe with a "489 Bad Event" error. Please let me know if there are any builds in the near future that will clean this issue up. I am looking for a very nice stable version of 4 that I can recommend. The problem is I do not feel that V4 has accomplished that yet. I was very happy with the stability of 3.4.0.3202 however lack of DoS protection and some memory issues was it's only shortcoming. I feel like with version 4 these 2 shortcomings of V3 were fixed, however many new issues were introduced. We saw this 489 issue yesterday in the lad and fixed it already. What OS are you running there? Quote Link to comment Share on other sites More sharing options...
polycom2080 Posted October 5, 2010 Report Share Posted October 5, 2010 We saw this 489 issue yesterday in the lad and fixed it already. What OS are you running there? we are having as well an issue with the latest version 4.2.0.3930 that on the polycom the BLF will remain ON/Blinking Evan that ext have answer the phone, do you have an update for WIN32 for that bug ? Thanks in advanced Quote Link to comment Share on other sites More sharing options...
jlumby Posted October 7, 2010 Author Report Share Posted October 7, 2010 Windows Quote Link to comment Share on other sites More sharing options...
pbx support Posted October 8, 2010 Report Share Posted October 8, 2010 Windows http://pbxnsip.com/protect/pbxctrl-4.2.0.3954.exe should have the fix for it. Quote Link to comment Share on other sites More sharing options...
polycom2080 Posted October 8, 2010 Report Share Posted October 8, 2010 http://pbxnsip.com/protect/pbxctrl-4.2.0.3954.exe should have the fix for it. thanks for the update, but the issue with the polycom BLF remain the same, once of your ext that you watch gets a call the light will just stay on forever.. as well when i am on the phone and one of the ext gets a call i will experience a call waiting beet as i would have a beep, Quote Link to comment Share on other sites More sharing options...
olecoot Posted October 8, 2010 Report Share Posted October 8, 2010 thanks for the update, but the issue with the polycom BLF remain the same, once of your ext that you watch gets a call the light will just stay on forever.. as well when i am on the phone and one of the ext gets a call i will experience a call waiting beet as i would have a beep, Is this version available for CentOS 5? Quote Link to comment Share on other sites More sharing options...
jlumby Posted October 8, 2010 Author Report Share Posted October 8, 2010 With this latest version that you posted, the BLFs light up on the Aastra, however they just like the previous post about the Polycom BLFs getting stuck, the Aastra BLFs get stuck as well. I did a packet capture, and I found that the PBX was sending the Notify to the phone, however the phones were rejecting it and responding with 500 CSeq out of order. I tried rebooting the phones, and the same issue happened during the first call after the reboot. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 11, 2010 Report Share Posted October 11, 2010 With this latest version that you posted, the BLFs light up on the Aastra, however they just like the previous post about the Polycom BLFs getting stuck, the Aastra BLFs get stuck as well. I did a packet capture, and I found that the PBX was sending the Notify to the phone, however the phones were rejecting it and responding with 500 CSeq out of order. I tried rebooting the phones, and the same issue happened during the first call after the reboot. Yes, this is a know problem with the Aastra phones. They register using SUBSCRIBE, and then when the PBX restarts it sends a SUBSCRIBE again as if nothing happened. The PBX then sends NOTIFY with "fresh" CSeq numbers which are really out of order from the device perspective. We'll try to send a 410 Gone code when we receive a "fresh" (as from the PBX point of view) subscription. That should solve the problem; hopefully it does not break anything with other devices... Quote Link to comment Share on other sites More sharing options...
jlumby Posted October 11, 2010 Author Report Share Posted October 11, 2010 Yes, this is a know problem with the Aastra phones. They register using SUBSCRIBE, and then when the PBX restarts it sends a SUBSCRIBE again as if nothing happened. The PBX then sends NOTIFY with "fresh" CSeq numbers which are really out of order from the device perspective. We'll try to send a 410 Gone code when we receive a "fresh" (as from the PBX point of view) subscription. That should solve the problem; hopefully it does not break anything with other devices... I have been aware of the issue you describe as occuring in all versions of PBXnSIP, however this is a new issue that only exists in 4.2 releases. The difference is that the BLFs get stuck after their first use, and the PBX is not rebooted. Each time the phones are reset, the BLFs light once, and get stuck again. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 11, 2010 Report Share Posted October 11, 2010 I have been aware of the issue you describe as occuring in all versions of PBXnSIP, however this is a new issue that only exists in 4.2 releases. The difference is that the BLFs get stuck after their first use, and the PBX is not rebooted. Each time the phones are reset, the BLFs light once, and get stuck again. If you like send an email to support for the latest build. Maybe the problem is solved now. Quote Link to comment Share on other sites More sharing options...
polycom2080 Posted October 12, 2010 Report Share Posted October 12, 2010 If you like send an email to support for the latest build. Maybe the problem is solved now. was the issue resolved ? if yes please post a link Quote Link to comment Share on other sites More sharing options...
jlumby Posted October 12, 2010 Author Report Share Posted October 12, 2010 was the issue resolved ? if yes please post a link I will when it is, however support still has not responded to my email request Quote Link to comment Share on other sites More sharing options...
pbx support Posted October 13, 2010 Report Share Posted October 13, 2010 I will when it is, however support still has not responded to my email request There are couple of issues in this area. We have fixed one and there is one more pending. We are working with Polycom (& Aastra) to resolve this issue. Quote Link to comment Share on other sites More sharing options...
jlumby Posted October 13, 2010 Author Report Share Posted October 13, 2010 There are couple of issues in this area. We have fixed one and there is one more pending. We are working with Polycom (& Aastra) to resolve this issue. The problem with your statement is that starting with the first version of 4.2 the CSeq number would decriment without the PBX being restarted. This goes against the SIP RFC. Here is a packet capture that shows it happening without the PBX being restarted. This is purely a PBXnSIP problem, and the only reason that some models of phones do not have an issue with it is because they are not strictly holding the PBX to the RFC. cseq.zip Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 13, 2010 Report Share Posted October 13, 2010 The problem with your statement is that starting with the first version of 4.2 the CSeq number would decriment without the PBX being restarted. This goes against the SIP RFC. We fixed one thing and another one popped up. One step forward, one back. However, it seems that we now made two steps forward and only one back. Quote Link to comment Share on other sites More sharing options...
pbx support Posted October 14, 2010 Report Share Posted October 14, 2010 We fixed one thing and another one popped up. One step forward, one back. However, it seems that we now made two steps forward and only one back. http://pbxnsip.com/protect/beta/win32/pbxctrl-4.2.0.3956.exe should have the fix for the BLF. We tested this on Polycom (where the problem was happening before) and verified it is fixed. Haven't had a chance to test with the Aastra. If you can test it & update the group, we'd appreciate it. Quote Link to comment Share on other sites More sharing options...
polycom2080 Posted October 14, 2010 Report Share Posted October 14, 2010 The BLF seems to work well to show if the ext is on a call, or haves an incoming call, but to grab a call and answer via pressing BLF it will only work if its an internal call, if its a call from external it worn work, ( seems that it send *87 and the ext number, {example *87201} if its from an outside call it sends {sip:*87+19787462777@pbx.snomone.com} and the PBX send back a 404 to that request as well the MWI just keeps on all the time Evan after doing *99 please advice Quote Link to comment Share on other sites More sharing options...
jlumby Posted October 17, 2010 Author Report Share Posted October 17, 2010 So far so good when it comes to the Aastra phones Quote Link to comment Share on other sites More sharing options...
jlumby Posted October 18, 2010 Author Report Share Posted October 18, 2010 I went on a little further to test to see if the BLFs worked after a PBX reboot. I see that the PBX replies to the subscribe with a 410 Gone now. It was worth a try, however unfortunately, the phone just gives up when it gets the 410 Gone message, so it is probably not worth having that portion in the code. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 19, 2010 Report Share Posted October 19, 2010 I went on a little further to test to see if the BLFs worked after a PBX reboot. I see that the PBX replies to the subscribe with a 410 Gone now. It was worth a try, however unfortunately, the phone just gives up when it gets the 410 Gone message, so it is probably not worth having that portion in the code. Does the "410 Gone" include the "Retry-After" header? Quote Link to comment Share on other sites More sharing options...
jlumby Posted October 19, 2010 Author Report Share Posted October 19, 2010 Does the "410 Gone" include the "Retry-After" header? Correct, it does include Retry-After: 60 I have also noticed that after a PBX reboot, Yealink phone BLFs stop functioning. This was not an issue prior to this 4.2.0.3956 build. To sum everything up, while the PBX has not been rebooted, BLFs on all phones seem to work perfectly, however after a reboot Yealink, and Aastra BLFs do not work. In previous versions 4.1 and earlier, only the Aastra BLFs were effected by a reboot, now the Yealink ones are as well. I am attaching a packet capture to show 2 occasions of 2 different Aastra subscriptions, and the 410 that the PBX is sending back. retry.zip Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 19, 2010 Report Share Posted October 19, 2010 To sum everything up, while the PBX has not been rebooted, BLFs on all phones seem to work perfectly, however after a reboot Yealink, and Aastra BLFs do not work. In previous versions 4.1 and earlier, only the Aastra BLFs were effected by a reboot, now the Yealink ones are as well. I am attaching a packet capture to show 2 occasions of 2 different Aastra subscriptions, and the 410 that the PBX is sending back. Right, now the problem is that the UA keeps the To-tag, even after retrying after the Answer-After. This is "one step forward, two steps back"... Anyway, the way to solve this problem it to take a look at the standard. A subscription is destroyed when a notifier sends a NOTIFY request with a "Subscription-State" of "terminated". A subscriber may send a SUBSCRIBE request with an "Expires" header of 0 in order to trigger the sending of such a NOTIFY request; however, for the purposes of subscription and dialog lifetime, the subscription is not considered terminated until the NOTIFY with a "Subscription-State" of "terminated" is sent. If a subscription's destruction leaves no other application state associated with the dialog, the dialog terminates. The destruction of other application state (such as that created by an INVITE) will not terminate the dialog if a subscription is still associated with that dialog. Nice, that would mean the PBX should send a NOTIFY? I doubt that this would solve the problem, as the UA probably will still keep the To-Tag. IMHO the dialog will time out eventually and then the UA must send a new subscription, which must not have a To-tag. That would solve the problem. Quote Link to comment Share on other sites More sharing options...
jlumby Posted November 22, 2010 Author Report Share Posted November 22, 2010 Just checking to see if there has been any more progress on this. I am currently testing 4.2.0.3961 and it has the advantage of the cseq numbers staying in sequence as long as the PBX is not restarted (this was a problem in the original 4.2 release, and fixed about half way through), however when the PBX is rebooted, Aastra, Grandstream, and Yealink BLFs stop working when the get the 410 error from the PBX. I know this was added as an attempt to fix Aastra BLFs after a reboot, however it has not, and it has created a new problem with Yealink, and Grandstream (that accept out of sequence cseq numbers). I was wondering if we could find a middle ground where the PBX does not send a 410 after a reboot, however the cseq numbers stay in order as long as the PBX is not rebooted. I feel this is the best compromise so far. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.