微信电话本
随着 3G/4G/WiFi 的广泛覆盖，OTT 厂商频繁发布各种移动 VoIP 应用，近日“微信电话本”推出“高清语音”功能更引来大量讨论，特别是——移动 VoIP 是否会对运营商传统业务造成冲击。本文从话音体验、应用场景、产品战略等方面较为系统地分析了移动 VoIP 应用的现状。作者 Hans，QQ & 微信：1396255225。
11 月 10 日“微信电话本”3.0 推出，主打“高清”VoIP 通话。挟着“微信”这个没法更响亮的名字，以及 VoIP 留给行业那个隐隐约约的“免费”印象，一时间“运营商根基不保”的话题充斥业内媒体。
工信部 9 月底的统计，国内 3G/4G 用户突破 5 亿，加上城市中普遍覆盖的 WiFi 热点，移动宽带时代已经真正到来，理论上已经足够支持 VoMBB（Voice Over Mobile Broadband）的业务发展。
不过，当我们回过头看看过去十年的行业的发展，会发现：日、韩、美、西欧等发达地区的移动宽带在 4~6 年前即已达到我们今天的发展水平，skype 10 年前即已在发达国家普及，基于智能终端的 VoIP APP 在 5 年前即已大量涌现，手机 QQ、微信、YY 皆早已推出 IP 话音、视频通话功能；但是，基于 VoMBB 的 OTT 应用并没有在任何发达国家成为日常最主要的移动话音通信手段（事实上全球主流移动运营商也并没有直接因为 VoMBB 的广泛应用发生明显的话音业务和营收萎缩）。缘由何在？
本文尝试从话音体验、应用场景、微信电话本自身的战略几个角度进行分析。
先说说本文的结论：
就移动话音体验而言，OTT 应用开发商尚无法提供能够匹配电信运营商的商用级服务，对运营商话音业务的冲击很有限；
微信电话本的战略并不在传统电信话音服务，它的对手和目标都不是运营商；
运营商完全可以从 OTT 提供的语音服务中获得利益。
一. OTT 服务难以提供商用级的话音体验：
对个体手机用户而言，商用级别的移动话音服务至少要满足如下条件：
– 使用便捷：打开手机就能用…
– 高质量的接续效果：跨网络连通；始终待机，快速接续；移动及高速移动中保持通话稳定…
– 高质量的 QoS 保证：E2E 资源保证；可靠的时延、丢包控制；回声抑制、噪声控制、静音检测、前向纠错…
– 稳定，安全
先说使用便捷：
打电话是智能手机的最基础功能，这是全球用户的基本和固化的认知；任何一款智能手机缺省都必须把电话应用放在最显著的位置，且电话应用不可被卸载。用户打开手机，就可以进行熟悉的拨号、短信、通讯录操作。
但微信电话本仅仅是一个 App。要让这个它运行，必须经过下载、安装、注册、登录等漫长过程；微信电话本的“免费通话”功能隐藏在二级目录下；要真正拨打“免费电话”，必须找到这个 App Icon 和其中“免费通话”菜单所在；同时，该菜单下只能提供本地通讯录中（在微信电话本有注册的）好友之间的 VoIP 呼叫，用户也不能进行拨号等熟悉的操作。
举个例子：用户如果试图与一个新的号码进行“免费通话”，首先必须将该号码存储到本地，然后才能尝试。如果该号码没有注册微信电话本，仍然无法拨打。
使用微信电话本的准备过程和操作路径都明显超过手机电话应用，使用起来并不方便。要让大众用户普遍改变现有习惯，将“微信电话本”作为缺省电话应用的操作路径，仅仅在操作层面就很难。
再说可接续：
世界各国的电信网络是基于统一的规范搭建的，只要用户有权限，就可以基于号码拨打全球任何一个电话；但微信和微信电话本都只能拨打在微信注册的用户。举个现实的例子：用户并不能用“微信电话本”向一个商家提供的固话号码拨打“免费电话”。
当然，理论上微信电话本也可以与其他提供 VoIP 的 OTT 体系互通，前提就是全球 OTT VoIP 厂商重建一个统一规范；理论上微信也可以学习 Skype 等部署与电信网络互通的网关，但这是一个巨大的工程和投入。
另一个容易被忽视的问题是：免费通话的接通率很难保证。因为基于 VoMBB 的 OTT 应用，很难保证用户持续在线，也就很难保证寻呼的成功率。
一方面，微信电话本 App 的进程在大量的应用场景中可能被清除(Kill)。当下智能终端的 App 泛滥，各种 ROM 或各种安全清理软件都有可能清除低优先级进程以保持智能手机的运行性能，用户一旦把微信电话本切换到后台（即成为 Background Process），在很多终端上，少则数十分钟，多则数小时，微信电话本进程就可能被清除。另外，ROM 和安全清理软件都会向用户提供手工清理进程功能，智能手机用户对这些操作并不陌生。事实上，在很多智能手机上，App 要持续在线，本身就很困难。
图1：OTT 服务很难保证长期后台在线
另一方面，微信和微信电话本的协议设计本身有缺陷，并不适合实时话音通话。做一个测试：用户 A 和用户 B 是微信电话本的好友；用户 B 进行了进程清理操作，或者显性退出微信电话本的操作，或者关机；此后用户 A 通过微信电话本的免费电话拨打用户 B——结果是，用户 B 接收不到寻呼，而用户 A 这边却能够发起呼叫且要等待超过 40 秒才会进入“话音留言”。同样的情况在微信的实时话音、视频通话功能中也存在。
图 2：被叫已经不在线，主叫拨打时却得不到及时&准确的提示，只能长时间等待
为什么会有这样的现象？微信有一个著名的理念，即假定移动智能终端用户永远在线。这种设计，对消息类可以以异步方式进行的通信而言，问题不大。但对移动话音这样的同步通信，矛盾就发生了：微信电话本认为用户永远在线，那当然就允许对用户发起“实时话音”或“视频通话”；但被叫用户的微信电话本可能并不在线，那微信就只能告诉主叫用户“请等待”；而被叫用户也很委屈，他会说“我是开机的啊”！这里也可看出，微信和微信电话本在其 VoIP 信令协议的设计上也还并不完全适应实时话音业务的需求。
VoMBB 能否有效支持移动中的通话稳定：
移动话音服务在不同网络条件下的平滑切换，保持通话在移动过程中的连续性，这是电信网络的重要技术环节，包括：2G 话音域/3G 话音域/4G VoLTE 之间的切换。
但是，OTT 厂商只能控制终端和服务器，并不能控制中间网络。OTT 厂商提供的 VoMBB 技术，不可能支持 WiFi 与 3G/4G 数据域（PS）之间的切换，更不可能支持 WiFi/3G/4G 网络数据域与 2G 话音域之前的切换。
举个具体的例子：微信电话本用户在室内通过 WiFi 发起了一个“免费”电话，当他走出室外离开 WiFi 的覆盖范围，该电话必然中断；该用户必须打开“移动数据”，并重新发起呼叫。但这样的问题，在运营商提供的话音服务中，是不存在的。
QoS（Quality of Service）：
商用级别的移动话音服务，建立在运营商和终端提供的 E2E 解决方案基础之上，是一个系统的工程。它包括：
– 运营商和终端对话音业务 E2E 资源保障；
– 保证话音的平滑接续（即上一章节涉及的内容）；
– 通过多种技术例如回声抑制、噪声控制、静音检测、前向纠错…保证用户获得贴近真实的话音体验，并排除其他因素例如噪声、回声等对话音的影响。
图 3：运营商网络和手机对话音服务提供 E2E 资源保证，而 VoMBB 一般只能被视作普通数据业务
运营商网络和手机都将话音业务作为高优先级服务，提供包括空口信道、传输资源、信令资源的特殊保证；而 VoIP 则无法得到相应的服务保证。
举一些实际例子：
– 在 2G 网络条件下，话音是电信网络话音域的基础服务；而 2G 数据域（GPRS，EDGE）理论上最多只能提供 384kbit/s 的带宽，在实际应用环境中完全无法支持可商用的 VoIP 话音服务。换句话说，离开 3G/4G/WiFi 环境，VoMBB 的效果是无法接受的。
– 电信网络在建立话音连接时，一定会保留足够的资源；而 VoMBB 一般只被视作普通数据业务，只能获得尽力而为（Best-Effort）的 QoS 服务级别，当网络数据流量繁忙时，语音质量即会出现明显下降。
– VoMBB 的优先级远低于话音服务。如果用户在“微信电话本”的免费通话中接到了一个来自电信网络的普通电话，那么基于“微信电话本”的通话被必然被中断；而在运营商提供的话音服务中，后进入的电话只能获得提示或忙音。
– 高速移动的智能终端，受较大的多普勒频移等因素影响，其数据域（3G/4G）上下行速率都会发生显著下降。典型的理论参考数值是 WCDMA R99 静止环境下理论下行速率可达 2M/s，但在步行环境下只能达到 384kb/s，车速环境下更只有 144kb/s。无论在 3G, 3.5G, 3.75G 还是 4G 覆盖中，在没有 E2E 资源保证的前提下，通过数据网络，运动或高速运动中的 VoMBB 效果都会明显差于静止状态中的效果。在 4G 甚至 3.5G 还没有在城市中完全覆盖的情况下，“微信电话本”的通话效果事实上还难以满足高速运动例如出租车环境中的使用要求。
二. “微信电话本”的“免费电话”对运营商话音服务的挑战有多大？
综合而言，VoMBB 还无法匹配电信网络提供的话音服务质量和保证。试想一下，用户尝试用“微信电话本”的“免费电话”呼叫通讯录好友：
如果对方“微信电话本”没有打开，或者已经被后台清理，甚至关机…呼叫都将不成功，而主叫方却无法确认被叫方的实际状况，可能会尝试反复拨打；
即使“免费电话”打通，如果被叫方网络条件不好（3G 覆盖不好，或者没有 3G 覆盖），或对方处于高速运动状态（例如在出租车上）…这通电话的质量是很难保证的；
如果通话过程中任意一方发生了网络切换，该通话必然中断；
如果通话过程中任意一方接到普通电话（来自电信话音域），该通话必然中断
……
事实上，大部分 VoMBB 都很难被作为日常常备的话音服务。
那么，VoMBB 有没有适合的应用场景？当然有！大体上，恰当的应用场景包括：
WiFi 环境下的通话
双方约定的通话
长途特别是国际长途通话
此外，VoMBB 在业务实现上往往也更为灵活，提供类似多方通话、跨屏通话（手机、PC，甚至电视…）都更为便捷
当下，室内覆盖仍然是移动运营商网络建设的难点，虽然已进入 4G 时代，但仍有大量的室内环境无线信号覆盖不佳。在这种环境下，WiFi 就可以成为移动网络的有效补充。
基于固定宽带提供的 WiFi 覆盖，带宽有良好的保证。如果通话双方约定都保证 VoMBB 服务在线，且都停留在 WiFi 环境下，那么通话质量是完全可以得到相当保证的。
运营商提供话音服务至今无法基于 WiFi，在室内环境下 OTT 提供的 VoWiFi (Voice over WiFi) 服务对用户非常有吸引力。
——这可能是“微信电话本”的“免费电话”对运营商的挑战最大的应用场景。
行业中很多观点认为“免费”就是“微信电话本”对运营商的杀手锏，是这样吗？
“免费”已经成为绝大部分互联网服务发展用户的基础手段，在互联网历史上，“免费”击败“收费”的案例比比皆是（典型如，360 的免费安全彻底打垮传统的收费杀毒）。所以，当话音这个传统上的收费服务面临来自互联网巨头的“免费服务”挑战时，很多人会自然联想到运营商根基不保。
但是，比“免费”更为关键的问题是“服务质量”。互联网历史上“免费”击败“收费”的前提是：免费服务能够提供与收费服务相当甚至更好的服务。
更何况，VoMBB 在 3G/4G 网络下还是需要用户为流量付费的。
此外，移动运营商的话音业务营收中往往还有一个重要组成，即企业网（如 IP Centrex 业务）通信服务，OTT 提供的 VoMBB 更无法满足此类需求。
综合而言，“微信电话本”的“免费电话”对运营商话音业务的挑战和冲击还很有限。
三. “微信电话本”的战略何在？
互联网服务的一般模式是，基于某种基础业务，通过免费服务获得海量用户，在此基础上探索实现其战略价值或商业价值。
而 3BAT 这类巨头，更看重互联网服务的“入口价值”。什么是入口？能够获得大众用户日常访问的服务，都是入口。SNS、桌面、搜索、输入法、资讯、浏览器、安全、音乐、O2O…都可以成为入口。入口级的 App 往往会获得海量的用户流量，有充分的业务空间实现其战略价值，甚至可以成为某种平台级的应用。
3BAT 等巨头不缺钱更不缺资源和渠道。任何一个潜在的“入口”都会被 3BAT 觊觎，因为谁也能保证某个入口级的应用不会成为下一个“超级平台”。
当入口之争普遍白热化的时候，一些在过去被忽视的用户日常应用也会成为新的争夺领域，例如：锁屏，天气，壁纸，甚至公共 WiFi 密码管理…“墨迹天气”“WiFi 万能钥匙”都 App 早已达到亿级用户规模。
那么，基于 OTT 的 VoMBB“免费电话”会不会成为“入口”，至少目前看，它不会成为用户日常使用的服务。但“通讯录”能不能成为“入口”？当然能！
“微信电话本”的前身其实就是“QQ 通讯录”。2013年初“QQ 通讯录”改名为“微信电话本”（猜测其团队在更早的时候也并入了目前的微信事业部）。
通讯录产品是手机大众用户日常访问最为频繁的应用之一，存在巨大的需求空间和发展空间，亦可以获得极有价值的用户信息，例如：
– 便捷访问线下服务：
当用户试图通过电话联系某种线下服务时，能否不通过其他搜索或 O2O 产品查询到电话号码再拨打？通讯录产品自身就可以成为 O2O 服务的入口，举个例子：当餐饮、外卖领域的 App 满天飞的时候，如果某个通讯录产品自身就可以提供“附近餐厅”的信息和电话，用户何必绕圈子？当用户需要通过电话订酒店、订机票，为什么一定要记住12580、114 或者携程、艺龙的服务电话？当用户希望拨打银行服务电话，为什么一定要记住银行服务电话？……对于需要通过电话联系线下服务的场景而言，通讯录本身就应该成为一个直接的访问入口。
（此外，在这里，通讯录还可以呈现出一个非常重要的功能价值——用户输入。背后有大文章可做，本文暂不赘述）
– 社交价值：通讯录产品本身就包含了用户的社交信息，本身就可以成为 SNS 或者社会化媒体产品的重要环节。
– 安全需求：典型如防骚扰…
– 跨终端访问：用户换手机或拥有多部手机，通讯录的共享…
行业中已有若干千万甚至亿级用户规模的通讯录产品，例如：
360 安全通讯录，搜狗号码通，点心拨号，91 通讯录，触宝电话，微会…其中大部分都有巨头背景或投资。
此外，小米 MIUI6，华为 EmotionUI3 都对通讯录进行了重大改进，例如集成“黄页”功能。
这些产品，包括他们的巨头背景，及其未来的入口地位和战略价值，才是腾讯和微信电话本真正的竞争对手和目标。
微信电话本的战略是抢占“通讯录”入口，而不是抢夺传统电信话音市场；“免费” VoIP 电话仅仅是“通讯录”的一个增值功能而已。
四. “微信电话本”以及 OTT VoMBB 服务对运营商有哪些启示？
笔者想谈 3 点：
1.“通讯录”是一门生意
如前一章节所述，通讯录本身就是一个大众化的功能入入口。用户访问线下服务，往往会通过通讯录拨打电话实现最终落地。通讯录产品一边面对海量用户输入，另一边可以集成海量的服务、商家，本身就可以成为服务平台。
国内运营商如中国移动已经有一些类似的产品，典型如 12580，其营收的重要组成部分就是来自商家的广告费，在这一点上，其商业模式就类似互联网搜索。中国移动还有一个现成的产品“和通讯录 Lite”，从三方主流应用商店渠道（如 360、豌豆荚）看，其下载量早已达到千万级规模。
通讯录可以成为最体现电信运营商传统优势的互联网服务平台，如何有效发掘通讯录的战略价值乃至直接的商业价值，如何在行业内丰富的通讯录产品中获得有效的市场地位，这是一个值得运营商思考和投入的互联网服务领域。
2. VoWiFi（Voice over WiFi）能否被重新考虑
统计上看，在移动互联网时代，绝大部分业务流量仍然是发生在室内。全球电信运营商、设备商都推出过若干解决方案。但室内覆盖并不仅仅是技术问题，还涉及工程、居民接受度等诸多因素影响。室内覆盖仍是全球移动运营商的难点。
WiFi 一直就是一种有效的室内覆盖补充方案。就数据业务而言，移动用户在室内可以通过 WiFi 接入网络。但就运营商传统话音技术而言，移动用户在室内也只能基于传统基站提供的覆盖；而 OTT 提供的 VoMBB 方案却可以充分利用WiFi覆盖，在室内环境中提供良好的话音服务。
对运营商而言，随着 VoLTE 和 IMS 的建设，在核心网层面可以统一接入更多的接入网络，VoWiFi 至少在核心网层面具备可行性。如果传统移动话音技术也可以支持VoWiFi 的方式，则在很大程度上能够提升解决室内的移动语音质量。
——当然，这是一个非常复杂的系统性工作。至少要考虑：基于 WiFi 热点的切换、WiFi 与其他接入网络的切换、WiFi 接入的安全、WiFi 部署的网络规划等诸多因素。目前看，非常非常难。
3. 运营商可以从 OTT VoMBB 获得利益，双方不是简单的竞争关系
对用户而言，OTT 提供的 VoMBB 能够给传统运营商话音服务提供良好的补充；而对运营商而言，VoMBB 的一些实现机制值得参考，运营商也可以从中获得直接的利益。
除了“微信电话本”，行业中还有一些非常不错的通讯录产品，典型如 YY 语音的“微会”，触宝的“触宝电话”。“微会”支持用户“免费”拨打任意电话，且并不要求对方安装特定客户端，非常有吸引力。
图6：“微会”免费电话机制，通话双方都是被叫，用户免费，“微会”向运营商付费
用户通过“微会”App 发起呼叫，“微会”服务器会通过运营商网络的网关建立 2 个呼叫，通过运营商话音域呼叫用户，这样做的好处是：
– 实际的通话并不需要通过“微会”客户端，就保证了用户在线和接通率；
– 通话双方都是运营商网络的被叫用户，用户不用为“主叫”付费；
– 实际通话是通过运营商话音域，不存在VoMBB的接续问题（例如网络切换导致断话，高速移动中话音质量严重下降等问题）
– 通话由“微会”服务器控制，也可以便捷提供更为灵活的通话模式，例如 会议，跨多种终端类型的通话等。
在此通话中，用户的确是免费的，但运营商仍然会获得收入。因为“微会”服务器会与运营商网络通过网关建立连接，会租用运营商的端口信道资源，需要向运营商付费。（对“微会”而言，这个费用就是它发展用户的成本）
当然，“微会”服务完全基于 IP，此会话的媒体流要会经过 IP 网，其语音质量仍然难以匹配运营商的专有话音域网络。
可以看出，“通讯录”产品和 OTT 的 VoMBB 服务，与运营商之间，并不是简单的竞争关系。话音服务有可能成为一些互联网服务发展用户的手段，而这些手段，往往仍然需要建立在与运营商合作的基础上。
对运营商而言，在新的产业链环境中，面对 OTT 服务，不仅仅是“应对挑战”的问题，更应当考虑，如何发挥自身的固有优势，开放自身的能力，与OTT服务和谐共赢。
相关阅读
A5创业网(公众号:iadmin5）6月12日讯，各种推销骚扰电话让人应接不暇，据悉今日，三大运营商因为电话推销扰民问题被江苏市场监管局约谈。
通信世界网消息（CWW）虽然5G已来，但从起步到规模发展，需要5G终端的普及。谁将成为5G时代王者？回顾终端发展可知，1G、2G缔造了摩托罗拉和
“虚拟运营商”这样的业务在国外最早发起于欧洲。当时英国的电信业在 90 年代的时候就开始开放。刚开始很多人对这个业务的理解都
5G商用在即，全球范围内与5G相关联的技术提供方、设备供应商……都在做最后的冲刺。在5G时代起到重要承接作用的电信运
A5创业网(公众号：iadmin5)11月9日消息：针对今日部分网友反映的百度宕机问题，百度官方回应，经排查宕机影响范围仅在北京，原因为受北京地
