如果让你向一个 2007 年的人解释“视频通话”，你大概率不用费太大劲。因为那一年的运营商广告、手机卖场海报、3G 体验区里，都在反复重复同一个词：可视电话。索尼爱立信 K770 就是带着这些叙事出场的一款手机。放到今天再看，它既不是性能旗舰，也不是销量神话，但从技术演进的视角看，它恰好站在“3G 网络落地”和“移动影像大众化”两条线的交点上，是一个非常适合做技术复盘的样本。

我的核心判断是：K770 这类手机真正值得琢磨的，不是它有多少万像素，也不是它能跑多快的网络，而是 3G 视频通话在当年的实现方式，和今天我们打开视频会议软件完全不一样。那是一套从终端协议栈、无线承载到计费体系都重新设计过的系统能力。用户看到的是“屏幕上出现对方的脸”，背后却是 H.324M、H.245、H.223、AMR、H.263 这一连串协议的协同工作。

这篇文章会沿着一条主线展开：先拆 3G 视频通话的业务模型与协议栈，再模拟一次呼叫从拨号到显示画面的完整流程，接着把 K770 身上“Cyber-shot 影像 + 3G 视频通话”这对容易被人忽视的组合关系讲清楚，最后落到现代 VoLTE 视频通话与互联网实时通信的架构对比。如果你关注移动通信技术、嵌入式多媒体开发，或者只是好奇老手机背后的工程逻辑，这篇文章应该能给你一个清晰的坐标系。

1. 从一台 2007 年的手机谈起：K770 到底代表什么

2007 年的手机市场，大体上能分成几条明显的主线：以诺基亚为代表的智能终端路线，以索尼爱立信为代表的影音娱乐路线，以及正在悄悄发育的“移动互联网”路线。当时消费者选手机，通常不会追问“处理器主频多少”“内存多大”，更多人关心的是：这台手机能不能拍出好看的照片，能不能在 3G 网络下实现视频通话，音乐外放是否够响。

索尼爱立信 K770 属于 Cyber-shot 产品线，也就是把索尼数码相机品牌授权到手机上的系列。它的定位并不是当年的最高端影像旗舰，而是把拍照手机的体验向更多用户普及。K770 这类机器在当时的独特之处在于：它必须同时取悦两类用户。一类用户冲着 Cyber-shot 这个标而来，希望手机能替代入门卡片机的一部分功能；另一类用户则是冲着 3G 视频通话而来，想体验广告里那种“看着对方打电话”的新鲜感。

这两个需求放在今天看毫无冲突，因为现在的手机摄像头、视频编码器、屏幕显示都由一套强大的 SoC 统一管理。但在 2007 年的硬件条件下，事情远没有那么简单。拍照需要调用主摄像头传感器和 ISP 图像信号处理器，视频通话需要驱动摄像头连续采集画面并实时编码，这两件事共享的硬件资源非常多，而终端侧可用的 CPU 算力、内存带宽、电池功耗都非常有限。

所以，K770 的技术价值不在于某个参数特别亮眼，而在于它把“专业影像”和“3G 多媒体电话”压缩在了一个普通用户能接受的价格和体积里。它从一个侧面回答了当时很多工程师都在问的问题：3G 网络已经建好了，但手机端的处理能力真的准备好承载视频通话了吗？要回答这个问题，必须先理解 3G 视频通话到底是一套怎样的技术。

2. “视频通话”不是新功能，而是一套终端与网络协议栈

很多人提起 3G 视频通话，会下意识把它理解成“用手机 QQ 视频”或者“用微信视频聊天”。这是一种典型的现代认知错位。今天的互联网视频通话，本质是一个运行在通用 IP 网络上的应用，视频数据通过 RTP 或私有协议传输，服务端和客户端都能灵活协商码率。而 2007 年前后运营商主推的 3G 视频通话，走的是一条完全不同的技术路线：电路域承载。

通俗地说，老式 3G 视频通话更像是“电话”，而不是“网络应用”。它由电信网络专门分配一条固定速率的信道，双方建立一条多媒体连接，然后在这条连接里同时传输声音和画面。一旦连接建立，网络侧不会因为用户数量增多而动态压缩你的视频码率，因为这是一条被预留出来的专用通道。这个设计的好处是体验稳定，坏处是资源占用很高，而且视频编码能力必须提前协商好。

2.1 3G 视频通话不是网络视频

