Назад | Перейти на главную страницу

Asterisk - входящие вызовы из магистрали SIP DID «отклонены, поскольку добавочный номер не найден»

У меня есть DID с DIDforSale, который указывает на мой сервер Asterisk. Когда я звоню со своего стационарного телефона, я получаю запись об отключенной линии AT&T. Интерфейс командной строки Asterisk показывает сообщение об ошибке:

[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.

Часть "от" указывает, что она правильно соответствует sip.conf одноранговая запись. Часть «Кому» показывает, что одноранговый узел правильно отправляет номер DID в качестве целевого расширения. Номер DID является допустимым расширением во входящем контексте однорангового узла (подробности ниже), поэтому я могу только предположить, что Asterisk ищет в неправильном контексте.

Конфигурация

Я использую Asterisk 1.6.2.5-0ubuntu1.4, установленный через Apt на физическом сервере под управлением Ubuntu Server 10.04 (lucid). Я настроил транк в sip.conf с одним партнером на каждый исходящий IP (их два). Это соответствующие строфы:

[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

Одноранговые узлы настроены для отправки вызовов from-did context, который содержит добавочный номер для каждого номера DID. Контекст настраивается в extensions.ael как это:

// 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;
}

Вывод отладки

С участием core set verbose 5, core set debug 5, и sip set debug on единственный дополнительный вывод CLI, помимо дампов SIP-пакетов:

  == Using SIP RTP CoS mark 5
Sending to AAA.AAA.AAA.AAA : 5060 (no NAT)
Using INVITE request as basis request - 1510862529_23265@CCC.CCC.CCC.CCC
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

Предварительное устранение неисправностей

Я проверил с sip show peer didforsale_1 что одноранговые узлы используют правильный контекст. dialplan show from-did указывает, что контекст проанализирован правильно. Если я включу его в контекст по умолчанию для моего настольного телефона, вызов номера DID даст мне меню IVR, как и ожидалось.

Я прочитал первые несколько страниц результатов Google для нескольких наборов поисковых запросов вокруг сообщения об ошибке, но не нашел ничего полезного. В основном это люди, использующие FreePBX или аналогичный продукт, которым нужна помощь в настройке эквивалента моего from-did контекст в графическом интерфейсе. Несколько сообщений выглядят так, будто это может быть та же проблема, что и у меня, но ни на одну из них нет ответов. Я бы разместил ссылки, но моя репутация слишком низкая. Как только он станет достаточно высоким, я отредактирую, чтобы добавить их.

В конце концов я прочитал источник handle_request_invite функция от chan_sip.c упоминается в сообщении об ошибке. Эта функция вызывает get_destination (в том же файле), чтобы разрешить адрес назначения. Если get_destination возвращает ошибку, он выдает сообщение об ошибке, которое я видел.

Домен URI во входящем SIP INVITE запрос от провайдера DID устанавливается на IP-адрес моей АТС, а не на ее домен. я имел allowexternaldomains отключен в sip.conf и моего IP-адреса не было в списке доменов, поэтому адрес назначения был отклонен. Глядя на источник get_destination похоже, что на уровне отладки 1 должно появиться сообщение об ошибке перед возвратом ошибки, но по какой-то причине я этого не вижу.

Добавление моего IP-адреса в список доменов, похоже, устранило проблему.

То, что я вижу сейчас со скрытыми числами, - это разница между числами и числами с добавленным +.

Самый простой тест, чтобы определить, является ли это проблемой, будет выглядеть примерно так:

// 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;
}

или запись опции «что я пропустил»:

// 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;
}

Это зарегистрирует фактическое расширение вашей консоли. Использование _. + Не одобряется (потому что оно соответствует всему) и даст вам предупреждение.

Знак + взят из стандарта ITU для публикации международных телефонных номеров. Разные SIP-провайдеры будут по-разному решать эту проблему. Но тот факт, что вы упоминаете AT&T (американскую компанию) и используете знаки 10 # для номера, дает мне понять, что суть проблемы заключается в различии между обозначениями, обычными в США для междугородного набора: 1-NNN- YYY-ZZZZ и международное обозначение ITU + 1-NNN-YYY-ZZZZ.