三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

FreeSWITCH呼叫流程全解析：从SIP信令到媒体协商的实战指南

发布时间：2026/8/16 21:54:39 三亩地 编程学习日记
FreeSWITCH呼叫流程全解析：从SIP信令到媒体协商的实战指南

1. 项目概述：从“fs呼叫流程”说起

最近在调试一个基于FreeSWITCH的通信项目，又遇到了那个老生常谈但又无比核心的问题——呼叫流程。无论是刚接触的新手，还是像我这样摸爬滚打多年的老鸟，一旦涉及到SIP协议栈的交互、媒体协商或是呼叫路由的异常，最终都得回到“呼叫流程”这个根上来。你可能会在日志里看到一堆SIP/2.0 100 Trying、183 Session Progress，或者更头疼的408 Request Timeout、503 Service Unavailable。如果不清楚一个标准的、健康的呼叫流程长什么样，排查问题就像在迷宫里乱撞。

“fs呼叫流程”这个标题，看似简单，实则包罗万象。它不仅仅是指FreeSWITCH内部从一个session对象创建到销毁的代码执行路径，更涵盖了从主叫用户代理（UA）发起INVITE，到信令经过SIP代理（可能就是FreeSWITCH本身），最终与被叫UA建立媒体通道的完整生命周期。这个过程涉及SIP信令的逐跳传递、SDP的offer/answer协商、RTP/RTCP媒体流的建立与控制，以及可能出现的各种补充业务（如呼叫转移、保持）。理解它，是掌握任何基于SIP的语音、视频通信系统的基石。

对于运维工程师，清晰的呼叫流程能帮你快速定位网络问题或配置错误；对于开发人员，它是你编写拨号计划（Dialplan）、设计IVR或集成第三方应用（如通过mod_event_socket）的逻辑蓝图；即便是测试人员，也需要依据标准流程来设计用例和判断测试结果是否正常。接下来，我就结合FreeSWITCH这个核心平台，把一次完整呼叫的“台前幕后”拆解清楚，并分享一些从实战中积累下来的、在官方文档里未必会明说的排查技巧和配置心得。

2. 核心概念与组件拆解

在深入流程之前，我们必须统一语言，明确几个关键角色和组件。这些概念是理解后续所有交互的基础。

2.1 核心角色：UAC, UAS, Proxy 与 B2BUA

一次SIP呼叫，通常涉及以下角色：

  • 用户代理客户端 (UAC)：发起请求的实体。比如，你的SIP话机或软电话（如MicroSIP, Zoiper）在拨号时，它就是UAC。
  • 用户代理服务器 (UAS)：接收并响应请求的实体。当被叫话机振铃时，它作为UAS回应180 Ringing。
  • 代理服务器 (Proxy Server)：负责转发SIP请求和响应。它不主动发起请求，主要工作是路由。一个请求从主叫到被叫，可能会经过多个Proxy。Proxy会修改SIP消息中的Via头域，以便响应能按原路返回。
  • 背靠背用户代理 (B2BUA)：这是FreeSWITCH在大多数呼叫场景中扮演的角色。它比Proxy复杂得多。B2BUA会终止来自主叫的SIP会话，然后以一个新的UAC身份向被叫发起另一个SIP会话。这意味着它完全掌控了两个独立会话的状态，可以在中间进行丰富的业务处理，如媒体转码、录音、IVR、呼叫排队等。这是理解FreeSWITCH呼叫流程的关键：你看到的日志，实际上是FreeSWITCH作为B2BUA，分别与主叫方和被叫方进行的两个独立SIP对话的混合。

2.2 FreeSWITCH的核心：Session与Channel

在FreeSWITCH内部，一次呼叫对应一个session对象（对应一个SIP对话），而channel（通道）则是session的核心组成部分，封装了媒体和信令的状态。一个呼叫从进入FreeSWITCH到离开，其channel会经历一系列状态变迁，例如CS_NEW（新建）、CS_INIT（初始化）、CS_ROUTING（正在路由）、CS_SOFT_EXECUTE（执行拨号计划）、CS_EXECUTE（执行应用）、CS_EXCHANGE_MEDIA（媒体交换）、CS_HANGUP（挂断）等。通过sofia status命令或事件套接字监听CHANNEL_STATE事件，可以清晰地跟踪这个状态机。

2.3 信令与媒体的分离：SIP 与 SDP/RTP

