yealink park blf fun

[s2svoip]

Read thru all the posts here about the issues with Yealink and BLF lights on park buttons - but there doesn't seem to be a definitive answer.

I have some T40G's that are working perfectly, showing the BLF light on the park button with it set up as Call Park and park+*5901 but the exact same settings on T42S or T43U don't work at all, the BLF light does not light up in any way, i tried setting the button as a BLF instead of call park button and also tried park+*5901@sub.domain.com but no change

had anyone managed to get the BLF lights working properly with call park, else you have no idea someone is parked in there!

 

[hfoster]

We run the whole gamut of Yealink's in the 4 series, and have never had to do anything particularly special to get call park lights working.

We either:
- BLF = park+*5901
- Call Park = park+*5901

(Some of the older lads use BLF for EVERYTHING...)

It is worth noting the the phones with dual colour LEDs that can go green and red do act a bit differently to the single colour ones. I can't remember if the 40G is a single colour one or not. features.blf_led_mode can change that in the Yealink config, think there's a FusionPBX variable for it $yealink_blf_led_mode

Are you talking about the light not changing at all though?

 

[s2svoip]

Yah the light does not light up at all in anyway, works perfect on the T40G, but nothing else, all in the same tenant in fusion - just don't understand ...

 

[hfoster]

Odd, I would like to suggest something. But it's just a fundamental part of sip_sofia. Lights for call flows, dnd, etc are set in /etc/freeswitch/autoload_configs/lua.conf.xml but just normal BLF?

I would recommend a packet capture either from the PBX using sngrep, or from the Yealink phones themsevles to make sure they are at least recieving the messages. Should look like dialog+info XML packets.

 

[s2svoip]

should there be something I am searching for in the pcap specifically ? I did a factory reset on a t43u started the capture and assigned the button to park+*5901 but the light did not show up, but not sure what I should be looking for in the capture

 

[hfoster]

Not really, just that your phone is receiving the status change packets when a BLF actually changes.

 

[s2svoip]

thanks @hfoster

so I have the T43U and a T54W on the same system, the park BLF works perfectly on the T54W, I did a capture on that and activated the park line from the T43U, the led changes just as it should, what should I look for on the T54W capture that's changing the LED, I've got wireshark up and filter for sip

 

[hfoster]

I believe it's a SIP INFO packet, with dialog+info XML inside it.

It's very strange it works on some models but not others.

 

[s2svoip]

so after doing captures on both a working and non-working device, i can see the sip flow on the working device, its getting a NOTIFY 200

when I do the same test on the T43U its not getting them at all, so how could that be ?

I checked out /etc/freeswitch/autoload_configs/lua.conf.xml and did see everything is commented out, assume this is how it should be ..? I mean its working on the T54W - this is so strange

 

[s2svoip]

Further testing, I got a brand new T43U and did not use fusion provisioning with it, manually added the account and set up the park button and the BLF works perfectly, so its something to do with the provisioning template fusion is using. any tips on where to look in the template, I found the yealink blf in default settings but I am not using this at all

 

[hfoster]

Hmmm, that's interesting. If I had to guess: $yealink_rport
That's off by default on Yealinks, but is almost mandatory in most setups. However it could be a SIP ALG thing....

Possibly: features.blf_led_mode = {$yealink_blf_led_mode} if you have change the default settings in the Yealink provisioning section.

A useful feature of Yealink is exporting the config and you can see all the things that are different from the default out of box config. That might be useful here.

 

[hfoster]

As for the lua.conf.xml, that's perfectly normal unless you want the 'extended' uses of BLFs (i.e, monitor a call flow or a DND status). They're off by default as it does vary wildly from vendor to vendor.

 

[s2svoip]

tried changing the rport, no change. I downloaded both config files to compare but it doesn't help too much as the full working T43U has 27 lines of config vs the auto provision non-working handset that has 166 - there's a ton of additional settings so not sure what one could be causing the lamp not to work at all - very interesting issue that's also affecting a T42S also, I haven't made any changes to the default settings in yealink provisioning and sip alg is 100% disabled and always has been. this is really head scratching

 

[s2svoip]

so after some extensive testing, I found its due to having 2 sip servers set in the account, I have 100@tennant.domain.com as the username, then pbx1.domain.com as sip server 1 host and pbx2.domain.com as sip server 2 host - this is my HA setup. as soon as I remove the 2nd sip server, the blf lights up and works perfectly. appreciate your responses @hfoster

do you have any insight into why this might affect the park blf this way ?

 

[hfoster]

Getting closer, have you got the keys set to the correct lines? I think you *can* do the Line 0 trick with BLFs, but I'm not sure.

 

[s2svoip]

well as soon as I remove the 2nd sip server it works perfect, so the keys are setup correct its something to do with having 2 sip servers. I can see in Fusion you can set keys on line 0 but not an actual line. what is the line 0 trick ?

 

[hfoster]

Can't verify it for all models, but Line 0 means whatever my active line is. (Left and right arrows to switch between them)

For your HA setup, you are replicating the core database too right? By default it's stored as a file in /var/lib/freeswitch/db/ but can be put into a postgresql database (dsn.sh script in the installer repo)

 

[s2svoip]

humm, i am using the fusion backup and restore script as part of my HA and I see that file is not included in the tgz, interesting. so no I am not replicating that, but I can add it in - you think that could be the cause here ?

 

[hfoster]

I'm 90% sure. That database contains the active state of sessions and such, I think what's happening is your phone is only listening to one of the servers (I would have to guess that last one in the list) as they are the same domain for failover.

Weird idea, but it might even work if the primary is second in the list and backup is first in the list.

 

[s2svoip]

Interesting, i gave it a test and the blf only works with 1 sip server - no matter what server. I did some reading of this document and specifically the section listed in the below screen grab. this could be the reason.

I did some testing and with the sip server 2 removed, but both servers are listed in the outbound proxy server with outbound proxy enabled, the blf lamp works - outbound calls failover to the 2nd server, haven't tested incoming yet - is there any issue with HA setup this way using proxy servers instead of 2 sip servers you think ?