奇怪的需求
工作中经常会遇到客户提出各种各样的需求,有些需求很合理,有些需求很有难度,有些需求则让人摸不着头脑,比如今天遇到的一个需求。客户的需求看上去似乎不复杂:
呼叫离线(offline)的被叫用户时,先 push 一个通知(notification)给被叫用户,收到响应后再发起呼叫。
我推测这位客户可能在构建某个移动APP。移动APP经常遇到的问题是:希望常驻后台,但是手机的电源管理往往会优化掉应用。这导致该移动APP会强制退出运行,从而无法正常接收消息、更无法接收呼叫。
客户提出的需求不应该是这个场景的解决方案。应当是APP自身向系统申请足够的权限驻留内存,并且APP应该和 SIP 服务器定时 keep-alive 保持激活状态。前者是APP自身的设计问题,后者是SIP注册、激活问题(标准流程)。
当然这只是我的个人推测,不太适合直接反馈给客户,因此向客户简单地提示了几个问题:
(1)离线状态下,怎么保证收到 notification 呢?
(2)既然可以收到 notification, 为什么就不能收到 SIP 的呼叫消息(INVITE)呢?
2020-10-12 更新: 稍微了解了一下相关的内容,大概是 iOS、Android 提供了统一的通知机制。如果收到了 notifications, 系统会从后台启动程序,这样 SIP 终端又可以重新注册并接收呼叫了。 这种模式当然是可以工作的,不过方案确实也很丑陋。另外,由于 GMS 在大陆已经不可描述了, 因此大陆的 Android 手机就更奇葩一些,通过应用程序链之间互相唤醒、互相调用(脏得一批 ……)。
2020-11-28 更新: RFC8599 定义了 SIP PUSH NOTIFICATION 的规范,对于移动终端 APP 类的 wake up 机制进行了定义。还不清楚该规范的应用情况,待进一步了解。