Baresip项目中如何避免自动发送180 Ringing响应的问题分析

问题背景

在Baresip项目中，当接收到一个INVITE请求时，系统会自动发送180 Ringing响应。这一行为在某些场景下可能并不理想，比如当应用程序需要先进行某些处理或验证后再决定是否接受呼叫时。开发者希望能够在应用程序层面控制是否发送180 Ringing响应，而不是由系统自动发送。

技术分析

当前实现机制

在Baresip的当前实现中，call_accept函数会直接调用sipsess_accept并硬编码发送180 Ringing响应：

err = sipsess_accept(&call->sess, sess_sock, msg, 180, "Ringing",
                     account_rel100_mode(call->acc),
                     ua_cuser(call->ua), "application/sdp", NULL,
                     auth_handler, call->acc, true,
                     sipsess_offer_handler, sipsess_answer_handler,
                     sipsess_estab_handler, sipsess_info_handler,
                     call->acc->refer ? sipsess_refer_handler : NULL,
                     sipsess_close_handler,
                     call, "Allow: %H\r\n%H",
                     ua_print_allowed, call->ua,
                     ua_print_require, call->ua);

问题根源

这种硬编码方式导致应用程序无法灵活控制是否发送180 Ringing响应。理想情况下，应该先发送100 Trying响应（这是一个临时响应，表示请求已被接收但尚未处理完毕），然后由应用程序决定是否发送180 Ringing响应。

解决方案

核心修改点

1. 修改sipsess_accept调用：将默认的180 Ringing改为100 Trying响应
2. 添加新的API函数：call_ringing，允许应用程序显式发送180 Ringing响应
3. 调整菜单模块：在需要时才调用call_ringing发送180响应

具体实现

1. 修改sipsess_accept调用：

err = sipsess_accept(&call->sess, sess_sock, msg, 100, "Trying",
                     account_rel100_mode(call->acc),
                     ua_cuser(call->ua), "application/sdp", NULL,
                     auth_handler, call->acc, true,
                     sipsess_offer_handler, sipsess_answer_handler,
                     sipsess_estab_handler, sipsess_info_handler,
                     call->acc->refer ? sipsess_refer_handler : NULL,
                     sipsess_close_handler,
                     call, NULL);

2. 新增call_ringing API：

int call_ringing(struct call *call)
{
    if (!call)
        return EINVAL;

    return sipsess_progress(call->sess, 180, "Ringing",
                account_rel100_mode(call->acc),
                NULL,
                "Allow: %H\r\n%H",
                ua_print_allowed, call->ua,
                ua_print_require, call->ua);
}

3. 菜单模块调整：

if (adelay == -1) {
    call_ringing(call);
    play_incoming(call);
}

技术优势

1. 更符合SIP协议规范：100 Trying是更合适的初始响应，表示请求已被接收但尚未处理
2. 提高灵活性：应用程序可以完全控制是否以及何时发送180 Ringing响应
3. 保持兼容性：不影响现有自动应答(autoanswer)功能
4. 更好的用户体验：只有在用户真正听到铃声时才发送180 Ringing响应

实现细节

sipsess_accept函数修改

原始实现中，sipsess_accept函数对状态码有严格限制(101-299)，这导致无法发送100 Trying响应。修改后允许100状态码：

if (!sessp || !sock || !msg || scode < 100 || scode > 299 ||
    !cuser || !ctype)
    return EINVAL;

状态机流程变化

修改后的流程更加合理：

1. 接收INVITE请求
2. 自动发送100 Trying响应
3. 应用程序处理呼叫（如播放铃声）
4. 应用程序显式调用call_ringing发送180 Ringing响应（如果需要）
5. 最终接受或拒绝呼叫

总结

通过对Baresip核心代码的修改，我们实现了对180 Ringing响应的灵活控制。这一改进不仅解决了原始问题，还使整个呼叫处理流程更加符合SIP协议规范，为应用程序提供了更大的控制权。这种设计模式也更易于扩展，未来可以方便地添加其他类型的临时响应控制。