O Asterisk não pode fazer nem receber chamadas através de uma interface PRI T1 para um roteador Cisco 2430

Question

Eu tenho um comutador de telefone Asterisk 1.8 com uma placa Digium T1. Ele é executado usando 5ESS PRI através do nosso provedor de telefone atual sem nenhum problema. No entanto, estamos pensando em mudar para o serviço de fibra da Time Warner (não o TWTelecom) e, em seguida, ele falha com erros de protocolo ISDN.

O serviço deles é essencialmente VOIP que eles não vão deixar você tocar 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 para fornecer uma interface T1 de algum tipo. PRI é a opção mais sensata, então. Assim que transferimos o plugue do ponto de demarcação T1 do nosso provedor 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 o libpri envia - seja uma chamada de saída. Aqui está um exemplo para a chamada recebida - os três primeiros pacotes. O roteador Cisco barfs em algo que o libpri está enviando. A questão é: o que e como consertar isso.

O roteador Cisco executa o firmware c2430-ik9o3s-mz.124-15.T9.bin - que, aparentemente, é 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)

    

Answer 1

Cause Data? Cause dados!

O libpri não é muito inteligente em indicar quais são os dados de causa no elemento de informação de causa (IE) - na verdade, a partir de 1.4.13, ele só lida com dois casos de cem dados em Q.850 ! Felizmente, não são apenas alguns dados diagnósticos proprietários aleatórios.

Referindo-se a Q.850 Uso de causa e localização ... , Tabela 1, precisamos verificar quais diagnósticos estão presentes para a causa 100 Conteúdo do elemento de informação inválido . E eis que é o identificador (es) do elemento de informação ! Então, IE 0x18 (24) da mensagem de Chamada Proceeding enviada pela libpri foi problemática. Por acaso, o IE 0x18 é o elemento do ID do canal. Então, pelo menos, sabemos que o problema está naquele elemento em particular. Para referência, aqui está a causa 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 do Canal IE - Para Identificar ou Não

Agora que o restringimos a um IE, consulte Q.931 4.5.13 Identificação de canal [IE], notamos que o elemento inteiro é opcional ao responder a uma configuração de chamada se, como é o caso aqui, o equipamento do usuário simplesmente deseja usar o único canal explicitamente solicitado pela rede ( aqui: roteador Cisco).

Ai, a API interna da libpri para enviar a mensagem de continuação da chamada, q931_call_proceeding em q931.c , não facilita muito o envio de um ID de canal completo. Na verdade, o struct q931_call do libpri não retém o código de canal explícito mais recentemente recebido, por isso não há como decidir se o envio de um ID do canal IE é apropriado ou não. Heck, é um erro que call_proceeding_ies[] contém Q931_CHANNEL_IDENT - a mensagem de solicitação de chamada nem sempre requer este IE.

Então, uma correção seria simplesmente não enviar o ID do canal.

Mas o que é O Problema Dentro?

Infelizmente, podemos tentar aprofundar e verificar o que, no ID do canal, o IE alterou o firmware da Cisco.

Vamos comparar o ID do canal IE como recebido da Cisco e enviado novamente 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: o libpri responde com um octeto Identificador DS1 inteiramente gratuito. O Identificador DS1 é um identificador de um intervalo PRI específico a ser usado em sistemas que usam vários links. Isso não é necessário aqui, pois existe apenas um intervalo T1 entre o libpri e o roteador Cisco.

Isso parece ser um bug no firmware da Cisco - não há motivo para não aceitar o Identificador DS1 - é opcional, mas permitido pelo padrão. A menos que, é claro, o Identificador DS1 esteja de alguma forma errado - eu não investiguei isso.

O hack necessário para obter a libpri para jogar bola é um one-liner 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 isso não é de forma alguma uma correção permanente para inclusão na libpri, apenas um hack temporário que exigiria alguns ajustes mais amplos para o libpri corrigir adequadamente.