0

ウォッチャーリストにサブスクライブしようとしていますが、サーバーは486BUSYHEREで頻繁に応答します。ただし、RFCは、486をINVITEの可能な応答として説明しています。これは、この応答の方が理にかなっています。
それ以外の場合、サーバーは正しく応答します。200OKの後に、NOTIFY要求が続きます。

私はALUIMSコアを使用しています。

誰かがこの問題を見たことがありますか？

私の購読リクエスト：

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
4

2 に答える 2

2

SIP 応答コードについて覚えておくべきことは、すべての状況でどの特定の応答コードを使用する必要があるかについて、厳格な規則はないということです。常に、SIP サーバーまたは UAS の現実世界のエラー状態は、SIP 失敗応答コードの 1 つの定義にうまく分類されないため、最も近いものが使用され、ステータス メッセージがカスタマイズされたり、警告ヘッダーが追加されたりする場合があります。

486 応答は SUBSCRIBE 要求としては少し珍しいですが、簡単に理解できます。たとえば、サブスクリプションを維持している SIP 通知サーバーが維持するアクティブなサブスクリプションの数に制限がある場合、または過負荷でしばらくの間サブスクリプション要求を処理したくない場合です。

486 応答を詳しく見て、警告またはその他の情報タイプのヘッダーがあるかどうかを確認します。また、使用している中間プロキシまたはエンド サーバーから応答が送信されているかどうかも確認してください。

于 2011-03-13T22:08:53.573 に答える
1

486 は、RFC3265で定義されている応答コードではありません。サーバーがこのような予期しないエラー コードを送信することを決定した理由を理解するには、(可能であれば) サーバーをトレースする必要があります。

あまり参考にならず申し訳ありません。私は数年間 SIP を使用してきましたが、SUBSCRIBE 要求に対する 486 応答は聞いたことがありません。理由が分かれば私も知りたいです。

于 2011-03-13T15:48:45.797 に答える