Pular para o conteúdo principal

Guia de NAT de Título Global

Visão Geral

A Tradução de Endereço de Título Global (GT NAT) é um recurso que permite ao OmniSS7 responder com diferentes endereços de Título Global com base no prefixo GT da parte chamadora, no prefixo GT da parte chamada ou em uma combinação de ambos. Isso é essencial ao operar com múltiplos Títulos Globais e precisar garantir que as respostas utilizem o GT correto com base em qual rede ou par está chamando e/ou qual GT eles chamaram.

Novidades (GT NAT Aprimorado)

O recurso GT NAT foi aprimorado com novas capacidades poderosas:

Novos Recursos

  1. Correspondência de Prefixo da Parte Chamado: As regras agora podem corresponder ao called_prefix além do calling_prefix
  2. Correspondência Combinada: As regras podem corresponder a prefixos de chamada E de chamada simultaneamente
  3. Priorização Baseada em Peso: As regras agora usam um campo weight (menor = maior prioridade) em vez de apenas o comprimento do prefixo
  4. Correspondência Flexível: Agora você pode criar regras com:
    • Apenas prefixo de chamada
    • Apenas prefixo da parte chamada
    • Ambos os prefixos de chamada e da parte chamada
    • Nenhum (regra de curinga/recuo)

Novo Formato de Regra

Campos obrigatórios:

  • weight: Prioridade inteira (menor = maior prioridade)
  • response_gt: O GT a ser usado na resposta

Campos opcionais (pelo menos um recomendado para correspondência específica):

  • calling_prefix: Correspondência no prefixo GT da parte chamadora
  • called_prefix: Correspondência no prefixo GT da parte chamada

Exemplo:

gt_nat_rules: [
# Regra específica com ambos os prefixos - maior prioridade
%{calling_prefix: "8772", called_prefix: "555", weight: 1, response_gt: "111111"},

# Regras específicas - prioridade média
%{calling_prefix: "8772", weight: 10, response_gt: "222222"},
%{called_prefix: "555", weight: 10, response_gt: "333333"},

# Recuo de curinga - menor prioridade
%{weight: 100, response_gt: "999999"}
]

Casos de Uso

Operação Multi-Rede

Quando você tem várias redes parceiras e cada uma espera respostas de um GT específico:

  • Rede A chama seu GT 111111 e espera respostas de 111111
  • Rede B chama seu GT 222222 e espera respostas de 222222

Sem o GT NAT, você precisaria de instâncias separadas ou roteamento complexo. Com o GT NAT, uma única instância do OmniSS7 pode lidar com isso de forma inteligente.

Cenários de Roaming

Ao operar como um HLR ou SMSc com acordos de roaming:

  • Assinantes da rede doméstica usam GT 555000
  • Parceiro de roaming 1 usa GT 555001
  • Parceiro de roaming 2 usa GT 555002

O GT NAT garante que cada parceiro receba respostas do GT correto ao qual estão configurados para rotear.

Testes e Migração

Durante migrações de rede ou testes:

  • Migre gradualmente o tráfego do GT antigo para o novo GT
  • Mantenha ambos os GTs durante o período de transição
  • Roteie respostas com base em qual GT o chamador usou

Como Funciona

