DID DIDforSaleがAsteriskサーバーを指しています。固定電話から電話をかけると、AT&Tの切断された回線の録音が表示されます。AsteriskCLIに次のエラーメッセージが表示されます。
[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.
「from」の部分は、sip.conf
ピアエントリと正しく一致していることを示します。 「to」の部分は、ピアがターゲット内線番号としてDID番号を正しく送信していることを示しています。DID番号は、ピアの着信コンテキストで有効な内線番号です。 (詳細は以下)ので、アスタリスクが間違ったコンテキストを探しているとしか思えません。
Ubuntu Server 10.04(lucid)を実行している物理サーバーにApt経由でインストールされたAsterisk1.6.2.5-0ubuntu1.4を使用しています。トランクをsip.conf
で構成し、発信元IPごとに1つのピアを使用しています(2つあります)。これらは関連するスタンザです:
[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 5
、core set debug 5
、およびsip 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または同様の製品を使用していて、GUIで私のfrom-did
コンテキストに相当するものを設定するための支援が必要です。いくつかの投稿は私が抱えているのと同じ問題である可能性があるように見えますが、どれも答えがありません。リンクを投稿しますが、評判が低すぎます。十分に高くなったら、編集して追加します。
エラーメッセージに記載されているhandle_request_invite
からchan_sip.c
関数のソースを読み取ることになりました。この関数は、(同じファイル内の)get_destination
を呼び出して、宛先アドレスを解決します。 get_destination
がエラーを返すと、私が見ていたエラーメッセージが表示されます。
SIPプロバイダーからの着信DID INVITE
リクエストのURIのドメインは、PBXではなくPBXのIPアドレスに設定されます。ドメイン。sip.conf
でallowexternaldomains
を無効にしましたが、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の違いです。