SIP与传统PSTN的互通网关：解决信令转换与媒体适配的技术难点

SIP这玩意儿，现在搞通信的多少都听过。但很多人一提到PSTN就头大，觉得那是上世纪的老古董。其实咱们现在打电话、接验证码，背后经常是SIP和PSTN在互相“翻译”。这个翻译的活儿，就是由一个叫“互通网关”的设备来干的。你别把它想得太玄乎，它就是个“翻译官”，一边听着SIP的普通话，一边说着PSTN的方言。今天咱们就聊聊这个翻译官最难搞的两件事：信令转换和媒体适配。

一、先搞懂两个“世界”

1.1 两个“世界”的方言

SIP世界，是纯IP的世界，一切都是“会话”。它用INVITE、ACK、BYE这种像HTTP一样的文本消息来建立和管理通话。而PSTN世界，是传统电话网，用的是ISDN Q.931、SS7这些老牌协议。PSTN里的语音也不是走IP包，而是走64kbps的时隙，用的编码通常是G.711A（欧洲标准）或G.711U（北美/日本标准）。说出来你可能不信，今天很多SIP音视频通话，最终落到PSTN上，音质也就是个“能听”的水平，就是因为要迁就这个老古董。

说白了，SIP世界里的一个“电话号”，在PSTN世界里可能对应一个中继、一条物理线路。两边要对上话，必须把“邀请”翻译成“摘机”，把“忙”翻译成“Q.931原因值#17”。这个翻译过程，一步错，电话就断了。而且你没法让PSTN去学SIP，因为它的软硬件都是几十年前定死的，所以只能让网关来受这份罪。

1.2 谁需要这个“翻译官”？

很多企业呼叫中心、云PBX，想接普通的电话线和手机号，就得通过互通网关。还有运营商内部，IP网和程控交换机之间，也需要。甚至你用App打电话到座机，中间也可能经过了这种网关。它不显眼，但无处不在。尤其这些年“上云”的呼声很高，但PSTN线路又不能直接插到云服务器上，于是网关就成了传统电信世界和互联网世界之间的一座独木桥。这座桥如果搭不好，两边的人就只能干瞪眼。

二、信令转换：最难啃的骨头

2.1 从ISDN的Q.931到SIP的INVITE

信令转换，第一个难点就是消息格式完全不一样。Q.931是一套二进制编码的消息，比如SETUP消息里有“承载能力”、“被叫号码”等字段，一个比特错了都不行。SIP则是纯文本，用SIP头域表示。网关要做的事，就是把Q.931里的“被叫号码”拽出来，填到SIP的Request-Line或To头里。听起来简单？实际上这里面有大量让你崩溃的细节。

问题不止于此。Q.931里有“消息类型”和“状态”，SIP里有“方法”和“状态码”。比如Q.931的ALERTING（振铃）要翻译成SIP的180 Ringing，Q.931的CONNECT对应SIP的200 OK。这种一对一的映射还算简单，但遇到复杂流程，比如呼叫转接、三方通话，映射关系就乱了。更别提有些老交换机实现得很“随性”，发出的Q.931字段缺胳膊少腿，网关就得学会“猜”。猜错了，呼叫就静默失败。

2.2 状态机映射的坑

更麻烦的是两边的“状态机”不一样。SIP是请求-响应模型，PSTN是电路状态模型。网关得维护两张状态表，一边是SIP事务，一边是ISDN呼叫。任何一边的状态跳变，都得触发对面进行相应动作。比如SIP侧收到BYE，网关就得给PSTN侧发DISCONNECT，并等待RELEASE，最后发送RELEASE COMPLETE。如果时序不对，就可能卡住呼叫。有些细心的朋友会发现，网关日志里经常出现“等待RELEASE”这种状态，一挂就是几十秒，就是状态机没对上。

还有一个容易忽视的点：两边的定时器机制不一样。Q.931释放流程有T305、T308定时器，SIP也有Timer B、Timer F。如果网关在收到RELEASE COMPLETE之前就把SIP事务清了，对端后面发来的消息就成了“孤儿”。反过来，SIP侧的重传请求可能被网关当成新事务处理，导致重复建链。解决这种问题，没有魔法，就是老老实实把状态转移图画清楚，每一个边缘情况都测一遍。

来看一个简单的Python模拟，把Q.931的SETUP转成SIP INVITE：

# 技术栈：Python 3.x，用于演示信令映射逻辑

from dataclasses import dataclass

