BLF Problems in 4.2

[jlumby]

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.

[pbx support]

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?

[polycom2080]

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

[jlumby]

Windows

[pbx support]

Windows

 

http://pbxnsip.com/protect/pbxctrl-4.2.0.3954.exe should have the fix for it.

[polycom2080]

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,

[olecoot]

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?

[jlumby]

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.

[Vodia PBX]

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...

[jlumby]

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.

[Vodia PBX]

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.

[polycom2080]

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

[jlumby]

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

[pbx support]

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.

[jlumby]

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

[Vodia PBX]

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.

[pbx support]

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.

[polycom2080]

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

[jlumby]

So far so good when it comes to the Aastra phones

[jlumby]

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.

[Vodia PBX]

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?

[jlumby]

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

[Vodia PBX]

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.

[jlumby]

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.