Eu tenho um switch telefônico Asterisk 1.8 com uma placa Digium T1. Ele funciona usando 5ESS PRI através de nossa operadora de telefonia atual sem problemas. No entanto, estamos pensando em mudar para o serviço de fibra da Time Warner (não para a TWTelecom) e então ele falha devido a erros de protocolo ISDN.
O serviço deles é essencialmente VOIP, que eles não permitem que você toque diretamente, apesar de funcionar bem com o Asterisk, eu sei - eu tentei. Em vez disso, eles o expõem usando um roteador Cisco 2430 e a única opção suportada é fornecer algum tipo de interface T1. PRI é a opção mais sensata, então. Assim que transferimos o plugue do ponto de demarcação T1 de nossa operadora de telefonia existente para o roteador Cisco, nenhuma chamada é realizada - seja de saída ou de entrada.
Ao ativar a depuração pri intensiva, é aparente que as coisas quebram no primeiro pacote que a libpri envia - seja uma chamada recebida ou efetuada. Aqui está um exemplo para a chamada recebida – os três primeiros pacotes. O roteador Cisco vomita em algo que a libpri está enviando. A questão é: o quê e como consertar.
O roteador Cisco executa firmware c2430-ik9o3s-mz.124-15.T9.bin- aparentemente esse é o padrão corporativo da TWC e eles não podem alterá-lo.
< 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)
Responder1
Causa Dados? Causa Dados!
libpri não é muito inteligente ao indicar o que significam os dados de causa no elemento de informação de causa (IE) - na verdade, a partir de 1.4.13, ele lida apenas com dois casos em cem dados emQ.850! Felizmente, não são apenas alguns dados de diagnóstico proprietários aleatórios.
Referindo-se aQ.850 Uso de causa e localização ..., Tabela 1, precisamos verificar quais diagnósticos estão presentes para a Causa 100Conteúdo do elemento de informação inválido. Vejam só, é oidentificador(es) de elemento de informação! Portanto, o IE 0x18 (24) da mensagem Call Proceeding enviada pela libpri era problemático. Acontece que IE 0x18 é o elemento Channel ID. Então pelo menos sabemos que o problema está nesse elemento específico. Para referência, aqui está o Cause IE que recebemos da Cisco:
< [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)
Identificação de Canal IE – Para Identificar ou Não
Agora que reduzimos a um IE, referindo-se aQ.931, 4.5.13 Identificação de canal [IE], notamos que todo o elemento é opcional ao responder a uma configuração de chamada se, como é o caso aqui, o equipamento do usuário quiser simplesmente utilizar o único canal que foi explicitamente solicitado pela rede ( aqui: roteador Cisco).
Infelizmente, a API interna da libpri para enviar a mensagem de procedimento de chamada, q931_call_proceedingemq931.c, realmente não facilita o envio de um ID de canal completo, IE. Na verdade, o libpri struct q931_callnão retém o ID de canal explícito recebido mais recentemente, portanto não há como decidir se enviar um ID de canal IE é apropriado ou não. Caramba, é um erro que call_proceeding_ies[]contém Q931_CHANNEL_IDENT- a mensagem de andamento da chamada nem sempre requer este IE.
Portanto, uma solução seria simplesmente não enviar o ID do canal.
Mas o queéO problema interno?
Infelizmente, podemos tentar nos aprofundar e verificar o que no ID do canal do IE perturbou o firmware da Cisco.
Vamos comparar o ID do canal IE recebido da Cisco e enviado de volta em resposta:
< [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]
A diferença é bastante óbvia: a libpri responde com um octeto de identificador DS1 totalmente gratuito. O Identificador DS1 é um identificador de um intervalo PRI específico para ser usado em sistemas que usam vários links. Isso não é necessário aqui, pois há apenas um intervalo T1 entre o libpri e o roteador Cisco.
Este parece ser um bug no firmware da Cisco - não há razão para que ele não aceite o identificador DS1 - é opcional, mas permitido pelo padrão. A menos, é claro, que o identificador DS1 esteja de alguma forma errado - eu não investiguei isso.
O hack necessário para fazer o libpri jogar bola é uma linha única em transmit_channel_id. Tudo o que precisamos fazer é suprimir a transmissão do octeto 3.1, o identificador DS1. Este patch faz isso:
--- 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;
Deve-se acrescentar que esta não é de forma alguma uma correção permanente destinada a ser incluída na libpri, apenas um hack temporário que exigiria alguns ajustes mais amplos na libpri para ser corrigido corretamente.