这是互联网电话（VoIP）的核心设计原则。

  • SIP (Session Initiation Protocol)：负责信令。即建立、修改和终止会话。所有我们提到的INVITE, 100 Trying, 180 Ringing, 200 OK, BYE都是SIP消息。它通常运行在UDP/5060端口（也可用TCP/TLS）。
  • SDP (Session Description Protocol)：是SIP消息体（Body）的一部分，在INVITE和200 OK中交换，负责媒体协商。它描述媒体流的属性：用什么编解码（如PCMA, PCMU, G.729, OPUS, H.264）、IP地址和端口号（RTP接收地址）、是否支持静音抑制（CN）等。
  • RTP/RTCP (Real-time Transport Protocol)：负责媒体传输。根据SDP协商好的地址和端口，直接在两端的媒体端点（可能是话机，也可能是FreeSWITCH）之间传输音频、视频数据包。RTCP则负责传输质量反馈。

理解这种分离至关重要。经常会出现“信令通，媒体不通”的情况，即双方能振铃、接听，但听不到声音。这通常就是SDP协商或RTP网络路径出了问题。

3. 一次标准SIP呼叫流程全解析

现在，让我们跟随一个从SIP话机A呼叫到话机B，中间经过FreeSWITCH B2BUA转接的完整流程。假设FreeSWITCH已经正确注册了两个话机（1001和1002）。

3.1 主叫侧：呼叫发起与进入FS

  1. INVITE (1001 -> FS)：话机1001（UAC）向FreeSWITCH的SIP接口（sofiaprofile）发送INVITE请求。这个消息体里包含了SDP Offer，指明了1001希望使用的编解码和它准备接收RTP的IP:端口。

    INVITE sip:1002@your.fs.server:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: <sip:1001@your.fs.server>;tag=12345 To: <sip:1002@your.fs.server> Call-ID: abcde12345@192.168.1.101 CSeq: 1 INVITE Contact: <sip:1001@192.168.1.101:5060> Content-Type: application/sdp Content-Length: ... v=0 o=1001 123456 123456 IN IP4 192.168.1.101 s=- c=IN IP4 192.168.1.101 t=0 0 m=audio 10000 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000

  2. 100 Trying (FS -> 1001)：FreeSWITCH（作为UAS）收到INVITE后，必须立即回复一个临时响应100 Trying，告诉主叫“我收到了，正在处理，别重发”。这是一个非常重要的防重传机制。

  3. 身份验证与路由决策：FreeSWITCH会检查INVITE请求。如果sofiaprofile要求认证，而INVITE里没有正确的认证信息，FS会回复401 Unauthorized，触发话机进行鉴权。认证通过后，FS根据To头域（sip:1002@...）进行路由。路由的核心是拨号计划（Dialplan）。FS会在配置的Dialplan上下文（Context）中寻找匹配destination_number（1002）的规则。

  4. 执行拨号计划：假设在default上下文中，有一条正则表达式^(\d{4})$匹配到了1002。拨号计划中的应用（Application）开始执行。最常见的是bridge应用，它的作用是向被叫发起一个新的呼叫。此时，FreeSWITCH为主叫侧创建的channel状态进入CS_EXECUTE。

3.2 被叫侧：FS作为UAC呼叫被叫

bridge应用触发FreeSWITCH角色转换：从面对主叫的UAS，转变为面向被叫的UAC。

  1. INVITE (FS -> 1002)：FreeSWITCH根据1002的注册信息（或静态配置），向话机1002发送一个新的INVITE。关键点来了：这个INVITE里的SDP Offer可能不是直接转发主叫的SDP。作为B2BUA，FreeSWITCH会生成一个新的SDP Offer，这个Offer描述的是FreeSWITCH自身媒体端点的能力。例如，主叫支持G.729和PCMU，但FreeSWITCH配置的codec_prefs是OPUS,PCMU,PCMA，那么发给被叫的Offer里可能就只有OPUS, PCMU, PCMA。同时，Contact头、Call-ID、From/To标签等都会是全新的。

    INVITE sip:1002@192.168.1.102:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.2.1:5060;branch=z9hG4bK87gh1 From: <sip:1001@your.fs.server>;tag=67890fs // 注意From仍是主叫，但tag是FS生成的 To: <sip:1002@your.fs.server> Call-ID: fghij67890@192.168.2.1 // 全新的Call-ID ... c=IN IP4 192.168.2.1 // FS自身的媒体IP m=audio 20000 RTP/AVP 111 8 0 // 编解码列表是FS重新排序或过滤后的 a=rtpmap:111 OPUS/48000/2

  2. 被叫侧响应回流：话机1002收到INVITE后，同样会回复100 Trying，然后振铃，回复180 Ringing。这个180 Ringing会先被FreeSWITCH收到。

  3. 信令传递：183/180 回传主叫：FreeSWITCH收到被叫的180 Ringing后，会生成一个对应的180 Ringing，发回给主叫1001。对于主叫而言，它认为这个振铃响应是来自最初它呼叫的“服务器”（即FS）。如果被叫回复的是183 Session Progress（可能携带了早期媒体，即回铃音），FS也会类似地转发或生成183给主叫。此时，主叫侧channel状态可能变为CS_RINGING。

