Asterisco - as chamadas de entrada do tronco SIP DID “rejeitadas porque a extensão não foi encontrada”

Question

Eu tenho um DID com DIDforSale que está direcionado para o meu servidor Asterisk. Quando eu ligo do meu telefone fixo, recebo a gravação de linha desconectada da AT & T. A CLI do Asterisk mostra a mensagem de erro:

[Oct  6 17:03:00] NOTICE[10563]: chan_sip.c:20163 handle_request_invite: Call from 'didforsale_1' to extension '###########' rejected because extension not found.

A parte "de" indica que corresponde corretamente à entrada sip.conf peer. A parte "para" mostra que o peer está enviando corretamente o número DID como o ramal alvo. O número DID é uma extensão válida no contexto de entrada do peer (detalhes abaixo), então só posso assumir que o Asterisk está procurando no contexto errado.

Configuração

Estou usando o Asterisk 1.6.2.5-0ubuntu1.4 instalado via Apt em um servidor físico que executa o Ubuntu Server 10.04 (lúcido). Eu tenho o tronco configurado em sip.conf com um peer por IP de origem (existem dois). Estas são as estrofes relevantes:

[didforsale_base](!)
    type=peer
    context=from-did
    nat=no
    insecure=port,invite

    ; configure codecs
    disallow=all
    allow=ulaw
    allow=alaw
    allow=g729
    dtmfmode=rfc2833

[didforsale_1](didforsale_base)
    host=AAA.AAA.AAA.AAA

[didforsale_2](didforsale_base)
    host=BBB.BBB.BBB.BBB

Os peers são configurados para enviar chamadas para o contexto from-did , que contém uma extensão por número DID. O contexto está configurado em extensions.ael da seguinte forma:

// starting context for calls originating from DID trunks
// the call is matched on the DID number and routed appropriately
context from-did {
    // test DID from DIDforSale
    ########### => jump s@inbound;
}

Saída de depuração

Com core set verbose 5 , core set debug 5 e sip set debug on , a única saída CLI adicional além dos despejos de pacotes SIP é:

  == Using SIP RTP CoS mark 5
Sending to AAA.AAA.AAA.AAA : 5060 (no NAT)
Using INVITE request as basis request - [email protected]
Found peer 'didforsale_1' for '+###########' from AAA.AAA.AAA.AAA:5060
Found RTP audio format 18
Found RTP audio format 0
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format PCMU for ID 0
Found audio description format telephone-event for ID 101
Capabilities: us - 0x10c (ulaw|alaw|g729), peer - audio=0x104 (ulaw|g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x104 (ulaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port CCC.CCC.CCC.CCC:5432

Resolução de problemas prévia

Eu verifiquei com sip show peer didforsale_1 que os pares estão usando o contexto correto. dialplan show from-did indica que o contexto foi analisado corretamente. Se eu incluí-lo no contexto padrão para o meu telefone de mesa, chamar o número DID me dá o menu IVR conforme o esperado.

Eu li as primeiras páginas dos resultados do Google para alguns conjuntos de termos de pesquisa ao redor da mensagem de erro, mas não encontrei nada de útil. É principalmente pessoas que usam o FreePBX ou um produto semelhante que precisa de ajuda para configurar o equivalente do meu contexto from-did na GUI. Alguns posts parecem ser o mesmo problema que eu estou tendo, mas nenhum deles tem respostas. Eu colocaria links, mas minha reputação é muito baixa. Quando estiver alto o suficiente, eu edito para adicioná-los.

    

Answer 1

Acabei de ler a fonte para a função handle_request_invite de chan_sip.c mencionada na mensagem de erro. Essa função chama get_destination (no mesmo arquivo) para resolver o endereço de destino. Se get_destination retornar um erro, será exibida a mensagem de erro que estava vendo.

O domínio do URI na solicitação SIP INVITE de entrada do provedor DID é configurado para o endereço IP do meu PBX, não para o seu domínio. Eu tinha allowexternaldomains desativado em sip.conf e meu IP não estava na lista de domínios, portanto, o endereço de destino estava sendo rejeitado. Olhando para a fonte para get_destination , parece que isso deve produzir uma mensagem de erro no nível de depuração 1 antes de retornar o erro, mas, por algum motivo, não estou vendo.

Adicionar meu endereço IP à lista de domínios parece ter corrigido o problema.

    

Answer 2

A coisa que vejo no momento com os números ocultos é a diferença entre os números e os números com o prefácio +.

O teste mais fácil de ver se esse é o problema seria algo como:

// starting context for calls originating from DID trunks
// the call is matched on the DID number and routed appropriately
context from-did {
    // test DID from DIDforSale
    ########### => jump s@inbound;
    +########### => jump s@inbound;
}

ou o log da opção "o que eu senti falta?":

// starting context for calls originating from DID trunks
// the call is matched on the DID number and routed appropriately
context from-did {
    // test DID from DIDforSale
    _.+ => NoOp(debug incoming exten = ${EXTEN})
    _.+ => jump s@inbound;
}

Isso registrará a extensão real no seu console. Usando _. + É desaprovado (porque corresponde a tudo) e lhe dará um aviso.

O + é do padrão ITU para publicação de números de telefone internacionais. Provedores SIP diferentes terão diferentes maneiras de lidar com isso. Mas o fato de você mencionar AT & T (empresa norte-americana) e usar 10 # sinais para o número me dá a dica de que o núcleo do problema é a diferença entre a notação usual nos EUA para discagem de longa distância: 1- NNN-YYY-ZZZZ e a notação internacional da ITU + 1-NNN-YYY-ZZZZ.