# 定义一个简化版Q931消息
@dataclass
class Q931Message:
    message_type: str  # 例如 "SETUP"
    called_number: str # 被叫号码
    calling_number: str # 主叫号码
    bearer_capability: str # 承载能力

# 定义一个简化版SIP请求
@dataclass
class SIPRequest:
    method: str        # 方法名，例如 "INVITE"
    request_uri: str   # Request-Line中的URI
    from_header: str   # From头字段
    to_header: str     # To头字段
    content_type: str  # Content-Type 头

def q931_setup_to_sip_invite(q931: Q931Message, proxy_domain: str):
    """
    将Q931的SETUP消息转换为SIP的INVITE请求。
    注意：真实网关里还会处理定时器、重传、会话参数等。
    proxy_domain 是SIP代理域的域名或IP。
    """
    # 被叫号码需要转成SIP URI，这里的号码去掉了空格和连字符
    called = q931.called_number.replace(" ", "").replace("-", "")
    target_uri = f"sip:{called}@{proxy_domain}"
    
    # 主叫号码要放到From头里，顺便加个标签参数，用于对话标识
    caller = q931.calling_number.replace(" ", "")
    from_field = f"<sip:{caller}@{proxy_domain}>;tag=1a2b3c"
    
    # To头通常不需要标签，等对端返回响应时再补
    to_field = f"<sip:{called}@{proxy_domain}>"
    
    # 构造SIP请求对象
    req = SIPRequest(
        method="INVITE",
        request_uri=target_uri,
        from_header=from_field,
        to_header=to_field,
        content_type="application/sdp"
    )
    return req

# 模拟一个Q931 SETUP消息
q931_setup = Q931Message(
    message_type="SETUP",
    called_number="010-8888-6666",
    calling_number="010-5555-1234",
    bearer_capability="speech"
)

# 做一次转换
sip_invite = q931_setup_to_sip_invite(q931_setup, "192.168.1.10")

# 打印转换结果，方便观察
print(f"转换后的SIP请求：{sip_invite.method} {sip_invite.request_uri}")
print(f"From: {sip_invite.from_header}")
print(f"To: {sip_invite.to_header}")

这个示例虽然简单，但已经包含了最核心的号码映射。实际开发中，你还要处理号码前缀、国家码、转义字符等，那才是真正的“坑”。

2.3 号码格式和编码

另一个容易踩的坑是号码格式。PSTN侧号码可能带有区号、国际前缀，而SIP侧要求的是E.164格式或者带域名。比如PSTN给你一个“01088886666”，网关要决定是原样转发给SIP，还是转成“+861088886666”。这个规则每个运营商都不一样。你需要提供一个可配置的号码转换表，而不是写死逻辑。

还有编码问题。Q.931的被叫号码是BCD编码，一个字节装两个数字，SIP是ASCII文本。你得先做BCD到ASCII的转换。写代码时稍不注意，奇数长度号码就会出错。下面是一个BCD转数字串的示例：

# 技术栈：Python 3.x，演示BCD号码转E.164字符串

def bcd_to_number(bcd_bytes: bytes) -> str:
    """
    将BCD编码的号码转换为数字字符串。
    每个字节存储两个BCD数字，高4位是第一个数字，低4位是第二个数字。
    特殊值0xF表示结束或填充。
    """
    digits = []
    for byte in bcd_bytes:
        # 取出高4位和低4位
        high = (byte >> 4) & 0x0F
        low = byte & 0x0F
        # 高4位如果是0-9，就是数字
        if high < 10:
            digits.append(str(high))
        # 高4位如果是0xF，说明号码已经结束，直接退出
        if high == 0xF:
            break
        # 低4位同理
        if low < 10:
            digits.append(str(low))
        if low == 0xF:
            break
    # 拼接成字符串
    return "".join(digits)

# 测试：电话号码是123456，BCD编码就是0x12 0x34 0x56
bcd_data = bytes([0x12, 0x34, 0x56])
number = bcd_to_number(bcd_data)
print("BCD转出的号码: ", number)

# 进一步转成E.164格式（中国区号加86）
# 如果号码以0开头，说明是国内长途，去掉0再加国家码
if number.startswith("0"):
    e164 = "+86" + number[1:]
else:
    e164 = "+86" + number
print("E.164格式: ", e164)

这个函数看着简单，但很多生产环境的bug就出在这里。比如某些交换机在号码长度是偶数时，会在最后补上0xF；有些则直接补0x00。你必须在代码里兼容这两种风格。

2.4 SDP协商的映射