理解这个区别非常重要。网络视频的特点是尽力而为，网络拥塞时画面会变模糊、卡顿，但它不会让呼叫直接失败。而 3G 视频通话的电路域模型更接近传统电话，呼叫要么建立成功，要么失败，中间没有那么多“弱网自适应”的空间。当时的网络侧和终端侧都需要严格执行一套协议，才能把音视频数据正确打包、传输、解包和播放。

3G 视频通话所依赖的协议框架，是 H.324M。这个 M 代表 Mobile，是 ITU-T H.324 标准针对移动通信环境的扩展。H.324M 不是单独一种编码算法，而是一整套多媒体通信框架，规定了终端之间如何复用数据、如何协商能力、如何传输音频和视频。

2.2 典型协议栈：H.324M 框架

可以把 H.324M 理解成一个乐高底座，不同的功能模块负责不同的任务。音频通常使用 AMR-NB，视频通常使用 H.263 或 MPEG-4 编码，控制过程由 H.245 完成，而 H.223 负责把音视频数据复用成一路可以在无线信道上传输的比特流。

功能层次	典型协议/标准	作用
呼叫控制	3GPP CC / RRC	负责在无线网络和核心网之间建立电路域呼叫
媒体控制与协商	H.245	完成终端能力交换、主从决定、逻辑信道打开
数据复用	H.223	把音频、视频、控制数据复用成单一字节流
音频编码	AMR-NB	将语音以窄带高质量压缩，码率一般从 4.75kbps 到 12.2kbps 可调
视频编码	H.263 / MPEG-4 / H.264	将摄像头画面压缩成适合窄带传输的视频流
无线承载	UMTS CS 64kbps	为多媒体会话提供固定速率的电路域信道

这套协议栈最反直觉的地方在于：视频通话的“控制”不是像今天的 Web 服务一样，通过 HTTP 请求独立发送的。H.245 控制消息必须和音视频数据一起，通过 H.223 复用进同一条数据流。这意味着终端侧要先完成一次复杂的“能力协商握手”，然后才能开始传输画面。如果协商失败，用户看到的不是“画面模糊”，而是“没有视频”。

从工程上看，这给当时的终端厂商带来了很高的集成门槛。手机厂商通常需要从协议栈供应商那里购买整套 H.324M 软件协议栈，再把它和基带芯片、摄像头模组、音频编解码器对接起来。任何一个模块不兼容，都可能导致呼叫建立失败。这也是为什么同样宣称支持 3G 视频通话的手机，不同品牌之间的互通性常常不理想。

3. 一次 3G 视频通话从拨号到显示画面的完整流程

仅仅知道协议名称还不够，要真正理解 3G 视频通话的工程量，应该走一遍从用户按下拨号键到屏幕上出现对方画面的流程。

3.1 第一步：终端发起视频呼叫

用户在电话本里选择某个联系人，并明确选择“视频呼叫”。手机应用处理器把这个指令传给基带协议栈。基带芯片随后发起无线资源控制 RRC 连接建立流程，请求网络分配一条适合多媒体传输的专用信道。在 UMTS 网络下，这条信道通常是 64kbps 的电路域承载。

这一步的难点在于，视频呼叫不能被当成普通语音呼叫处理。普通语音电话只需要分配一个语音信道，而视频呼叫需要额外确认终端能力、准备视频编码通道，并且网络侧要正确识别这是一个多媒体呼叫。

3.2 第二步：网络侧完成寻址与呼叫路由

核心网接收到视频呼叫请求后，会按照类似普通电话的方式完成被叫寻址，向对方终端发起寻呼。如果对方处于空闲状态且网络覆盖支持 3G 电路域多媒体业务，对方手机同样会建立 RRC 连接。此时，双方之间的电路域连接已经被网络接通。

从用户体验来看，这个阶段通常是“正在连接”的等待时间。如果是在跨网、漫游场景下，呼叫建立时间会进一步拉长，因为网络需要在不同交换设备之间传递信令。

3.3 第三步：H.245 能力协商

电路接通以后，真正的多媒体控制才开始。双方终端通过 H.245 协议交换能力集，包括各自支持的音频编码格式、视频编码格式、最大分辨率、帧率、比特率等信息。同时还要完成“主从决定”，确定在出现冲突时以哪一端的配置为准。

能力协商是整个流程中最容易出现兼容性问题的部分。如果双方都支持 H.263，但一方支持 QCIF 分辨率，另一方只支持更低的 Sub-QCIF，系统必须自动选择双方都能接受的公共能力集。协议设计上存在多轮重试，相当耗时，这也是老式视频通话“接通慢”的原因之一。

