VoIP电话建立以后，用户真正需要传输的是声音，视频通话还要继续传输图像。这些实际承载通信内容的数据通常称为媒体（Media）。与媒体不同，SIP主要负责告诉通信双方“要不要建立这次会话、对方正在振铃还是已经接听、什么时候结束通话”。
因此，一通IP电话可以先拆成两个问题：信令负责建立和控制通信，媒体负责传送真正的语音或视频内容。
在常见SIP语音系统中，终端先通过SIP交换呼叫信息，再通过SDP协商可以使用的音频编码、媒体IP地址和端口。会话建立以后，实际实时语音通常通过RTP传输；如果启用了媒体加密，则可能使用SRTP。
VoIP中的“媒体”具体指什么
最典型的媒体是语音。用户对着麦克风讲话以后，声音先被终端采集并数字化，再经过语音Codec编码形成适合网络传输的数据。
视频通话中，摄像机采集的图像经过H.264、H.265、VP8等视频编码以后，同样形成连续的媒体数据。
从实时通信角度看，常见媒体可以包括：
- 实时语音；
- 实时视频；
- 部分实时文本或其他实时数据；
- 与会议、共享等业务有关的其他媒体流。
但并不是任何业务数据都必须通过RTP传输。例如即时消息、文件传输、传真等业务可以采用不同协议。传真既可能使用音频方式经过语音通道，也可能采用T.38等专门机制，因此不能简单写成“除了文字，所有媒体都走RTP”。
SIP、SDP和RTP分别负责什么
SIP电话中最容易混淆的，就是把SIP和语音媒体本身当成同一种数据。
实际上三者承担不同任务。
| 协议/数据 | 主要职责 | 典型内容 |
|---|---|---|
| SIP | 建立、修改和结束会话 | INVITE、Ringing、200 OK、ACK、BYE等 |
| SDP | 描述和协商媒体参数 | 媒体IP、端口、Codec、媒体方向等 |
| RTP | 传输实时媒体数据 | 编码后的语音或视频数据包 |
| RTCP | 提供RTP会话相关的质量反馈和控制信息 | 丢包、抖动、发送与接收统计等 |
例如分机1001呼叫1002时，1001先发送SIP INVITE。INVITE中可以携带SDP，告诉对方自己准备接收媒体的IP和端口，并列出可以使用的音频编码。
1002接听以后，在200 OK中的SDP返回自己的媒体参数。双方确认这些参数后，才按照协商结果建立媒体流。
所以可以简单记成：
SIP：我要和你通话
SDP：我们用什么方式传媒体
RTP：真正把声音或视频送过去
声音怎样变成RTP数据包
用户讲话时产生的是连续模拟声波，IP网络只能传输数字数据，因此声音进入网络以前要经历采样、量化、编码和分组。
以常见G.711语音为例，模拟语音经过8kHz采样并使用8bit PCM编码以后，形成64kbit/s的基础音频数据。
Codec不会直接把整个通话一次性生成一个巨大文件，而是连续处理很短的一段段声音。例如终端可以每20ms取得一段编码后的语音数据，再把它封装到RTP包中发送。
一个常见媒体路径可以理解为：
麦克风 → 音频采集 → Codec编码 → RTP封装 → UDP/IP → 网络 → RTP解包 → Codec解码 → 扬声器
RTP头部还会携带序列号和时间戳等信息，使接收端能够判断数据包顺序，并按照正确的播放时间恢复连续声音。
网络中的RTP包不一定严格按照发送顺序到达，也可能出现延迟变化甚至丢包，因此语音终端通常还需要抖动缓冲等机制平滑实际播放。
Codec和RTP是什么关系
Codec决定“声音怎样被编码”，RTP决定“编码后的实时数据怎样在网络中组织和传输”，两者不能混为一谈。
例如G.711、G.729、Opus等属于语音编码方式。不同Codec在语音质量、码率、计算复杂度和丢包适应能力方面存在差异。
双方建立通话时，需要找到共同支持的编码方式。如果主叫只允许某一种Codec，而被叫完全不支持，就可能无法建立正常媒体。
RTP本身并不知道“这一定是G.711”。RTP头中的Payload Type等信息用于标识媒体格式，具体编号和格式关系可能来自静态映射，也可能通过SDP动态协商。
因此，一通VoIP电话的媒体配置通常同时涉及：
- 媒体IP地址；
- RTP端口；
- Payload Type；
- 语音Codec；
- 每个媒体包承载多少毫秒语音；
- 发送和接收方向。
关于PCM与G.711本身的编码原理，可以继续参考PCM语音采样与G.711编码相关内容，本页不再重复展开采样和量化过程。
RTCP为什么和RTP一起出现
RTP主要传送媒体，而RTCP（RTP Control Protocol）负责提供与媒体传输有关的控制和统计信息。
通信端点可以通过RTCP交换接收质量信息，例如：
- 接收了多少RTP数据包；
- 出现多少丢包；
- 包到达时间变化情况；
- 发送端与接收端时间信息；
- RTP参与者相关标识。
这些数据可以用于监测媒体质量，也可以帮助系统判断当前网络是否存在较严重丢包或抖动。
RTCP并不会替代RTP，也不负责重传所有丢失的语音数据。实时电话通常更关注低延迟，某个语音包如果到达过晚，即使重新传输也可能已经失去播放价值。
如果系统需要保护媒体内容，还可能使用SRTP（Secure RTP）。SRTP在RTP媒体基础上增加加密、认证等安全机制。
因此，常见SIP安全体系里可以看到：
SIP over TLS：保护会话信令
SRTP：保护实际音视频媒体
两者保护的对象不同。
RTP媒体为什么不一定经过SIP服务器
SIP服务器参与了呼叫建立，并不意味着所有语音都必须经过这台服务器。
在一个简单局域网中，两台SIP终端通过服务器建立会话以后，可以按照SDP中协商的地址直接交换RTP：
SIP话机A ═══ RTP ═══ SIP话机B
服务器负责信令控制，但语音直接在两个终端之间传输。
在另外一些系统中，媒体可能需要经过中间设备，例如：
- SBC；
- 媒体代理；
- 录音服务器；
- 转码服务器；
- 会议媒体服务器；
- NAT边界设备。
这时媒体路径可能变成：
终端A → 媒体服务器/SBC → 终端B
采用哪种方式取决于网络结构、NAT、安全、录音、转码和会议等业务要求。
因此，排查VoIP问题时一定要知道实际RTP去了哪里，不能只根据SIP服务器地址推测媒体路径。
为什么电话已经接通却没有声音
这是理解“信令和媒体分离”最实际的例子。
如果主叫已经听到振铃，被叫也已经接听，通话计时开始，说明SIP层面的呼叫建立通常已经完成。但此时如果双方没有声音，问题更可能出现在媒体路径。
常见原因包括：
- SDP中填写了不可达的媒体IP地址；
- RTP端口被防火墙拦截；
- NAT转换后仍携带内网地址；
- SBC或媒体代理没有正常转发媒体；
- 双方没有协商到真正可用的Codec；
- 终端麦克风、扬声器或音频设备配置错误。
如果只有一边能够听到声音，则通常称为单通。此时应分别检查A→B和B→A两个方向的RTP，而不是继续反复修改SIP账号密码。
一个比较实用的排查顺序是：
SIP是否建立 → SDP协商了什么 → RTP实际发送到哪里 → 双向RTP是否都有数据 → Codec和终端音频是否正常
站内SIP电话建立流程已经重点讲INVITE、200 OK和ACK等信令，本页则专门把接通以后真正的语音媒体路径拆开说明。两篇结合起来，就能比较完整地理解一通SIP电话从呼叫建立到声音传输的过程。
从VoIP架构角度看，最需要记住的不是“RTP就是语音”，而是完整的分层关系：
Codec决定媒体如何编码，SDP描述双方媒体条件，RTP/SRTP传输实时媒体，RTCP提供质量反馈，而SIP负责建立和控制整个会话。