3.3 媒体协商与通话建立

  1. 200 OK (被叫摘机)：被叫1002摘机，回复200 OK，其消息体中携带了SDP Answer，从FS提供的编解码列表中选择了一个（比如OPUS），并告知其接收RTP的地址（192.168.1.102:30000）。

  2. ACK (FS -> 被叫)：FreeSWITCH作为UAC，必须向被叫1002发送ACK，确认收到200 OK。至此，FS与被叫侧的SIP对话建立完成。

  3. 200 OK 与 ACK (FS -> 主叫)：与此同时，FreeSWITCH需要向主叫1001发送200 OK。这个200 OK里的SDP Answer，是FS根据被叫的Answer和自身能力，再次生成的给主叫的Answer。它可能与被叫的Answer不同。例如，被叫选择了OPUS，但主叫只支持PCMU，那么FS就需要进行媒体转码。此时，FS发给主叫的SDP Answer中，编解码就是PCMU，而FS的媒体引擎会负责在OPUS和PCMU之间进行实时转码。然后，FreeSWITCH等待主叫的ACK。

  4. RTP流建立：当两个方向的ACK都发送完毕后，两个独立的媒体路径就建立了：

    • 路径1：主叫1001 <-> FreeSWITCH （基于主叫与FS协商的编解码和地址）
    • 路径2：FreeSWITCH <-> 被叫1002 （基于FS与被叫协商的编解码和地址） RTP流开始在这两条路径上流动。如果不需要转码（双方编解码一致且FS允许直通），FreeSWITCH可能会尝试媒体绕接（bypass），即通过SDP: sendrecv指令让两端直接通信，以降低服务器负载和延迟。此时，channel状态进入CS_CONNECTED（已连接）或CS_EXCHANGE_MEDIA。

3.4 通话保持、转移与终止

  1. 通话中操作：通话建立后，可能涉及DTMF按键传输（RFC2833或SIP INFO）、呼叫保持（通过re-INVITE或UPDATE方法携带a=sendonly的SDP）、三方通话、盲转（REFER）或出席转（Attended Transfer）等。FreeSWITCH的拨号计划或通过uuid_transfer等API可以控制这些行为。例如，执行attended_transfer时，FS会桥接两个channel，并在适当时机发送BYE给一方。

  2. 呼叫终止：任何一方挂机（发送BYE请求）。假设主叫挂机：

    • 主叫1001发送BYE给FreeSWITCH。
    • FreeSWITCH回复200 OK给主叫，终止主叫侧会话。
    • 同时，FreeSWITCH作为UAC，向被叫1002发送BYE。
    • 被叫1002回复200 OK给FreeSWITCH。
    • 双方释放RTP端口，FreeSWITCH清理内部的session和channel资源，呼叫结束。channel状态最终变为CS_DESTROY。

4. 关键配置与调试实战

理解了流程，我们来看看在FreeSWITCH中，哪些配置会深刻影响这个流程，以及如何调试。

4.1 SIP Profile配置精要

sofiaprofile的配置（通常在/usr/local/freeswitch/conf/sip_profiles/internal.xml）是呼叫能否正常进入FS的第一道关卡。

  • context：定义未认证呼叫（如来自外网的INVITE）进入的拨号计划上下文。务必设置正确，否则呼叫会因无匹配路由而失败。
  • rtp-ip与sip-ip：这两个参数至关重要。rtp-ip是FS在SDP中宣告的媒体IP地址。如果FS部署在私有网络，公网话机需要连接，这里必须配置为公网IP或通过STUN获取。sip-ip是FS在Contact等头域中使用的IP。在NAT环境下，通常需要设置ext-rtp-ip和ext-sip-ip为公网IP，并启用NDLB（NAT Detection and Local IP/Port Binding）相关参数。
    <param name="rtp-ip" value="$${local_ip_v4}"/> <param name="sip-ip" value="$${local_ip_v4}"/> <!-- 如果 behind NAT --> <param name="ext-rtp-ip" value="公网IP"/> <param name="ext-sip-ip" value="公网IP"/> <param name="NDLB-detect-nat" value="true"/> <param name="NDLB-preserve-port" value="true"/>
  • codec-prefs：这里定义的编解码优先级列表，直接影响FS生成的SDP Offer。把带宽占用低、音质好的编解码（如OPUS）放前面。disable掉不用的编解码可以简化协商。
    <param name="codec-prefs" value="OPUS,PCMU,PCMA,G729"/> <param name="disable-codecs" value="G722,H264,VP8"/>
  • inbound-reg与auth-calls：是否允许匿名注册和匿名呼叫。生产环境内部profile通常关闭匿名（auth-calls=true），外部profile根据安全策略配置。

