跳到主要内容

P-CSCF/E-CSCF 操作指南

目录​

  1. 概述
  2. IMS 架构中的角色
  3. P-CSCF 功能
  4. E-CSCF 功能
  5. Web UI 操作
  6. 呼叫流程
  7. 故障排除

概述​

P-CSCF（代理呼叫会话控制功能）是 IMS 网络中用户设备（UE）的第一个接触点。它作为边缘代理，处理安全性、QoS 强制执行和紧急呼叫路由。在此实现中，P-CSCF 还充当 E-CSCF（紧急 CSCF）以支持紧急服务。

重要：在我们的部署中，P-CSCF 默认不转发媒体。媒体直接在 UE 和 OmniTAS（电话应用服务器）或其他媒体端点之间流动。P-CSCF 仅作为 SIP 信令代理。

3GPP 规范​

  • 3GPP TS 23.228：IP 多媒体子系统（IMS）第二阶段
  • 3GPP TS 24.229：IMS 呼叫控制协议
  • 3GPP TS 33.203：IMS 的接入安全
  • 3GPP TS 23.167：IP 多媒体子系统（IMS）紧急会话

主要职责​

  1. 第一接触点：UE 在 IMS 中的初始 SIP 代理
  2. 安全强制：IPsec 隧道的建立和管理
  3. QoS 控制：通过 Rx 与 PCRF 接口进行策略强制
  4. 紧急服务：路由紧急呼叫并提供 IMEI 到 MSISDN 的查找（E-CSCF 功能）
  5. 压缩：支持 SigComp 以优化带宽
  6. 传输支持：支持 UDP 和 TCP

IMS 架构中的角色​

网络位置​

3GPP 参考点​

接口协议目的连接到
GmSIP/IPsecUE 到 P-CSCF用户设备
MwSIPP-CSCF 到 I-CSCF/S-CSCF核心 IMS
RxDiameterQoS/策略控制PCRF
MlHTTP/HELD位置检索LRF（E-CSCF）
MgSIP紧急呼叫MGCF/E-CSCF

P-CSCF 功能​

1. 注册处理​

P-CSCF ��来自 UE 的 SIP REGISTER 消息的第一个跳。

注册流程​

关键特性​

路径头插入：

Path: <sip:term@pcscf.ims.mnc001.mcc001.3gppnetwork.org:5060;lr>
  • 确保后续请求通过 P-CSCF 路由返回
  • 根据 RFC 3327 的要求用于 IMS

注册计时器强制：

  • 强制注册过期时间为 599 秒
  • 用于网络控制覆盖 UE 请求的值

IMEI 提取：

  • 从 Contact 头提取 IMEI： +sip.instance="<urn:gsma:imei:...>"
  • 存储在哈希表中以进行紧急呼叫映射

特定于传输的处理：

  • iOS 设备：延长 TCP 生命周期以防止过早断开连接

2. 安全功能​

IPsec 隧道管理​

P-CSCF 与 UE 建立 IPsec ESP 隧道以实现安全的 SIP 信令。

IPsec 配置：

IPsec 功能配置如下参数：

  • 监听地址：10.4.12.165（P-CSCF 的 IP 地址，用于 IPsec 端点）
  • 客户端端口（基础）：5100（UE → P-CSCF 流量的起始端口）
  • 服务器端口（基础）：6100（P-CSCF → UE 流量的起始端口）
  • 端口范围：可配置的端口池（通常为 1000-10000 个端口）
  • SPI ID 起始：4096（安全参数索引分配的起始值）
  • SPI ID 范围：100000（可用于分配的 SPI 对数量）
  • 最大连接数：20（每个工作线程的最大并发 IPsec 安全关联）

SPI 和端口管理​

每个 UE 和 P-CSCF 之间的 IPsec 隧道需要唯一标识符以保持流量的分离和安全。系统管理两种类型的资源：

安全参数索引（SPIs）：

每个 IPsec 隧道使用两个 SPI - 每个方向一个：

  • spi-c（客户端 SPI）：标识从 UE 发送到 P-CSCF 的数据包
  • spi-s（服务器 SPI）：标识从 P-CSCF 发送到 UE 的数据包

SPI ��对的形式从配置的池中分配。系统通常配置为：

  • 起始 SPI 值：4096
  • 可用范围：100,000 SPI 值
  • 这为 50,000 个同时隧道提供了容量（对以连续的偶数/奇数分配）

端口分配：

