H323是一套应用在VoIP和视频会议领域的通信协议栈，由ITU-T定义，涉及H.225呼叫信令、H.245控制信道以及RTP/RTCP媒体传输等多个层次。在实际项目开发中，我们经常需要对接支持H323的硬件终端或MCU设备，但真实设备数量有限、价格昂贵，且不方便随时搭建测试环境。这时候，用Node.js写一个H323 Mock服务就非常实用了。本文会从协议结构入手，逐步实现信令交互模拟，并结合Image图片数据模拟视频流，最终形成一个可以用于自动化测试的模拟器。
H323协议栈结构与Mock需要模拟的内容
在动手写代码之前，需要先弄清楚H323到底由哪些部分组成。H323并非单一协议，而是一个协议簇：H.225.0负责呼叫信令（基于Q.931）和RAS注册（基于UDP）；H.245负责能力协商、主从判定、逻辑通道的打开与关闭；真正的音视频数据则通过RTP协议在协商好的逻辑通道上传输。一次完整的H323呼叫流程大致是：终端通过RAS向网守（Gatekeeper）注册，然后通过Q.931的Setup、CallProceeding、Alerting、Connect消息建立呼叫，接着在H.245通道中交换能力集并打开逻辑通道，最后才进入媒体流传输阶段。
对于Mock服务来说，并不需要完整实现所有细节。测试场景通常只需要模拟到两个层面：第一层是信令交互，也就是能正确响应或发起Setup、Connect等Q.931消息，让对方设备认为呼叫已经建立；第二层是媒体层面，即在H.245协商完成后，通过RTP推送伪造的媒体数据。如果测试目标是媒体处理逻辑，甚至可以跳过信令，直接对RTP端口灌数据，这是最常见也最省事的Mock策略。
Node.js在这类场景下有天然优势：dgram模块处理UDP非常方便，net模块处理TCP信令通道也很简洁，配合Buffer操作可以灵活构造二进制报文。下面我们从Q.931信令模拟开始。
用Node.js模拟H.225与Q.931信令交互
Q.931报文走TCP通道（默认端口1720），报文格式为：一个字节的协议鉴别符（0x08）、两个字节CRV（呼叫参考值）、一个字节消息类型，后面跟若干信息单元（Information Element）。Mock服务需要至少响应Setup消息，并回送Connect，让对方设备认为呼叫成功建立。
下面是一个简化版的信令监听实现，重点是报文的解析思路和Connect消息的构造：
const net = require('net');
// Q.931消息类型常量
const SETUP = 0x05;
const CONNECT = 0x07;
const RELEASE_COMPLETE = 0x5A;
const server = net.createServer((socket) => {
console.log('对端已连接:', socket.remoteAddress);
socket.on('data', (buf) => {
// TPKT头4字节 + Q.931报文
const msgType = buf[4 + 2]; // 跳过TPKT 4字节，再跳过协议鉴别符和CRV
const crv = buf.readUInt16BE(5); // 读取呼叫参考值
if (msgType === SETUP) {
console.log('收到Setup消息，CRV =', crv.toString(16));
const connect = buildConnect(crv);
socket.write(connect);
}
});
});
// 构造TPKT + Q.931 Connect报文
function buildConnect(crv) {
const body = Buffer.from([
0x08, // 协议鉴别符
(crv >> 8) & 0xFF, // CRV高字节
crv & 0xFF, // CRV低字节
CONNECT // 消息类型
]);
const tpkt = Buffer.from([0x03, 0x00, 0x00, 0x00]);
tpkt.writeUInt16BE(body.length + 4, 2);
return Buffer.concat([tpkt, body]);
}
server.listen(1720, () => {
console.log('H323信令Mock服务监听在 1720 端口');
});这段代码省略了H.225的ASN.1 PER解码细节。真实场景中Setup消息里携带的User-User信息单元包含复杂的ASN.1结构，如果需要精确解析，建议引入asn1.js或直接用Wireshark抓包对照报文位序。对于大多数Mock场景，我们只需要提取CRV并回应Connect即可让呼叫进入已连接状态。如果对端设备在Connect之后会主动发起H.245控制通道，还需要监听一个动态TCP端口来处理H.245消息，主要是能力交换（TCS）和打开逻辑通道（OLC）消息。
基于Image图片构造RTP媒体流模拟
信令打通后，剩下的就是媒体模拟。这里介绍一种实用的技巧：用静态Image图片作为视频帧源，构造RTP包推送出去。做法是把一张图片编码为一帧视频数据（比如JPEG或H.264裸流），然后按固定时间间隔切成RTP包发送。接收端解码时就能看到这张图片，非常适合验证媒体链路是否通畅。
下面演示如何用JPEG图片生成RTP流，采用RFC 2435定义的JPEG载荷格式：
const dgram = require('dgram');
const fs = require('fs');
const socket = dgram.createSocket('udp4');
// 读取一张JPEG图片作为视频帧
const jpeg = fs.readFileSync('test.jpg');
const ssrc = 123456;
let seq = 0;
const timestampStep = 3600; // 30fps下每帧时间戳增量
function buildRtpHeader(seqNum, ts, marker) {
const header = Buffer.alloc(12);
header[0] = 0x80; // V=2
header[1] = (26 << 0) | 0; // PT=26(JPEG)，Marker位
header.writeUInt16BE(seqNum & 0xFFFF, 2);
header.writeUInt32BE(ts, 4);
header.writeUInt32BE(ssrc, 8);
return header;
}
// RFC2435 JPEG载荷：主坐标类型 + 量化表 + JPEG数据分片
const payload = Buffer.concat([
Buffer.from([0x00, 0x00, 0x00, 0x00]), // 类型0，256x256
Buffer.from([0x00, 0x21]), // 量化表
jpeg
]);
const target = { address: '127.0.0.1', port: 5004 };
setInterval(() => {
seq++;
const ts = seq * timestampStep;
const header = buildRtpHeader(seq, ts, 1);
const packet = Buffer.concat([header, payload]);
socket.send(packet, target.port, target.address);
console.log(`已发送RTP包 seq=${seq}`);
}, 33); // 约30fps这段代码每33毫秒发送一个RTP包，载荷就是完整的JPEG图片数据。接收端可以用ffplay或VLC打开rtp://@:5004验证，正常情况下画面会显示这张图片。如果要更接近真实视频，可以准备一组图片轮播，或者用ffmpeg先把图片转成H.264裸流再按RFC 6184打包，效果会更接近生产环境。需要注意的是，RTP包载荷超过MTU时要做分片处理，JPEG类型的最后一个分片要置Marker位，否则解码端无法判断帧边界。
常见调试坑点与验证方法
Mock H323最容易踩的坑有几个。第一个是TPKT头处理：Q.931走TCP时每个报文前面有4字节的TPKT头，版本固定0x03，长度占两个字节。如果忘了剥掉这4个字节，解析出来的消息类型必然是错的。第二个是字节序问题，CRV、长度字段都是网络字节序，Node.js的Buffer默认方法要选对readUInt16BE还是readUInt16LE，搞反了会导致对端直接丢弃报文。第三个是RTP时间戳单位，视频流的时钟频率通常是90000Hz，时间戳增量算错会导致播放端画面卡顿或跳帧。
验证方面，强烈建议配合Wireshark使用。它自带H.225和H.245的解码器，能直接把Q.931报文解析成可读的树状结构，比肉眼分析十六进制高效得多。RTP流可以用Wireshark的Telephony菜单里的RTP Stream功能查看丢包率和抖动。另外，做自动化测试时可以把Mock服务封装成可编程接口，暴露启动、停止、注入异常报文的方法，结合jest或mocha就能实现信令流程的回归测试。
总结一下，用Node.js实现H323 Mock的核心思路是分层模拟：信令层只需正确响应Q.931关键消息，媒体层用图片数据构造RTP载荷即可完成视频流伪造。这种方案成本极低，却能在没有真实终端的情况下覆盖大部分联调场景，对于需要频繁回归的视频会议类项目来说，是提升测试效率的实用手段。