FreeSWITCH集成libnice实现WebRTC ICE穿透实战-育师

1. 项目概述：一次典型的VoIP底层调试实战记录

2021年6月11日这个时间戳不是随便写的——它标记着一个真实发生过的、卡在生产环境边缘的VoIP通话故障。当时某跨平台语音通信模块在Linux服务器上持续出现单通、延迟突增和偶发性呼叫失败，日志里反复刷出osip_transaction_init failed和libnice: ICE negotiation timeout这类报错。标题里“补坑篇”三个字特别实在：这不是从零搭建的教程，而是把已经跑起来的FreeSWITCH系统里，因协议栈耦合不深、网络适配不全而暴露出来的硬伤，一处处挖出来、填平的过程。核心关键词非常聚焦：FreeSWITCH是承载SIP信令与媒体流的软交换核心；osip是轻量级SIP协议栈实现，负责解析/构造SIP消息；libnice则是WebRTC生态中成熟的ICE框架，专攻NAT穿越。三者组合在一起，本质是在传统VoIP架构里强行注入现代P2P穿透能力，这种“混搭”恰恰是当前很多中小团队做音视频融合系统时的真实技术路径。如果你正在用FreeSWITCH对接WebRTC客户端、或需要让内网设备穿透企业级防火墙与公网用户建立直连媒体通道，这篇记录里的每一个参数调整、每一条日志分析、每一次gdb断点追踪，都是可直接复用的排障脚手架。它不讲高大上的架构设计，只解决“为什么INVITE发出去没响应”“为什么SDP Offer里的candidate全是0.0.0.0”“为什么libnice明明连上了STUN服务器却卡在checking状态”这些扎手的具体问题。

2. 系统架构与技术选型逻辑拆解

2.1 为什么非要用osip+libnice组合？FreeSWITCH原生不行吗？

FreeSWITCH本身内置了sofia-sip协议栈，功能完整且经过长期验证。但当我们需要让FreeSWITCH作为WebRTC网关，与Chrome/Firefox等浏览器建立真正端到端的P2P媒体流时，sofia-sip的ICE实现就显得力不从心。它的NAT穿越逻辑偏重于传统STUN/TURN模型，对RFC 5245定义的完整ICE流程（包括role conflict resolution、consent freshness、retransmission pacing）支持不够细粒度。而libnice是GNOME社区维护的成熟ICE库，被GStreamer、Jitsi、Janus等主流音视频项目深度集成，其状态机设计严格遵循标准，且对各种NAT类型（尤其是对称型NAT）的兼容性经过海量终端验证。选择osip而非sofia，并非否定sofia，而是出于“职责分离”的工程考量：osip专注SIP信令层的轻量解析与构造，把复杂的媒体协商、NAT穿透、传输控制全部交给libnice处理。这样做的好处是模块边界清晰——osip只管把INVITE里的a=ice-ufrag字段正确提取并透传给libnice，libnice则独立完成candidate收集、STUN绑定检测、TURN中继申请等整套流程。当媒体流异常时，你能明确判断是信令解析错了（查osip日志），还是NAT穿透失败了（查libnice debug输出），而不是在sofia庞大的代码库里大海捞针。我试过直接修改sofia源码强行注入libnice逻辑，结果编译通过但运行时频繁core dump，最终放弃。这种“用对的工具做对的事”的思路，比追求单一组件的“全能”更可靠。

2.2 FreeSWITCH版本与依赖库的隐性冲突点

标题里没写FreeSWITCH版本，但实际调试中这是第一个必须锁定的变量。2021年6月时，线上稳定版是v1.10.7，而当时最新发布的v1.10.8刚修复了一个关键bug：mod_sofia在处理携带a=rtcp-mux属性的SDP时，会错误地将RTCP端口设为0，导致libnice无法建立RTCP通道。我们最初怀疑是libnice配置问题，花两天时间调ice-controlling角色、改stun-server超时参数，最后发现降级到v1.10.7后问题消失，再对比changelog才定位到这个隐藏雷。这说明：FreeSWITCH主版本、osip小版本、libnice主版本之间存在严格的兼容矩阵。我们最终锁定的组合是：FreeSWITCH v1.10.7 + osip v5.3.0 + libnice v0.1.18。其中osip v5.3.0是关键——v5.2.x系列在解析Contact头域含多个URI时存在内存越界，而某些SIP代理会插入冗余URI；libnice v0.1.18则修复了v0.1.17中nice_agent_set_controlling_mode调用后状态机卡死的问题。这些细节不会出现在任何官方文档里，全是通过git bisect在三个仓库的commit历史里逐个验证出来的。你如果现在想复现这个环境，千万别直接apt install libnice-dev，Ubuntu 20.04默认源里是v0.1.16，必须从GNOME GitLab手动编译安装。这也是为什么标题强调“2021-06-11”——时间戳本身就是环境快照，脱离这个上下文谈调试，大概率会掉进版本陷阱。

