Asterisk - 来自 SIP DID 中继的入站呼叫“由于未找到分机而被拒绝”

Asterisk - 来自 SIP DID 中继的入站呼叫“由于未找到分机而被拒绝”

我有一个指向 Asterisk 服务器的 DID,其中有 DIDforSale。当我从固定电话拨打电话时,我听到的是 AT&T 断线录音。Asterisk CLI 显示错误消息:

[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 在错误的上下文中查找。

配置

我在运行 Ubuntu Server 10.04 (lucid) 的物理服务器上通过 Apt 安装 Asterisk 1.6.2.5-0ubuntu1.4。我已将中继配置为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上下文,其中包含每个 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 5core set debug 5sip set debug on除 SIP 数据包转储之外的唯一附加 CLI 输出是:

  == 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

事先排除故障

我已经验证了对sip show peer didforsale_1等端使用的上下文是否正确。dialplan show from-did表示上下文解析正确。如果我将其包含在我桌面电话的默认上下文中,则拨打 DID 号码会按预期显示 IVR 菜单。

我阅读了 Google 搜索结果的前几页,搜索了几组与错误消息相关的搜索词,但没有找到任何有用的信息。主要是使用 FreePBX 或类似产品的人需要帮助from-did在 GUI 中设置与我的上下文相同的内容。一些帖子看起来可能与我遇到的问题相同,但没有一个有答案。我会发布链接,但我的声誉太低了。一旦声誉足够高,我就会编辑以添加它们。

答案1

我最终阅读了错误消息中提到的handle_request_invite函数的源代码。该函数调用(在同一个文件中)来解析目标地址。如果返回错误,它会生成我看到的错误消息。chan_sip.cget_destinationget_destination

来自 DID 提供商的传入 SIP 请求中的 URI 域INVITE设置为我的 PBX 的 IP 地址,而不是其域。我已allowexternaldomains禁用sip.conf,并且我的 IP 不在域列表中,因此目标地址被拒绝。查看它的源代码get_destination似乎应该在返回错误之前在调试级别 1 产生错误消息,但出于某种原因我没有看到它。

将我的 IP 地址添加到域列表似乎已解决了该问题。

答案2

我现在看到的隐藏数字是数字与前面带有 + 的数字之间的差异。

要查看这是否是问题,最简单的测试是这样的:

// 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 之间的差异。

相关内容