每个隧道还在 P-CSCF 上使用唯一的 UDP 端口：

  • 客户端端口：P-CSCF 接收来自 UE 的 IPsec 数据包的端口
  • 服务器端口：P-CSCF 向 UE 发送 IPsec 数据包的端口

典型的端口配置：

  • 客户端端口起始值：5100
  • 服务器端口起始值：6100
  • 端口范围：10,000 个可用端口
  • 当范围耗尽时，端口会回绕到起始位置

资源分配工作原理：

当 UE 注册并请求 IPsec 保护时：

  1. 第一次注册：获取 spi-c=4096，spi-s=4097，client port=5100，server port=6100
  2. 第二次注册：获取 spi-c=4098，spi-s=4099，client port=5101，server port=6101
  3. 第三次注册：获取 spi-c=4100，spi-s=4101，client port=5102，server port=6102

依此类推...

在 10,000 次注册后，端口回绕到开头（5100，6100），而 SPI 继续递增。这允许比可用端口更多的隧道，只要 UE 拥有不同的 IP 地址。

资源限制：

同时 IPsec 隧道的最大数量由首先达到的限制决定：

  • SPI 范围容量（通常为 50,000 对）
  • 端口范围容量（通常为 10,000 个端口）
  • 系统内存和处理能力

通过 Web UI 监控：

导航到 P-CSCF 页面 → IPsec 统计（如果可用）查看：

  • 活动 IPsec 隧道的数量
  • 可用 SPI/端口对的数量
  • 利用率百分比

如果您看到与 IPsec 相关的注册失败，可能表示：

  • SPI 池耗尽（所有 50,000 对都在使用中）
  • 端口池耗尽（所有 10,000 个端口都在使用中）
  • 旧隧道未被正确清理

何时释放资源：

当以下情况发生时，SPI 和端口会返回到可用池中：

  • UE 注销（发送带有 Expires: 0 的 REGISTER）
  • 注册过期而未被刷新
  • 通过 Web 界面手动销毁 IPsec 隧道
  • 系统管理员清理过期隧道

容量规划：

对于部署规划：

  • 每个活动隧道大约使用 1KB 的内存
  • 典型的生产部署支持 10,000-50,000 个同时隧道
  • 监控利用率趋势以预测何时需要扩展容量
  • 如果经常超过 80% 的利用率，请与系统管理员协调以增加 SPI/端口范围

安全关联（SA）设置：

  1. UE 发送带有 Security-Client 头的 REGISTER：

    Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; ealg=null;
                     spi-c=12345; spi-s=67890; port-c=5100; port-s=6100

  2. P-CSCF 响应 Security-Server：

    Security-Server: ipsec-3gpp; alg=hmac-sha-1-96; ealg=null;
                     spi-c=11111; spi-s=22222; port-c=5100; port-s=6100

  3. P-CSCF 使用 setkey 创建 IPsec 策略：

    # 从客户端到服务器
    spdadd <ue-ip>[5100] <pcscf-ip>[6100] any -P out ipsec esp/transport//require;

    # 从服务器到客户端
    spdadd <pcscf-ip>[6100] <ue-ip>[5100] any -P in ipsec esp/transport//require;

  4. 所有后续 SIP 消息使用 IPsec 隧道

支持的算法：

  • 认证：hmac-md5-96, hmac-sha-1-96
  • 加密：null, des-ede3-cbc, aes-cbc（首选：LTE 的 null）

3. 媒体处理​

重要说明：在我们的部署中，P-CSCF 默认不转发媒体。媒体（RTP/SRTP）直接从 UE 流向 OmniTAS（电话应用服务器）或其他媒体端点。P-CSCF 仅处理 SIP 信令。

媒体直接在 UE 和 OmniTAS（电话应用服务器）之间流动，完全绕过 P-CSCF 以进行 RTP/SRTP 流量：

UE <------ SIP ------> P-CSCF <------ SIP ------> S-CSCF <------ SIP ------> OmniTAS
    <----------------------- RTP/SRTP（直接到 TAS） ---------------------->

P-CSCF 仅处理 SIP 信令。所有媒体（语音、视频）直接在 UE 和 OmniTAS 之间建立。

4. QoS 和策略强制（Rx 接口）​

Diameter Rx 集成​

目的：与 PCRF 协调 QoS 以建立承载

Diameter 配置：

P-CSCF 通过 Diameter 在 3868 端口连接到 PCRF，使用 Rx 应用程序（应用程序 ID 16777236，3GPP 供应商 ID 10415）。