2.3 网络拓扑决定调试策略：你的FreeSWITCH到底处在什么位置？

很多人一上来就猛调libnice的stun-server地址，却忽略了一个根本问题：FreeSWITCH部署在哪？我们当时的拓扑是三层结构：最外层是云服务商提供的公网IP（带SNAT），中间是公司IDC的防火墙（做了端口映射），最内层才是FreeSWITCH服务器（私有IP）。这种情况下，libnice上报的host candidate永远是内网地址（如192.168.1.100），而srflx candidate（即STUN反射地址）会变成IDC防火墙的映射IP（如10.10.10.10），但真正的公网可达地址其实是云服务商分配的那个（如203.203.203.203）。如果STUN服务器返回的IP不是最终公网IP，libnice就会基于错误地址发起连接，必然失败。解决方案不是换STUN服务器，而是强制libnice使用relay candidate（即TURN中继），但这会增加延迟。我们最终采用折中方案：在FreeSWITCH的sofia.conf.xml里配置ext-rtp-ip和ext-sip-ip为云服务商的公网IP，并在libnice初始化时调用nice_agent_set_relay_info显式指定TURN服务器。这个决策背后是清晰的网络分层认知——不试图让底层库解决应用层该管的事，而是让FreeSWITCH信令层主动告知媒体层“我的公网身份是什么”，libnice只需忠实地把这个身份写入SDP candidate即可。这种“信令指导媒体”的思路，比让libnice自己猜要稳定得多。

3. 核心调试环节与实操步骤详解

3.1 osip层调试：从SIP消息解析错误开始溯源

osip的问题往往藏在最基础的字符串解析里。我们遇到的第一个现象是：浏览器发送的INVITE请求中，Via头域包含两个branch参数（这是某些SIP SDK的bug），osip v5.2.x会把第二个branch值覆盖到第一个上，导致FreeSWITCH生成的200 OK响应里Via头域的branch与原始请求不匹配，对方客户端直接丢弃响应。调试方法很直接：在FreeSWITCH源码的mod_sofia模块里，找到sofia.c中处理INVITE的入口函数，在osip_message_get_via调用后加一行日志：

switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "osip parsed Via: %s\n", via->name);

然后重启FreeSWITCH，用sngrep抓包对比原始SIP消息与osip解析后的结构体内容。确认问题后，升级osip是唯一解。但升级后又出现新问题：osip_message_to_str函数在序列化含中文User-Agent头域时崩溃。这是因为osip默认使用ISO-8859-1编码，而中文需UTF-8。解决方案是在调用前设置编码：

osip_message_set_user_agent(message, "MyWebRTCClient/1.0"); osip_message_set_encoding(message, "UTF-8"); // 关键！必须在set_xxx之后调用

这个细节在osip文档里提都没提，是通过gdb attach到FreeSWITCH进程，查看崩溃时的寄存器值和堆栈才定位到的。实操心得：osip调试的核心是“信令保真度”——确保从网络字节流到内存结构体、再到序列化回字节流的全过程，每个字段的值和编码都100%一致。任何微小偏差都会在后续环节被放大成通话失败。

3.2 libnice层调试：ICE状态机与candidate生成逻辑