3.4 第四步：H.223 复用与媒体传输

协商完成后，视频编码器和音频编码器开始工作。摄像头采集到的画面经过 ISP 处理后进入视频编码器，压缩成 H.263 码流；麦克风采集的声音经过 AMR 编码后形成音频码流。这两类数据打到 H.223 复用层里，被打成更小的数据块，与 H.245 控制消息一起交织成一路串行比特流。

H.223 复用是一个容易被人低估的环节。无线信道不像局域网那样稳定，一次突发干扰就可能打断整帧数据。H.223 协议通过精心设计的帧头部、长度字段和错误检测机制，让接收端能够在一个数据包损坏后快速恢复同步，而不是把所有后续数据都丢掉。这种“宁可丢一小块，也不能让整条语音流中断”的设计思路，对后续移动视频通信产生了深远影响。

3.5 第五步：接收端解码与画面呈现

接收端把 H.223 数据流解析出来，分离出音频包、视频包和控制消息，分别送入 AMR 解码器和 H.263 解码器。音频解码结果通过听筒或扬声器播放，视频解码结果送到屏幕显示。为了保证音画同步，还需要进行一定的缓冲。

如果终端处理能力不足，或者射频信道质量恶化，视频解码会出现花屏、马赛克甚至直接冻结。老式 3G 视频通话的信号链路非常脆弱，一步出错，用户就会产生“视频通话不靠谱”的印象。

这个完整流程想说明的核心问题只有一个：3G 视频通话不是手机上的一个普通应用，而是基带协议栈、应用处理器、摄像头、音频系统、无线网络协同完成的系统级任务。它的复杂度远远高于当时大多数用户和开发者的想象。

4. K770 与 Cyber-shot：移动影像的系统工程

如果只看通信协议，很容易把 K770 理解成一台“能打视频电话的机器”，而忽略了它身上的另一条重要产品线基因：Cyber-shot 影像。事实上，在这台手机的内部，拍照和视频通话并不是两个互相独立的模块，它们共享了摄像头、ISP、内存带宽和电源预算。理解这种共享关系，才能真正看懂 K770 这类 2007 年影像手机的设计取舍。

4.1 拍照与视频通话共享同一套硬件链路

拍照的典型流程是：光线进入镜头，传感器把光信号转换成电信号，ISP 做降噪、白平衡、色彩校正，最后交给 JPEG 编码器压缩成静态图片。视频通话的流程与之类似，但要求不一样：摄像头必须以固定帧率连续输出画面，ISP 处理后的数据不能慢慢攒，每帧都必须在规定时间内送到视频编码器。如果 ISP 处理速度跟不上，视频帧率就会下降，画面看起来像幻灯片。

在 2007 年的硬件条件下，ISP、视频编码器的算力都非常有限。K770 这类中端定位的 Cyber-shot 手机不能像旗舰机那样堆满处理模块，因此工程师必须在“静态拍照画质”和“视频通话流畅度”之间做权衡。这可以解释一个现象：当年不少主打拍照的手机，视频通话效果反而不如一些低端 3G 手机，因为高端拍照模组对数据吞吐和功率的要求更高，留给视频编码的资源反而更少。

4.2 Cyber-shot 意味着什么

Cyber-shot 并不是一个技术标准，而是一种产品定义方式。它意味着终端厂商不再是简单地把一颗摄像头模组装进手机，而是要把整套“相机体验”移植过来，包括取景、对焦、曝光控制、色彩风格、照片处理流程等。今天的用户已经习惯了手机计算摄影，但在 2007 年，Cyber-shot 这种品牌化做法最直接的贡献，是让消费者开始以“相机的标准”去要求手机的成像质量。

这件事对视频通话同样有帮助。一颗摄像头如果只会输出“能看清轮廓”的画面，视频通话体验一定差。Cyber-shot 调校过的 ISP 往往会带来更好的曝光和色彩表现，让视频通话中的人物肤色更自然。所以，K770 把 Cyber-shot 与 3G 视频通话放在一起，不是简单的功能堆叠，而是希望通过影像能力的下放，弥补视频通话早期“画面质量差”的最大痛点。

4.3 功耗和散热是隐形瓶颈

视频通话还有一个静态拍照不存在的问题：持续功耗。拍照可能只持续几百毫秒，而视频通话可能持续几十分钟甚至更久。屏幕亮着，摄像头连续采集，视频编码器持续运行，射频模块一直保持上行和下行传输，这几项加起来，对当时的电池是非常严峻的考验。