信令转换里还有一块经常被忽略：SDP协商。SIP消息的body里带着SDP，里面描述了IP地址、端口、音视频编码格式。而PSTN侧没有SDP，只有类似“承载能力”的字段。网关要自己“无中生有”地构造一个SDP，还要把PSTN的编码类型映射成SDP里的rtpmap。比如PSTN支持A-law，你就在SDP里写PCMA。反过来，SIP侧发过来的SDP如果带了Opus编码，你没法直接送到PSTN，必须在SDP协商时就“欺骗”对端，只让它选网关支持的PCMA/PCMU。

下面演示如何生成一段最简单的SDP：

# 技术栈：Python 3.x，演示根据PSTN承载能力生成SDP

def create_sdp_for_pstn(payload_type: int, sample_rate: int, channels: int) -> str:
    """
    根据PSTN侧协商好的编码参数生成一段SDP。
    payload_type: RTP负载类型，比如8表示PCMA，0表示PCMU
    sample_rate: 采样率，如8000
    channels: 声道数，通常为1
    """
    # 根据负载类型确定编码名称
    if payload_type == 8:
        encoding_name = "PCMA"
    elif payload_type == 0:
        encoding_name = "PCMU"
    else:
        encoding_name = "UNKNOWN"
    
    # 构造SDP文本，每一行都要以\r\n结尾
    sdp = (
        "v=0\r\n"
        "o=- 123456 2 IN IP4 192.168.1.10\r\n"
        "s=-\r\n"
        "c=IN IP4 192.168.1.10\r\n"
        f"m=audio 4000 RTP/AVP {payload_type}\r\n"
        f"a=rtpmap:{payload_type} {encoding_name}/{sample_rate}/{channels}\r\n"
        # 告诉对端建议的打包时长是20毫秒，减少小包数量
        "a=ptime:20\r\n"
    )
    return sdp

print("生成PCMA SDP:")
print(create_sdp_for_pstn(8, 8000, 1))

真实网关里，SDP生成还要处理带宽、加密参数、传真检测等。但核心思路就是你得先把PSTN的能力“翻译”成SIP能理解的媒体描述，否则SIP对端根本不知道往哪儿发语音。

三、媒体适配：让语音“听得懂”

3.1 编码转换：G.711A和G.711U

信令通了，语音也得通。PSTN侧几乎固定用G.711A或G.711U，而SIP侧通常用PCMU/PCMA，但也可以是G.729、Opus等等。如果两端编码不一致，网关就得干“翻译”的活。

G.711A和G.711U之间有一个标准转换表。很多人以为直接用公式算就行，但公式有取舍，查表才准确。为什么？因为A-law和mu-law的压缩曲线不同，一个用奇函数，一个用近似线性，没有简单的位运算能100%兼容。标准里给出的表是经过互操作验证的，你直接用就好。下面是一个简化版的转换函数，用Python模拟PCMA（A-law）负载转换成PCMU（mu-law）负载：

# 技术栈：Python 3.x，用于演示PCMA到PCMU的转换逻辑
# 注意：这里使用简化的对照表演示，实际应用需要完整256字节转换表。

# 为了演示，构造一个极简的A-law到mu-law映射表
# 真实场景中这个表有256个值，每个值对应一个A-law码字的mu-law码字
A2U_TABLE = list(range(256))  # 占位，实际上应该用标准转换表

def pcma_to_pcmu(pcma_payload: bytes) -> bytes:
    """
    将一段PCMA编码的RTP负载转换为PCMU编码的RTP负载。
    参数:
        pcma_payload: 来自RTP包的PCMA（A-law）数据，每个字节一个采样
    返回:
        对应的PCMU（mu-law）数据
    """
    # 创建输出字节数组，长度相同
    pcmu_payload = bytearray(len(pcma_payload))
    
    # 遍历每个PCMA字节，查表得到PCMU字节
    for i, a_byte in enumerate(pcma_payload):
        # 这里直接使用占位表做索引；真实网关会用国际标准ITU-T G.711表
        pcmu_payload[i] = A2U_TABLE[a_byte]
    
    # 返回不可变bytes对象，方便网络层发送
    return bytes(pcmu_payload)

# 模拟从RTP里抓到的10字节PCMA数据
sample_pcma = bytes([0xD5, 0x2A, 0x7F, 0x80, 0x00, 0x55, 0xAA, 0xFF, 0x12, 0x34])

# 转换
converted = pcma_to_pcmu(sample_pcma)

# 输出结果，方便调试验证
print("PCMA原始数据:", sample_pcma.hex())
print("PCMU转换数据:", converted.hex())