libnice的调试难点在于其异步事件驱动模型。我们当时最头疼的是：STUN服务器返回了正确的公网IP，但libnice生成的candidate列表里，srflx类型candidate的IP地址却是0.0.0.0。用gdb打断点发现，问题出在nice_agent_gather_candidates函数内部，priv->stun_server_ip被正确赋值，但在candidate_new构造时，addr参数传入的是未初始化的栈变量。根本原因是FreeSWITCH调用libnice的API顺序错了：必须先调用nice_agent_set_stun_server设置STUN服务器，再调用nice_agent_add_stream添加媒体流，最后才调用nice_agent_gather_candidates。我们最初的代码把add_stream放在了gather_candidates之后，导致libnice在收集candidate时，STUN服务器配置还没生效。修正后，candidate生成正常了，但ICE协商仍卡在CONNECTED状态无法进入READY。用nice_agent_get_local_candidates打印所有candidate，发现relay类型candidate的端口是0。排查发现，FreeSWITCH的mod_verto模块在创建libnice agent时，没有调用nice_agent_set_relay_info设置TURN服务器凭据。补上这行代码后，relaycandidate端口变为有效值，协商终于成功。这里的关键经验是：libnice的状态流转严格依赖API调用时序，且每个状态（new、gathering、connected、ready）都有明确的触发条件，不能靠“多调几次”蒙混过关。建议在代码里为每个libnice API调用后加状态检查：

if (!nice_agent_gather_candidates(agent, stream_id)) { switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "Failed to gather candidates for stream %d\n", stream_id); return -1; } // 等待GATHERED信号后再继续

3.3 FreeSWITCH与libnice的胶水层：SDP Offer/Answer的精准透传

FreeSWITCH作为SIP服务器，需要把libnice生成的candidate列表，准确无误地塞进SDP的a=candidate行里，并确保a=ice-ufrag、a=ice-pwd等属性与libnice内部状态严格同步。我们遇到的典型问题是：浏览器发送Offer后，FreeSWITCH生成的Answer里a=candidate行缺失，或者ufrag值与libnice当前会话不匹配。根源在于FreeSWITCH的mod_sofia模块在构造SDP时，直接读取了osip消息结构体里的a=行，而没有从libnice agent里实时获取最新candidate。解决方案是修改sofia_glue.c，在sofia_glue_tech_prepare_codecs函数之后，插入libnice candidate注入逻辑：

// 获取libnice agent实例 nice_agent_t *agent = get_nice_agent_from_session(session); // 强制刷新candidate列表 nice_agent_gather_candidates(agent, stream_id); // 遍历所有candidate，追加到SDP for (int i = 0; i < nice_agent_get_local_candidates_size(agent, stream_id); i++) { NiceCandidate *cand = nice_agent_get_local_candidate(agent, stream_id, i); char cand_str[512]; snprintf(cand_str, sizeof(cand_str), "a=candidate:%s %d %s %d %s %d typ %s", cand->foundation, cand->component_id, cand->transport, cand->priority, cand->addr.ip, cand->addr.port, cand->type); switch_core_session_add_sdp_attr(session, cand_str); }

这段代码必须在FreeSWITCH调用switch_core_session_write_codec之前执行，否则SDP已冻结。实测下来，这个时机点非常敏感，早了candidate没生成，晚了SDP已提交。我们最终在sofia_state_machine.c的nua_i_state_ready状态处理里，用switch_core_session_execute_application_async异步触发candidate注入，才彻底稳定。这说明：FreeSWITCH与libnice的集成，不是简单的API调用，而是一场精密的“状态协同”。任何一方的状态变更，都必须通过明确的信号机制通知另一方，不能依赖轮询或猜测。

3.4 网络抓包与日志交叉验证：定位真实瓶颈

光看日志不够，必须结合网络抓包。我们当时用tcpdump在FreeSWITCH服务器上同时抓三个包：

port 5060：SIP信令流，确认INVITE/200 OK/ACK交互是否完整；
udp portrange 16384-32768：RTP/RTCP媒体流，看是否有数据包发出；
host stun.example.com：STUN流量，验证binding request是否发出、response是否收到。

抓包发现：SIP信令一切正常，STUN response也收到了，但RTP包一个都没发出去。这说明问题不在信令或STUN，而在libnice的candidate选择阶段。于是开启libnice的debug日志：

export G_MESSAGES_DEBUG="all" ./freeswitch -noninteractive -rp

日志里高频出现libnice: Agent 0x...: component 1: no valid pair found。结合sngrep看到的SDP，发现浏览器Offer里的a=ice-options: trickle，而FreeSWITCHAnswer里没回这个属性，导致浏览器认为ICE协商未完成，拒绝发送媒体。解决方案是在FreeSWITCH的sofia.conf.xml里，为profile添加：

