Question

我正在尝试订阅一个观察者列表，服务器经常以486 BUSY HERE响应。然而，RFC将INV6描述为INVITE的可能响应，这对于此响应更有意义。
在其他时间，服务器确实正确响应 - 200 OK，然后是NOTIFY请求。

我正在使用ALU IMS核心。

有没有人见过这个问题？

我的订阅请求：

SUBSCRIBE sip:yyyyyyyyyyy@example.com;transport=TCP SIP/2.0
Call-ID: 81fcd7229c882f230c726e21f16aadc9@10.0.2.15
CSeq: 4 SUBSCRIBE
From: "XXXX" <sip:yyyyyyyyyyy@example.com>;tag=92521573
To: <sip:yyyyyyyyyyy@example.com>
Via: SIP/2.0/TCP 10.0.2.15:5060;branch=z9hG4bK68630e2ec7c21d2e991854010b7f64543332
Max-Forwards: 70
Contact: <sip:yyyyyyyyyyy@10.0.2.15:5060;transport=TCP>;+g.oma.sip-im;expires=3600
User-Agent: My Android Client/OMA1.0
Require: pref
Supported: replaces,100rel,eventlist,timer
Event: presence.winfo
Accept: application/watcherinfo+xml
Route: <sip:yyyyyyyyyyy@z.z.z.z:5060;transport=TCP;lr>
Expires: 3600
Content-Length: 0

Answer 1

使用SIP响应代码要记住的事情是，没有关于在所有情况下应该使用哪个特定响应代码的硬性规则。 SIP服务器或UAS上的实际世界错误情况总是不能完全落入其中一个SIP失败响应代码的定义中，因此使用最接近的一个并且可以自定义状态消息和/或添加警告标头。

对于SUBSCRIBE请求，486响应有点不寻常，但它很容易理解。例如，如果维护订阅的SIP通知服务器对其将维护的活动订阅数量有限制，或者它是否过载且不希望暂时处理订阅请求。

我将仔细查看486响应，看看是否有警告或任何其他信息类型标头。还要检查响应是来自您正在使用的中间代理还是来自终端服务器。

Answer 2

486不是RFC3265中定义的响应代码。您需要跟踪您的服务器（如果可能）以了解它为什么决定发送这样的意外错误代码。

很抱歉没有多大帮助。我已经使用SIP工作了几年，从未听说过有关SUBSCRIBE请求的486响应。当你找到我想知道它的原因时。

SIP订阅在这里收到486忙

2 个答案: