在VoNR（Voice over NR）业务中，终端要打通任何一通IMS语音、视频或RCS呼叫，都必须先完成两件事：第一，建立一条通往IMS的IP-CAN承载；第二，向IMS核心网发起SIP REGISTER注册。而横亘在这两步之间、决定整个IMS业务能否"敲门"成功的第一道关口，就是P-CSCF（Proxy-Call Session Control Function）地址发现。
P-CSCF是IMS网络的唯一入口网元，所有来自UE的SIP信令都必须经过它转发、压缩、加密与策略控制。如果UE拿不到一个可达的P-CSCF IP地址，那么后续的鉴权、注册、呼叫建立都无从谈起。本文聚焦3GPP TS 23.228、TS 23.501/23.502与TS 24.501所定义的通过ePCO（Extended Protocol Configuration Options）在PDU会话建立过程中下发P-CSCF地址这一具体机制，从信令时序、IE编码、SMF解析逻辑到抓包排错进行全链路拆解。
在3GPP TS 23.228第5.1节中明确定义了IMS架构中P-CSCF的角色：它是UE接入IMS的第一个接触点（first point of contact），负责与UE之间的SIP信令交互、SIP压缩（SigComp）、IPsec安全联盟协商，并向PCF发起承载策略请求（5G中经N5/Rx接口）。正因为它是"门"，UE必须先知道这扇门在哪里。
TS 23.228定义了P-CSCF发现的几种可选方式：
设计意图：为什么3GPP要优先把P-CSCF发现"搭便车"放在承载建立流程里，而不是单独走一次DHCP？核心在于减少往返时延与简化UE实现。IMS语音业务对注册时延敏感（典型要求VoNR初始注册在数秒内完成），将P-CSCF地址的请求与下发捎带（piggyback）在PDU会话建立的NAS消息中，可以节省一次完整的DHCP四步交互（DORA）往返，使UE在承载一建立的同时就具备发起REGISTER的条件。这也是运营商现网普遍在SMF/PGW上静态配置P-CSCF地址池、直接经ePCO下发的根本原因。
PCO（Protocol Configuration Options）最早定义于TS 24.008第10.5.6.3节，用于在NAS信令中承载"协议配置参数"，其结构是一组（协议/容器ID + 长度 + 内容）的列表。在5G系统中，TS 24.501复用了这套PCO编码，并在此基础上引入了ePCO（Extended PCO）。
二者的关键差异在于长度域与可承载能力：
当UE和网络（SMF）均支持ePCO时，优先使用ePCO；否则回落到PCO。
P-CSCF地址请求与下发依赖以下容器ID（定义于TS 24.008第10.5.6.3节，被TS 24.501继承）：
| 容器ID（Hex） | 名称 | 作用 | 出现位置 |
|---|---|---|---|
| 0x000C | P-CSCF IPv4 Address Request / Info | 请求/携带一个或多个P-CSCF IPv4地址 | UE请求中为"请求标志"，SMF响应中携带地址列表 |
| 0x000D | P-CSCF IPv6 Address Request / Info | 请求/携带一个或多个P-CSCF IPv6地址 | 同上，IPv6场景 |
| 0x0003 | DNS Server IPv4 Address Request | 请求DNS服务器IPv4 | 常与P-CSCF一并请求 |
| 0x0006 | MS Support of Local Address Assignment | 指示UE支持本地地址分配 | 辅助参数 |
| 0x000A | IP address allocation via NAS signalling | 指示IP地址经NAS信令分配 | 影响地址分配方式 |
ePCO将这些容器ID承载在扩展结构中，并允许单个容器携带多至N个P-CSCF地址，为冗余与负载分担提供基础。
flowchart LR
A["ePCO IE<br/>TS 24.501 §9.11.4.3"] --> B["Configuration Protocol<br/>(4 bit 配置协议指示)"]
A --> C["Extension bit / Spare"]
A --> D["Protocol ID / Container ID List"]
D --> C1["0x000C<br/>P-CSCF IPv4"]
D --> C2["0x000D<br/>P-CSCF IPv6"]
D --> C3["0x0003<br/>DNS IPv4"]
C1 --> E1["IPv4地址列表<br/>(按优先级排序)"]
C2 --> E2["IPv6地址列表<br/>(按优先级排序)"]
下面给出VoNR场景下，UE建立IMS专用PDU会话并经ePCO获取P-CSCF地址的完整信令时序（对应TS 23.502第4.3.2.2.1节"UE requested PDU Session Establishment"）：
sequenceDiagram
participant UE
participant RAN as gNB
participant AMF
participant SMF
participant UDM
participant PCF
participant UPF
UE->>RAN: RRC建立 + NAS: PDU Session Establishment Request
Note over UE: DNN=ims, S-NSSAI, PDU类型=IPv4v6<br/>ePCO含0x000C/0x000D(P-CSCF请求)
RAN->>AMF: N2 Initial UE Message(透传NAS)
AMF->>AMF: 基于DNN=ims+S-NSSAI选择SMF
AMF->>SMF: N11 Nsmf_PDUSession_CreateSMContext<br/>(SUPI,DNN,ePCO,请求类型)
SMF->>UDM: Nudm_SDM_Get(获取SM签约/DNN配置)
UDM-->>SMF: Session Mgmt Subscription(DNN信息)
SMF->>PCF: N7 Npcf_SMPolicyControl_Create(建立SM策略)
PCF-->>SMF: SM Policy(PCC规则, 默认5QI=5)
SMF->>UPF: N4 Session Establishment(PFCP)
UPF-->>SMF: N4响应(F-TEID)
Note over SMF: 解析P-CSCF地址池(本地配置/UDM/DNS)<br/>选择IP并排序
SMF-->>AMF: N11 响应(N1 SM msg: PDU Estab Accept + ePCO[P-CSCF IP])
AMF->>RAN: N2 PDU Session Resource Setup(N1 SM msg + N2传输层IE)
RAN->>UE: RRC Reconfiguration + NAS: PDU Estab Accept(ePCO含P-CSCF地址)
Note over UE: 提取P-CSCF IP列表 → 发起SIP REGISTER
消息①：UE → gNB（透传至AMF）—— PDU Session Establishment Request
这是整条流程的起点，也是P-CSCF发现请求真正"上车"的地方。该NAS消息（TS 24.501第8.3.1节）中的核心IE包括：
0x000C（P-CSCF IPv4 Address Request）与0x000D（P-CSCF IPv6 Address Request），向网络声明"我要P-CSCF地址"。这正是P-CSCF发现的请求载体。消息③：AMF → SMF —— Nsmf_PDUSession_CreateSMContext（N11/SBI）
AMF依据(DNN, S-NSSAI)查询NRF或本地配置选择SMF后，通过服务化接口N11发起SM上下文创建。AMF会把UE的ePCO原样透传给SMF——注意，AMF并不理解也不修改ePCO内容，它只是搬运工。真正的P-CSCF解析与决策发生在SMF。
消息④-⑤：SMF ↔ UDM
SMF通过Nudm_SDM_Get获取该SUPI在IMS DNN上的签约数据（DNN配置、SSC模式、允许的PDU会话类型、默认5QI等）。在某些部署中，UDM/UDR也会保存该DNN对应的P-CSCF候选地址列表或FQDN，作为SMF解析的输入之一。
消息⑥-⑦：SMF ↔ PCF
SMF向PCF发起Npcf_SMPolicyControl_Create建立SM策略关联。PCF下发PCC规则，确定IMS信令默认QoS流为5QI=5（Standardized 5QI，Non-GBR，优先级0.5，对应IMS信令承载）。这一步与P-CSCF地址下发并不同一回事，但同属IMS会话的策略准备。
SMF内部：P-CSCF地址解析与选择
这是整个机制的"心脏"。SMF拿到ePCO中的P-CSCF请求后，按如下优先级解析地址：
随后SMF对返回的多个地址按优先级排序（可基于到UPF的拓扑就近、实时负载、健康检查结果），填入ePCO响应。
消息⑨：SMF → AMF（透传至UE）—— PDU Session Establishment Accept
SMF构造N1 SM消息PDU SESSION ESTABLISHMENT ACCEPT（TS 24.501第8.3.2节），其中：
0x000C（一个或多个P-CSCF IPv4地址）与0x000D（一个或多个P-CSCF IPv6地址）。这就是P-CSCF地址真正下发到UE的载体。UE收到后，从ePCO中取出P-CSCF地址列表，选首个地址作为目标，向其发起SIP REGISTER——至此P-CSCF发现完成，IMS注册流程正式开始。
| 维度 | ePCO/PCO捎带方式 | DHCP方式 | DNS方式 |
|---|---|---|---|
| 触发时机 | PDU会话/PDN建立NAS流程内 | 承载建立后单独发起 | 获得FQDN后查询 |
| 标准依据 | TS 23.228 §5.1; TS 24.501/24.008 | RFC 3361/3319 | RFC 3263 |
| 额外信令往返 | 无（捎带） | 1次DORA往返 | 1~多次DNS查询 |
| 时延影响 | 最小 | 中 | 较大 |
| 地址形态 | 直接返回IP | IP或FQDN | 需先有FQDN |
| 现网部署 | 主流首选 | 备选/异厂商对接 | 常作为DHCP后的二级解析 |
| UE实现复杂度 | 低 | 中（需DHCP客户端） | 中（需DNS+RFC3263） |
选型逻辑：由于ePCO方式零额外往返、对UE最友好，且与5GC的会话管理天然耦合，几乎成为所有VoNR现网的事实标准。DHCP方式更多见于跨厂商对接或早期VoLTE过渡阶段；DNS方式则作为DHCP返回域名时的必然后继步骤。
ePCO允许SMF一次返回多个P-CSCF地址，这不仅是冗余设计，更承载着负载分担语义。UE按地址列表的顺序（由SMF排序决定优先级）选择首个P-CSCF发起REGISTER；若该P-CSCF在一定时间内无响应（定时器超时，典型如SIP T1重传到上限）或返回5xx类错误，UE则切换到列表中的下一个P-CSCF地址重试。
下图为P-CSCF发现后的注册决策与故障转移流程：
flowchart TD
A[UE完成IMS PDU会话建立] --> B[ePCO返回P-CSCF地址列表]
B --> C[按优先级取首个P-CSCF IP]
C --> D[发起SIP REGISTER]
D --> E{注册成功?}
E -->|成功| F[IMS注册完成]
E -->|超时/5xx失败| G{列表中还有<br/>备选P-CSCF?}
G -->|是| H[切换到下一地址]
H --> D
G -->|否| I[注册失败上报<br/>触发会话重建/重选]
这一机制使得单台P-CSCF故障时，UE无需重建PDU会话即可自动切换，显著提升VoNR业务可用性。SMF侧通常配合健康检查（如定期N端口探测或与P-CSCF的邻接关系维护）动态调整地址池，避免把故障P-CSCF排在首位。
在5G核心网抓包（NGAP/NAS或N11 SBI）时，识别P-CSCF发现的关键是定位PDU SESSION ESTABLISHMENT REQUEST / ACCEPT这两条NAS消息，并展开其Extended protocol configuration options字段：
PDU SESSION ESTABLISHMENT REQUEST中应能看到容器ID 0x000c（P-CSCF IPv4 address request）和/或 0x000d（P-CSCF IPv6 address request），此时仅为请求标志，内容为空；PDU SESSION ESTABLISHMENT ACCEPT的ePCO中，0x000c/0x000d容器里应填入一个或多个P-CSCF IP地址。若此处为空，说明SMF未下发P-CSCF地址——这是VoNR注册失败的头号原因。| 现象 | 可能原因 | 排错方向 |
|---|---|---|
| UE始终不发REGISTER | ePCO中P-CSCF地址为空 | 检查SMF的P-CSCF地址池配置、DNN=ims匹配、UDM签约 |
| REGISTER发出但无响应 | P-CSCF地址不可达/防火墙拦截 | ping/traceroute到P-CSCF；核查UPF到P-CSCF路由、IPsec策略 |
| 偶发注册失败 | 首选P-CSCF负载高或故障 | 查ePCO是否返回多个地址；核查P-CSCF健康检查与负载均衡 |
| IPv6场景P-CSCF缺失 | UE请求IPv4但DNN仅配IPv6 P-CSCF | 核对PDU Session Type与地址族配置一致性 |
| UE发了DHCP而未用ePCO | UE或网络未协商ePCO能力 | 查UE 5GS capability与SMF ePCO支持开关 |
| ## 常见问题 |
Q: PCO和ePCO到底该用哪个？会不会冲突？ A: 不会冲突。当UE和SMF均支持ePCO时，双方优先使用ePCO；若任一方不支持，则回落到传统PCO。二者承载的容器ID（如0x000C/0x000D）语义一致，ePCO的优势在于扩展的长度域与更丰富的参数支持，是PCO的超集演进。
Q: P-CSCF地址是UE自己选，还是网络指定？ A: 网络指定。SMF完成地址解析、排序后，把P-CSCF地址列表（含优先级）经ePCO下发给UE；UE只能在列表内按顺序选择，不能自行发明地址。这种"网络主导、UE执行"的设计保证了运营商对IMS入口的完全掌控。
Q: 如果ePCO里没有下发P-CSCF地址，UE还能注册IMS吗？ A: 理论上可以走DHCP/DNS方式兜底，但现网中绝大多数UE不会主动这么做，而是直接判定IMS会话不可用。因此ePCO地址缺失通常直接表现为VoNR/VoLTE注册失败，是排错的首要怀疑点。
Q: P-CSCF发现和IMS的IPsec安全联盟（SA）建立是什么关系？ A: P-CSCF发现只解决"地址在哪"，是后续所有SIP交互的前提。拿到P-CSCF地址后，UE才会在REGISTER/401/REGISTER/200的鉴权过程中与P-CSCF协商建立IPsec SA（基于port Kaiser/Ipsec-3gpp参数），二者是先后承接的两个独立机制。
Q: VoNR和VoLTE在P-CSCF发现上有本质区别吗？ A: 机制一致，差异在承载载体：VoLTE中是PDN Connectivity流程的PCO（TS 24.301/23.401），VoNR中是PDU Session Establishment流程的ePCO（TS 24.501）。5G的ePCO在扩展性与参数容量上更强，是4G PCO向5G的演进。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。