全球标题 NAT 指南
概述
全球标题网络地址转换(GT NAT)是一项功能,允许 OmniSS7 根据呼叫方的 GT 前缀、被叫方的 GT 前缀或两者的组合响应不同的全球标题地址。当需要确保响应使用正确的 GT 时,这一点至关重要,尤其是在与多个全球标题操作时,确保根据哪个网络或对等方在呼叫和/或他们呼叫的 GT 来使用正确的 GT。
新功能(增强的 GT NAT)
GT NAT 功能已增强,具备强大的新能力:
新特性
- 被叫方前缀匹配:规则现在可以匹配
called_prefix,除了calling_prefix之外 - 组合匹配:规则可以同时匹配呼叫和被叫前缀
- 基于权重的优先级:规则现在使用
weight字段(较低 = 较高优先级),而不仅仅是前缀长度 - 灵活匹配:现在可以创建具有以下特性的规则:
- 仅呼叫前缀
- 仅被叫前缀
- 同时具有呼叫和被叫前缀
- 两者都没有(通配符/回退规则)
新规则格式
必需字段:
weight:整数优先级(较低 = 较高优先级)response_gt:要响应的 GT
可选字段(建议至少指定一个以进行特定匹配):
calling_prefix:匹配呼叫方 GT 前缀called_prefix:匹配被叫方 GT 前缀
示例:
gt_nat_rules: [
# 同时具有两个前缀的特定规则 - 最高优先级
%{calling_prefix: "8772", called_prefix: "555", weight: 1, response_gt: "111111"},
# 特定规则 - 中等优先级
%{calling_prefix: "8772", weight: 10, response_gt: "222222"},
%{called_prefix: "555", weight: 10, response_gt: "333333"},
# 通配符回退 - 最低优先级
%{weight: 100, response_gt: "999999"}
]
用例
多网络操作
当您有多个对等网络,每个网络都期望从特定 GT 接收响应时:
- 网络 A 呼叫您的 GT
111111并期望从111111接收响应 - 网络 B 呼叫您的 GT
222222并期望从222222接收响应
没有 GT NAT,您需要单独的实例或复杂的路由。使用 GT NAT,单个 OmniSS7 实例可以智能地处理此情况。
漫游场景
当作为 HLR 或 SMSc 运营时,具有漫游协议:
- 本地网络 用户使用 GT
555000 - 漫游合作伙伴 1 使用 GT
555001 - 漫游合作伙伴 2 使用 GT
555002
GT NAT 确保每个合作伙伴从他们配置的正确 GT 接收响应。
测试和迁移
在网络迁移或测试期间:
- 逐步将流量从旧 GT 迁移到新 GT
- 在过渡期间维护两个 GT
- 根据呼叫者使用的 GT 路由响应
工作原理
地址转换流程
-
传入请求:OmniSS7 接收到带有以下内容的 SCCP 消息:
- 被叫方 GT:
55512341112(您的 GT) - 呼叫方 GT:
877234567(他们的 GT)
- 被叫方 GT:
-
GT NAT 查找:系统检查呼叫 GT
877234567是否与配置的前缀规则匹配 -
前缀匹配:找到最长的匹配前缀(例如,
8772匹配877234567) -
响应 GT 选择:使用匹配规则中的
response_gt(例如,55512341112) -
发送响应:SCCP 响应使用:
- 被叫方 GT:
877234567(反转 - 他们的 GT) - 呼叫方 GT:
55512341112(NAT'd GT)
- 被叫方 GT:
受影响的响应类型
GT NAT 适用于 SS7 栈的多个层次:
SCCP 层(所有响应)
- 所有响应消息中的 SCCP 被叫/呼叫 GT 地址
- ISD(InsertSubscriberData)确认
- UpdateLocation 响应
- 错误响应
MAP 层(操作特定)
- SRI-for-SM 响应:
networkNode-Number(SMSc GT 地址) - UpdateLocation:响应中的
hlr-Number - InsertSubscriberData:ISD 消息中的 HLR GT
配置
基本配置
添加到 config/runtime.exs:
config :omniss7,
# 启用 GT NAT
gt_nat_enabled: true,
# 定义 GT NAT 规则
gt_nat_rules: [
# 规则 1:来自前缀 "8772" 的呼叫从 "55512341112" 获取响应
%{calling_prefix: "8772", response_gt: "55512341112"},
# 规则 2:来自前缀 "8773" 的呼叫从 "55512341111" 获取响应
%{calling_prefix: "8773", response_gt: "55512341111"},
# 默认规则(空前缀匹配所有内容)
%{calling_prefix: "", response_gt: "55512311555"}
]
配置参数
有关完整的配置参考,请参见 配置参考中的全球标题 NAT 参数。
| 参数 | 类型 | 必需 | 描述 |
|---|---|---|---|
gt_nat_enabled | 布尔 | 是 | 启用/禁用 GT NAT 功能 |
gt_nat_rules | 映射列表 | 是(如果启用) | 前缀匹配规则列表 |
规则格式
每个规则都是一个具有以下键的映射:
%{
calling_prefix: "8772", # (可选)要与呼叫 GT 匹配的前缀
called_prefix: "555", # (可选)要与被叫 GT 匹配的前缀
weight: 10, # (必需)优先级值(较低 = 较高优先级)
response_gt: "55512341112" # (必需)在响应中使用的 GT
}
规则字段:
-
calling_prefix(可选):要与传入呼叫 GT 匹配的字符串前缀- 匹配通过
String.starts_with?/2完成 - 空字符串
""或nil作为通配符(匹配任何呼叫 GT) - 可以省略以匹配任何呼叫 GT
- 匹配通过
-
called_prefix(可选):要与传入被叫 GT 匹配的字符串前缀- 匹配通过
String.starts_with?/2完成 - 空字符串
""或nil作为通配符(匹配任何被叫 GT) - 可以省略以匹配任何被叫 GT
- 匹配通过
-
weight(必需):整数优先级值- 较低的权重 = 较高的优先级(优先处理)
- 必须大于或等于 0
- 用作匹配规则的主要排序标准
-
response_gt(必需):在响应中使用的全球标题地址- 必须是有效的 E.164 数字字符串
- 应与您的配置 GT 之一匹配
至少应指定 calling_prefix 或 called_prefix 中的一个以进行特定路由。两者都可以省略以用于通配符/回退规则。
规则匹配逻辑
规则首先按 权重(升序) 进行评估,然后按 组合前缀特异性:
匹配算法:
- 筛选所有指定前缀匹配的规则
- 如果设置了
calling_prefix,则必须匹配呼叫 GT - 如果设置了
called_prefix,则必须匹配被叫 GT - 如果两者都设置,则两者都必须匹配
- 如果两者都未设置,则规则作为通配符
- 如果设置了
- 按以下方式对匹配规则进行排序:
- 主要:权重(升序 - 较低的值优先)
- 次要:组合前缀长度(降序 - 较长 = 更特定)
- 返回第一个匹配的规则
示例:
# 示例规则
gt_nat_rules: [
# 权重 1:最高优先级 - 匹配两个前缀
%{calling_prefix: "8772", called_prefix: "555", weight: 1, response_gt: "111111"},
# 权重 10:中等优先级 - 特定规则
%{calling_prefix: "8772", weight: 10, response_gt: "222222"}, # 仅呼叫
%{called_prefix: "555", weight: 10, response_gt: "333333"}, # 仅被叫
# 权重 100:最低优先级 - 通配符回退
%{weight: 100, response_gt: "444444"} # 匹配所有
]
# 匹配示例:
# 呼叫:"877234567",被叫:"555123" -> "111111"(权重 1,两个匹配)
# 呼叫:"877234567",被叫:"999999" -> "222222"(权重 10,仅呼叫)
# 呼叫:"999999999",被叫:"555123" -> "333333"(权重 10,仅被叫)
# 呼叫:"999999999",被叫:"888888" -> "444444"(权重 100,通配符)
示例
示例 1:两个网络合作伙伴
场景:您运营一个 SMSc,拥有两个网络合作伙伴。每个合作伙伴期望从不同的 GT 接收响应。
config :omniss7,
gt_nat_enabled: true,
# 默认 SMSc GT(在禁用 GT NAT 或没有规则匹配时使用)
smsc_service_center_gt_address: "5551000",
# 合作伙伴的 GT NAT 规则
gt_nat_rules: [
# 合作伙伴 A(前缀 4412)期望从 GT 5551001 获取响应
%{calling_prefix: "4412", weight: 10, response_gt: "5551001"},
# 合作伙伴 B(前缀 4413)期望从 GT 5551002 获取响应
%{calling_prefix: "4413", weight: 10, response_gt: "5551002"},
# 默认:使用标准 SMSc GT(通配符回退)
%{weight: 100, response_gt: "5551000"}
]
流量流程:
来自 44121234567 的传入 SRI-for-SM:
被叫 GT:5551001(您使用的 GT,合作伙伴 A 使用)
呼叫 GT:44121234567(合作伙伴 A 的 GT)
GT NAT 查找:
"44121234567" 匹配前缀 "4412"
选择的 response_gt: "5551001"
响应 SRI-for-SM 到 44121234567:
被叫 GT:44121234567(反转)
呼叫 GT:5551001(NAT'd)
networkNode-Number:5551001(在 MAP 响应中)
示例 2:具有区域 GT 的 HLR
场景:国家 HLR,每个区域有不同的 GT。
config :omniss7,
gt_nat_enabled: true,
hlr_service_center_gt_address: "555000", # 默认 HLR GT
gt_nat_rules: [
# 北方区域 VLR(前缀 5551)
%{calling_prefix: "5551", weight: 10, response_gt: "555100"},
# 南方区域 VLR(前缀 5552)
%{calling_prefix: "5552", weight: 10, response_gt: "555200"},
# 西方区域 VLR(前缀 5553)
%{calling_prefix: "5553", weight: 10, response_gt: "555300"},
# 其他区域的默认(通配符)
%{weight: 100, response_gt: "555000"}
]
示例 3:迁移场景
场景:逐步从旧 GT 迁移到新 GT。
config :omniss7,
gt_nat_enabled: true,
hlr_service_center_gt_address: "123456789", # 旧 GT(默认)
gt_nat_rules: [
# 已迁移的网络(已更新其配置)
%{calling_prefix: "555", weight: 10, response_gt: "987654321"}, # 新 GT
%{calling_prefix: "666", weight: 10, response_gt: "987654321"}, # 新 GT
# 其他人仍然使用旧 GT(通配符)
%{weight: 100, response_gt: "123456789"} # 旧 GT
]
示例 4:被叫方前缀匹配(新)
场景:您有多个 GT 用于不同服务,并希望根据呼叫的 GT 响应正确的 GT。
config :omniss7,
gt_nat_enabled: true,
gt_nat_rules: [
# 当他们呼叫您的 SMS GT(5551xxx)时,响应该 GT
%{called_prefix: "5551", weight: 10, response_gt: "555100"},
# 当他们呼叫您的语音 GT(5552xxx)时,响应该 GT
%{called_prefix: "5552", weight: 10, response_gt: "555200"},
# 当他们呼叫您的数据 GT(5553xxx)时,响应该 GT
%{called_prefix: "5553", weight: 10, response_gt: "555300"},
# 默认回退
%{weight: 100, response_gt: "555000"}
]
流量流程:
传入请求到被叫 GT:555100(您的 SMS GT)
呼叫 GT:441234567(任何呼叫者)
GT NAT 查找:
被叫 GT "555100" 匹配前缀 "5551"
选择的 response_gt: "555100"
响应使用呼叫 GT:555100(匹配他们所呼叫的)
示例 5:组合呼叫 + 被叫前缀匹配(高级)
场景:不同的合作伙伴呼叫不同的 GT,您希望进行精细控制。
config :omniss7,
gt_nat_enabled: true,
gt_nat_rules: [
# 合作伙伴 A 呼叫您的 SMS GT - 最高优先级(权重 1)
%{calling_prefix: "4412", called_prefix: "5551", weight: 1, response_gt: "555101"},
# 合作伙伴 B 呼叫您的 SMS GT - 最高优先级(权重 1)
%{calling_prefix: "4413", called_prefix: "5551", weight: 1, response_gt: "555102"},
# 任何人呼叫您的 SMS GT - ���等优先级(权重 10)
%{called_prefix: "5551", weight: 10, response_gt: "555100"},
# 合作伙伴 A 呼叫任何 GT - 中等优先级(权重 10)
%{calling_prefix: "4412", weight: 10, response_gt: "555200"},
# 默认回退 - 低优先级(权重 100)
%{weight: 100, response_gt: "555000"}
]
匹配示例:
# 合作伙伴 A 呼叫 SMS GT
呼叫:"441234567",被叫:"555100"
→ 匹配权重 1 规则(两个前缀)→ "555101"
# 合作伙伴 A 呼叫语音 GT
呼叫:"441234567",被叫:"555200"
→ 匹配权重 10 规则(仅呼叫)→ "555200"
# 未知呼叫者呼叫 SMS GT
呼叫:"999999999",被叫:"555100"
→ 匹配权重 10 规则(仅被叫)→ "555100"
# 未知呼叫者呼叫语音 GT
呼叫:"999999999",被叫:"555200"
→ 匹配权重 100 通配符 → "555000"
操作模式
GT NAT 在所有 OmniSS7 操作模式下工作:
HLR 模式
GT NAT 影响:
- UpdateLocation 响应(响应中的 HLR GT)
- InsertSubscriberData 消息(作为呼叫方的 HLR GT)
- SendAuthenticationInfo 响应
- 取消位置响应
有关 HLR 操作的更多信息,请参见 HLR 配置指南。
配置:
config :omniss7,
hlr_mode_enabled: true,
hlr_service_center_gt_address: "5551234567", # 默认 HLR GT
gt_nat_enabled: true,
gt_nat_rules: [
%{calling_prefix: "331", weight: 10, response_gt: "5551234568"}, # 法国
%{calling_prefix: "44", weight: 10, response_gt: "5551234569"}, # 英国
%{weight: 100, response_gt: "5551234567"} # 默认通配符
]
SMSc 模式
GT NAT 影响:
- SRI-for-SM 响应(
networkNode-Number字段) - 参见 SRI-for-SM 详细信息 - MT-ForwardSM 确认
有关 SMSc 操作的更多信息,请参见 SMSc 配置指南。
配置:
config :omniss7,
smsc_mode_enabled: true,
smsc_service_center_gt_address: "5559999", # 默认 SMSc GT
gt_nat_enabled: true,
gt_nat_rules: [
%{calling_prefix: "1", weight: 10, response_gt: "5559991"}, # 北美
%{calling_prefix: "44", weight: 10, response_gt: "5559992"}, # 英国
%{calling_prefix: "86", weight: 10, response_gt: "5559993"}, # 中国
%{weight: 100, response_gt: "5559999"} # 默认通配符
]
CAMEL 网关模式
GT NAT 影响:
- 所有 SCCP 层响应(gsmSCF GT 作为呼叫方)
- CAMEL/CAP 操作响应(InitialDP、EventReportBCSM 等)
- RequestReportBCSMEvent 确认
- ApplyCharging ���应
- Continue 响应
配置:
config :omniss7,
camelgw_mode_enabled: true,
camel_gsmscf_gt_address: "55512341112", # 默认 gsmSCF GT
gt_nat_enabled: true,
gt_nat_rules: [
%{calling_prefix: "555", weight: 10, response_gt: "55512341111"}, # 网络 A
%{calling_prefix: "666", weight: 10, response_gt: "55512311555"}, # 网络 B
%{weight: 100, response_gt: "55512341112"} # 默认通配符
]
用例: 当作为多个网络的 gsmSCF(服务控制功能)操作时,每个网络的 gsmSSF 可能期望从特定的 gsmSCF GT 接收响应。GT NAT 确保根据哪个 gsmSSF 在呼叫使用正确的 GT。
日志记录和调试
启用 GT NAT 日志记录
GT NAT 包括对所有转换的自动日志记录:
# 在日志中,您将看到:
[info] GT NAT [SRI-for-SM 响应]: 呼叫 GT 877234567 -> 响应 GT 55512341112
[info] GT NAT [UpdateLocation ISD]: 呼叫 GT 331234567 -> 响应 GT 55512341111
[info] GT NAT [MAP BEGIN 响应]: 呼叫 GT 441234567 -> 响应 GT 55512311555
上下文字段显示了 NAT 应用的位置:
"SRI-for-SM 响应"- 在 SRI-for-SM 处理程序中"UpdateLocation ISD"- 在 InsertSubscriberData 消息中"UpdateLocation END"- 在 UpdateLocation END 响应中"MAP BEGIN 响应"- ��用 MAP BEGIN 响应"ISD ACK"- ISD 确认"HLR 错误响应"- HLR 的错误响应"CAMEL 响应"- CAMEL/CAP 操作响应(gsmSCF)
验证
系统在启动时验证 GT NAT 配置:
# 检查 GT NAT 配置
iex> GtNat.validate_config()
{:ok, [
%{calling_prefix: "8772", weight: 10, response_gt: "55512341112"},
%{calling_prefix: "8773", weight: 10, response_gt: "55512341111"}
]}
# 检查是否启用
iex> GtNat.enabled?()
true
# 获取所有规则
iex> GtNat.get_rules()
[
%{calling_prefix: "8772", weight: 10, response_gt: "55512341112"},
%{calling_prefix: "8773", weight: 10, response_gt: "55512341111"}
]
测试 GT NAT
以编程方式测试 GT NAT 逻辑:
# 仅使用呼叫 GT 测试转换(called_gt 为 nil)
iex> GtNat.translate_response_gt("877234567", nil, "default_gt")
"55512341112"
# 使用呼叫和被叫 GT 测试转换
iex> GtNat.translate_response_gt("877234567", "555123", "default_gt")
"55512341112"
# 测试日志记录(nil 被叫 GT)
iex> GtNat.translate_response_gt_with_logging("877234567", nil, "default_gt", "test")
# 日志:GT NAT [test]: 呼叫 GT 877234567 -> 响应 GT 55512341112
"55512341112"
# 测试日志记录(两个 GT)
iex> GtNat.translate_response_gt_with_logging("877234567", "555123", "default_gt", "test")
# 日志:GT NAT [test]: 呼叫 GT 877234567, 被叫 GT 555123 -> 响应 GT 55512341112
"55512341112"
# 测试无匹配(返回默认)
iex> GtNat.translate_response_gt("999999999", "888888", "default_gt")
"default_gt"
故障排除
问题:GT NAT 无法工作
检查 1:是否启用?
iex> Application.get_env(:omniss7, :gt_nat_enabled)
true # 应为 true
检查 2:规则是否配置?
iex> Application.get_env(:omniss7, :gt_nat_rules)
[%{calling_prefix: "8772", response_gt: "55512341112"}, ...] # 应返回列表
检查 3:检查日志 搜索日志中的 "GT NAT" 以查看是否发生了转换。
问题:响应中的 GT 错误
症状:响应使用意外的 GT 地址
原因:规则前缀匹配可能过于宽泛或默认规则捕获了流量
解决方案:检查规则权重和前缀:
# 不好:低权重的通配符(捕获所有内容)
gt_nat_rules: [
%{weight: 1, response_gt: "111111"}, # 这会首先匹配所有内容!
%{calling_prefix: "8772", weight: 10, response_gt: "222222"} # 从未到达
]
# 好:具有较低权重的特定规则,较高权重的通配符
gt_nat_rules: [
%{calling_prefix: "8772", weight: 10, response_gt: "222222"}, # 特定,低权重
%{weight: 100, response_gt: "111111"} # 通配符,高权重(回退)
]
问题:GT NAT 未应用于特定消息类型
症状:某些响应使用 NAT'd GT,其他则不使用
当前覆盖范围:
- ✅ SCCP 呼叫 GT(所有响应)
- ✅ SRI-for-SM 响应(networkNode-Number)
- ✅ UpdateLocation ISD 消息(HLR GT)
- ✅ UpdateLocation END 响应
- ✅ ISD 确认
- ✅ MAP BEGIN 响应
如果特定消息类型未使用 GT NAT,可能尚未实现。检查源代码或联系支持。
性能考虑
查找性能
GT NAT 使用简单的前缀匹配,复杂度为 O(n),其中 n 是规则的数量。
性能提示:
- 将规则数量保持在 100 以下以获得最佳性能
- 使用特定前缀以减少规则数量
- 默认规则(空前缀)应放在最后
基准(典型系统):
- 10 条规则:每次查找 < 1µs
- 50 条规则:每次查找 < 5µs
- 100 条规则:每次查找 < 10µs
内存使用
每条规则大约需要 100 字节的内存:
- 10 条规则 ≈ 1 KB
- 100 条规则 ≈ 10 KB
最佳实践
1. 始终包含通配符回退规则
gt_nat_rules: [
%{calling_prefix: "8772", weight: 10, response_gt: "111111"},
%{calling_prefix: "8773", weight: 10, response_gt: "222222"},
%{weight: 100, response_gt: "default_gt"} # 始终有一个高权重的通配符
]
2. 使用有意义的前缀和权重
# 好:清晰、特定的前缀和适当的权重
%{calling_prefix: "331", weight: 10, response_gt: "..."} # 法国
%{calling_prefix: "44", weight: 10, response_gt: "..."} # 英国
# 不好:过于宽泛的前缀或混淆的权重
%{calling_prefix: "3", weight: 5, response_gt: "..."} # 太多国家
%{calling_prefix: "331", weight: 100, response_gt: "..."} # 权重应为较低以适用于特定规则
3. 记录您的规则
gt_nat_rules: [
# 合作伙伴 XYZ - 英国网络(GT 范围:4412xxxxxxx)
# 权重 10:标准合作伙伴优先级
%{calling_prefix: "4412", weight: 10, response_gt: "5551001"},
# 合作伙伴 ABC - 法国网络(GT 范围:33123xxxxxx)
# 权重 10:标准合作伙伴优先级
%{calling_prefix: "33123", weight: 10, response_gt: "5551002"}
]
4. 部署前测试
# 在部署前在 iex 中测试
iex> GtNat.translate_response_gt("44121234567", nil, "default")
"5551001" # 预期结果
# 使用被叫 GT 测试
iex> GtNat.translate_response_gt("44121234567", "555123", "default")
"5551001" # 预期结果
5. 监控日志
启用 INFO 级别日志记录,以查看生产环境中的所有 GT NAT 转换。
与其他功能的集成
STP 模式
GT NAT 独立于 STP 路由工作。STP 根据点代码和目标 GT 进行路由,而 GT NAT 处理响应地址。
有关 STP 路由的更多信息,请参见 STP 配置指南。
CAMEL 集成
GT NAT 与 CAMEL/CAP 操作 完全集成:
SCCP 层:
- 所有 CAMEL 响应中的呼叫方 GT
- 根据传入的 gsmSSF GT 自动应用
配置:
camel_gsmscf_gt_address- 默认 gsmSCF GT(可选)- 如果未配置,则使用来自传入请求的被叫方 GT
- GT NAT 规则根据呼叫方前缀覆盖默认值
示例:
# 当 gsmSSF 555123456 呼叫您的 gsmSCF
# 传入:被叫=55512341112,呼叫=555123456
# GT NAT 查找:"555" -> response_gt="55512341111"
# 响应:被叫=555123456,呼叫=55512341111
负载均衡
GT NAT 可以与 M3UA 负载均衡结合使用,以实现高级流量管理。
迁移指南
在现有系统上启用 GT NAT
-
准备配置
# 添加到 runtime.exs(最初保持禁用)
config :omniss7,
gt_nat_enabled: false, # 初始禁用
gt_nat_rules: [
# 您的规则在这里,带有权重
%{calling_prefix: "877", weight: 10, response_gt: "111111"},
%{weight: 100, response_gt: "999999"} # 通配符回退
] -
测试配置
# 验证配置是否编译
mix compile
# 在 iex 中测试
iex -S mix
iex> GtNat.validate_config() -
在暂存环境中启用
gt_nat_enabled: true # 更改为 true -
监控日志
tail -f log/omniss7.log | grep "GT NAT" -
部署到生产
- 在维护窗口期间进行部署
- 密切监控前 24 小时
- 准备回滚计划(设置
gt_nat_enabled: false)
支持
如有问题或疑问:
- 检查日志中的 "GT NAT" 消息
- 使用
GtNat.validate_config()验证配置 - 查看本指南的故障排除部分
- 联系 OmniSS7 支持,提供日志摘录