Rx 操作：

  1. AAR（授权认证请求）：请求媒体流的 QoS
  2. AAA（授权认证应答）：PCRF 授予/拒绝
  3. STR（会话终止请求）：在呼叫结束时释放 QoS

AAR 消息流​

发送到 PCRF 的媒体信息：

  • 流描述（IP、端口、协议）
  • 带宽要求（上行/下行）
  • 媒体类型（音频、视频）
  • 流状态（启用、禁用）

5. 防洪保护​

Pike 模块配置（速率限制）： pike 模块提供防洪保护，具有以下设置：

  • 采样时间单位：2 秒 - 测量��求速率的时间窗口
  • 每单位请求密度：每 2 秒窗口允许来自单个 IP 的 16 个请求
  • 移除延迟：300 秒（5 分钟） - 超过限制后阻止 IP 的持续时间

失败认证跟踪： P-CSCF 跟踪失败的认证尝试以防止暴力攻击：

  • 为每个源 IP 维护一个哈希表计数器，用于失败的认证尝试
  • 在认证失败时增加计数器，过期时间为 120 秒
  • 如果一个 IP 在 120 秒内超过 10 次失败尝试，则用 403 Too Many Failed Attempts 阻止该 IP
  • 防止攻击者猜测用户凭证

E-CSCF 功能​

P-CSCF 包含 E-CSCF 功能以处理紧急呼叫。

紧急呼叫检测​

识别的 SIP URI：

  • urn:service:sos（一般紧急情况）
  • urn:service:sos.police
  • urn:service:sos.ambulance
  • urn:service:sos.fire
  • urn:service:sos.marine
  • urn:service:sos.mountain

检测逻辑：通过检查请求 URI 检测紧急呼叫：

  • 检查方法是否为 INVITE（呼叫设置请求）
  • 检查请求 URI 是否匹配紧急模式：
    • URN 格式：urn:service:sos*（在 RFC 5031 中定义的 SOS URN）
    • 北美紧急情况：911
    • 欧洲/国际紧急情况：112
  • 如果检测到紧急呼叫，则路由到紧急处理块以进行特殊处理

IMEI 到 MSISDN 的映射用于紧急呼叫​

为什么需要这个��当用户拨打紧急呼叫（例如，911、112、urn:service:sos）时，UE 通常不在 SIP 消息中提供 MSISDN（电话号码）。紧急服务（PSAP - 公共安全应答点）需要知道呼叫者的电话号码以便回拨。为了解决这个问题，P-CSCF/E-CSCF 维护 IMEI（设备标识符）到 MSISDN 的映射。

工作原理：

  1. 在注册期间（当 MSISDN 已知时）：

    • 从 Contact 头的 +sip.instance 参数提取 IMEI（格式：urn:gsma:imei:123456-78-901234-5）
    • 从 From 头的用户名中提取用户的公共身份（IMPU）中的 MSISDN
    • 将 IMEI → MSISDN 映射存储在具有 24 小时 TTL（86400 秒）的哈希表中
    • 示例：imei_msisdn["urn:gsma:imei:123456789012345"] = "12015551234"
    • 在集群部署中：自动将映射复制到集群中的所有其他 P-CSCF 节点

  2. 在紧急呼叫期间（当 MSISDN 可能缺失时）：

    • 从紧急呼叫的 Contact 头 +sip.instance 参数提取 IMEI
    • 执行哈希表查找以检索与此 IMEI 关联的 MSISDN
    • 如果在映射中找到 MSISDN：
      • 添加 P-Asserted-Identity 头，包含完整的 MSISDN（sip:+12015551234@domain）
      • 这为 PSAP 提供了紧急呼叫者的回拨号码

高可用性 - 多节点同步：

在具有多个 P-CSCF 节点以实现冗余的生产部署��，IMEI→MSISDN 映射会在所有节点之间自动同步：

集群复制行为：

当 UE 在 P-CSCF 节点 1 上注册时：

  1. 节点 1 在本地创建 IMEI→MSISDN 映射
  2. 节点 1 立即将映射广播到集群中的所有其他 P-CSCF 节点
  3. P-CSCF 节点 2、节点 3 等接收更新并创建相同的本地副本
  4. 所有节点现在都有相同的 IMEI→MSISDN 映射

为什么这很重要：

如果 UE 通过 P-CSCF 节点 1 注册，但拨打的紧急呼叫被路由到 P-CSCF 节点 2（由于负载均衡或故障转移），节点 2 已经拥有 IMEI→MSISDN 映射，并且可以向 PSAP 提供回拨号码。

