アスタリスクは、Cisco2430ルータへのT1 PRIインターフェイスを介して通話を発信または受信できません
DigiumT1カードを備えたAsterisk1.8電話スイッチを持っています。現在の電話プロバイダーを通じて5ESS PRIを使用して問題なく実行されます。ただし、Time Warnerのファイバーサービス（TWTelecomではない）への切り替えを検討しているため、ISDNプロトコルエラーで失敗します。
彼らのサービスは本質的にVOIPであり、Asteriskで問題なく機能しているにもかかわらず、直接触れることはできません。私は試しました。代わりに、Cisco 2430ルーターを使用して公開し、サポートされている唯一のオプションは、ある種のT1インターフェイスを提供することです。 PRIが最も賢明なオプションです。既存の電話プロバイダーのT1境界ポイントからCiscoルーターにプラグを転送するとすぐに、発信または着信のいずれの通話も通過しません。
集中的なpriデバッグを有効にすると、libpriが送信する最初のパケットで問題が発生することは明らかです。これは、発信呼び出しの着信であるかどうかに関係ありません。着信コールの例を次に示します-最初の3つのパケット。 libpriが送信しているものでCiscoルーターbarfs。問題は、それを修正する方法と方法です。
Ciscoルータはファームウェアを実行しますc2430-ik9o3s-mz.124-15.T9.bin-これは明らかにTWCの企業標準であり、変更することはできません。
< TEI: 0 State 7(Multi-frame established)
< V(A)=2, V(S)=2, V(R)=2
< K=7, RC=0, l3_initiated=0, reject_except=0, ack_pend=0
< T200_id=0, N200=3, T203_id=8192
< [ 02 01 04 04 08 02 00 91 05 .... ]
< 59 bytes of data
< Protocol Discriminator: Q.931 (8) len=59
< TEI=0 Call Ref: len= 2 (reference 145/0x91) (Sent from originator)
< Message Type: SETUP (5)
< [04 03 80 90 a2]
< Bearer Capability (len= 5) [ Ext: 1 Coding-Std: 0 Info transfer capability: Speech (0)
< Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
< User information layer 1: u-Law (34)
< [18 03 a9 83 81]
< Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0
< ChanSel: As indicated in following octets
< Ext: 1 Coding: 0 Number Specified Channel Type: 3
< Ext: 1 Channel: 1 Type: CPE]
< [28 0f ...]
< Display (len=15) [ ... ]
< [6c 0c 21 80 ...]
< Calling Party Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Presentation: Presentation allowed, User-provided, not screened (0) '...' ]
< [70 0b a1 ...]
< Called Party Number (len=13) [ Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '...' ]
> DL-DATA request
> Protocol Discriminator: Q.931 (8) len=11
> TEI=0 Call Ref: len= 2 (reference 145/0x91) (Sent to originator)
> Message Type: CALL PROCEEDING (2)
TEI=0 Transmitting N(S)=2, window is open V(A)=2 K=7
> TEI: 0 State 7(Multi-frame established)
> V(A)=2, V(S)=2, V(R)=3
> K=7, RC=0, l3_initiated=0, reject_except=0, ack_pend=0
> T200_id=0, N200=3, T203_id=8192
> [ 00 01 04 06 08 02 80 91 02 18 04 e9 81 83 81 ]
> Informational frame:
> SAPI: 00 C/R: 0 EA: 0
> TEI: 000 EA: 1
> N(S): 002 0: 0
> N(R): 003 P: 0
> 11 bytes of data
> Protocol Discriminator: Q.931 (8) len=11
> TEI=0 Call Ref: len= 2 (reference 145/0x91) (Sent to originator)
> Message Type: CALL PROCEEDING (2)
> [18 04 e9 81 83 81]
> Channel ID (len= 6) [ Ext: 1 IntID: Explicit Other(PRI) Spare: 0 Exclusive Dchan: 0
> ChanSel: As indicated in following octets
> Ext: 1 DS1 Identifier: 1
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 1 Type: CPE]
< TEI: 0 State 7(Multi-frame established)
< V(A)=3, V(S)=4, V(R)=3
< K=7, RC=0, l3_initiated=0, reject_except=0, ack_pend=0
< T200_id=8192, N200=3, T203_id=0
< [ 02 01 06 06 08 02 00 91 7d 08 03 80 e4 18 14 01 01 ]
< Informational frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< N(S): 003 0: 0
< N(R): 003 P: 0
< 13 bytes of data
< Protocol Discriminator: Q.931 (8) len=13
< TEI=0 Call Ref: len= 2 (reference 145/0x91) (Sent from originator)
< Message Type: STATUS (125)
< [08 03 80 e4 18]
< Cause (len= 5) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0)
< Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ]
< Cause data 1: 18 (24)
< [14 01 01]
< Call State (len= 3) [ Ext: 0 Coding: CCITT (ITU) standard (0) Call state: Call Initiated (1)
原因データ？原因データ！
libpriは、原因情報要素（IE）の原因データが何を意味するかを示すのにあまり賢くありません-実際、1.4.13の時点では、 Q.85 で与えられた100のうち2つのケースしか処理しません。 =！ありがたいことに、それは単なるランダムな独自の診断データではありません。
Q.850原因と場所の使用法... 、表1を参照して、原因100無効な情報要素の内容にどのような診断が存在するかを確認する必要があります。見よ、それは情報要素識別子です！したがって、libpriによって送信されるCallProceedingメッセージのIE 0x18（24）は問題がありました。たまたま、IE 0x18はチャネルID要素です。少なくとも、問題がその特定の要素にあることはわかっています。参考までに、シスコから受け取った原因IE：
< [08 03 80 e4 18]
< Cause (len= 5) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0)
< Ext: 1 Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ]
< Cause data 1: 18 (24)
チャネル識別IE-識別するかどうか
IEに絞り込んだので、 Q.931 、4.5.13チャネル識別[IE]を参照すると、次の場合にコールセットアップに応答するときに要素全体がオプションであることに注意してください。ここでの場合のように、ユーザー機器は、ネットワークによって明示的に要求された唯一のチャネル（ここではCiscoルーター）を使用したいだけです。
残念ながら、通話進行メッセージを送信するためのlibpriの内部API q931_call_proceeding in q931.c は、完全なチャネルIDIEを送信しないことを実際には簡単にしません。実際、libpriのstruct q931_callは、最後に受信した明示的なチャネルIDを保持しないため、チャネルID IE）を送信することが適切かどうかを判断する方法はありません。 call_proceeding_ies[]にQ931_CHANNEL_IDENTが含まれているというエラー-通話続行メッセージは必ずしもこのIEを必要としません。
したがって、1つの修正は、単にチャネルIDを送信しないことです。
しかし、は何ですか内の問題は何ですか？
残念ながら、さらに深く掘り下げて、チャネルID IEがCiscoのファームウェアを混乱させたものを確認することができます。
シスコから受信したチャネルIDと返信で返送したチャネルID IE）を比較してみましょう。
< [18 03 a9 83 81]
< Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0
< ChanSel: As indicated in following octets
< Ext: 1 Coding: 0 Number Specified Channel Type: 3
< Ext: 1 Channel: 1 Type: CPE]
> [18 04 e9 81 83 81]
> Channel ID (len= 6) [ Ext: 1 IntID: Explicit Other(PRI) Spare: 0 Exclusive Dchan: 0
> ChanSel: As indicated in following octets
> Ext: 1 DS1 Identifier: 1
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 1 Type: CPE]
違いはかなり明白です。libpriは完全に無償のDS1識別子オクテットで応答します。 DS1 IDは、複数のリンクを使用するシステムで使用される特定のPRIスパンの識別子です。libpriとCiscoルータの間にはT1スパンが1つしかないため、ここではまったく必要ありません。
これはCiscoファームウェアのバグのようです-DS1識別子を受け入れるべきではない理由はありません-それはオプションですが、標準で許可されています。もちろん、DS1識別子がどういうわけか間違っていない限り-私はそれを調査していません。
Libpriにボールをプレーさせるために必要なハックは、transmit_channel_idのワンライナーです。 DS1識別子であるオクテット3.1の送信を抑制するだけです。このパッチはそれを行います：
--- libpri-1.4.14/q931.c.org 2013-04-16 15:22:24.910001979 -0400
+++ libpri-1.4.14/q931.c 2013-04-16 15:22:49.454001959 -0400
@@ -1441,7 +1441,7 @@
return 0;
}
- if (!ctrl->bri && (((ctrl->switchtype != PRI_SWITCH_QSIG) && (call->ds1no > 0)) || call->ds1explicit)) {
+ if (0 && !ctrl->bri && (((ctrl->switchtype != PRI_SWITCH_QSIG) && (call->ds1no > 0)) || call->ds1explicit)) {
/* We are specifying the interface. Octet 3.1 */
ie->data[pos++] |= 0x40;
ie->data[pos++] = 0x80 | call->ds1no;
これは、libpriに含めることを目的とした恒久的な修正ではなく、適切に修正するためにlibpriにさまざまな調整を加える必要がある一時的なハックにすぎないことを付け加えておく必要があります。