不少用户应该还有印象：早期的 3G 视频通话手机，通话几分钟后机身就会明显发热。这背后的原因集中在电源管理和散热设计。终端的 DVS 动态电压频率调节能力远不如现代 SoC，编码器很难在空闲时快速降频。今天的开发者看到这一点可能会觉得不可思议，但这就是 2007 年移动多媒体设备面对的真实工程约束。把发热控制住，比把算法跑通更难。

5. 从 H.324M 到 VoLTE：视频通话的架构迁移

既然 3G 视频通话从 2000 年代中期就开始商用，为什么今天的主流视频通话反而都跑在 IP 网络上？答案要从架构层面去找，而不是简单归因于“资费贵”或“用户不习惯”。

第一代 3G 视频通话采用的电路域承载，优点是服务质量可控、网络不会剧烈拥塞，但缺点也非常明显。固定 64kbps 信道在视频编码效率不高时非常受限，网络资源利用率低，业务扩展成本高。更关键的是，电路域视频通话和 IP 数据业务很难自然融合。它像一条专用的窄轨铁路，虽然稳定，但只能跑固定型号的列车，无法和旁边宽阔的互联网公路无缝衔接。

从 3GPP R5 开始，IMS 被引入网络架构，VoLTE 和 VoNR 的思路逐渐成熟。终端之间不再依赖专门的 64kbps 电路承载，而是通过 SIP 信令完成呼叫控制，使用 SDP 协商媒体参数，媒体数据通过 RTP 在 IP 网络上传输。视频编码也一路升级到 H.264、H.265 甚至更高效率的编码标准，码率可以随着网络质量动态调整。

今天的互联网视频通话，比如各类会议软件和实时通信 SDK，走得比 VoLTE 更远。它们不只使用 RTP 传输媒体数据，还有整套基于 UDP 的拥塞控制、丢包重传、前向纠错、码率自适应机制。不需要运营商参与，不需要统一的 IMS 网络，两个终端只要都能访问互联网，就可以建立高质量音视频连接。

从技术对比看，这种架构迁移的本质是：把“电信业务”变成“网络应用”。

对比维度	第一代 3G 视频通话	现代 IMS 视频通话	互联网视频通话
承载网络	UMTS 电路域 64kbps	IP 分组域	IP 分组域
呼叫控制	3GPP CC / H.245	SIP / SDP	SIP 或私有信令
媒体传输	H.223 复用后的串行比特流	RTP / RTCP	RTP / SRTP 或私有协议
视频编码	H.263 / MPEG-4	H.264 / H.265	H.264 / VP8 / VP9 / AV1 等
码率自适应	弱，基本固定	较强，网络可配置	很强，客户端实时调整
互通范围	同运营商或互通协议	运营商之间	互联网应用内闭环

这张表说明了一个容易被忽略的结论：3G 视频通话并没有“消失”，它的需求被继承了下来，只是实现方式发生了系统性的转移。如今 VoLTE/VoNR 视频通话仍然保留了“从手机拨号键发起视频通话”的产品形态，但底层已经是全 IP 架构。而互联网视频通话则把能力协商和媒体控制下沉到了应用层，让任何开发者都能通过 SDK 构建类似能力。

从这个角度看，K770 时代遇到的很多问题，本质上不是“3G 不够快”，而是电路域架构与互联网生态之间的断裂。一旦视频通话变成普通 IP 应用，它的创新速度立刻被释放了。

6. 实验示例：理解老视频通话的带宽与协商逻辑

这一节提供三个最小示例，帮助你从抽象协议走向可验证的代码。需要说明的是，K770 内部的软件已经很难从外面直接观察，这里的示例是为了理解底层逻辑，而不是复刻当年的手机系统。

6.1 示例一：64kbps 带宽预算模拟

老式 3G 视频通话一个通道的典型速率是 64kbps。语音编码通常要占掉一部分码率，H.223 复用和 H.245 控制消息也要消耗开销，留给视频的码率并没有想象中那么多。

# 文件路径：video_budget.py
# 模拟一路 64kbps 电路域视频通话的带宽分配

total_kbps = 64
audio_kbps = 12.2          # AMR-NB 12.2kbps 模式
control_overhead = 4.0     # H.223/H.245 控制开销，经验估计
video_kbps = total_kbps - audio_kbps - control_overhead

print(f"视频可用码率约: {video_kbps:.1f} kbps")

fps = 15
bytes_per_frame = video_kbps * 1000 / 8 / fps
print(f"15fps 时每帧可用数据约: {bytes_per_frame:.0f} bytes")

