We have just encountered a minor issue with presence after deploying some softphones into the mix. A group of users often use BLFs and will utilise the pickup facility to takeover a call if they see it ringing on someone’s phones as a flashing light. This works perfectly with a single registered endpoint for each extension.
Now, users have softphones that they frequently put on DND out of hours, or when they are sat at their desk and it’s stopped the ‘Ringing’ BLF from happening as the endpoint immediately sends back: 100 Trying, then:486 Busy Here.
However some of the other endpoints return 100 Trying, 180 Ringing, 486 Busy Here. which doesn’t interfere with the other endpoints.
Is there any way to configure the behaviour of FreeSWITCH to ignore specific endpoints sending busy regarding presence?
Which method are you using for BLF?
/b
Hi Brian,
dialog-info for all endpoints, what I notice when an endpoint immediately sends back Busy with no Ringing, we get an empty NOTIFY message immediately after the 486 Busy from one of the endpoints. I can’t tell you if that’s up to the RFC spec or not! I did try to read it. If there’s no empty message, the phones just happily show ‘ringing’ until it’s terminated or picked up though.
If there’s anything else I can provide, I will do my best to.
If the soft phone doesn’t know how to do this, it will cause the problem you’ve outlined.
Yeh, I was dreading that. It’s not actually the softphone, it’s the push server that wakes the softphone, and that’s shared by hundreds of customers, so I will have zero sway in getting them to insert a fake ‘180 ringing’ in there; especially because if the device is ‘DND’ it shouldn’t ring anyway.
None of the endpoints handle it well (mainly tested Yealinks) and wake up and immediately shutoff the BLF until it’s picked up.
I was really hoping for the equivalent of ‘continue_on_fail’ but for presence instead.
SIP is fun at times, and stuff like this make you wanna pull your hair out… but mixing presence types is a disaster.
/b
Haha yeh, but it’s more that it just can’t really work out multiple registered handsets as I’ve only been able to find handsets that use dialog-info.
Continue_on_fail stops the busy signal going back to the A leg when a single or couple of handsets are busy, but it doesn’t affect the presence part of mod_sofia.
For now, we have just told the customers multiple handsets isn’t supported fully and that presence only works with one handset, until I get brave with a C compiler and the NUA part of mod_sofia.
Cheers anyway.
