I’m in the process of developing a web-based phone directory with presence. I work for a Mitel customer which has a deployment of approximately 14,000 single device MiVB users and climbing via MiCloud Flex. The user fleet consists of Mitel 69xx, 53xx phones along with ‘Generic SIP Devices’. Not all 14,000 users are piping presence updates through the same CloudLink gateway as I understand this is well beyond the current capabilities of the CloudLink gateway for MiVB.
So far, my testing has been successful and the web app itself works quite well. Presence update publications are received into my app via external webhook. I use the below subscription to get presence updates for all devices synced via that specific MiVB/CloudLink account.
I have some questions on the behaviour of the API and some other general questions.
I only receive presence updates for a ‘Generic SIP Device’ when: a call is made (busy), a call is received (busy), when a call is dropped (available), when the device is signed into the SIP extension (available). I don’t receive a presence update when the device is signed out. I’ve confirmed the SIP registration is torn down at a MiVB level. Is this a bug or expected behaviour? I would expect the presence to change to ‘out of service’ or similar to replicate the behaviour of a Mitel PKM.
I don’t receive presence updates for the primary device if a ‘line key’ is called on that device. For example, a reception phone of extension 1000 has multicall keys 1101, 1102, 1103 programmed on it. If any of the 11xx keys are called, the presence of the primary device (1000) does not update via API publication.
What is the best way to be monitoring for presence updates? Via the platform-api-presence topic to monitor presence or via platform-api-media to monitor device state? I am only interested in Available/Busy at this stage, not so much the ringing state.
I’ve noticed that after creating a subscription, it has an expiry time allocated to it. Does the subscription automatically renew or do I need to handle that? Can I specify an expiry 12 months in advance by using expiryDateTime in my subscription creation POST? I currently have an automatic task that stops the subscription and creates a new subscription every evening.
Hi @andrew! I’m working on answers for questions 1-3 for you. Regarding subscriptions, you will need to renew the subscription after expiration. I’m not sure what the max value for expiryDateTime is, but best practice is to let it be auto-generated or use a value that makes sense in the context of your app (12 months does not). If your automated task failed to run for any reason, you would have ghost subscriptions floating around forever trying to deliver notifications to endpoints that may no longer be listening.
I only receive presence updates for a ‘Generic SIP Device’ when: a call is made (busy), a call is received (busy), when a call is dropped (available), when the device is signed into the SIP extension (available). I don’t receive a presence update when the device is signed out. I’ve confirmed the SIP registration is torn down at a MiVB level. Is this a bug or expected behaviour? I would expect the presence to change to ‘out of service’ or similar to replicate the behaviour of a Mitel PKM.
We currently don’t send the ‘outofservice/backinservice’ events. This is not supported at this time.
I don’t receive presence updates for the primary device if a ‘line key’ is called on that device. For example, a reception phone of extension 1000 has multicall keys 1101, 1102, 1103 programmed on it. If any of the 11xx keys are called, the presence of the primary device (1000) does not update via API publication.
I’m waiting on confirmation that this is the same issue, but there should be a bug fix released next week for this.
What is the best way to be monitoring for presence updates? Via the platform-api-presence topic to monitor presence or via platform-api-media to monitor device state? I am only interested in Available/Busy at this stage, not so much the ringing state.
For “presence” or rather user/entity presence, “platform-api-presence” is the correct topic. Understand that a user can have multiple phones, calendars, and other sources that all contribute to presence. If you don’t care about the user and roll ups you can listen to line state events, but your app will be responsible for all the necessary interpretations, de-duplications, aggregations, and all that noise so that may not be what you want.
I’m not sure what the max value for expiryDateTime is, but best practice is to let it be auto-generated or use a value that makes sense in the context of your app (12 months does not)
I currently use the default expiry (which I think is 24hrs). Every evening, my app queries the active subscriptions and automatically re-creates them to extend the expiry by 24hrs. I have a portal that allows administrators to view and manipulate subscriptions as required.
We currently don’t send the ‘outofservice/backinservice’ events. This is not supported at this time.
It seems odd that the API publishes “Available” on SIP registration but nothing on de-registration/registration expiry. If I want to submit a feature request for this, should I go through my channel partner?
I’m waiting on confirmation that this is the same issue, but there should be a bug fix released next week for this.
Thank you. I look forward to hearing back from you.
For “presence” or rather user/entity presence, “platform-api-presence” is the correct topic.
Understood, I’ll continue using the presence topic given I don’t need ringing & idle states.
Yes, your partner is the best channel for raising the request. There’s also a bug fix out this week for the line key issue, it should be available by Wednesday.
I have tested the latest release of the CLGW software. I can confirm that the prime line of a device now updates to Busy when a non-prime line is dialled, thank you for the bug fix. However, I think I’ve noticed another bug.
It appears that some devices are ‘locking up’ and not clearing calls. What I see from a Notifications API perspective is multiple Busy events when calls are connected & disconnected instead of Busy then Available. I had experienced this issue pre-CLGW upgrade on some extensions but held off reporting it due to the impending CLGW software update.
Running the MiVB commands “BUSY EXTENSION XXX” then “RTS EXTENSION XXX” fixes the issue and returns the extension to an Available state.
I have a screen recording which illustrates this issue clearly, would you like me to send that to you or report the issue through the channel?
Edit:
Further testing shows that if the calling party disconnects the call first, this produces the issue. If the called party (the extension) hangs up first, the extension updates as it should.
This issue has now been resolved in release 1.3.0.01-2925 of the CloudLink Gateway. Please update your CloudLink Gateway through the CloudLink Account Console and let us know if you’re still experiencing this issue.