摘要

  • RFC 2127 把物理 ISDN 接入、D 信道的 LAPD 与网络层实体、每条 B 信道以及上层接口分别建成 ifTable 记录，再由 ifStack 表示层间关系；这是一幅本地代理声明的拓扑，不是端到端电路证明。
  • 一通超信道呼叫可以同时使用多条 B 信道，但在信令统计中仍只算一次。相关承载记录会复制同一组呼叫字段，因此行数既不等于呼叫数，也不能证明可用总容量。
  • 规范用删除本地 ifStack 绑定来表达断开操作。该动作本身不能证明远端已释放、计费已结清或应用已经得到预期结果。

先看一个看似矛盾的账面：四条 B 信道都处于活动状态，四行记录里的对端地址、建立时间和计费单位完全相同；D 信道的呼叫统计却只增加了一次。这里没有数据冲突。按照 RFC 2127，这正是一通超信道呼叫应有的样子。

1997 年 3 月发布的这份规范没有把 ISDN 接口压成一个总状态。一个基本速率或基群速率接入之上，既有承担信令的 D 信道，也有传送业务的多条 B 信道；D 信道又区分 LAPD 数据链路实体和网络层信令实体；PPP 等封装位于更高一层。规范为这些组件分别建立接口身份，再用 ifStack 说明谁运行在谁之上。

行数要跟问题一起数

isdnBearerTable 的每一行只描述一条 B 信道。它的运行状态区分空闲、正在发起呼叫、正在验证来话和已经活动。这个粒度适合回答“哪条承载信道被占用”，却不能单独回答“端到端业务是否可用”。

RFC 1573 给出了通用的 Interfaces MIB 分层思路：每个子层对应 ifTable 中的概念行，ifStackTable 保存高层与低层的关系。RFC 2127 把这套图应用到 ISDN。图中的边由本地代理报告，它可以准确反映实现所认定的连接关系，但不会自动见证远端交换机、对端设备或有效载荷。

规范还把通用拨号控制交给必需的 RFC 2128。对端配置、活动呼叫与呼叫历史属于 Dial Control MIB；ISDN 的物理、承载和信令细节属于 RFC 2127。两份规范相互关联，却没有假装一条记录拥有所有语义。

超信道打破了“一行一次”的直觉

多速率呼叫需要一层封装同时连接多条 B 信道。实现可以引入 DS0Bundle，也可以建立多条 ifStack 关系：高层索引相同，低层索引各不相同。采用哪一种方式由实现者决定。

属于同一超信道呼叫的承载行，会共享对端地址与子地址、呼叫方向、信息类型、多速率标志、建立与接通时间、计费单位等字段。但 isdnSignalingStatsTable 无论涉及多少条 B 信道，都把它记作一通呼叫。

因此，四行承载记录不能推出四通呼叫；一通呼叫也不能推出只占一条信道；四条已分配信道更不能证明四份容量都向应用交付成功。信令计数、资源分配和有效吞吐各有自己的分母。

1999 年的 RFC 2494 后来正式定义了 DS0 与 DS0Bundle MIB。它可用于理解分组方案，但不能倒推所有 1997 年设备都采用了相同实现。

断开是一项本地拓扑变更

RFC 2127 在 B 信道组的定义中写明：要断开活动呼叫，应删除把上层接口与 B 信道接口绑定起来的 ifStack 条目。这不是模糊的“结束”标签，而是对本地管理图执行的一项明确动作。

动作明确，证明范围也就明确。删除成功可以说明本地代理接受了拓扑变更；它没有同时证明远端已经清除呼叫、释放消息全部完成、计费系统关闭账目、排队数据消失，或应用按预期处理了中断。把一次本地写操作升级成全链路结论，会重新混合规范刚刚分开的层。

字段保留了“当前或上一次”

对端地址描述的是当前呼叫或上一次呼叫。其格式可能取决于交换机或 PBX，规范明确允许实现相关，也允许在不可得时留空。一个非空字符串并不自动等于最新、规范化、已认证的身份。

计费单位同样属于当前或上一次连接。对于来话，或交换机没有提供计费信息的情况，该值为零。零在这里可能表示没有报告，而不是已核实的零成本。信令统计中的累计计费单位又有更窄的范围，只统计适用于本地接口的主叫或反向计费。

拨号 B 信道与租用 B 信道的控制权也不同。前者受关联信令信道控制，后者没有信令控制；完全用于租线的 PRI 甚至可以只由 DS1/E1 MIB 处理，而不需要 ISDN 专用信息。缺少信令记录可能是设计事实，不是故障结论。

语音、3.1 kHz 音频和旧 7 kHz 音频的承载能力被规范称为信令手段。网络在承诺的服务边界内决定具体处理方式。标记为语音的连接可以经过压缩等处理，仍满足通话质量，却不保证调制解调器可用。标签不是传输路径的完整陈述。

规范留下的空白不能被填成保证

RFC Editor 记录与 IETF 文档历史显示，这是 ISDN MIB 工作组产出的 Proposed Standard。勘误记录包含一项已确认的符合性对象标识符修正和一项被拒绝的报告；它们没有提供部署规模或产品正确性的证据。

安全章节只有一个结论：本文不讨论安全问题。这句话既不是认证保证，也不是机密性、写入授权或恶意管理者防护的替代品。空白必须保持为空白。

RFC 2127 的历史价值不在于提供了一个更漂亮的总状态，而在于它让管理者看见：一个连接需要多层记录，多条记录也可能只属于一次呼叫。真正的纪律，是让每一层只证明它能够证明的事情。

来源与证据边界

上述官方文档证明规范结构和对象语义，不证明某款产品的部署率、一次真实呼叫或账单准确性。Lu Heng 后来的运行代码优先、最小初始规范与现实层文章在这里只作为推理纪律：规范、本地可执行状态和运营结果属于不同证据层。它们不是 1997 年 RFC 作者意图的证据。