# 一个 QCIF(176x144) I 帧如果编码为 3000 bytes，按 P 帧 800 bytes 估算
i_frame_bytes = 3000
p_frame_bytes = 800
scene = 15 * i_frame_bytes + (15 * 15 - 15) * p_frame_bytes
print(f"模拟一秒 GOP 场景下约需要: {scene} bytes")
print(f"实际每秒可用: {video_kbps * 1000 / 8:.0f} bytes")

运行方式是：

python video_budget.py

这段代码的重点是帮助你建立“码率预算”这个直觉。64kbps 听上去是拨号上网的两倍左右，但在视频通话场景中非常紧张。如果 H.263 编码器不能在复杂画面下高效压缩，画面很快就会出现大量马赛克。这也是为什么当年的视频通话通常使用 QCIF 级别分辨率，而不是 VGA 甚至更高。

6.2 示例二：现代 IMS 视频通话的 SDP 媒体协商

前面提到，老式 H.324M 的视频通话能力协商使用 H.245。到了 IMS 时代，协商工作改由 SIP 消息中的 SDP 完成。下面是一段经过简化的 SDP 媒体描述，展示了终端如何同时声明音频和视频能力。

# 文件路径：video_call.sdp
# 该示例仅用于理解参数格式，字段中的 IP 为测试示例

v=0
o=video-terminal 2890844526 2890842807 IN IP4 192.0.2.10
s=Video Call
c=IN IP4 192.0.2.10
t=0 0

m=video 51234 RTP/AVP 98
a=rtpmap:98 H263-1998/90000
a=fmtp:98 profile=0;level=10

m=audio 51236 RTP/AVP 96
a=rtpmap:96 AMR/8000
a=fmtp:96 mode-set=0,1,2,3,4,5,6,7;mode-change-capability=2

这段 SDP 的作用是向对端声明：“我可以接收 H.263 视频，也可以接收 AMR 音频。”如果双方都接受，媒体会话就可以建立。这里的 H.263 和 AMR 与 H.324M 时代使用的编码类型直接同源。对比 H.245 中复杂的逻辑信道协商，SDP 的书面含义更直观，这也是现代开发者更容易入门的原因。

6.3 示例三：用 FFmpeg 生成低分辨率低码率测试素材

如果你想直观感受“接近老电话视频的质量”，可以尝试用 FFmpeg 把一段视频压成低分辨率、低码率的 H.263 素材。注意，这个文件本身不是 H.324M 协议的传输流，只是用来观察编码效果的工具。

# 提取一段 10 秒视频，压缩为 QCIF 分辨率、15fps、码率约 40kbps
ffmpeg -i input.mp4 -t 10 -c:v h263 -s 176x144 -r 15 -b:v 40k -an test_qcif.3gp

如果终端环境缺少 AMR 音频编码器，先不加音频参数，只生成纯视频文件。执行后，用本地播放器打开 test_qcif.3gp 。你会很快发现，在这个分辨率下，画面的边缘细节基本丢失，快速运动场景会出现明显的块效应。再把参数调整到 20 帧以上，观察文件体积和画质的变化。这个练习能很好地还原当年视频通话编码器面对的画面复杂度。

7. 常见问题与排查思路

很多对老手机感兴趣的人在实验室或二手设备上测试 3G 视频通话时，会遇到各种奇奇怪怪的问题。下面把常见现象和排查逻辑整理成一个表。需要强调的是，现在很多地区的 3G 网络已经关闭或缩减覆盖，真实测试必须在合法授权且网络可用的条件下进行，不建议在公共网络用个人号码反复拨测。

问题现象	可能原因	排查方式	解决方案
呼叫无法建立，提示网络错误	当前网络不支持电路域视频业务，或终端注册在 2G 网络	查看终端网络模式设置，确认是否已注册到 3G/UMTS 网络	切换到支持 3G 的 PLMN；或更换可用的测试网络
呼通后对方只能听到声音，看不到画面	至少一端未正确完成 H.245 视频能力协商	查看终端日志中 H.245 能力集与逻辑信道状态	关闭不必要的视频格式，改为双方都支持的 H.263 QCIF
画面出现大量马赛克或直接冻结	射频质量差，或视频编码器码率超过信道预算	查看无线信号强度、误块率，核对码率分配	降低视频帧率或分辨率，避免使用高码率视频模式
本地看不到自己的预览画面	摄像头没有被视频通话应用正确占用	检查摄像头驱动是否与基带协议栈接通	重启终端并确认摄像头能被录像应用正常调用
通话过程中机身明显发热	摄像头、编码器和射频同时处于高负载状态	通过工程菜单观察 CPU/基带占用和电池电流	缩短单次通话时间；检查散热结构是否异常
不同品牌手机之间无法视频互通	双方协议栈实现版本或能力集不匹配	分别查看双方 H.245 日志	升级协议栈到兼容版本，回到公共能力集

