Resumo

  • A RFC 2127 criou registros ifTable separados para o acesso físico, as camadas do canal D, cada canal B e a interface superior; as relações ifStack declaravam a topologia local, não a continuidade fim a fim.
  • Um hipercanal podia ocupar vários canais B e ainda contar como uma só chamada de sinalização. As linhas portadoras repetiam os mesmos valores, de modo que contar linhas não revelava chamadas nem capacidade entregue.
  • A retirada da ligação em ifStack era a ação de desconexão prevista. Ela não provava sozinha liberação remota, encerramento de cobrança ou resultado na aplicação.

Comece por duas portas idênticas. Uma é discada e controlada por um canal de sinalização. A outra é dedicada e não possui controle de sinalização. Se o sistema de gestão exigir o mesmo recibo das duas, ele transformará uma diferença de autoridade em falso alarme.

A RFC 2127, publicada em março de 1997, fez o contrário. Separou o acesso físico Basic Rate ou Primary Rate, o canal D, as entidades LAPD e de rede, cada canal B e a encapsulação de nível superior. Cada componente recebia uma linha conceitual em ifTable; ifStack informava qual camada operava sobre qual.

A porta não era a chamada

Uma linha em isdnBearerTable descrevia um único canal B. Seu estado podia indicar ocioso, tentativa de saída, validação de entrada ou chamada ativa. Isso permitia observar a alocação do portador sem confundi-la com o acesso físico completo ou com a sessão da aplicação.

O modelo geral vinha da RFC 1573, que usava uma linha por subcamada e uma tabela de pilha para os vínculos. O grafo dizia o que o agente local afirmava estar conectado. Ele não incluía uma testemunha independente do comutador remoto, do destino ou dos bytes úteis.

A RFC 2128 mantinha configuração de pares, chamadas ativas e histórico de acesso discado em um MIB genérico. A separação importava: o objeto que configurava um vizinho, o canal que carregava a ligação e o registro histórico eram evidências relacionadas, mas de custódias diferentes.

O hipercanal mudou o sentido da contagem

Para uma chamada multicanal, havia uma interface de encapsulação sobre vários canais B. O fabricante podia usar um DS0Bundle ou várias linhas ifStack com o mesmo índice superior e índices inferiores distintos.

Cada linha de portador associada repetia endereço e subendereço do par, origem, tipo de informação, indicador multirate, horários de setup e conexão e unidades cobradas. Mesmo assim, a tabela de estatísticas de sinalização registrava uma única chamada, independentemente da quantidade de canais B.

Logo, três linhas podiam representar uma chamada, e uma chamada podia consumir três canais. Nenhuma dessas cifras dizia, sem medição adicional, quanto tráfego útil atravessou o circuito. Alocação, sinalização e entrega tinham denominadores diferentes.

A RFC 2494 formalizou os MIBs DS0 e DS0Bundle em 1999. É contexto posterior para a alternativa de agrupamento, não prova de implementação universal em 1997.

Desconectar era alterar o grafo

O próprio bloco do grupo de canais B explicava a operação: para desconectar, remover a entrada ifStack que vinculava a interface superior ao canal B. Esse era um ato administrativo verificável dentro do agente.

Essa confirmação, por si só, só comprovava a alteração local. A remoção não assegurava que a outra ponta tivesse liberado, que todos os sinais de encerramento tivessem sido processados, que a cobrança tivesse fechado ou que a aplicação tivesse descartado filas. Tratar a aceitação da escrita como conclusão global apagaria as fronteiras que o MIB havia criado.

Campos que carregavam passado e ausência

O endereço do par valia para a chamada atual ou para a última. Seu formato podia depender do switch ou PBX e ficar vazio quando indisponível. Não era automaticamente atual, normalizado ou autenticado.

As unidades cobradas também pertenciam à ligação atual ou anterior. O valor era zero em chamadas recebidas ou quando o switch não fornecia dados de tarifa. Zero, portanto, podia representar ausência de informação — não gratuidade comprovada.

No canal dedicado, a ausência de sinalização era ainda mais explícita. Uma PRI totalmente dedicada podia ser descrita apenas pelo MIB DS1/E1, sem dados específicos de ISDN. Já num canal discado, o controle vinha da entidade associada. O mesmo campo ausente tinha significados diferentes conforme o modo do recurso.

As categorias speech, áudio de 3,1 kHz e áudio de 7 kHz eram recursos de sinalização. A rede decidia o tratamento compatível com a capacidade pedida. Um canal de voz podia preservar a qualidade da fala e ainda assim não sustentar um modem. O rótulo delimitava uma promessa, não narrava a execução.

Um silêncio que deve continuar sendo silêncio

O registro oficial e o Datatracker do IETF mostram um Proposed Standard do grupo ISDN MIB. O registro de erratas traz uma correção técnica verificada no identificador de conformidade e uma proposta rejeitada. Isso não valida produtos, chamadas ou tarifas.

A seção de segurança limitava-se a dizer que segurança não era discutida. O texto não estabeleceu autenticação do gerente, confidencialidade dos dados ou proteção contra mudanças indevidas. Uma lacuna documental não pode ser transformada em garantia.

O valor histórico da RFC 2127 está justamente em não oferecer um estado total. Ela dividiu a realidade gerenciável em camadas suficientes para que o operador pudesse perguntar qual recibo estava vendo — e qual ainda faltava.

Fontes e limites

Os documentos oficiais sustentam a semântica de 1997, não adoção comercial ou um incidente observado. Os textos posteriores de Lu Heng sobre primazia do código em execução, especificação inicial mínima e camadas da realidade entram apenas como disciplina de inferência: especificação, estado local executável e resultado operacional não são equivalentes. Eles não demonstram a intenção dos autores da RFC.