Jump to content

BLF Problems in 4.2


jlumby
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

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,

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...