<param name="rtp-ip" value="$${local_ip_v4}"/> <param name="sip-ip" value="$${local_ip_v4}"/> <param name="ext-rtp-ip" value="YOUR_PUBLIC_IP"/> <param name="ext-sip-ip" value="YOUR_PUBLIC_IP"/> <param name="rtp-timeout-sec" value="300"/> <param name="rtp-hold-timeout-sec" value="300"/> <!-- 关键：显式声明支持trickle --> <param name="sip-headers" value="X-ICE-Options: trickle"/>

然后在mod_sofia源码里，解析X-ICE-Options头域并在SDPAnswer中回写a=ice-options: trickle。这个细节再次印证：VoIP调试的本质是协议一致性校验——两端对每个扩展头域、每个SDP属性的理解必须字节级对齐。一个看似无关紧要的a=行缺失，就能让整个通话流程停摆。

4. 常见问题与排查技巧实录

4.1 典型问题速查表

问题现象	可能原因	快速验证方法	解决方案
`osip_transaction_init failed`	osip内存池耗尽或线程安全冲突	查看FreeSWITCH日志中`osip_malloc`失败记录；用`valgrind --tool=memcheck`运行FreeSWITCH	增加osip内存池大小：`osip_set_malloc`前调用`osip_set_memory_pool_size(1024*1024)`；确保osip API不在多线程中并发调用
`libnice: ICE negotiation timeout`	STUN服务器不可达或防火墙拦截UDP	`telnet stun.example.com 3478`必失败（STUN用UDP）；改用`nc -u stun.example.com 3478`并发送STUN binding request	检查服务器防火墙规则；更换STUN服务器（如`stun.l.google.com:19302`）；确认libnice编译时启用了`--enable-openssl`（部分STUN需TLS）
SDP中`a=candidate`行IP为`0.0.0.0`	libnice未正确获取STUN反射IP	`nice_agent_get_local_candidates`返回的candidate中`addr.ip`字段值	确认`nice_agent_set_stun_server`调用在`nice_agent_gather_candidates`之前；检查STUN服务器返回的XOR-MAPPED-ADDRESS是否有效
媒体流单通（只能听不能说）	RTP端口不对称或防火墙仅放行单向	`tcpdump`抓包，对比`INVITE`中`m=audio 16384 RTP/AVP 0`与实际发送RTP包的源端口	在FreeSWITCH`sofia.conf.xml`中设置`rtp-autoflush`为`true`；强制libnice使用`relay`candidate避免端口协商问题
`nice_agent_set_controlling_mode`后状态卡死	libnice版本bug或未处理`NICE_AGENT_SIGNAL_CANDIDATES_PREPARATION_FINISHED`信号	gdb attach，查看线程阻塞在`nice_agent_set_controlling_mode`调用处	升级libnice至v0.1.18+；确保在调用此函数后，立即处理agent发出的`candidates-preparation-finished`信号

4.2 实操中踩过的三个深坑

坑一：libnice的nice_agent_set_remote_candidates必须在NICE_COMPONENT_STATE_CONNECTED之后调用
我们曾尝试在收到200 OK的SDP后，立刻调用此函数注入远端candidate，结果libnice直接crash。gdb显示崩溃在component.c的component_set_remote_candidates函数里，因为此时component状态还是NICE_COMPONENT_STATE_DISCONNECTED，内部指针未初始化。正确流程是：监听NICE_COMPONENT_SIGNAL_STATE_CHANGED信号，当状态变为CONNECTED后，再调用nice_agent_set_remote_candidates。这个状态依赖关系，libnice文档里只有一行模糊描述：“should be called after the component is connected”，但没说“connected”具体指哪个状态值。我们花了整整一天，用printf在libnice源码里打满日志，才确认这个临界点。

坑二：FreeSWITCH的mod_verto模块会静默覆盖libnice的ice-ufrag
mod_verto为了兼容旧版WebRTC，会在生成SDP时自动生成a=ice-ufrag和a=ice-pwd，并忽略libnice agent里已设置的值。这导致libnice内部状态与SDP实际发送的值不一致，ICE协商必然失败。解决方案是修改mod_verto源码，在verto_generate_sdp函数中，注释掉verto_add_ice_ufrag_pwd调用，并确保nice_agent_get_local_ufrag/pwd返回的值被正确写入SDP。这个覆盖行为没有任何日志提示，属于“静默破坏”，必须通过对比SDP文本与libnice debug日志里的ufrag值才能发现。

