Digium T1 카드가 있는 Asterisk 1.8 전화 스위치가 있습니다. 현재 전화 제공업체를 통해 5ESS PRI를 사용하여 문제 없이 실행됩니다. 그러나 우리는 Time Warner의 광섬유 서비스(TWTelecom 아님)로 전환하려고 고려 중이며 ISDN 프로토콜 오류로 인해 실패합니다.
그들의 서비스는 본질적으로 Asterisk와 잘 작동함에도 불구하고 사용자가 직접 만지는 것을 허용하지 않는 VOIP입니다. 나도 알고 있습니다. 시도해 보았습니다. 대신 Cisco 2430 라우터를 사용하여 이를 노출하며 지원되는 유일한 옵션은 일종의 T1 인터페이스를 제공하는 것입니다. 그렇다면 PRI가 가장 합리적인 선택입니다. 기존 전화 제공업체의 T1 경계 지점에서 Cisco 라우터로 플러그를 전송하자마자 아웃바운드 또는 인바운드 통화가 통과되지 않습니다.
집중적인 pri 디버깅을 활성화하면 libpri가 보내는 첫 번째 패킷에서 문제가 발생하는 것이 분명합니다. 즉, 그것이 수신되는 발신 호출인지 여부와 관계가 없습니다. 다음은 수신 호출(처음 세 개의 패킷)에 대한 예입니다. Cisco 라우터는 libpri가 보내는 내용을 보고 짖습니다. 문제는 무엇을, 어떻게 해결해야 하는가입니다.
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)
답변1
원인 데이터? 원인 데이터!
libpri는 원인 정보 요소(IE)의 원인 데이터가 무엇을 의미하는지 표시하는 데 그리 영리하지 않습니다. 실제로 1.4.13부터 libpri는 100개 사례 중 2개 사례만 처리합니다.Q.850! 다행히도 이는 단지 임의의 독점 진단 데이터가 아닙니다.
참조Q.850 원인과 위치의 활용..., 표 1, 원인 100에 대해 어떤 진단이 있는지 확인해야 합니다.잘못된 정보 요소 콘텐츠. 보라, 바로 이것이다정보 요소 식별자! 그래서 libpri에서 보낸 Call Proceeding 메시지의 IE 0x18(24)이 문제가 되었습니다. 공교롭게도 IE 0x18은 채널 ID 요소입니다. 따라서 적어도 우리는 문제가 특정 요소에 있다는 것을 알고 있습니다. 참고로 Cisco로부터 받은 Cause 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과 같습니다 .q931.c, 완전한 채널 ID IE를 보내지 않는 것이 실제로 쉽지는 않습니다. 실제로 libpri는 struct q931_call가장 최근에 수신된 명시적인 채널 ID를 유지하지 않으므로 채널 ID IE를 보내는 것이 적절한지 여부를 결정할 방법이 없습니다. call_proceeding_ies[]도대체 오류입니다 Q931_CHANNEL_IDENT. 통화 진행 메시지에 항상 이 IE가 필요한 것은 아닙니다.
따라서 한 가지 해결 방법은 단순히 채널 ID를 보내지 않는 것입니다.
근데 뭐~이다내면의 문제?
아쉽게도 우리는 채널 ID IE에서 Cisco 펌웨어를 혼란스럽게 한 것이 무엇인지 더 깊이 파고들어 확인해 볼 수 있습니다.
Cisco로부터 수신된 채널 ID IE와 응답으로 다시 전송된 채널 ID를 비교해 보겠습니다.
< [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 식별자는 다중 링크를 사용하는 시스템에서 사용되는 특정 PRI 범위의 식별자입니다. libpri와 Cisco 라우터 사이에 T1 범위가 하나만 있기 때문에 여기서는 전혀 필요하지 않습니다.
이는 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에 대한 광범위한 조정이 필요한 임시 해킹일 뿐이라는 점을 추가해야 합니다.