4.2 拨号计划（Dialplan）路由逻辑

拨号计划是FS呼叫流程的“大脑”。它的匹配和执行顺序决定了呼叫的命运。

  • 上下文（Context）与分机（Extension）：呼叫首先进入一个Context（如default,public）。然后在Context中按顺序匹配Extension的condition。destination_number是系统变量，存储被叫号码。
    <context name="default"> <extension name="Local_Extension"> <condition field="destination_number" expression="^(10[0-9][0-9])$"> <!-- 匹配1000-1099 --> <action application="set" data="dialed_extension=$1"/> <action application="bridge" data="user/${dialed_extension}@$${domain}"/> </condition> </extension> </context>
  • bridge应用：这是最核心的应用。user/1002@domain会查找1002的注册信息并进行呼叫。bridge支持同时呼叫多个目标（用逗号分隔），实现“遇忙转移”或“循环振铃”等策略。
  • set与变量：使用set设置通道变量（如call_timeout,hangup_after_bridge），这些变量能控制呼叫行为（如超时时间、是否在桥接后挂断）。

4.3 媒体处理与编解码协商

媒体问题是无声、单通、杂音的根源。

  • 转码与直通：FS默认会进行转码以确保两端能通话。转码消耗CPU。如果两端编解码相同（如都是PCMU），可以通过设置通道变量bypass_media=true或bypass_media_after_bridge=true来尝试媒体绕接，降低负载。但要注意，绕接后，FS将无法进行录音、DTMF检测等需要访问媒体流的操作。
  • DTMF传输模式：有三种主要方式：RFC2833（带内RTP事件，推荐）、SIP INFO（带外信令，兼容性好但可能不同步）、inband（音频带内，不可靠）。在profile中配置dtmf-type为rfc2833，并在拨号计划中为需要传递DTMF的呼叫设置rfc2833_pt。
  • NAT穿越：对于内网话机，需要在profile中启用aggressive-nat、enable-ice等参数。对于FS本身在NAT后，除了前面提到的ext-rtp-ip，还需要在SDP中正确设置a=candidate属性（ICE），这通常需要mod_verto或深度配置。

4.4 日志分析与问题排查

FreeSWITCH的日志是诊断呼叫流程的终极武器。通过fs_cli控制台调整日志级别：

# 全局提高日志级别（生产环境慎用，日志量巨大） console loglevel 7 # 仅提高SIP相关日志 sofia global loglevel 9 # 跟踪特定IP的日志 sofia logfile /tmp/sip.log 192.168.1.101

在日志中，关注以下关键点：

  1. INVITE是否到达：搜索RECV SIP消息，看INVITE是否被正确接收。
  2. 认证与路由：查看是否出现401，以及PARSE后的路由决策（CALL TO...）。
  3. Dialplan执行：搜索EXECUTE，看是否执行了预期的bridge。
  4. SDP协商：仔细对比INVITE和200 OK中的SDP。检查m=行中的编解码ID和a=rtpmap映射是否一致，IP地址和端口是否可达。
  5. 媒体流：搜索rtp.c或switch_rtp.c相关的日志，看是否有Audio Hook、start talking或stop talking，这表示RTP流开始/停止。使用rtp stats命令可以查看丢包、抖动情况。
  6. 呼叫状态：监听CHANNEL_CREATE,CHANNEL_STATE,CHANNEL_ANSWER,CHANNEL_HANGUP等事件，可以编程式地跟踪呼叫生命周期。

5. 常见问题排查与实战技巧

结合多年踩坑经验，以下是一些高频问题及排查思路：