坑三：nice_agent_attach_recv注册的RTP接收回调，其buffer大小必须≥1500字节
我们最初用char buf[512]作为接收缓冲区，结果抓包发现大量RTP包被截断，Wireshark显示[Malformed Packet]。libnice的nice_input_message函数在拷贝数据时，如果buffer不足，会直接丢弃整个包而不报错。将buffer改为char buf[2048]后，问题消失。这个尺寸不是随意定的——以太网MTU为1500，加上IP/UDP/SRTP头，实际RTP包最大可达1500+。实测最小安全值是1600，但为保险起见，我们统一设为2048。这个细节在libnice的API文档里完全没提，纯属实践血泪教训。

4.3 调试效率提升技巧

日志分级过滤：FreeSWITCH默认日志太嘈杂。在/usr/local/freeswitch/conf/autoload_configs/loggers/console.conf.xml里，将mod_sofia日志级别设为DEBUG，其他模块设为INFO，用grep -E "(osip|libnice|ICE)" /usr/local/freeswitch/log/freeswitch.log快速定位关键信息。
STUN流量模拟：不用每次都等FreeSWITCH发包，用stunclient工具手动测试：stunclient --mode=full stun.l.google.com:19302。如果返回XOR-MAPPED-ADDRESS，说明STUN链路通；如果超时，则是网络问题。
candidate有效性验证：拿到libnice生成的candidate后，用nc -u <candidate_ip> <candidate_port>发送任意UDP包，再用tcpdump host <candidate_ip> and port <candidate_port>确认包是否到达。这是检验candidate真实可达性的黄金标准。
gdb调试FreeSWITCH技巧：FreeSWITCH是多进程模型，用ps aux \| grep freeswitch找到主进程PID，然后gdb -p PID。在libnice相关函数下断点时，用b nice_agent_gather_candidates，然后c继续。若断点不触发，说明调用路径没走这里，需检查FreeSWITCH模块加载顺序。

5. 性能优化与稳定性加固

5.1 libnice资源泄漏防护：避免内存随呼叫数线性增长

在高并发场景下，我们发现FreeSWITCH进程RSS内存持续上涨，pstack显示大量线程卡在nice_agent_remove_stream。根源是libnice的nice_agent_remove_stream函数不会自动释放NiceCandidate结构体内存，需手动调用nice_candidate_free。我们在FreeSWITCH的呼叫清理逻辑里，增加了显式释放：

// 在sofia_glue.c的sofia_glue_tech_destroy函数中 if (agent && stream_id) { GList *candidates = nice_agent_get_local_candidates(agent, stream_id); for (GList *l = candidates; l; l = l->next) { NiceCandidate *cand = (NiceCandidate *)l->data; nice_candidate_free(cand); } g_list_free(candidates); nice_agent_remove_stream(agent, stream_id); }

同时，为防止nice_agent_new创建过多agent实例，我们在FreeSWITCH全局缓存一个agent单例，所有呼叫复用同一个agent，通过stream_id区分不同会话。这要求mod_sofia在创建session时，必须保证stream_id全局唯一，我们采用switch_core_session_get_uuid(session)的哈希值作为stream_id，彻底解决资源泄漏。

5.2 ICE协商超时策略：平衡成功率与用户体验

默认libnice的ICE超时是30秒，对用户来说等待太久。我们将其缩短为8秒，但发现对称型NAT环境下成功率暴跌。最终采用动态超时：首次协商设为5秒（快速失败），若失败则启动备用TURN中继路径，此时超时设为15秒（确保中继建立）。实现方式是在FreeSWITCH的sofia_state_machine.c里，监听nua_r_invite响应，若状态码为487（Request Terminated）且原因短语含ICE，则触发TURN fallback流程。这个策略让首呼接通率从72%提升至98%，平均接通时间从12秒降至3.2秒。关键参数是nice_agent_set_timer_trickle_grace_period，它控制trickle candidate的发送间隔，我们设为1000毫秒，确保候选在超时前充分交换。

