2011-03-13 64 views
0

我想訂閱一個觀察者列表,並且服務器經常以486忙於響應。但是,RFC將486描述爲INVITE的可能響應,這對於此響應更有意義。
在其他時候,服務器確實響應正確 - 200 OK,然後是NOTIFY請求。

我正在使用ALU IMS核心。

有沒有人看過這個問題?SIP訂閱接收486繁忙這裏

我的SUBSCRIBE請求:

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 

回答

2

用SIP響應代碼記住的事情是沒有硬性規則和快速規則應該在所有情況下使用哪個特定的響應代碼。總之,SIP服務器或UAS上的真實世界錯誤條件並不完整地落入其中一個SIP失敗響應代碼的定義中,因此使用最近的一個,並且可以定製狀態消息和/或添加警告頭。

對於SUBSCRIBE請求,486響應有點不尋常,但它很容易理解。例如,如果維護訂閱的SIP通知服務器對其要維護的活動訂閱數量有限制,或者超出限制並且不想處理訂閱請求一段時間。

我想仔細看看486響應,看看是否有警告或任何其他信息類型的標題。還要檢查響應是來自您正在使用的中間代理還是終端服務器。

+0

我正在執行兩個訂閱:一個用於好友列表,另一個用於觀察者列表。當它失敗時,它只會在觀察者列表中失敗,而不會成爲好友列表。即使我顛倒這兩個訂閱者的順序,也會發生這種情況。 – 2011-03-14 07:24:01

+0

訂閱觀察者列表時,你是否總是失敗?您是否能夠檢查您收到的錯誤回覆,以獲取更多信息,如警告標題。除此之外,瞭解發生了什麼的最好方法是從服務器中找出它爲什麼通過查看其日誌或其他任何其他機制來拒絕請求。 – sipwiz 2011-03-14 11:40:27

+0

我已經向ALU詢問了解釋。與此同時,響應不包括額外的標題。 – 2011-03-14 12:44:59

1

486不是一個響應代碼在RFC3265定義。您需要跟蹤您的服務器(如果可能)以瞭解爲何它決定發送這樣的意外錯誤代碼。

對不起,沒有太大的幫助。我一直與SIP合作多年,從未聽說過SUBSCRIBE請求的486響應。當你發現我也想知道的原因。