同步机制：

同步通过 P-CSCF 节点之间的基于 SIP 的消息传递进行：

  • 使用自定义 SIP 消息传播哈希表更新
  • 消息以 JSON 格式发送，包含 IMEI、MSISDN 和 TTL
  • 传输是自动和透明的 - 无需操作员干预
  • 更新在几毫秒内广播到所有集群成员

操作影响：

  • 弹性：无论哪个 P-CSCF 节点处理呼叫，紧急呼叫都能正常工作
  • 无单点故障：任何 P-CSCF 节点都可以为任何注册的 UE 提供回拨号码
  • 自动化：同步是内置的，无需手动配置或干预
  • 监控：通过 Web UI，导航到 P-CSCF → 哈希表 → imei_msisdn 查看每个节点的映���

集群配置要求：

为了使哈希表同步正常工作：

  • 所有 P-CSCF 节点必须配置彼此的地址
  • 节点通过可用性通知自动发现彼此
  • 网络连接必须允许所有 P-CSCF 节点之间的 SIP 流量
  • 如果同步失败，请检查防火墙规则以允许节点间通信

示例场景：

1. 用户注册：IMEI=123456789012345，MSISDN=12015551234
   → 存储：imei_msisdn[123456789012345] = 12015551234

2. 用户拨打 911：INVITE urn:service:sos（MSISDN 不在 From 头中）
   → P-CSCF 从 Contact 中提取 IMEI：123456789012345
   → P-CSCF 查找：imei_msisdn[123456789012345] → 12015551234
   → P-CSCF 添加头：P-Asserted-Identity: <sip:+12015551234@...>
   → PSAP 接收到带有回拨号码的呼叫：+12015551234

紧急路由​

紧急呼叫特性：

  • 跳过注册检查
  • 添加 PIDF-LO（位置对象的存在信息数据格式）
  • 路由到紧急应用服务器或 PSAP
  • 优先处理（抢占正常呼叫）
  • 来自 LRF 或 UE 的位置信息

Web UI 操作​

访问 P-CSCF 页面​

导航到：https://<control-panel>/pcscf

页面布局​

P-CSCF 页面有三个主要选项卡：

  1. 注册联系人 - 活动注册
  2. 用户位置 - 按 IMSI/IP 搜索
  3. 哈希表 - 共享内存表

查看注册联系人​

显示列：

  • AoR（记录地址）：用户的 SIP 身份
  • Contact：设备联系 URI
  • Expires：注册过期时间戳
  • Public IP：UE 的公共 IP 地址
  • Received：实际接收的 IP（如果与 Contact 不同）
  • Path：用于路由的路径头
  • Rx 会话 ID：Diameter Rx 会话（如果 QoS 活动）

特性：

  • 每 5 秒自动刷新
  • 按部分 AoR 或 Contact 搜索
  • 按列排序（单击标题）
  • 可展开行以获取完整详细信息

示例输出：

AoR: sip:12015551234@ims.mnc001.mcc001.3gppnetwork.org
Contact: sip:12015551234@10.4.12.100:5060;transport=udp
Expires: 2025-11-29 14:30:15
Public IP: 10.4.12.100
Received: 10.4.12.100:52341
Path: <sip:term@pcscf.ims.mnc001.mcc001.3gppnetwork.org:5060;lr>
Rx Session: rx-pcscf-session-12345

搜索用户位置​

搜索选项：

  • 按 IMSI： imsi:310150123456789
  • 按 IP： 10.4.12.100

用例：

  1. 查找哪个用户正在使用特定 IP
  2. 检查 IMSI 是否已注册
  3. 验证 IPsec 隧道状态
  4. 检查服务路由

哈希表管理​

常见表：

表目的典型大小
imei_msisdn紧急 IMEI→MSISDN 映射100-1000 条目
service_routes缓存服务路由每次注册
dialog_out出站对话跟踪每通话

操作：

  • 列出表：单击“哈希表”选项卡
  • 转储表：单击表名以查看内容
  • 删除条目：单击条目旁边的“删除”
  • 清空表：单击“清空”以清除整个表（请谨慎使用！）

示例条目：

Key:   urn:gsma:imei:123456-78-901234-5
Value: 310150123456789
TTL:   86400 秒（24 小时）

呼叫流程​

移动发起呼叫（MO）​

所有发起的呼叫都通过 TAS（OmniTAS）进行服务逻辑和计费：

移动终止呼叫（MT）​