5.1 问题一：注册成功，但呼叫立即失败（如 403, 404, 486）

  • 403 Forbidden：通常与认证相关。检查主叫是否在INVITE中携带了正确的From头域（应与注册用户一致）。检查profile的auth-calls设置。使用sofia status profile internal reg确认用户确实在线。
  • 404 Not Found：路由失败。检查被叫号码是否匹配Dialplan中的任何Extension。使用show channels看呼叫是否创建了channel。在Dialplan中使用info或log应用打印destination_number，确认它是否如你预期。
  • 486 Busy Here：被叫线路忙。可能是被叫话机正在通话，或者FS认为该用户已经有一个活跃的会话（检查max_sessions参数）。

技巧：在Dialplan最前面加一个“全捕获”的Extension用于调试，记录所有呼叫的详细信息。

<extension name="debug_catch_all"> <condition> <action application="log" data="INFO DEBUG: Call from ${caller_id_number} to ${destination_number}"/> <action application="set" data="hangup_after_bridge=true"/> <!-- 这里可以临时桥接到一个测试分机 --> </condition> </extension>

5.2 问题二：有振铃，能接听，但无声音（单通或双不通）

这是最经典的媒体问题。

  1. 检查SDP：首先对比主叫INVITE、FS给被叫的INVITE、被叫200 OK、FS给主叫的200 OK这四个SDP中的IP地址和端口。确认它们是否都是可达的IP（非私有地址如192.168.x.x被发送到了公网对端）。
  2. 检查NAT：如果一方在NAT后，确保FS的ext-rtp-ip设置正确，并且NAT路由器上开启了相应的UDP端口转发（通常是10000-20000范围）。在话机侧，可能需要配置STUN服务器。
  3. 防火墙：临时关闭FS主机和客户端主机的防火墙进行测试（sudo ufw disable或systemctl stop firewalld）。确保RTP端口范围（在internal.xml中由rtp-start-port和rtp-end-port定义）是开放的。
  4. 编解码匹配：确认双方最终协商出的编解码一致。如果FS在中间转码，确认系统已安装对应编解码的库（如mod_opus）。
  5. 抓包分析：终极武器。在FS主机上使用tcpdump或tshark抓取SIP和RTP包。
    tcpdump -i any -w call.pcap host 192.168.1.101 or host 192.168.1.102
    用Wireshark打开call.pcap，过滤sip和rtp。查看SDP内容，并使用Telephony -> RTP -> Stream Analysis工具，可以直观看到RTP流是否双向都有包，以及丢包、抖动情况。

5.3 问题三：通话一段时间后莫名断线

  • SIP会话定时器（Session Timer）：某些运营商或话机启用了Session Timer，会定期发送re-INVITE或UPDATE来刷新会话。如果FS或对端没有正确处理，可能导致超时挂断。可以在profile中配置session-timeout，或设置enable-timer参数。
  • NAT超时：UDP NAT映射有超时时间（通常30秒到几分钟）。如果通话中RTP流长时间静音（无语音包），NAT映射表项可能被删除，导致后续媒体包被丢弃。启用RTP保活（在profile中设置rtp-timeout-sec和rtp-hold-timeout-sec为false，或使用rtp_keepalive通道变量）可以发送空RTP包维持NAT映射。
  • 网络抖动与丢包：高丢包率或持续高抖动会导致RTCP报告质量差，某些激进的话机或客户端可能会主动挂断。检查网络质量。

5.4 高级技巧：使用Homer或SIPCapture进行可视化抓包

对于复杂的分布式系统，在服务器上抓包可能不够。可以搭建一个SIP抓包服务器（如Homer），将FS和所有话机的SIP流量镜像到Homer。Homer提供了Web界面，可以图形化地展示整个呼叫流程的SIP消息序列图，极大提升排查效率。配置FS的sofiaprofile，将sip-capture设置为yes，并指向Homer服务器的地址即可。

理解“fs呼叫流程”不仅仅是记住一串SIP消息的顺序。它要求你将FreeSWITCH的B2BUA架构、SIP协议状态机、SDP媒体协商、RTP流传输以及FreeSWITCH自身的配置和拨号计划逻辑融会贯通。当出现问题时，沿着这条清晰的路径，从信令到媒体，从主叫侧到被叫侧，逐段排查，你总能找到那个出错的环节。最好的学习方式，就是搭建一个实验环境，用两台软电话注册到FS，打一个电话，然后对照着日志和抓包，一步一步地走完这个流程。踩过几次坑之后，这些流程和概念就会变得无比清晰。

编程学习 学习日记 实战经验
← 返回列表