工作中经常会遇到客户提出各种各样的需求，有些需求很合理，有些需求很有难度，有些需求则让人摸不着头脑，比如今天遇到的一个需求。客户的需求看上去似乎不复杂：

呼叫离线（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 机制进行了定义。还不清楚该规范的应用情况，待进一步了解。