Fluxo de Tradução de Endereço

  1. Solicitação de Entrada: O OmniSS7 recebe uma mensagem SCCP com:

    • GT da Parte Chamado: 55512341112 (seu GT)
    • GT da Parte Chamadora: 877234567 (GT deles)
  2. Consulta GT NAT: O sistema verifica o GT de chamada 877234567 contra as regras de prefixo configuradas

  3. Correspondência de Prefixo: Encontra o prefixo correspondente mais longo (por exemplo, 8772 corresponde a 877234567)

  4. Seleção do GT de Resposta: Usa response_gt da regra correspondente (por exemplo, 55512341112)

  5. Resposta Enviada: A resposta SCCP usa:

    • GT da Parte Chamado: 877234567 (invertido - GT deles)
    • GT da Parte Chamadora: 55512341112 (GT NAT'd)

Tipos de Resposta Afetados

O GT NAT se aplica a múltiplas camadas da pilha SS7:

Camada SCCP (Todas as Respostas)

  • Endereços GT Chamado/Chamador SCCP em todas as mensagens de resposta
  • Reconhecimentos de ISD (InsertSubscriberData)
  • Respostas de UpdateLocation
  • Respostas de erro

Camada MAP (Operação Específica)

  • Respostas SRI-for-SM: networkNode-Number (endereço GT do SMSc)
  • UpdateLocation: hlr-Number nas respostas
  • InsertSubscriberData: GT do HLR em mensagens ISD

Configuração

Configuração Básica

Adicione ao config/runtime.exs:

config :omniss7,
# Ativar GT NAT
gt_nat_enabled: true,

# Definir regras de GT NAT
gt_nat_rules: [
# Regra 1: Chamadas do prefixo "8772" recebem resposta do "55512341112"
%{calling_prefix: "8772", response_gt: "55512341112"},

# Regra 2: Chamadas do prefixo "8773" recebem resposta do "55512341111"
%{calling_prefix: "8773", response_gt: "55512341111"},

# Regra padrão (prefixo vazio corresponde a tudo)
%{calling_prefix: "", response_gt: "55512311555"}
]

Parâmetros de Configuração

Para referência completa de configuração, veja Parâmetros de NAT de Título Global na Referência de Configuração.

ParâmetroTipoObrigatórioDescrição
gt_nat_enabledBooleanoSimAtivar/desativar recurso GT NAT
gt_nat_rulesLista de MapasSim (se ativado)Lista de regras de correspondência de prefixo

Formato da Regra

Cada regra é um mapa com as seguintes chaves:

%{
calling_prefix: "8772", # (Opcional) Prefixo para corresponder ao GT chamador
called_prefix: "555", # (Opcional) Prefixo para corresponder ao GT chamado
weight: 10, # (Obrigatório) Valor de prioridade (menor = maior prioridade)
response_gt: "55512341112" # (Obrigatório) GT a ser usado nas respostas
}

Campos da Regra:

  • calling_prefix (Opcional): Prefixo de string para corresponder ao GT chamador de entrada

    • A correspondência é feita por String.starts_with?/2
    • A string vazia "" ou nil atua como curinga (corresponde a qualquer GT chamador)
    • Pode ser omitido para corresponder a qualquer GT chamador
  • called_prefix (Opcional): Prefixo de string para corresponder ao GT chamado de entrada

    • A correspondência é feita por String.starts_with?/2
    • A string vazia "" ou nil atua como curinga (corresponde a qualquer GT chamado)
    • Pode ser omitido para corresponder a qualquer GT chamado
  • weight (Obrigatório): Valor de prioridade inteira

    • Peso menor = maior prioridade (processado primeiro)
    • Deve ser >= 0
    • Usado como critério de ordenação primário para regras de correspondência
  • response_gt (Obrigatório): O endereço de Título Global a ser usado nas respostas

    • Deve ser uma string de número E.164 válida
    • Deve corresponder a um dos seus GTs configurados

Pelo menos um dos calling_prefix ou called_prefix deve ser especificado para roteamento específico. Ambos podem ser omitidos para uma regra de curinga/recuo.

Lógica de Correspondência de Regras

As regras são avaliadas por peso primeiro (crescente), depois pela especificidade combinada do prefixo:

Algoritmo de Correspondência:

  1. Filtrar regras onde todos os prefixos especificados correspondem
    • Se calling_prefix estiver definido, deve corresponder ao GT chamador
    • Se called_prefix estiver definido, deve corresponder ao GT chamado
    • Se ambos estiverem definidos, ambos devem corresponder
    • Se nenhum estiver definido, a regra atua como um curinga
  2. Classificar regras correspondentes por:
    • Primário: Peso (crescente - valores menores primeiro)
    • Secundário: Comprimento combinado do prefixo (decrescente - mais longo = mais específico)
  3. Retornar a primeira regra correspondente

Exemplos:

# Regras de exemplo
gt_nat_rules: [
# Peso 1: Maior prioridade - corresponde a ambos os prefixos
%{calling_prefix: "8772", called_prefix: "555", weight: 1, response_gt: "111111"},

# Peso 10: Prioridade média - regras específicas
%{calling_prefix: "8772", weight: 10, response_gt: "222222"}, # Apenas chamando
%{called_prefix: "555", weight: 10, response_gt: "333333"}, # Apenas chamado

# Peso 100: Menor prioridade - recuo curinga
%{weight: 100, response_gt: "444444"} # Corresponde a tudo
]

# Exemplos de correspondência:
# Chamando: "877234567", Chamado: "555123" -> "111111" (peso 1, ambos correspondem)
# Chamando: "877234567", Chamado: "999999" -> "222222" (peso 10, apenas chamando)
# Chamando: "999999999", Chamado: "555123" -> "333333" (peso 10, apenas chamado)
# Chamando: "999999999", Chamado: "888888" -> "444444" (peso 100, curinga)

Exemplos

Exemplo 1: Dois Parceiros de Rede

Cenário: Você opera um SMSc com dois parceiros de rede. Cada um espera respostas de um GT diferente.

config :omniss7,
gt_nat_enabled: true,

# GT padrão do SMSc (usado quando o GT NAT está desativado ou nenhuma regra corresponde)
smsc_service_center_gt_address: "5551000",

# Regras de GT NAT para parceiros
gt_nat_rules: [
# Parceiro A (prefixo 4412) espera respostas do GT 5551001
%{calling_prefix: "4412", weight: 10, response_gt: "5551001"},

# Parceiro B (prefixo 4413) espera respostas do GT 5551002
%{calling_prefix: "4413", weight: 10, response_gt: "5551002"},

# Padrão: usar GT padrão do SMSc (recuo curinga)
%{weight: 100, response_gt: "5551000"}
]

Fluxo de Tráfego:

SRI-for-SM de entrada de 44121234567:
GT Chamado: 5551001 (seu GT que o Parceiro A usa)
GT Chamador: 44121234567 (GT do Parceiro A)

Consulta GT NAT:
"44121234567" corresponde ao prefixo "4412"
GT de resposta selecionado: "5551001"

Resposta SRI-for-SM para 44121234567:
GT Chamado: 44121234567 (invertido)
GT Chamador: 5551001 (NAT'd)
networkNode-Number: 5551001 (na resposta MAP)

Exemplo 2: HLR com GTs Regionais

Cenário: HLR nacional com diferentes GTs por região.

config :omniss7,
gt_nat_enabled: true,
hlr_service_center_gt_address: "555000", # GT padrão do HLR

gt_nat_rules: [
# VLRs da região norte (prefixo 5551)
%{calling_prefix: "5551", weight: 10, response_gt: "555100"},

# VLRs da região sul (prefixo 5552)
%{calling_prefix: "5552", weight: 10, response_gt: "555200"},

# VLRs da região oeste (prefixo 5553)
%{calling_prefix: "5553", weight: 10, response_gt: "555300"},

# Padrão para outras regiões (curinga)
%{weight: 100, response_gt: "555000"}
]

Exemplo 3: Cenário de Migração

Cenário: Migrando gradualmente do GT antigo para o novo GT.

config :omniss7,
gt_nat_enabled: true,
hlr_service_center_gt_address: "123456789", # GT antigo (padrão)

gt_nat_rules: [
# Redes migradas (já atualizaram suas configurações)
%{calling_prefix: "555", weight: 10, response_gt: "987654321"}, # Novo GT
%{calling_prefix: "666", weight: 10, response_gt: "987654321"}, # Novo GT

# Todos os outros ainda usam o GT antigo (curinga)
%{weight: 100, response_gt: "123456789"} # GT antigo
]

Exemplo 4: Correspondência de Prefixo da Parte Chamado (NOVO)

Cenário: Você tem múltiplos GTs para diferentes serviços e deseja responder com o GT correto com base em qual GT foi chamado.

config :omniss7,
gt_nat_enabled: true,

gt_nat_rules: [
# Quando chamam seu GT de SMS (5551xxx), responda com esse GT
%{called_prefix: "5551", weight: 10, response_gt: "555100"},

# Quando chamam seu GT de Voz (5552xxx), responda com esse GT
%{called_prefix: "5552", weight: 10, response_gt: "555200"},

# Quando chamam seu GT de Dados (5553xxx), responda com esse GT
%{called_prefix: "5553", weight: 10, response_gt: "555300"},

# Recuo padrão
%{weight: 100, response_gt: "555000"}
]

Fluxo de Tráfego:

Solicitação de entrada para GT Chamado: 555100 (seu GT de SMS)
GT Chamador: 441234567 (qualquer chamador)

Consulta GT NAT:
GT Chamado "555100" corresponde ao prefixo "5551"
GT de resposta selecionado: "555100"

Resposta usa GT Chamador: 555100 (corresponde ao que eles chamaram)

Exemplo 5: Correspondência Combinada de Prefixo Chamando + Chamado (AVANÇADO)

Cenário: Diferentes parceiros chamam diferentes GTs, e você deseja controle detalhado.

config :omniss7,
gt_nat_enabled: true,

gt_nat_rules: [
# Parceiro A chamando seu GT de SMS - maior prioridade (peso 1)
%{calling_prefix: "4412", called_prefix: "5551", weight: 1, response_gt: "555101"},

# Parceiro B chamando seu GT de SMS - maior prioridade (peso 1)
%{calling_prefix: "4413", called_prefix: "5551", weight: 1, response_gt: "555102"},

# Qualquer um chamando seu GT de SMS - prioridade média (peso 10)
%{called_prefix: "5551", weight: 10, response_gt: "555100"},

# Parceiro A chamando qualquer GT - prioridade média (peso 10)
%{calling_prefix: "4412", weight: 10, response_gt: "555200"},

# Recuo padrão - baixa prioridade (peso 100)
%{weight: 100, response_gt: "555000"}
]

Exemplos de Correspondência:

# Parceiro A chama GT de SMS
Chamando: "441234567", Chamado: "555100"
→ Corresponde à regra de peso 1 (ambos os prefixos) → "555101"

# Parceiro A chama GT de Voz
Chamando: "441234567", Chamado: "555200"
→ Corresponde à regra de peso 10 (apenas chamando) → "555200"

# Chamador desconhecido chama GT de SMS
Chamando: "999999999", Chamado: "555100"
→ Corresponde à regra de peso 10 (apenas chamado) → "555100"

# Chamador desconhecido chama GT de Voz
Chamando: "999999999", Chamado: "555200"
→ Corresponde ao peso 100 curinga → "555000"

Modos Operacionais

O GT NAT funciona em todos os modos operacionais do OmniSS7:

Modo HLR

O GT NAT afeta:

  • Respostas de UpdateLocation (GT do HLR na resposta)
  • Mensagens de InsertSubscriberData (GT do HLR como parte chamadora)
  • Respostas de SendAuthenticationInfo
  • Respostas de Cancel Location

Para mais informações sobre operações HLR, veja o Guia de Configuração HLR.

Configuração:

config :omniss7,
hlr_mode_enabled: true,
hlr_service_center_gt_address: "5551234567", # GT padrão do HLR

gt_nat_enabled: true,
gt_nat_rules: [
%{calling_prefix: "331", weight: 10, response_gt: "5551234568"}, # França
%{calling_prefix: "44", weight: 10, response_gt: "5551234569"}, # Reino Unido
%{weight: 100, response_gt: "5551234567"} # Curinga padrão
]

Modo SMSc

O GT NAT afeta:

  • Respostas SRI-for-SM (campo networkNode-Number) - veja Detalhes SRI-for-SM
  • Reconhecimentos de MT-ForwardSM

Para mais informações sobre operações SMSc, veja o Guia de Configuração SMSc.

Configuração:

config :omniss7,
smsc_mode_enabled: true,
smsc_service_center_gt_address: "5559999", # GT padrão do SMSc

gt_nat_enabled: true,
gt_nat_rules: [
%{calling_prefix: "1", weight: 10, response_gt: "5559991"}, # América do Norte
%{calling_prefix: "44", weight: 10, response_gt: "5559992"}, # Reino Unido
%{calling_prefix: "86", weight: 10, response_gt: "5559993"}, # China
%{weight: 100, response_gt: "5559999"} # Curinga padrão
]

Modo Gateway CAMEL

O GT NAT afeta:

  • Todas as respostas em nível SCCP (GT gsmSCF como Parte Chamadora)
  • Respostas de operações CAMEL/CAP (InitialDP, EventReportBCSM, etc.)
  • Reconhecimentos de RequestReportBCSMEvent
  • Respostas de ApplyCharging
  • Respostas de Continue

Configuração:

config :omniss7,
camelgw_mode_enabled: true,
camel_gsmscf_gt_address: "55512341112", # GT padrão gsmSCF

gt_nat_enabled: true,
gt_nat_rules: [
%{calling_prefix: "555", weight: 10, response_gt: "55512341111"}, # Rede A
%{calling_prefix: "666", weight: 10, response_gt: "55512311555"}, # Rede B
%{weight: 100, response_gt: "55512341112"} # Curinga padrão
]

Caso de Uso: Ao operar como um gsmSCF (Função de Controle de Serviço) para várias redes, cada gsmSSF da rede pode esperar respostas de um GT gsmSCF específico. O GT NAT garante que o GT correto seja usado com base em qual gsmSSF está chamando.

Registro e Depuração

Ativar Registro de GT NAT

O GT NAT inclui registro automático de todas as traduções:

# Nos logs, você verá:
[info] GT NAT [resposta SRI-for-SM]: GT Chamador 877234567 -> GT de Resposta 55512341112
[info] GT NAT [UpdateLocation ISD]: GT Chamador 331234567 -> GT de Resposta 55512341111
[info] GT NAT [resposta MAP BEGIN]: GT Chamador 441234567 -> GT de Resposta 55512311555

O campo de contexto mostra onde o NAT foi aplicado:

  • "resposta SRI-for-SM" - No manipulador SRI-for-SM
  • "UpdateLocation ISD" - Em mensagens InsertSubscriberData
  • "UpdateLocation END" - Na resposta UpdateLocation END
  • "resposta MAP BEGIN" - Respostas MAP BEGIN genéricas
  • "ISD ACK" - Reconhecimento ISD
  • "resposta de erro HLR" - Resposta de erro do HLR
  • "resposta CAMEL" - Respostas de operações CAMEL/CAP (gsmSCF)

Validação

O sistema valida a configuração do GT NAT na inicialização:

# Verifique a configuração do GT NAT
iex> GtNat.validate_config()
{:ok, [
%{calling_prefix: "8772", weight: 10, response_gt: "55512341112"},
%{calling_prefix: "8773", weight: 10, response_gt: "55512341111"}
]}

# Verifique se está ativado
iex> GtNat.enabled?()
true

# Obtenha todas as regras
iex> GtNat.get_rules()
[
%{calling_prefix: "8772", weight: 10, response_gt: "55512341112"},
%{calling_prefix: "8773", weight: 10, response_gt: "55512341111"}
]

Testando o GT NAT

Teste a lógica do GT NAT programaticamente:

# Teste a tradução com GT chamador apenas (called_gt é nil)
iex> GtNat.translate_response_gt("877234567", nil, "default_gt")
"55512341112"

# Teste a tradução com ambos os GTs chamador e chamado
iex> GtNat.translate_response_gt("877234567", "555123", "default_gt")
"55512341112"

# Teste com registro (GT chamado nil)
iex> GtNat.translate_response_gt_with_logging("877234567", nil, "default_gt", "test")
# Logs: GT NAT [test]: GT Chamador 877234567 -> GT de Resposta 55512341112
"55512341112"

# Teste com registro (ambos os GTs)
iex> GtNat.translate_response_gt_with_logging("877234567", "555123", "default_gt", "test")
# Logs: GT NAT [test]: GT Chamador 877234567, GT Chamado 555123 -> GT de Resposta 55512341112
"55512341112"

# Teste sem correspondência (retorna padrão)
iex> GtNat.translate_response_gt("999999999", "888888", "default_gt")
"default_gt"

Resolução de Problemas

Problema: GT NAT Não Funcionando

Verifique 1: Está ativado?

iex> Application.get_env(:omniss7, :gt_nat_enabled)
true # Deve ser true

Verifique 2: As regras estão configuradas?

iex> Application.get_env(:omniss7, :gt_nat_rules)
[%{calling_prefix: "8772", response_gt: "55512341112"}, ...] # Deve retornar lista

Verifique 3: Verifique os logs Procure por "GT NAT" nos logs para ver se as traduções estão acontecendo.

Problema: GT Errado nas Respostas

Sintoma: Respostas usam endereço GT inesperado

Causa: A correspondência de prefixo da regra pode ser muito ampla ou a regra padrão está capturando o tráfego

Solução: Revise os pesos e prefixos das regras:

# RUIM: Curinga com peso baixo (captura tudo primeiro)
gt_nat_rules: [
%{weight: 1, response_gt: "111111"}, # Isso corresponde a tudo primeiro!
%{calling_prefix: "8772", weight: 10, response_gt: "222222"} # Nunca alcançado
]

# BOM: Regras específicas com peso menor, curinga com peso maior
gt_nat_rules: [
%{calling_prefix: "8772", weight: 10, response_gt: "222222"}, # Específico, peso baixo
%{weight: 100, response_gt: "111111"} # Curinga, peso alto (recuo)
]

Problema: GT NAT Não Aplicado a Tipo de Mensagem Específico

Sintoma: Algumas respostas usam GT NAT'd, outras não

Cobertura Atual:

  • ✅ GT Chamador SCCP (todas as respostas)
  • ✅ Respostas SRI-for-SM (networkNode-Number)
  • ✅ Mensagens ISD de UpdateLocation (GT do HLR)
  • ✅ Respostas de UpdateLocation END
  • ✅ Reconhecimentos de ISD
  • ✅ Respostas MAP BEGIN

Se um tipo de mensagem específico não estiver usando GT NAT, pode não ter sido implementado ainda. Verifique o código-fonte ou entre em contato com o suporte.

Considerações de Desempenho

Desempenho de Consulta

O GT NAT usa correspondência de prefixo simples com complexidade O(n) onde n é o número de regras.

Dicas de desempenho:

  • Mantenha a contagem de regras abaixo de 100 para melhor desempenho
  • Use prefixos específicos para reduzir a contagem de regras
  • A regra padrão (prefixo vazio) deve ser a última

Benchmark (sistema típico):

  • 10 regras: < 1µs por consulta
  • 50 regras: < 5µs por consulta
  • 100 regras: < 10µs por consulta

Uso de Memória

Cada regra requer ~100 bytes de memória:

  • 10 regras ≈ 1 KB
  • 100 regras ≈ 10 KB

Melhores Práticas

1. Sempre Inclua uma Regra de Recuo Curinga

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"} # Sempre tenha um curinga com peso alto
]

2. Use Prefixos e Pesos Significativos

# BOM: Prefixos claros e específicos com pesos apropriados
%{calling_prefix: "331", weight: 10, response_gt: "..."} # França
%{calling_prefix: "44", weight: 10, response_gt: "..."} # Reino Unido

# RUIM: Prefixos excessivamente amplos ou pesos confusos
%{calling_prefix: "3", weight: 5, response_gt: "..."} # Muitos países
%{calling_prefix: "331", weight: 100, response_gt: "..."} # Peso deve ser menor para regras específicas

3. Documente Suas Regras

gt_nat_rules: [
# Parceiro XYZ - rede do Reino Unido (faixa de GT: 4412xxxxxxx)
# Peso 10: Prioridade padrão do parceiro
%{calling_prefix: "4412", weight: 10, response_gt: "5551001"},

# Parceiro ABC - rede da França (faixa de GT: 33123xxxxxx)
# Peso 10: Prioridade padrão do parceiro
%{calling_prefix: "33123", weight: 10, response_gt: "5551002"}
]

4. Teste Antes da Implantação

# Teste no iex antes de implantar
iex> GtNat.translate_response_gt("44121234567", nil, "default")
"5551001" # Resultado esperado

# Teste com GT chamado
iex> GtNat.translate_response_gt("44121234567", "555123", "default")
"5551001" # Resultado esperado

5. Monitore os Logs

Ative o registro em nível INFO para ver todas as traduções do GT NAT em produção.

Integração com Outros Recursos

Modo STP

O GT NAT funciona independentemente do roteamento STP. O STP roteia com base em códigos de ponto e GTs de destino, enquanto o GT NAT lida com endereçamento de resposta.

Para mais informações sobre roteamento STP, veja o Guia de Configuração STP.

Integração CAMEL

O GT NAT está totalmente integrado com operações CAMEL/CAP:

Camada SCCP:

  • GT da Parte Chamadora em todas as respostas CAMEL
  • Aplicado automaticamente com base no GT gsmSSF de entrada

Configuração:

  • camel_gsmscf_gt_address - GT padrão gsmSCF (opcional)
  • Se não configurado, usa o GT da Parte Chamado da solicitação de entrada
  • As regras de GT NAT substituem o padrão com base no prefixo da parte chamadora

Exemplo:

# Quando gsmSSF 555123456 chama seu gsmSCF
# Entrada: Chamado=55512341112, Chamando=555123456
# Consulta GT NAT: "555" -> response_gt="55512341111"
# Resposta: Chamado=555123456, Chamando=55512341111

Balanceamento de Carga

O GT NAT pode ser combinado com balanceamento de carga M3UA para gerenciamento avançado de tráfego.

Guia de Migração

Ativando o GT NAT em um Sistema Existente

  1. Prepare a Configuração

    # Adicione ao runtime.exs (mantenha desativado inicialmente)
    config :omniss7,
    gt_nat_enabled: false, # Comece desativado
    gt_nat_rules: [
    # Suas regras aqui com pesos
    %{calling_prefix: "877", weight: 10, response_gt: "111111"},
    %{weight: 100, response_gt: "999999"} # Recuo curinga
    ]
  2. Teste a Configuração

    # Valide se a configuração compila
    mix compile

    # Teste no iex
    iex -S mix
    iex> GtNat.validate_config()
  3. Ative em Staging

    gt_nat_enabled: true  # Mude para true
  4. Monitore os Logs

    tail -f log/omniss7.log | grep "GT NAT"
  5. Implante em Produção

    • Implemente durante a janela de manutenção
    • Monitore as primeiras 24 horas de perto
    • Tenha um plano de reversão pronto (defina gt_nat_enabled: false)

Suporte

Para problemas ou perguntas:

  • Verifique os logs para mensagens "GT NAT"
  • Valide a configuração com GtNat.validate_config()
  • Revise a seção de resolução de problemas deste guia
  • Entre em contato com o suporte OmniSS7 com trechos de log