1. QuteCom 拨号后 INVITE 无响应或 401 的真实排查场景QuteCom 这套老牌 SIP 软电话代码分层是 UI → owphone → SipWrapper(PhapiWrapper) → phapi → exosip → osip2。你按下拨号按钮最终会走到phLinePlaceCall_withCa()由 exosip 的eXosip_build_initial_invite()和eXosip_initiate_call()把 INVITE 发出去。问题就出在这一步之后INVITE 发出去了但要么石沉大海没有任何响应要么立刻回来一个 401 Unauthorized。这个场景的核心矛盾在于你无法从 UI 上判断 INVITE 到底有没有真正离开网卡。QuteCom 的界面只会显示正在拨号然后卡住或者直接挂断。是鉴权失败是路由不可达是对端根本没收到还是收到了但拒绝响应这四种情况的表象几乎一样。我试过在纯 SIP 服务端侧排查结果发现服务端日志里压根没有 INVITE 记录说明包根本没到。这时候就需要在客户端侧抓包同时打开 phapi/exosip 的日志开关把协议栈认为发生了什么和网卡上实际发生了什么对照起来看。这里引入 TaoToken 统一 Key 的价值当你需要对照验证同样的 INVITE 头域换一条干净的 API 通道发出去会怎样时可以用 TaoToken 的模型对话或 API 通道做一次独立的请求对照排除本地网络环境干扰。TaoToken 官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。具体来说排查分三条线并行第一条线是抓包线。用 tcpdump 或 Wireshark 在 QuteCom 所在主机上抓 SIP 流量过滤条件要精确到 INVITE 方法和 5060 端口。抓到的包要逐条比对 Via、From、To、Contact、Authorization 这几个头域。第二条线是日志线。QuteCom 的 phapi 和 exosip 都有日志开关但默认是关的。你需要重新编译或者改配置文件打开OSIP_TRACE和EXOSIP_TRACE让协议栈把每一步的状态变化打印出来。重点看eXosip_initiate_call()之后有没有eXosip_event_wait超时以及 401 回来时osip_authorization有没有被正确解析。第三条线是对照线。当你怀疑是本地网络或鉴权配置问题时用 TaoToken 的统一 Key 发一条独立的 API 请求确认你的出口网络是通的、Key 是有效的。这样就能把网络问题和SIP 配置问题分开。适合谁看正在维护 QuteCom 或类似 phapi/exosip 架构软电话的开发者需要定位 SIP 拨号失败但服务端无日志的运维以及想理解 SIP 协议栈事件链的初学者。2. TaoToken 统一 Key 与 API 通道的前置准备在开始抓包之前先把 TaoToken 的通道准备好。这不是让你用 TaoToken 替代 SIP 服务器而是把它当作一个独立的网络出口验证工具。当 QuteCom 的 INVITE 发不出去时你需要快速判断是这台机器的网络出口有问题还是 SIP 协议栈配置有问题。TaoToken 的 API 入口是 https://taotoken.net/api 统一 Key 的获取在控制台完成。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 管理页是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。拿到 Key 之后先做一次最简单的连通性验证。用 curl 发一条模型对话请求curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoTokenKey \ -d { model: gpt-4o-mini, messages: [{role: user, content: ping}], max_tokens: 5 }如果这条请求返回 200 并且有正常的 JSON 响应说明你的机器出口网络是通的DNS 解析正常TLS 握手没问题。这时候如果 QuteCom 的 INVITE 还是发不出去问题就锁定在 SIP 协议栈或本地防火墙而不是网络层。如果这条请求也超时或返回 401那说明网络出口本身有问题先解决网络再排查 SIP。注意这里不要用任何代理工具TaoToken 的 API 是直连的。对于需要长期做编码和 Agent 调试的场景可以用 Coding Plan入口是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它提供更稳定的通道适合在排查 SIP 问题的同时跑一些辅助脚本。模型对话的 Web 入口是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 可以快速验证 Key 是否有效。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的 Base URL、Key 格式和 Model ID 说明。这里要强调一个原则TaoToken 只做网络出口和 API 通道的对照验证不参与 SIP 信令。SIP 的 INVITE、401、ACK、BYE 这些还是走你自己的 SIP 服务器。两者是并行的排查线不要混在一起。准备好 Key 之后把它写进环境变量方便后续脚本调用export TAOTOKEN_KEYsk-你的TaoTokenKey export TAOTOKEN_BASEhttps://taotoken.net/api然后验证环境变量是否生效echo $TAOTOKEN_KEY | head -c 8应该输出sk-开头的前 8 个字符。这一步看起来简单但很多 401 问题就是因为 Key 复制时带了空格或换行。3. 可复制的抓包过滤命令与 Phapi/exosip 日志开关配置这一节给出可以直接复制运行的命令和配置片段。分三部分抓包命令、日志开关、以及一个用于对照验证的 JSON 配置。3.1 tcpdump 抓包过滤命令在 QuteCom 运行的主机上用 tcpdump 抓 SIP 流量。假设 SIP 服务器地址是10.0.0.100本地网卡是eth0sudo tcpdump -i eth0 -n -s 0 -w /tmp/qutecom_invite.pcap \ udp port 5060 and (host 10.0.0.100)如果只想看 INVITE 和它的响应用更精确的过滤sudo tcpdump -i eth0 -n -A -s 0 \ udp port 5060 and (host 10.0.0.100) and (udp[8:4] 0x494e5649 or udp[8:4] 0x5349502f)这里的udp[8:4]是在匹配 SIP 消息的前 4 个字节。0x494e5649是 INVI 的十六进制0x5349502f是 SIP/ 的十六进制。这样能同时抓到 INVITE 请求和 SIP 响应。抓包的同时在另一个终端用 Wireshark 实时查看sudo tshark -i eth0 -f udp port 5060 -Y sip -V-Y sip是显示过滤器只展示 SIP 协议的消息。-V展开完整头域。3.2 Phapi/exosip 日志开关QuteCom 的日志开关在编译时通过宏控制。找到qutecom/wifo/eXosip目录下的eXosip.c确认以下宏是否打开#define OSIP_TRACE_ENABLE 1 #define EXOSIP_TRACE_ENABLE 1如果没有在编译配置里加上cmake -DENABLE_OSIP_TRACEON -DENABLE_EXOSIP_TRACEON ..运行时exosip 的日志会输出到 stderr。你可以重定向到文件./qutecom 2/tmp/qutecom_exosip.log然后在日志里搜索关键行grep -n eXosip_initiate_call\|eXosip_build_initial_invite\|401\|Authorization /tmp/qutecom_exosip.logphapi 层的日志在phLinePlaceCall_withCa()附近搜索CALLSTATE_REMOTE_OFFERING可以确认事件是否被触发。3.3 对照验证用的 JSON 配置当你需要确认 TaoToken 通道正常时用这个 JSON 配置做一次请求。保存为/tmp/taotoken_check.json{ model: gpt-4o-mini, messages: [ {role: system, content: You are a network diagnostic assistant.}, {role: user, content: Reply with exactly: NETWORK_OK} ], max_tokens: 10, temperature: 0 }然后执行curl -s -X POST $TAOTOKEN_BASE/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_KEY \ -d /tmp/taotoken_check.json | python3 -m json.tool如果返回的choices[0].message.content是NETWORK_OK说明通道正常。3.4 三件套配置对照表项目SIP 侧TaoToken 侧Base URLsip:10.0.0.100:5060https://taotoken.net/apiKey/凭证SIP 账号密码sk-开头的 API KeyModel/目标被叫 SIP URIgpt-4o-mini等 Model ID这张表的作用是当 SIP 侧 401 时用 TaoToken 侧同样的 Key 逻辑去验证如果 TaoToken 返回 200 而 SIP 返回 401说明问题在 SIP 鉴权配置不在网络。4. 验证请求与成功结果逐条比对 INVITE 头域与响应码抓包和日志都打开之后开始逐条比对。这一节给出具体的验证动作和预期结果。4.1 确认 INVITE 是否真正发出在 tcpdump 的输出里找到第一个 INVITE 包。正常的 INVITE 请求行应该是INVITE sip:100110.0.0.100:5060 SIP/2.0如果抓不到任何 INVITE但 exosip 日志里显示eXosip_initiate_call()被调用了说明包在协议栈内部就被丢弃了。常见原因是eXosip_build_initial_invite()返回了错误码或者本地 SIP 端口被占用。检查本地端口sudo ss -ulnp | grep 5060如果 5060 被其他进程占用QuteCom 会绑定失败INVITE 发不出去。4.2 比对 INVITE 头域抓到 INVITE 后重点看这几个头域Via: SIP/2.0/UDP 192.168.1.50:5060;branchz9hG4bK-xxx From: User sip:100010.0.0.100;tagxxx To: sip:100110.0.0.100 Contact: sip:1000192.168.1.50:5060 Authorization: Digest username1000, realm10.0.0.100, noncexxx, urisip:100110.0.0.100, responsexxx逐条检查Via 里的 IP 和端口必须是 QuteCom 实际监听的地址。如果 Via 里是127.0.0.1或者错误的网卡 IP对端无法回包表现为超时。From 和 To 的 URI 必须和 SIP 服务器配置的域一致。如果 From 里是sip:1000localhost而服务器期望sip:100010.0.0.100服务器可能直接返回 403 或 401。Contact 里的地址必须是可达的。如果 Contact 是内网地址而服务器在外网回包会丢失。Authorization 头域只在收到 401 后的第二次 INVITE 里出现。如果第一次 INVITE 就没有 Authorization服务器返回 401 是正常的关键看第二次 INVITE 有没有带上正确的 response。4.3 分析响应码用 tshark 过滤响应sudo tshark -i eth0 -f udp port 5060 -Y sip.Status-Code -T fields \ -e ip.src -e ip.dst -e sip.Status-Code -e sip.CSeq预期输出类似10.0.0.100 192.168.1.50 401 1 INVITE 192.168.1.50 10.0.0.100 401 1 ACK 192.168.1.50 10.0.0.100 200 2 INVITE 10.0.0.100 192.168.1.50 200 2 OK如果只有 401 没有后续的 200说明第二次 INVITE 的 Authorization 计算错误。检查 SIP 账号密码是否包含特殊字符以及 realm 和 nonce 是否被正确解析。如果连 401 都没有只有超时说明 INVITE 根本没到服务器。回到 4.1 检查网络和端口。4.4 用 TaoToken 做对照验证在 SIP 排查的同时跑一次 TaoToken 的验证请求curl -s -o /tmp/taotoken_resp.json -w %{http_code} \ -X POST $TAOTOKEN_BASE/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_KEY \ -d /tmp/taotoken_check.json如果返回200说明网络出口正常。如果返回401说明 Key 无效或过期。如果返回000说明连接超时网络层有问题。这个对照的意义在于当 SIP 返回 401 时你无法确定是 SIP 账号问题还是网络问题。TaoToken 返回 200 就排除了网络问题把范围缩小到 SIP 鉴权配置。4.5 成功结果的标志一次成功的拨号在抓包里应该看到完整的四次握手第一次 INVITE → 401 → ACK → 第二次 INVITE带 Authorization→ 100 Trying → 180 Ringing → 200 OK → ACK。在 QuteCom 界面上状态会从正在拨号变成振铃最后变成通话中。exosip 日志里会看到eXosip_event_wait返回EXOSIP_CALL_PROCEEDING、EXOSIP_CALL_RINGING、EXOSIP_CALL_ANSWERED等事件。如果卡在 401 之后的 ACK说明 ACK 没有正确发送。检查eXosip_initiate_call()之后的eXosip_event_wait循环是否处理了EXOSIP_CALL_UNAUTHORIZED事件。5. 本篇常见错误排查401、local proxy failed、reading choices、OAuth这一节列出实际排查中遇到的真实报错以及对应的处理动作。5.1 SIP 401 Unauthorized报错表现抓包里第一次 INVITE 后立刻返回 401第二次 INVITE 后仍然 401或者直接超时。排查步骤先确认 SIP 账号密码。在 QuteCom 的账户设置里重新输入密码注意不要有前后空格。然后用osip_authorization的日志确认 response 值是否变化。如果两次 401 的 nonce 相同但 response 相同说明密码没变或者计算逻辑有问题。检查 realm。服务器返回的 401 里会带WWW-Authenticate: Digest realm10.0.0.100, noncexxx。QuteCom 计算 response 时必须用这个 realm不能用配置文件里的默认值。如果确认密码和 realm 都对检查Authorization头域的uri字段。它必须和 INVITE 请求行的 URI 完全一致。有些服务器对 uri 大小写敏感。5.2 local proxy failed报错表现exosip 日志里出现local proxy failed或eXosip_initiate_call返回负数。这个错误通常是本地 SIP 监听端口绑定失败。检查sudo ss -ulnp | grep 5060 sudo ss -ulnp | grep 5061如果有其他进程占用先停掉。QuteCom 默认用 5060如果被占用会尝试 5061但有些配置只监听 5060。另一个原因是防火墙拦截了本地回环。检查 iptablessudo iptables -L -n | grep 5060如果有 DROP 规则加上放行sudo iptables -I INPUT -p udp --dport 5060 -j ACCEPT5.3 reading choices 报错报错表现在对照验证 TaoToken 通道时返回的 JSON 里没有choices字段或者解析时报KeyError: choices。这个错误说明 API 返回的不是标准的 chat completion 格式。可能原因Key 无效返回的是错误 JSON。用curl -v看完整响应curl -v -X POST $TAOTOKEN_BASE/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_KEY \ -d /tmp/taotoken_check.json 21 | tail -30如果返回 401检查 Key 是否以sk-开头是否过期。如果返回 404检查 Base URL 是否写成了https://taotoken.net/api而不是其他路径。Model ID 写错也会导致返回错误。确认gpt-4o-mini这个 Model ID 在你的账号下可用。可以在模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 里先手动发一条消息验证。5.4 OAuth 相关报错报错表现在配置 Claude Code 或类似工具时出现 OAuth 认证失败。如果你在用 Claude Code 接入需要配置三件套Base URL、Key、Model ID。Base URL 是https://taotoken.net/apiKey 是sk-开头的字符串Model ID 根据你的套餐选择。Claude Code 的配置入口在 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude-code-anthropicutm_campaignrewrite 里面有完整的 settings 片段。如果出现 OAuth 报错先确认没有混用其他认证方式。TaoToken 用的是 Bearer Token不需要 OAuth 流程。在配置文件里只保留Authorization: Bearer sk-xxx这一种认证头。5.5 排查对照表报错可能原因处理动作SIP 401密码错误/realm 不匹配重新输入密码检查 WWW-Authenticatelocal proxy failed5060 端口被占用ss -ulnp检查并释放端口reading choicesKey 无效/Model ID 错误curl -v看完整响应验证 KeyOAuth 失败认证方式混用只保留 Bearer Token6. 用 TaoToken 统一 Key 做长期 SIP 排查的接入方式SIP 排查不是一次性的。每次改配置、换网络、升级 QuteCom 版本都可能重新出现 INVITE 无响应或 401。把 TaoToken 的统一 Key 固定成排查流程的一部分可以快速区分网络问题和协议问题。接入方式很简单在排查脚本里加一段 TaoToken 连通性检查。每次开始 SIP 排查前先跑一次#!/bin/bash # sip_debug_precheck.sh TAOTOKEN_KEY${TAOTOKEN_KEY:-} if [ -z $TAOTOKEN_KEY ]; then echo TAOTOKEN_KEY not set exit 1 fi HTTP_CODE$(curl -s -o /tmp/taotoken_precheck.json -w %{http_code} \ -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_KEY \ -d {model:gpt-4o-mini,messages:[{role:user,content:ping}],max_tokens:3}) if [ $HTTP_CODE 200 ]; then echo NETWORK_OK else echo NETWORK_FAIL code$HTTP_CODE cat /tmp/taotoken_precheck.json fi这个脚本返回NETWORK_OK时你就可以放心去抓 SIP 包因为网络层已经确认没问题。返回NETWORK_FAIL时先解决网络别浪费时间在 SIP 配置上。对于需要长期跑 Agent 做自动化排查的场景Coding Plan 提供更稳定的通道入口是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。你可以把上面的 precheck 脚本挂到 cron 里每小时跑一次记录网络可用性。API Keys 的管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 建议为排查脚本单独创建一个 Key方便审计和轮换。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的错误码说明和请求示例。最后给一个实际踩过的坑QuteCom 的 exosip 日志默认不打印 Authorization 头域的内容只打印osip_authorization结构体的地址。如果你需要看具体的 response 值得在eXosip.c里手动加一行OSIP_TRACE(osip_trace(__FILE__, __LINE__, OSIP_INFO1, NULL, auth response: %s\n, auth-response));。加完之后重新编译就能在日志里看到每次 401 后计算的 response 值和抓包里的值对比很快就能定位是密码错了还是 nonce 解析错了。