注意上面的A2U_TABLE是占位，实际项目里你需要从标准文档里把256个字节的表抄下来，或者用开源库。这种查表方式比公式快，也更容易验证。

3.2 回声消除和抖动缓冲

除了编码，媒体侧还有很多麻烦事。PSTN侧是传统电路，有回声。IP侧有网络抖动和丢包。网关必须在Jitter Buffer里缓存一定数量的语音包，抵消抖动，但缓存太大又会增加延迟。你会听到对方声音“慢半拍”，就是缓存太深了。

一个常见的做法是自适应抖动缓冲，根据网络状况动态调整缓存深度。下面是一个非常简化的示例，演示怎么基于RTP时间戳计算抖动并调节缓存：

# 技术栈：Python 3.x，用于演示自适应抖动缓冲的核心想法

from collections import deque

class JitterBuffer:
    """
    一个非常简化的自适应抖动缓冲示例。
    真实场景需要考虑语音帧大小、静音检测、时钟漂移等。
    """
    def __init__(self, initial_depth_ms: float, frame_ms: float = 20.0):
        self.frame_ms = frame_ms                # 每帧语音的时长（毫秒）
        self.buffer = deque()                    # 用双端队列缓存语音帧
        self.current_depth_ms = initial_depth_ms # 当前目标缓存深度（毫秒）
        self.inter_arrival_jitter_ms = 0.0       # 网络抖动估计（毫秒）

    def add_frame(self, rtp_timestamp: int, received_at_ms: float):
        """
        收到一个RTP语音帧时调用。
        rtp_timestamp: 发送端的时间戳（此处简化为主观单位）
        received_at_ms: 本地接收时间（毫秒）
        """
        # 这里用一个简单的公式模拟抖动估计
        # 真实场景要对比多个RTP包的发送时间和到达时间差
        # 我们暂时用固定增量模拟
        self.inter_arrival_jitter_ms = (
            (15.0 if received_at_ms % 2 == 0 else 25.0)
        )
        
        # 把帧放入缓存，时间戳仅作排序演示，不实际使用
        self.buffer.append((rtp_timestamp, received_at_ms))
        
        # 模拟缓存区“播放”逻辑：如果缓存深度低于目标，则多等一会
        if len(self.buffer) * self.frame_ms < self.current_depth_ms:
            # 还不够深度，先不取帧，等更多数据
            return self.current_depth_ms
        
        # 深度合适，则从缓冲取走最老的一帧，模拟播放
        self.buffer.popleft()
        # 根据抖动调整目标深度：抖动大就增加，小就减少，但限制在40~120ms
        if self.inter_arrival_jitter_ms > self.current_depth_ms / 2:
            self.current_depth_ms = min(120.0, self.current_depth_ms + 5)
        else:
            self.current_depth_ms = max(40.0, self.current_depth_ms - 5)
        
        return self.current_depth_ms

# 模拟连续收到10帧RTP语音
jb = JitterBuffer(initial_depth_ms=60.0)
for seq in range(10):
    depth = jb.add_frame(rtp_timestamp=seq * 160, received_at_ms=seq * 21.0)
    # 打印每次调节后的深度，方便观察变化
    print(f"第{seq+1}帧后，当前目标缓存深度: {depth:.1f}ms")

这个例子把复杂的算法大幅简化了，但你能看到核心思路：抖动小时缓存浅，延迟低；抖动大时缓存深，抗抖动。实际商用实现要统计每个包的发送时间戳与到达间隔，做指数平均，还要处理丢包补偿。另外，别忘了静音检测。如果缓存机制不区分静音包和语音包，就会把一长段静音当成语音缓存下来，导致停顿感。

四、应用场景和优缺点

4.1 典型应用场景

最常见的场景是企业IP-PBX连接到运营商PSTN中继。企业内部分机走SIP，拨外线时，网关把SIP呼叫转成PSTN的ISDN PRI信令。另一个场景是运营商IMS网络与传统TDM交换机的互通，用于语音业务的平滑演进。还有那些“云呼叫中心”，也需要通过网关接入传统电话网，保证普通手机和座机能收到来电。你会发现，只要PSTN存在一天，这种网关就有吃不完的饭。

具体来说，假设你给一家银行做呼叫中心，银行有一套老掉牙的PBX，用的还是模拟中继。你要把它接到新的SIP平台，让客服能用软电话接听。网关要做的事情包括：感知模拟中继的振铃、摘机、挂机，把DTMF按键转成RFC 2833，还要把模拟语音转成G.711并封装成RTP包。这一整套流程，任何一个环节慢半拍，客服就会觉得“电话变钝了”。

