Presence Notification Not Received SIP Endpoint - Presence API

Notification API
1

Hi Budd/fellow dev forum members

I’ve encountered an issue with the Notifications API post-upgrade to MiVB 10.1 SP1. I no longer receive presence notifications for SIP devices upon SIP REGISTER (binding). Pre 10.1 SP1 I would receive binding notifications, but I wouldn’t receive remove binding notifications (logout).

The expected behaviour is on binding, I should receive an “Available” presence event and on remove binding, an event which depicts unavailable or out of service (but not “Busy”). I understand that the out of service event is a feature request and it’s currently working as designed. However, I want to understand why I no longer receive “Available” events post-upgrade to MiVB 10.1 SP1. This is a huge step backward for me in my project.

My subscription payload is below

{
“applicationId”: “{app ID}”,
“deviceId”: “{webhook URL}”,
“transport”: “webhook”,
“topic”: “platform-api-presence”,
“subjectFilter”: “/presentities”,
“publicationFilter”: "$.publications[?(@.content.presence.status == ‘Available’ || @.content.presence.status == ‘Busy’)]”
}

If I remove the publication filter and target a specific test extension directly, I receive no events whatsoever on registration (binding or remove binding).

Budd - if you’d like to reach out for logs in our existing email chain, I’d be happy to provide them. I thought I’d create this new forum post as it’s a new issue.

1 Like
2

In testing, it looks like the SIP devices are sending the presence update after logout/login, after the initial registration. I’ll provide more information on this when I have an update.

3

Hi @andrew - In speaking with the R&D teams for the PBX and CloudLink, SIP registration events are not reported to CloudLink by design. The fact that it worked previously was a byproduct of how SIP registration worked prior to MiVB V10.1 and a recent change has eliminated that side effect.

In short, this scenario was never supported. You’re not the first person to bring this up (as you noted), and I will add you to the feature request, though for now the only real (admittedly not ideal) solution here is to use a ‘heart beat’ method of checking on device presence intermittently. I’d recommend doing it in batches with GET /presentities to keep traffic reasonable.