提问：
我近期投入了一些时间排查一个与 JsSIP 相关的问题，场景中使用的用户名是自动生成的字符串，包含大小写字母和数字。
在被叫方向 JsSIP 发送 BYE 请求时，JsSIP 返回了 404 响应，且调试控制台中显示错误信息：Request-URI does not point to us（请求 URI 并非指向本端）。
经排查发现，JsSIP 会将 REGISTER 请求收到的 200 OK 响应中的 Contact 字段转换为全小写形式，并使用该值发起新的呼出 INVITE 请求。
但在处理 BYE 请求时，JsSIP 未能将请求中的 URI 与该小写 Contact 值进行正确匹配，从而返回 404 错误。
我注意到 Kamailio 注册器模块（registrar）中存在一个相关配置项：
3.11. case_sensitive（整数类型）
若设置为 1，则 AOR（地址记录）的对比与存储会区分大小写；若设置为 0，则不区分大小写。
此参数为推荐配置项，可通过 Kamailio 配置框架修改。
默认值：0
由于 RFC 规范明确要求用户名的处理需区分大小写，或许将该配置的默认值修改为 1 会是更合理的选择。
RFC 相关原文如下：
SIP 和 SIPS URI 中用户信息（userinfo）的对比是区分大小写的，这包括带有密码的用户信息，或采用电话号码格式的用户信息。
...
以下两组 URI 并不等价：
SIP:ALICE@AtLanTa.CoM;Transport=udp （用户名不同）
sip:alice@AtLanTa.CoM;Transport=UDP
复现步骤
使用包含大小写字母的用户名进行注册操作，该用户名会被 Kamailio 转换为全小写形式存储。
可能的解决方案
修改 case_sensitive 配置项的默认值。
minconda 回答：
我记得当初将该配置默认设为 "不区分大小写" 的决策，是与 RFC 规范相悖的，核心考量是提升用户使用体验------ 尤其是当用户名以真实姓名作为身份标识的场景。
通常用户代理（UA，如桌面或智能手机端的 SIP 应用）会自动将姓名修正为驼峰格式（例如把 alice 转为 Alice）。此外，我们认为让 alice 和 Alice 作为两个独立用户的场景，在实际应用中并不常见。
另外，对于电话号码形式的用户名，匹配逻辑本身也是不区分大小写的。
当然，在用户名是随机生成的字母数字组合的场景下，当前默认配置确实可能引发冲突。
但该默认值已经沿用多年，且过去并未收到大量相关问题反馈。若贸然修改默认值，可能会导致现有 Kamailio 部署环境出现意外的呼叫失败问题，因此我倾向于维持现有默认配置不变。
结论就是，默认值就很好，大小写不敏感，内部自动处理成小写