SIP 订阅收到 486 BUSY HERE
我正在尝试订阅观察者列表，服务器经常响应 486 BUSY HERE。然而，RFC 将 486 描述为 INVITE 的可能响应，这对于此响应更有意义。
在其他时候，服务器确实会正确响应 - 使用 200 OK，后跟 NOTIFY 请求。
< br> 我正在使用 ALU IMS 核心。
有人见过这个问题吗？
我的订阅请求：
SUBSCRIBE sip:[email protected];transport=TCP SIP/2.0
Call-ID: [email protected]
CSeq: 4 SUBSCRIBE
From: "XXXX" <sip:[email protected]>;tag=92521573
To: <sip:[email protected]>
Via: SIP/2.0/TCP 10.0.2.15:5060;branch=z9hG4bK68630e2ec7c21d2e991854010b7f64543332
Max-Forwards: 70
Contact: <sip:[email protected]: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:[email protected]:5060;transport=TCP;lr>
Expires: 3600
Content-Length: 0
I am trying to SUBSCRIBE to a watcher list and the server frequently responds with 486 BUSY HERE. However, the RFCs describe 486 as a possible response for an INVITE, which make more sense for this response.
At other times, the server does respond correctly - with a 200 OK, followed by a NOTIFY request.
I am working with an ALU IMS core.
Has anyone seen this issue?
My SUBSCRIBE Request:
SUBSCRIBE sip:[email protected];transport=TCP SIP/2.0
Call-ID: [email protected]
CSeq: 4 SUBSCRIBE
From: "XXXX" <sip:[email protected]>;tag=92521573
To: <sip:[email protected]>
Via: SIP/2.0/TCP 10.0.2.15:5060;branch=z9hG4bK68630e2ec7c21d2e991854010b7f64543332
Max-Forwards: 70
Contact: <sip:[email protected]: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:[email protected]:5060;transport=TCP;lr>
Expires: 3600
Content-Length: 0
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于 SIP 响应代码，需要记住的是，对于在所有情况下应使用哪种特定响应代码，没有硬性规定。 SIP 服务器或 UAS 上的现实世界错误情况总是不会完全落入 SIP 故障响应代码之一的定义中，因此使用最接近的一个，并且可以自定义状态消息和/或添加警告标头。
对于 SUBSCRIBE 请求来说，486 响应有点不寻常，但它很容易理解。例如，如果维护订阅的 SIP 通知服务器对其维护的活动订阅数量有限制，或者如果它过载并且暂时不想处理订阅请求。
我会仔细查看 486 响应，看看是否有警告或任何其他信息类型标头。还要检查响应是否来自您正在使用的中间代理或最终服务器。
The thing to remember with SIP response codes is there are no hard and fast rules about which specific response code should be used in all situations. Invariably a real World error condition on a SIP server or UAS does not fall neatly into the definition of one of the SIP failure response codes so the closest one is used and the status message may be customised and/or a Warning header added.
The 486 response is a little bit unusual for a SUBSCRIBE request but it could easily make sense. For example if the SIP notification server maintaining the subscriptions has a limit on how many active subscriptions it will maintain or if it's overloaded and doesn't want to process subscription requests for a while.
I'd have a closer look at the 486 response and see if there is a Warning or any other informational type header. Also check whether the response is coming from the intermediate proxy you are using or the end server.
486 不是 RFC3265 中定义的响应代码。您需要跟踪您的服务器（如果可能）以了解它决定发送此类意外错误代码的原因。
抱歉没有提供太多帮助。我已经使用 SIP 多年了，从未听说过 SUBSCRIBE 请求的 486 响应。当你找到原因后，我也想知道。
486 is not a response code define in RFC3265. You need to trace your server (if possible) to understand why it decided to send such an unexpected error code.
Sorry for not being much help. I have been working with SIP for several years and never heard of a 486 response for a SUBSCRIBE request. When you find out the reason I'd like to know about it too.