终止呼叫也通过 TAS 进行服务逻辑：

紧急呼叫流程​

故障排除​

注册问题​

UE 无法注册​

症状：UE 收到 408 超时或没有响应

诊断步骤：

  1. 通过控制面板检查注册状态：

    • 导航到 P-CSCF 页面
    • 检查“注册联系人”选项卡
    • 验证用户是否出现在列表中

  2. 通过控制面板的日志页面查看系统日志以查找错误

  3. 验证 UE 和 P-CSCF 之间的网络连接

  4. 检查防火墙规则是否允许 SIP 流量（端口 5060 UDP/TCP）

  5. 如果 P-CSCF 服务似乎已停止，请与系统管理员协调

IPsec 隧道未建立​

症状：发送 401 挑战但重新注册失败

诊断步骤：

  1. 通过控制面板的日志页面查看与 IPsec 相关的错误

  2. 验证 UE 是否在初始 REGISTER 中发送 Security-Client 头

  3. 检查 UE 在重新注册中是否使用 IPsec 端口（5100 客户端，6100 服务器）

  4. 验证接收地址是否与预期的 IPsec 隧道端点匹配

  5. 与系统管理员协调以验证 IPsec 内核模块是否已加载且不存在端口冲突

呼叫问题​

呼叫未路由到 UE​

症状：INVITE 发送到 P-CSCF 但 UE 不响铃

诊断步骤：

  1. 通过控制面板验证注册是否存在：

    • 导航到 P-CSCF 页面
    • 检查“注册联系人”选项卡
    • 搜索用户并验证注册是否处于活动状态

  2. 验证路径头是否存储在注册中

  3. 检查呼叫是否发送到正确的联系地址

  4. 查看系统日志以查找路由错误

  5. 验证 P-CSCF 到 UE 的网络路径是否可达

单向音频​

症状：一方听不到另一方

注意：在我们的部署中，P-CSCF 不转发媒体。媒体直接在 UE 和 OmniTAS 之间流动。如果您遇到单向音频，问题可能出在端点或网络路由上，而不是 P-CSCF。

诊断步骤：

  1. 验证 INVITE/200 OK 中的 SDP 是否包含正确的 IP 地址和端口（如果可用，查看系统日志或数据包捕获）

  2. 验证防火墙规则是否允许 UE 和 OmniTAS 之间的 RTP/SRTP 流量

  3. 检查 UE 是否在 NAT 后面

  4. 验证 OmniTAS 媒体端点是否可以从 UE 访问（网络连接）

  5. 如果需要，请与系统管理员协调进行数据包捕获分析

紧急呼叫失败​

症状：urn:service:sos 呼叫被拒绝

诊断步骤：

  1. 通过控制面板验证 IMEI→MSISDN 哈希表：

    • 导航到 P-CSCF → 哈希表选项卡
    • 检查 imei_msisdn 表是否包含条目
    • 验证呼叫者的 IMEI 是否有映射

  2. 首先测试注册用户拨打紧急呼叫（以隔离注册与紧急路由问题）

  3. 通过控制面板的日志页面查看系统日志以查找紧急路由错误

  4. 验证紧急应用服务器配置

  5. 如果需要，请与系统管理员协调以查看紧急路由配置

性能问题​

高 CPU 使用率​

可能原因：

  • 注册过多
  • Pike 防洪触发
  • 数据库查询缓慢

解决方案：

  1. 通过控制面板检查注册计数：

    • 导航到 P-CSCF → 注册联系人选项卡
    • 查看活动注册的总数

  2. 查看系统日志以查找 Pike 防洪阻止

  3. 如果需要，请与系统管理员协调以进行水平扩展（添加更多 P-CSCF 实例）

高内存使用率​

可能原因：

  • 哈希表增长
  • 对话表未被清除
  • 内存泄漏

解决方案：

  1. 通过控制面板查看哈希表：

    • 导航到 P-CSCF → 哈希表选项卡
    • 检查表大小和条目计数

  2. 通过控制面板清除旧条目：

    • 选择有问题的哈希表
    • 如有必要，使用“清空”操作（请谨慎使用 - 清除整个表）

  3. 如果怀疑内存泄漏，请与系统管理员协调以重启 P-CSCF 服务

Diameter/Rx 问题​

PCRF 对等体关闭​

症状：Web UI 中 Diameter 对等体显示“关闭”状态

