简介这份PPT文档面向通信网络、核心网技术学习者及运营商技术人员系统讲解IMSIP多媒体子系统的技术原理与发展趋势帮助读者理解传统电路交换向基于IP的会话控制与业务提供系统演进的核心逻辑。资源共1个pptx文件压缩包约3.81MB内容以图文并茂的幻灯片形式呈现便于课堂讲解与自学梳理。文档从IMS概述、标准体系、产生背景切入逐层展开CSCF、MGCF、MRF等核心实体与SIP协议、鉴权安全及QoS机制并归纳接入无关、归属地控制、统一策略控制等主要特征。业务层面覆盖VoIP、视频通话、即时消息、多媒体彩铃等典型应用同时说明IMS在网络分层中的位置及与PSTN/PLMN的互通方式最后结合3GPP、GSMA RCS及5G演进梳理标准进展。已有101人学习适合需要建立IMS整体知识框架、准备技术汇报或教学备课的读者参考。1. IMS 到底是什么从一个打不通的电话说起你有没有遇到过这种情况手机信号满格VoLTE 图标也亮着但拨出去的电话就是接不通或者接通了没声音。排查半天基站正常、核心网正常最后定位到 IMS 注册失败。IMSIP Multimedia Subsystem中文叫 IP 多媒体子系统是 3GPP 在 Release 5 引入的一套全 IP 架构用来在分组域上承载语音、视频、消息和会议类业务。它最核心的价值是把传统电路域的语音搬到 IP 网络上同时保留电信级的服务质量控制和计费能力。今天你手机上的 VoLTE、VoNR、5G 新通话底层全靠 IMS 撑着。这份笔记面向的是需要理解 IMS 架构、动手搭环境验证、或者做 IMS 相关方案选型的工程师从原理到部署到排障一步步拆开讲。2. IMS 分层架构与核心网元SIP 信令怎么跑完全程2.1 三层架构的职责划分IMS 的架构从纸面上看是一张复杂的网元连接图但拆开来看就是三层承载层、控制层、业务层。承载层负责 IP 包的转发和 QoS 保障涉及 GGSN/UPF、PCRF/PCF 这些网元核心工作是给 SIP 信令和媒体流分配承载资源。控制层是 IMS 的大脑由 CSCF 系列网元组成负责注册、鉴权、会话建立和路由。业务层则是各种应用服务器 AS提供彩铃、会议、呼叫转移等增值业务。这三层之间通过标准化的参考点连接比如 Gm 接口连接 UE 和 P-CSCFISC 接口连接 S-CSCF 和 AS。理解这些参考点的作用比死记网元名字有用得多。实际排障时大部分问题都能通过抓包定位到某个参考点上的信令异常。2.2 CSCF 家族P、I、S 各管什么CSCF 是 Call Session Control Function分三种角色。P-CSCFProxy CSCF是 UE 进入 IMS 的第一跳相当于 SIP 代理负责信令转发、头域压缩和 IPSec 安全关联。I-CSCFInterrogating CSCF是 IMS 域的入口查询点负责向 HSS 查询用户注册状态并选择合适的 S-CSCF。S-CSCFServing CSCF是核心中的核心负责用户注册鉴权、会话控制和业务触发。用一句话概括P-CSCF 管接入I-CSCF 管查询S-CSCF 管控制。三者的分工在 3GPP TS 23.228 里有详细定义但实际部署中小规模场景常把三者合设在一个物理网元上大规模商用则严格分离。2.3 一次 VoLTE 呼叫的完整信令流程下面用 SIP 消息的简化流程说明一次 VoLTE 呼叫从发起到接通经历了什么。这里用 Python 伪代码模拟 SIP 消息的构造和发送顺序帮助理解信令交互。# 模拟 VoLTE 呼叫的 SIP 信令流程简化版 # 实际环境中这些消息由 UE 和 CSCF 自动生成此处仅用于理解流程 sip_flow [ # 第一步UE 发起 INVITE携带 SDP 提议 { step: 1, direction: UE - P-CSCF, method: INVITE, headers: { From: sip:user_aims.mnc001.mcc460.3gppnetwork.org, To: sip:user_bims.mnc001.mcc460.3gppnetwork.org, Contact: sip:user_a[UE_IP], Content-Type: application/sdp }, body: SDP: audio codecAMR-WB, port49152 }, # 第二步P-CSCF 转发 INVITE 到 S-CSCF { step: 2, direction: P-CSCF - S-CSCF, method: INVITE, note: P-CSCF 添加 Path 头域记录自身地址 }, # 第三步S-CSCF 触发业务逻辑查询 HSS 获取被叫信息 { step: 3, direction: S-CSCF - HSS, method: Cx: Location-Info-Request, note: 获取被叫当前注册的 S-CSCF 地址 }, # 第四步主叫侧 S-CSCF 将被叫 INVITE 路由到被叫侧 I-CSCF { step: 4, direction: S-CSCF(主叫) - I-CSCF(被叫), method: INVITE, note: 通过 DNS/ENUM 查询被叫域名的下一跳 }, # 第五步被叫侧返回 183 Session Progress携带被叫 SDP { step: 5, direction: 被叫 UE - 主叫 UE, method: 183 Session Progress, body: SDP: audio codecAMR-WB, port50123 }, # 第六步主叫发送 PRACK 确认临时响应 { step: 6, direction: 主叫 UE - 被叫 UE, method: PRACK, note: 确保 183 可靠传输 }, # 第七步被叫振铃返回 180 Ringing { step: 7, direction: 被叫 UE - 主叫 UE, method: 180 Ringing }, # 第八步被叫摘机返回 200 OK { step: 8, direction: 被叫 UE - 主叫 UE, method: 200 OK (INVITE), note: 携带最终 SDP 确认 }, # 第九步主叫发送 ACK 确认 { step: 9, direction: 主叫 UE - 被叫 UE, method: ACK, note: 会话正式建立开始 RTP 媒体流传输 } ] # 打印信令流程 for msg in sip_flow: print(fStep {msg[step]}: {msg[direction]} | {msg[method]}) if note in msg: print(f - {msg[note]})这段代码把一次 VoLTE 呼叫拆成九个关键步骤。第一步 INVITE 里携带的 SDP 是媒体协商的起点决定了双方用什么编解码器、哪个端口传 RTP。第三步的 Cx 查询是 IMS 特有的传统 SIP 网络没有这一步HSS 在这里充当了用户数据库和路由决策者的角色。第五步的 183 和第六步的 PRACK 是 IMS 对 SIP 的扩展目的是在正式接通前就完成媒体协商和资源预留这是 VoLTE 接通速度比 OTT 语音快的关键原因之一。参数上需要关注的是 SDP 里的编解码器协商结果。如果主叫提议 AMR-WB 但被叫只支持 AMR-NB最终会降级到窄带。实际部署中编解码器优先级由运营商策略决定通常在 S-CSCF 或 AS 上配置。2.4 关键协议栈与接口一览IMS 涉及的协议不止 SIP 一个。下表列出最常打交道的几个接口和协议方便对照排查。接口连接双方协议主要用途GmUE - P-CSCFSIP注册、呼叫信令CxI-CSCF/S-CSCF - HSSDiameter用户鉴权、位置查询ShAS - HSSDiameter业务数据查询ISCS-CSCF - ASSIP业务触发RxP-CSCF - PCRF/PCFDiameterQoS 策略请求MwCSCF 之间SIP信令路由排查注册失败时先看 Gm 接口的 SIP 消息有没有 401 挑战再看 Cx 接口的 Diameter 响应码。如果 Cx 返回 5001用户未知说明 HSS 里没有签约数据返回 5002用户未注册说明鉴权通过了但注册状态不对。这些 Diameter 结果码在 3GPP TS 29.228 里有完整定义。3. 从零搭一套 IMS 实验环境开源方案选型与部署3.1 开源 IMS 方案对比Kamailio、OpenIMS、FreeSWITCH想动手验证 IMS 流程最直接的办法是搭一套开源环境。常见的选择有三个方向。Kamailio 本身是 SIP 服务器不是完整的 IMS 套件但通过加载 ims_isc、ims_registrar_scscf 等模块可以模拟 CSCF 行为灵活性最高适合做信令流程验证。OpenIMS 是较早的开源 IMS 实现包含 P/I/S-CSCF 和 HSS架构完整但社区活跃度下降部署文档偏旧。FreeSWITCH 常被用作 IMS 中的 MRF媒体资源功能或 AS处理媒体面和会议业务。我一般推荐用 Kamailio MySQL 搭最小化 IMS 核心再配合 sngrep 抓包分析。这套组合的好处是每个模块的行为都能通过配置文件精确控制出了问题也容易定位到具体模块。3.2 用 Docker 部署 Kamailio 模拟 P-CSCF 和 S-CSCF以下步骤在 Ubuntu 22.04 上验证过Docker 版本 24.x 以上。先拉取 Kamailio 镜像并准备配置文件。# 拉取 Kamailio 官方镜像 docker pull kamailio/kamailio:5.7-alpine # 创建配置目录 mkdir -p /opt/ims-lab/kamailio/etc /opt/ims-lab/kamailio/log # 生成最小化 P-CSCF 配置 cat /opt/ims-lab/kamailio/etc/kamailio.cfg EOF #!KAMAILIO ####### 全局参数 ####### debug3 log_stderroryes forkyes children4 ####### 加载模块 ####### loadmodule sl.so loadmodule tm.so loadmodule rr.so loadmodule pv.so loadmodule maxfwd.so loadmodule siputils.so loadmodule xlog.so loadmodule registrar.so loadmodule ims_usrloc_pcscf.so loadmodule ims_registrar_pcscf.so ####### 模块参数 ####### modparam(ims_usrloc_pcscf, db_url, mysql://kamailio:kamailiodb/ims_usrloc) modparam(ims_registrar_pcscf, is_registered_fallback, 1) ####### 请求路由 ####### request_route { # 检查 SIP 消息合法性 if (!mf_process_maxfwd_header(10)) { sl_send_reply(483, Too Many Hops); exit; } # 处理注册请求 if (is_method(REGISTER)) { # 调用 P-CSCF 注册处理 if (!ims_registrar_pcscf_handle_register()) { xlog(L_ERR, REGISTER failed from $si:$sp\n); sl_send_reply(500, Registration Failed); exit; } xlog(L_INFO, REGISTER success for $fu\n); exit; } # 处理 INVITE 等会话请求 if (is_method(INVITE|ACK|BYE|CANCEL)) { # 记录路由 if (!loose_route()) { record_route(); } # 转发到 S-CSCF此处简化为直接转发 xlog(L_INFO, Forwarding $rm from $fu to $tu\n); if (!t_relay()) { sl_send_reply(500, Relay Failed); } exit; } sl_send_reply(405, Method Not Allowed); } EOF # 启动 Kamailio 容器 docker run -d \ --name kamailio-pcscf \ --network host \ -v /opt/ims-lab/kamailio/etc/kamailio.cfg:/etc/kamailio/kamailio.cfg \ -v /opt/ims-lab/kamailio/log:/var/log/kamailio \ kamailio/kamailio:5.7-alpine \ kamailio -DD -E -f /etc/kamailio/kamailio.cfg这段配置做了三件事加载 IMS 相关模块、处理 REGISTER 注册请求、转发会话类请求。ims_registrar_pcscf_handle_register()是 P-CSCF 注册的核心函数它会解析 SIP REGISTER 消息中的 Contact 头域和 Path 头域将 UE 的地址信息存入 usrloc 表。is_registered_fallback参数设为 1 表示当数据库查询失败时回退到内存缓存实验环境建议开启生产环境要关掉。启动后可以用docker logs kamailio-pcscf查看运行日志。如果看到REGISTER success说明注册流程通了。接下来用 sngrep 或 tcpdump 抓包验证 SIP 消息交互。3.3 用 sngrep 验证 SIP 注册与呼叫流程sngrep 是一个终端下的 SIP 抓包分析工具比 tcpdump 直观得多。安装后直接运行即可监听指定网卡的 SIP 流量。# 安装 sngrep sudo apt install sngrep -y # 监听 eth0 网卡的 SIP 流量5060 端口 sudo sngrep -d eth0 port 5060 # 或者保存抓包结果到文件后续分析 sudo sngrep -d eth0 -O /opt/ims-lab/capture.pcap port 5060运行后界面会实时显示 SIP 消息流。按 Enter 进入某条会话可以看到完整的消息交互。重点看几个地方REGISTER 消息的响应码是不是 200 OKINVITE 消息的 Route 头域是否正确指向了下一跳SDP 里的 IP 和端口是否可达。如果注册返回 401 Unauthorized说明鉴权挑战正常UE 需要用 IMS AKA 算法重新计算认证响应。如果返回 403 Forbidden通常是 IMPI/IMPU 不匹配检查 HSS 里的签约数据。这些排查思路在后面的避坑章节还会展开。4. IMS 与 5G 的融合VoNR 架构变化与关键参数4.1 从 VoLTE 到 VoNR哪些网元变了5G 时代 IMS 仍然是语音业务的核心但接入网和核心网的变化带来了一些调整。最明显的是 VoNRVoice over New Radio不再依赖 LTE 锚点语音直接跑在 NR 上。核心网侧SMF/UPF 取代了 SGW/PGW 的部分功能PCF 取代了 PCRF 做策略控制。IMS 侧的变化相对小CSCF 和 HSS 基本保留但 HSS 需要支持 5G 的签约数据格式通常升级为 UDM/UDR 架构。另一个变化是 IMS 数据通道IMS Data Channel的引入这是 3GPP Release 16 为 5G 新通话定义的能力允许在语音通话中同时传输结构化数据比如实时翻译、名片推送、互动表情。这给 IMS 业务层带来了新的 AS 类型和 SIP 消息扩展。4.2 5G 新通话的关键参数配置部署 VoNR 时以下几个参数直接影响通话质量和接通率。参数典型值作用调整建议5QI1语音承载的 QoS 标识必须设为 1对应 GBR 承载AMR-WB 速率12.65 kbps语音编解码速率根据无线条件动态调整TTI Bundling开启提升边缘覆盖小区边缘用户建议开启ROHC开启头压缩减少 IP 头开销提升频谱效率IMS 注册周期3600s重新注册间隔太短增加信令负荷太长影响可达性5QI 设为 1 是 VoNR 的硬性要求对应 5G 核心网里的 GBRGuaranteed Bit Rate承载。如果设错了语音包会被当成普通数据流处理拥塞时优先丢弃用户感知就是断断续续。AMR-WB 的速率调整由无线侧根据信道质量决定核心网侧只需要保证承载带宽足够。4.3 用 Wireshark 分析 VoNR 呼叫的 RTP 流VoNR 呼叫建立后媒体面走的是 RTP 流。用 Wireshark 抓包后通过 RTP 分析功能可以看抖动、丢包和编解码器类型。# 在 UPF 侧抓取 N3 接口的 GTP-U 流量 sudo tcpdump -i eth0 -w /opt/ims-lab/vonr_n3.pcap udp port 2152 # 用 Wireshark 打开后过滤 RTP 流 # 过滤表达式rtp # 然后点击 Telephony - RTP - Show All StreamsWireshark 的 RTP 流分析界面会显示每个流的 SSRC、丢包率、最大抖动和编解码器。VoNR 场景下如果抖动超过 30ms 或丢包率超过 1%用户就会感知到卡顿。这时候需要回到 QoS 参数检查 5QI 配置和无线侧的调度策略。注意抓取 GTP-U 流量需要在 UPF 或 N3 接口的镜像端口上操作生产环境要确保抓包行为符合安全规范避免捕获用户面敏感数据。5. IMS 部署避坑指南注册失败、单通、编解码不匹配5.1 注册返回 401 后 UE 不再重试现象UE 发起 REGISTER网络返回 401 Unauthorized 挑战但 UE 没有发送带鉴权响应的第二次 REGISTER注册流程中断。原因通常是 UE 侧的 ISIM 应用没有正确读取 IMPI 或密钥或者 P-CSCF 返回的 WWW-Authenticate 头域里缺少必要参数。另一个常见原因是 UE 的 IMS APN 配置错误导致鉴权响应发到了错误的地址。解决检查 UE 的 IMS 配置确认 IMPI、IMPU 和密钥与 HSS 签约一致。在 P-CSCF 侧抓包看 401 消息的 WWW-Authenticate 头域是否包含algorithmAKAv1-MD5和正确的 nonce 值。如果 nonce 过期时间太短UE 计算完响应已经超时可以适当调大 nonce 有效期。5.2 呼叫建立成功但一方听不到声音现象SIP 信令显示 200 OK 和 ACK 都正常通话计时也开始走了但主叫或被叫一方完全听不到声音。原因九成以上是媒体面问题。可能是 SDP 协商的 IP 地址不可达比如 UE 在 NAT 后面SDP 里填的是私网地址也可能是 RTP 端口被防火墙拦截或者编解码器协商成功但实际发送的编码格式不匹配。解决先在 UE 侧抓 RTP 包确认有没有发出和收到 RTP 流。如果只有单向流检查 SDP 里的c行和m行的地址端口。NAT 场景需要 IMS 支持 ICE 或 STUN但运营商 IMS 通常用 P-CSCF 做媒体代理来规避这个问题。如果 RTP 双向都有但听不到声音用 Wireshark 的 RTP 分析看编解码器类型确认双方实际发送的 PT 值是否一致。5.3 编解码器协商成功但音质极差现象SDP 协商显示双方都选了 AMR-WB但通话中声音断断续续MOS 分低于 3。原因可能是无线侧丢包严重也可能是核心网 QoS 没配好导致语音包被降级处理。还有一种情况是 AMR-WB 的速率模式不匹配一方用 23.85 kbps 另一方只支持 12.65 kbps实际传输时频繁切换速率。解决先看无线侧的 BLER误块率和丢包统计。如果无线正常检查核心网的 5QI 或 QCI 配置VoLTE 场景 QCI 必须为 1VoNR 场景 5QI 必须为 1。然后在 SDP 里确认mode-set参数强制双方使用相同的 AMR 速率集合。运营商通常会在 S-CSCF 或 AS 上做编解码器策略控制限制可用的速率范围。5.4 HSS 返回 5001 用户未知现象I-CSCF 向 HSS 发送 Cx 查询HSS 返回 5001User Unknown注册或呼叫流程失败。原因HSS 里没有该用户的签约数据或者 IMPI/IMPU 的格式不对。常见的是 IMPU 缺少sip:前缀或者域名部分与 HSS 配置的 IMS 域不匹配。解决登录 HSS 管理界面检查用户的 IMPI、IMPU 和签约业务列表。IMPU 的格式通常是sip:号码ims.mncXXX.mccXXX.3gppnetwork.org注意 mnc 和 mcc 的位数要对齐。如果用户是从其他 HSS 迁移过来的确认数据导入时没有截断字段。5.5 P-CSCF 地址在 UE 上配置错误现象UE 根本无法发起 IMS 注册或者注册请求发到了错误的地址。原因UE 的 P-CSCF 地址通常通过 PCOProtocol Configuration Options从 PGW/UPF 获取如果核心网侧没有正确配置 P-CSCF 的发现机制UE 就不知道往哪发注册请求。解决检查 PGW/UPF 的 P-CSCF 地址配置确保通过 PCO 或 DHCP 下发给 UE 的地址是正确的。VoLTE 场景下P-CSCF 地址一般在 APN 配置里指定。VoNR 场景下SMF 需要支持 P-CSCF 发现功能可以通过本地配置或 NRF 查询获取。UE 侧可以用*#*#4636#*#*查看 IMS 注册状态和 P-CSCF 地址。6. IMS 发展趋势与验证方法从 RCS 到 IMS Data Channel6.1 用 SIPp 做 IMS 压力测试验证一套 IMS 环境能不能扛住并发最直接的工具是 SIPp。它可以模拟大量 UE 同时发起注册和呼叫观察 CSCF 的响应时间和成功率。!-- ims_register_test.xmlSIPp 注册压力测试脚本 -- ?xml version1.0 encodingISO-8859-1 ? !DOCTYPE scenario SYSTEM sipp.dtd scenario nameIMS REGISTER Stress Test !-- 第一步发送 REGISTER -- send retrans500 ![CDATA[ REGISTER sip:[field0] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch[branch] From: sip:[field0][field1];tag[call_number] To: sip:[field0][field1] Call-ID: [call_id] CSeq: 1 REGISTER Contact: sip:[field0][local_ip]:[local_port] Max-Forwards: 70 Expires: 3600 Content-Length: 0 ]] /send !-- 第二步期待 401 挑战 -- recv response401 authtrue / !-- 第三步发送带鉴权响应的 REGISTER -- send retrans500 ![CDATA[ REGISTER sip:[field0] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch[branch] From: sip:[field0][field1];tag[call_number] To: sip:[field0][field1] Call-ID: [call_id] CSeq: 2 REGISTER Contact: sip:[field0][local_ip]:[local_port] [authentication username[field0] password[field2]] Max-Forwards: 70 Expires: 3600 Content-Length: 0 ]] /send !-- 第四步期待 200 OK -- recv response200 rtdtrue / !-- 第五步注销 -- send retrans500 ![CDATA[ REGISTER sip:[field0] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch[branch] From: sip:[field0][field1];tag[call_number] To: sip:[field0][field1] Call-ID: [call_id] CSeq: 3 REGISTER Contact: sip:[field0][local_ip]:[local_port] Expires: 0 Content-Length: 0 ]] /send recv response200 / /scenario这个脚本模拟了一个完整的注册-鉴权-注销流程。[field0]到[field2]是外部传入的参数分别代表 IMPI、IMS 域和密码。运行时用-inf参数指定 CSV 文件批量导入用户数据。# 准备用户数据文件 users.csv cat /opt/ims-lab/users.csv EOF user001;ims.mnc001.mcc460.3gppnetwork.org;password001 user002;ims.mnc001.mcc460.3gppnetwork.org;password002 user003;ims.mnc001.mcc460.3gppnetwork.org;password003 EOF # 运行 SIPp 压力测试100 个并发用户每秒发起 10 个注册 sipp -sf ims_register_test.xml \ -inf /opt/ims-lab/users.csv \ -m 100 \ -r 10 \ -d 1000 \ -l 50 \ 192.168.1.100:5060 # 参数说明 # -m 100 总共发起 100 次注册 # -r 10 每秒发起 10 次 # -d 1000 每次注册后暂停 1000ms # -l 50 最大并发呼叫数 50跑完后 SIPp 会输出统计报告重点看Successful call和Failed call的比例以及Response Time的分布。如果失败率超过 1%需要检查 CSCF 的 CPU 和内存占用或者 HSS 的 Diameter 响应延迟。我一般会在压测同时用docker stats监控容器资源找到瓶颈网元。6.2 IMS Data Channel 的验证思路IMS Data Channel 是 5G 新通话的核心能力允许在通话中建立一条可靠的数据通道。验证这个功能需要 UE、IMS 核心网和 AS 都支持。目前开源方案对 Data Channel 的支持还不完善Kamailio 需要通过自定义模块处理SIP INFO或MSRP消息来模拟。一个可行的验证路径是先用 SIPp 模拟支持 Data Channel 的 UE在 INVITE 的 SDP 里携带mapplication行声明数据通道能力然后观察 S-CSCF 是否正确触发对应的 AS。如果 AS 返回 200 OK 并在 SDP 里确认了数据通道参数说明信令面通了。媒体面则需要用 MSRP 客户端发送测试消息验证端到端可达。6.3 我踩过的坑和现在的习惯刚接触 IMS 的时候我花了两天时间排查一个注册失败问题最后发现是 HSS 里 IMPU 的域名少写了一个mnc的零。从那以后我养成了一个习惯每次配置完 HSS 数据先用sip:开头的完整 IMPU 在本地做一次格式校验确认域名部分和 P-CSCF 配置的 IMS 域完全一致。另一个习惯是抓包永远从 Gm 接口开始因为 UE 和 P-CSCF 之间的信令最干净没有经过任何网元改写能最快定位问题是出在 UE 侧还是网络侧。IMS 这套体系学起来陡峭但一旦把注册和呼叫两条信令流程跑通后面排查问题就是按图索骥。希望帮到你。本文还有配套的精品资源点击获取