4.2 网关方案的优缺点

优点很明显：节约成本，不用把PSTN设备全换掉；灵活性高，可以在IP上做智能路由；还能实现统一计费、录音等增值功能。缺点也不少：多一次转换就可能多一毫秒延迟；信令兼容性差，不同厂商的ISDN实现风格不一样，导致网关要“对症下药”；而且一旦网关出问题，整条语音链路就瘫了。

更直白地说，网关就是那个“脏活累活全包”的角色。它既要懂电信级的高可用，又要懂IP网络的动态性。上层的业务要快速迭代，下层的PSTN却十年不变，中间的网关就成了不断打补丁的对象。所以做网关开发的人，需要同时精通SIP、RTP、Q.931、G.711，还要有极强的耐心去跟各种老设备对日志。

五、注意事项和调试技巧

5.1 注意事项

干这行最怕的是“半吊子”信令。比如有些老交换机发的Q.931消息，编解码不规范，你可能需要做容错。还有SIP的100rel临时确认、PRACK、UPDATE方法，在转给PSTN时往往没有对应动作，要小心“静默丢弃”，否则对端会等超时。另外，媒体协商时，SDP里的IP地址可能是内网地址，网关要做NAT穿透，否则语音流发不出去。

还有一点，一定要关注信令链路本身。ISDN的D通道如果掉线了，所有呼叫都会失败。网关需要实时检测D通道状态，并自动切换备用链路。同时，PSTN中继的E1可能出现时钟不同步，导致滑码和误码。这些都算不上“信令转换”问题，但会直接影响互通质量，所以在工程上必须重视。

5.2 调试技巧

调试互通问题，首先得有抓包习惯。你可以用scapy在Python里做一个简单的SIP抓包分析工具，只把关键头打印出来。但抓包只能看到IP侧的报文，PSTN侧就无法直接抓。这时候就需要网关打印详细的呼叫日志。日志里通常会有“Q.931 Event”和“SIP Event”对应关系。一个好的调试习惯是，拿着一个呼叫ID，把网关两侧的事件按时间排列出来，看哪个环节断了。

另外，可以用脚本快速映射PSTN原因值到SIP状态码，帮你看懂日志中的失败原因。下面是一个简单的映射函数：

# 技术栈：Python 3.x，演示Q.931原因值到SIP状态码的映射

def q931_cause_to_sip_code(cause: int):
    """
    将Q.931释放原因值映射为SIP响应码。
    原因值定义参考ITU-T Q.850。
    """
    mapping = {
        1: 404,    # 未分配的号码
        17: 486,   # 用户忙
        18: 480,   # 用户无应答
        19: 480,   # 用户未应答
        21: 403,   # 呼叫被拒绝
        22: 410,   # 号码已改变
        27: 503,   # 目的地不可达
        28: 503,   # 无效的号码格式
        34: 503,   # 无可用电路
        38: 503,   # 网络故障
        47: 503,   # 资源不可用
    }
    # 如果没有映射关系，返回一个通用的500作为兜底
    return mapping.get(cause, 500)

# 测试几个常见原因值
for cause in [1, 17, 28, 999]:
    print(f"Q.931原因值 {cause} -> SIP状态码 {q931_cause_to_sip_code(cause)}")

排查媒体问题要关注RTP序号和时间戳的连续性。如果RTP序号乱跳，说明有丢包或乱序；如果时间戳稳定，则编码转换有问题。你还可以在网关里用RTP loopback功能，把接收的RTP原样发回，来定位是编码转换的问题还是网络传输的问题。这些技巧虽然老土，但非常管用。

六、总结

SIP与PSTN的互通，本质上是一场“信令语言翻译”和“媒体格式翻译”的双重工程。信令转换的核心是把两边的呼叫状态机掰到一个频道上来，媒体适配的核心是编码和缓冲的完美配合。别看这个网关只是个“小盒子”，里面的坑比想象中多得多。理解了消息映射、状态机、编码转换和抖动缓冲这几个关键点，你再去接触具体的网关产品，就会轻松很多。希望这篇文章能帮你把“互通”这两个字看得更透，也少走一些弯路。如果你正在做相关开发，不妨先从最简单的INVITE映射和PCMA/PCMU查表练起，跑通一个最小闭环，再逐步处理那些奇奇怪怪的边界情况。毕竟，真正的大牛不是背了多少协议，而是能在一片混沌中把问题理清楚。