如果你是想用现代技术理解老式视频通话，这个排查表同样有参考价值。任何实时音视频系统的问题，都可以从“网络有没有问题”“编解码有没有问题”“媒体协商有没有完成”三个方向切入。这个基本方法论从 H.324M 时代到今天并没有本质改变。

8. 最佳实践与工程建议

复盘 K770 和 3G 视频通话，不能只停留在怀旧。对今天的开发者和工程师来说，这段技术史至少能提炼出几条可复用的经验。

8.1 协议栈集成要提前做兼容矩阵

第一代 3G 视频通话的互通问题，很大程度上来自不同厂商对 H.245 能力协商实现的细节差异。今天做实时音视频 SDK 或通信类产品，依然要面对同样的问题。不要假设两端都是你自己的客户端，必须把服务端、Web 端、iOS、Android、车机、IoT 设备放到同一个兼容矩阵里做联调。哪怕只是 H.264 的 profile-level 不一致，也可能导致一端无法解码。

8.2 媒体链路的端到端延迟预算

3G 视频通话的延迟来源不只是编码器，还包括摄像头采集延迟、ISP 处理延迟、H.223 复用缓冲延迟、网络传输、解码显示延迟。任何一个环节超预算，都会让通话感受断崖式变差。现代实时通信通常把端到端延迟控制在几百毫秒量级，建议在项目早期建立延迟测量机制，而不是等到用户反馈“很卡”之后才开始排查。

8.3 无线环境下的弱网模拟必不可少

老式 3G 视频通话在弱网场景下表现不佳，因为电路域承载一旦误码升高，基本没有太多恢复手段。今天的 IP 视频通话虽然有了更多抗丢包机制，但依然必须在弱网、高抖动、丢包、带宽受限的真实场景里做测试。可以用网络损伤模拟工具来构造测试环境，而不是只在办公室 Wi-Fi 下验证。

8.4 拍照与视频预览要统一考虑资源调度

K770 的影像系统和视频通话共享资源，这个矛盾在今天的手机上依然存在，只是复杂度和规模发生了变化。拍照高像素模式、录像、视频通话、扫码，都在争抢 ISP 和编码器资源。开发相机类应用时，要特别关注多路并发采集和编码的场景。比如用户在视频通话过程中切到后置摄像头拍照，系统是否能够平滑降级，视频帧率是否会突然下跌，这些都是需要在真机上反复验证的细节。

8.5 安全合规与隐私边界

任何涉及通话、摄像头、麦克风的应用，都必须严格遵守隐私安全规范。尤其是在调试和测试阶段，要在最小权限原则下使用摄像头和麦克风，测试数据要经过脱敏处理。对于通信协议和信令的调试，只能在合法授权、本人可控的设备和网络环境中进行，不能干扰公共通信网络，也不能对未授权的号码发起呼叫或信令测试。

9. 总结与后续学习方向

K770 这样的 2007 年手机，放到今天已经没有任何跑分和性能上的竞争力，但它作为技术标本的价值反而越来越清晰。它把 3G 视频通话、Cyber-shot 移动影像、嵌入式多媒体处理、电路域通信协议这些内容压缩在了一台可以单手掌握的终端里，替后来者提前演示了一遍“移动设备做实时多媒体通信会遇到哪些坑”。

如果你想继续深入学习这一块，建议按下面的顺序展开：先读 3GPP TS 26.111 或相关 H.324M 资料，弄懂 H.245 和 H.223 是如何协同工作；再切换到现代 IP 网络，学习 SIP、SDP、RTP/RTCP 这套更开放的协议栈；最后可以接触 WebRTC 源码，看今天的实时音视频系统是怎么通过拥塞控制和码率自适应，解决当年固定信道想解决又解决不好的问题。

读这些资料时，脑海里可以始终保留一个问题：如果只能使用 64kbps 的可靠带宽，你要怎么设计一套视频通话系统？这个问题会把协议栈、编码器、终端功耗、网络调度全部串起来。想明白了它，你再看 K770 这类老手机，就不会只停留在“像素高不高、拍照好不好看”的表面判断上。