KamoCRM 内的商务电话不是经销商安排。 我们运营 SIP 基础设施 — FreePBX 和 Asterisk,需要的部件使用 Kamailio 和 FreeSWITCH — 并将呼叫详细记录与其所属的客户记录进行对账。
| 措施 | 价值 | 资料来源 | 已计量 |
|---|---|---|---|
| 生产中的电话组件 | 3 application, edge and media deployments, plus FreePBX and its database | kubectl get deployments,statefulsets -n kamopbx and -n kamo | |
| 运行的SIP和媒体软件 | Asterisk, Kamailio, FreeSWITCH, FreePBX | deployment inventory across the kamopbx and kamo namespaces | |
| 支持调用状态的基础设施 | CouchDB and RabbitMQ stateful sets | kubectl get statefulsets -n kamopbx |
它教会了我们什么建筑
电话是我们所描述的差距的最明显的例子。 几乎每个提供电话功能的平台都在转售某人的 API 并对其进行标记。 这种情况一直持续到需要诊断通话质量问题为止,到那个时候,经销商只能代表您打开一个票据并等待,因为他们无法看到媒体路径,也无法对其进行任何更改。
操作它意味着拥有一些尴尬的细节。 写入数据库的配置变更不会到达运行的开关,除非发出一个明确的重载 — — 没有重载就写入,你刚刚创建的分机除了在接听呼叫的系统中以外,在任何地方都存在。 呼叫记录在你预期的分机字段中命名中继的呼叫者ID,而分机则在完全不同的字段中命名,因此任何天真地将呼叫归因于人是错误的,看起来很合理。 如果在负载平衡器上未正确配置一致哈希,则注册会在特定协议阶段挂起。
这些都不在入门指南中。 这些是您在实时呼叫中学到的知识,也是我们能够将电话集成到客户端系统中的原因,我们的估计是现实的,而不是乐观的。
建于
- Asterisk
- Kamailio
- FreeSWITCH
- FreePBX
- SIP
- RTP
- CouchDB
- RabbitMQ
- Go