诊断步骤：

  1. 通过控制面板检查 Diameter 对等体状态：

    • 导航到 Diameter 页面
    • 选择 P-CSCF 节点
    • 验证 PCRF 对等体状态（连接时应为“ I_Open”）

  2. 验证与 PCRF 的网络连接（如有需要，请与网络团队协调）

  3. 尝试通过控制面板启用对等体：

    • 导航到 Diameter 页面
    • 找到 PCRF 对等体
    • 单击“启用”按钮

  4. 通过控制面板的日志页面查看系统日志以查找 Diameter 连接错误

  5. 如有需要，请与系统管理员协调以验证 Diameter 配置

QoS 无法正常工作​

症状��呼叫连接但未建立 QoS 承载

诊断步骤：

  1. 通过控制面板查看系统日志以查找 AAR（授权认证请求）和 AAA（授权认证应答）消息

  2. 检查 PCRF 响应结果代码（成功时应为 2001）

  3. 验证 PCRF 对等体是否已连接（见前一节）

  4. 验证媒体信息是否在 SDP 中正确发送到 PCRF

  5. 如有需要，请与系统管理员协调以验证 QoS 配置

最佳实践​

安全​

  1. 始终使用 IPsec 保护移动设备（LTE/5G）
  2. 为固定/企业客户端启用 TLS
  3. 配置防洪（Pike）以防止 DoS 攻击
  4. 限制失败的认证 尝试以防止暴力攻击
  5. 使用强加密算法 进行 TLS（禁用 SSLv2/v3）
  6. 定期轮换 IPsec 密钥（通过重新注册）

性能​

  1. 根据预期注册数量调整 hash_size：

    • 1,000 用户：hash_size=10（创建 2^10 = 1,024 个哈希桶）
    • 10,000 用户：hash_size=13（创建 2^13 = 8,192 个哈希桶）
    • 100,000 用户：hash_size=16（创建 2^16 = 65,536 个哈希桶）

  2. 根据 CPU 核心调整工作进程：

    • 设置子进程以匹配 CPU 核心数量以进行 SIP 处理
    • 设置 tcp_children 为 2× CPU 核心以处理 TCP 连接

  3. 使用 mlock_pages 防止交换：

    • 启用 mlock_pages=yes 将共享内存页面锁定在 RAM 中
    • 防止因内存交换到磁盘而导致的性能下降

  4. 在 IMS 环境中禁用 DNS 缓存：

    • 设置 dns_cache_init=off 以使用新鲜的 DNS 查找
    • 对于基于动态 DNS SRV 的负载均衡是必要的

  5. 启用 SRV 负载均衡：

    • 设置 dns_srv_lb=yes 以在多个服务器之间分配流量
    • 使用 DNS SRV 记录进行自动负载分配

监控​

  1. 启用 Prometheus 指标（配置中的端口 9090） - 请参见 指标参考 以获取所有可用的 P-CSCF 指标
  2. 监控注册计数 趋势
  3. 跟踪 Diameter 对等体健康（Rx 到 PCRF）
  4. 在日志中警报高错误率
  5. 监控对话计数（活动会话）
  6. 定期检查内存使用情况

高可用性​

  1. 部署多个 P-CSCF 实例

  2. 使用 DNS SRV 进行负载均衡：

    _sip._udp.pcscf.example.com. SRV 10 50 5060 pcscf01.example.com.
    _sip._udp.pcscf.example.com. SRV 10 50 5060 pcscf02.example.com.

  3. 尽可能避免状态（无状态代理）

  4. 使用共享数据库 存储持久数据（如有需要）

  5. 通过 Web 界面监控 使用控制面板健康检查

紧急服务​

  1. 始终允许 紧急呼叫，即使未注册
  2. 在注册期间存储 IMEI→MSISDN 映射
  3. 为紧急哈希表设置 TTL（86400 = 24 小时）
  4. 定期与测试 PSAP 进行测试
  5. 确保 LRF 连接以获取位置
  6. 对紧急呼叫进行优先处理

参考​

其他技术资源​

对于系统管理员和开发人员，底层软件组件的技术模块文档可在线获取。

3GPP 规范​

  • TS 23.228：IMS 架构
  • TS 24.229：IMS SIP 配置文件
  • TS 33.203：接入安全
  • TS 23.167：紧急服务
  • TS 29.214：Rx 接口（PCRF）

RFCs​

  • RFC 3261：SIP
  • RFC 3327：路径头
  • RFC 3608：服务路由头
  • RFC 3GPP-IMS：P-头（P-Asserted-Identity 等）
  • RFC 5626：出站（连接管理）