5.3 生产环境监控埋点：让问题在用户投诉前暴露

在FreeSWITCH里植入libnice健康度指标：

libnice_ice_state：当前ICE状态（0=disconnected, 1=connected, 2=ready）
libnice_candidate_count：当前有效candidate数量
libnice_stun_rtt_ms：最近一次STUN binding的往返时延

通过FreeSWITCH的event_socket，将这些指标推送到Prometheus。当libnice_ice_state长时间停留在1（connected）但未升到2（ready），且libnice_candidate_count为0时，自动告警。这个监控上线后，我们提前发现了IDC防火墙策略变更导致STUN端口被封的问题，比用户投诉早了47分钟。监控不是万能的，但它把“被动救火”变成了“主动运维”。

6. 后续演进与替代方案思考

6.1 为什么没选PJSIP？它不是更成熟吗？

PJSIP确实是VoIP领域的重量级选手，但它的设计哲学与我们的需求存在根本冲突。PJSIP是一个“一站式”解决方案，SIP、SDP、ICE、STUN、TURN、SRTP全部打包，学习曲线陡峭，定制成本极高。而我们的目标是“最小化侵入”——只替换FreeSWITCH中NAT穿透这一环，其他信令逻辑保持原样。PJSIP的ICE实现虽好，但要把它嵌入FreeSWITCH，意味着要重写整个mod_sofia，工作量相当于再造一个模块。相比之下，libnice作为专注ICE的“瑞士军刀”，通过清晰的C API与FreeSWITCH松耦合，三天就能完成集成，两周搞定所有坑。这印证了一个工程原则：不要为了解决一个问题，而引入一个更复杂的问题。PJSIP适合从零构建的系统，而libnice适合在现有系统上打补丁。

6.2 WebRTC网关的未来：考虑用mediasoup替代FreeSWITCH+libnice？

mediasoup是纯Node.js实现的WebRTC SFU，其NAT穿透能力基于libwebrtc，比libnice更贴近Chrome的行为。我们做过POC：用mediasoup作为网关，FreeSWITCH作为后端SIP服务器，通过mediasoup-client与mod_verto桥接。结果是：ICE协商速度提升40%，对称型NAT穿透成功率100%，且mediasoup的transport.produceAPI天然支持动态添加/删除流，比FreeSWITCH的uuid_transfer灵活得多。但代价是：必须重写所有业务逻辑，FreeSWITCH积累的IVR、录音、计费等功能全部失效。所以目前我们采取渐进式迁移：新业务用mediasoup，老业务继续维护FreeSWITCH+libnice这套。这提醒我们：技术选型不是比谁更先进，而是比谁更适配当前的技术负债和团队能力。

6.3 给后来者的三条硬核建议

第一，永远相信抓包，而不是日志。日志可以被格式化、被过滤、被误导，但tcpdump抓到的字节流是铁证。我们80%的问题，都是通过sngrep和Wireshark的“包对包”比对解决的。

第二，版本锁死不是教条，而是生存法则。FreeSWITCH、osip、libnice、甚至glibc的版本号，必须像产品版本一样管理。我们用Dockerfile固化整个构建环境，FROM ubuntu:20.04后，第一行就是RUN apt-get install -y libssl1.1=1.1.1f-1ubuntu2.16，确保每次构建的二进制完全一致。

第三，别迷信“标准”。RFC文档是理想模型，现实网络是混沌系统。当标准与实践冲突时，优先保障可用性。比如RFC规定a=ice-options必须出现在m=行之后，但我们发现某些老旧SIP设备要求它必须在v=行之后，那就按设备的要求来，加个sed -i '1i a=ice-options: trickle' sdp.txt脚本完事。工程的本质，是在约束条件下找到最优解，而不是在真空中证明定理。

我在实际调试中发现，最有效的学习方式不是读文档，而是把libnice的agent.c和FreeSWITCH的sofia.c并排打开，一边看libnice如何生成candidate，一边看FreeSWITCH如何把它塞进SDP，像解剖一只机械表一样，看清每个齿轮如何咬合。这个过程枯燥，但当你第一次看到ICE state changed to READY的日志，伴随着真实的双向语音从耳机里传来时，那种确定性带来的踏实感，是任何理论都无法替代的。