Twilio Programmable Voice SDK for Android 号码机制与呼叫流程咨询

1. 纯应用内互拨场景是否需要为每个用户分配Twilio电话号码 #

完全不需要。Twilio电话号码的唯一作用是对接公共交换电话网（PSTN），也就是实现App和普通手机号、固定电话之间的呼入呼出，纯App端到端的VoIP呼叫走的是Twilio的私有客户端信令网络，和公共电话网完全隔离，不需要占用任何Twilio号码资源。

2. 用户A呼叫用户B时，Twilio如何识别被叫目标 #

Twilio识别应用内被叫用户的核心依据是用户唯一身份标识（Identity），而非电话号码。这个Identity是你自己定义的字符串，可以直接和你业务体系内的用户名、用户UID做一一映射，不需要符合电话号码的格式规则。

你可以把Twilio Voice的客户端呼叫体系理解成一个独立的实时语音信令系统：

• 每个登录你App的用户，都需要先从你的自有业务服务端获取一个带Identity字段的有效访问令牌（Access Token），客户端拿着这个令牌调用SDK的注册方法，和Twilio云端建立维持在线状态的长连接，同时绑定设备的推送通道信息。
• 注册完成后，Twilio云端会实时维护一张映射表，记录「每个Identity当前对应哪些在线设备、推送凭证是什么」，这张表就是呼叫路由的唯一依据，和电话号码体系完全不互通。
• 当你需要发起呼叫时，只需要把被叫用户对应的Identity传给Twilio，Twilio会直接查这张映射表找对应的在线设备，不需要经过电话号码路由逻辑。

从用户打开App到接通呼叫，全链路步骤和各端职责如下：

• 上线注册环节
  1. 用户A、用户B分别用自己的业务账号登录App，App向你的自有后端请求Twilio访问令牌，生成令牌时你分别为两个用户绑定和业务账号一一对应的Identity值，比如用户A对应alice_uid_123，用户B对应bob_uid_456
  2. 两个用户的客户端拿到令牌后，调用Voice SDK的注册接口，和Twilio云端建立长连接，Twilio更新映射表，标记两个Identity对应的设备为在线状态，记录对应的推送通道信息
• 呼叫发起环节
  1. 用户A在App内搜索到用户B的用户名，点击呼叫按钮，客户端将被叫用户的Identity（bob_uid_456）上报给你的自有后端
  2. 你的自有后端校验用户A的呼叫权限后，调用Twilio的呼叫创建接口，指定主叫Identity为alice_uid_123、呼叫路由规则为「连接到Identity为bob_uid_456的客户端」
• 来电推送环节
  1. Twilio收到呼叫请求后，先校验请求合法性，再查询在线映射表找到bob_uid_456对应的在线设备，通过长连接/系统推送通道向用户B的设备下发呼叫邀请
  2. 用户B的App收到SDK抛出的来电回调事件，弹出包含主叫信息的接听/拒接界面
• 接通通话环节
  1. 用户B点击接听按钮，SDK向Twilio返回接听信令，Twilio开始为主叫、被叫两端协商媒体传输参数，收集双方的网络连通候选地址、协商语音编解码规则
  2. 媒体链路协商完成后，两端直接传输加密的实时语音流，呼叫正式接通，后续的静音、保持、挂断等操作都通过SDK和Twilio的信令通道交互完成

你看官方快速入门项目产生困惑是正常的：快速入门为了降低演示门槛，把本该放在服务端的令牌生成、呼叫创建逻辑临时放到了客户端实现，而且没有专门区分客户端呼叫和PSTN呼叫的场景差异，才会让你觉得好像缺了电话号码相关的逻辑——实际上纯客户端互拨场景下，电话号码从始至终都不会参与任何流程。

内容的提问来源于stack exchange，提问作者D-I-S-C