Golang+FreeSWITCH软电话外呼INVITE重复返回407认证错误排查

核心错误点 #

从抓包信令看，呼叫失败是两个明确的SIP协议实现错误导致的，和账号密码、FreeSWITCH侧配置无关：

• 认证响应头字段使用错误：服务端返回407挑战时使用Proxy-Authenticate头携带认证参数，客户端携带认证信息重试请求时，必须使用Proxy-Authorization头传递计算后的认证信息。当前实现直接把服务端返回的Proxy-Authenticate头原样塞入第二次INVITE请求，FreeSWITCH无法识别到携带的认证内容，判定请求未完成认证。
• CSeq序号不符合规范要求：第一次发起INVITE请求时CSeq值为1 INVITE，按照RFC3261协议要求，同个呼叫场景下响应407挑战重试INVITE时，CSeq序号仅需在原值基础上加1，即应为2 INVITE。当前实现第二次发INVITE时CSeq直接跳为4 INVITE，FreeSWITCH会将其判定为全新的INVITE请求，而非对前一次407挑战的应答，因此生成了全新的nonce值（第二次返回407的nonce从81f85e27-b5d0-4b27-9358-5eded4524e3a变为edbe6f39-3aa5-4034-8df8-aae050b77e1a可佐证），再次发起认证挑战。

修复方案 #

1. 修正认证头字段：将第二次INVITE请求中的Proxy-Authenticate头替换为Proxy-Authorization头，头内携带的Digest认证参数保持原有计算逻辑即可。
2. 修正CSeq递增逻辑：重试认证请求时，CSeq序号在原请求基础上+1，禁止跳号。
3. 兜底校验Digest计算逻辑：若修复上述两点后仍返回407，再核对MD5哈希计算逻辑是否符合RFC2617规范（因REGISTER流程可正常完成，该部分逻辑出错概率极低）：
   • 当qop=auth时，HA1 = MD5(用户名:域:密码)
   • HA2 = MD5(请求方法:请求URI)
   • response = MD5(HA1:nonce:nc:cnonce:qop:HA2)

正常流程验证标准 #

修复后信令流程应符合预期：

• 发送无认证信息的INVITE（CSeq=1）
• 接收407 Proxy Authentication Required响应
• 发送携带Proxy-Authorization认证信息的INVITE（CSeq=2，使用第一次407返回的nonce值计算认证参数）
• 收到100 Trying/180 Ringing/200 OK响应，呼叫正常建立

内容的提问来源于stack exchange，提问作者it'Simon