問題タブ [jain-sip]

JAIN-SIP スタック (Android デバイス用) からイベントを受信する SipListener インターフェイスを実装するクラスを作成しています。テストするために、2 つのデバイスを OpenSIP に接続し、1 つのデバイスをもう 1 つのデバイスに呼び出してみました。サードパーティのクライアントを使用しても問題ありません。

1 つの奇妙な問題を除いて、すべてが私の基本的な実装でうまく機能しているようです。processRequest で INVITE リクエストを受信すると、RINGING レスポンスを作成し、続いて OK レスポンスを作成します。問題は、(tcpdump によると) RINGING 応答がサーバーに届かないことです。INVITE パケットを受信した後、デバイスは TRYING パケットを送信し (私のコードでは実行しないので、JAIN-SIP の一部である必要があります)、OK パケットを送信します。私はさまざまな例をたどりましたが、それらはすべてこれらの行に沿って何かを示唆しているようです:

参考までに、INVITE ヘッダーは次のようになります。

64.xxx は OpenSIP の IP で、10.xx10 は UAC の IP です。

ヘッダーがないか、RINGING パケットの設定が間違っていますか? どんな助けでも大歓迎です！

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

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

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

私の購読リクエスト：

NIST の JAIN SIP API の実装を使用して REGISTER SIP リクエストを送信しようとしています。

最初に、SipController クラスのデータ メンバーの宣言を行います。

リクエストを送信するコードは次のとおりです。

ステートメントを使用してこのメ​​ソッドを呼び出します

データ メンバー ポートの値は 5060 です。

私がしようとしているのは、ポート 5061 でリッスンしているコンピューターで実行されている別のアプリケーションに要求を送信することです。このアプリケーションは、要求を送信している同じプログラムの別のインスタンスです。

SipProvider クラスの sendRequest() メソッドを呼び出すと、javax.sip.SipException 例外が発生し、「リクエストの送信中に IO 例外が発生しました」というメッセージが表示されます。この例外には、「要求されたアドレスを割り当てることができません: データグラムの送信に失敗しました」というメッセージの原因として、java.net.BindException が含まれています。

スタック トレースは次のとおりです。

私が間違っていることについてのアイデアはありますか？

Asteriskサーバーに接続して発信を試みるSIPユーザーエージェントアプリケーションを開発しています。JAINSIPAPIのNIST実装を使用しています。

アプリケーションがそれ自体を登録すると、401（Unauthorized）応答がWWW-Authenticateヘッダーでアプリケーションにチャレンジします。アプリケーションは、Authorizationヘッダーを次のREGISTERリクエストに挿入します。今回、Asteriskは200（OK）応答を返します-登録は成功します。

アプリケーションがINVITE要求を送信すると、Asteriskは407（プロキシ認証が必要）応答で応答します。今回の応答には、Proxy-Authenticateヘッダーが含まれています。私のアプリケーションは再びINVITEを送信しますが、今回はAuthorizationヘッダーを使用して、Asteriskが同じ407（プロキシ認証が必要）応答で応答します。

送信されるSIPメッセージは次のとおりです（「>>」は送信メッセージを示し、「<<」は受信メッセージを示します）。

>>

<<

<<

>>

<<

<<

>>

>>

<<

>>

>>

<<

Authorizationヘッダーは、どちらの場合もまったく同じ方法で作成されます（実行される同じコード）。「digestURI」にリクエストのリクエストURIを使用しています。Authorizationヘッダーの代わりにProxy-Authorizationヘッダーを使用しようとしましたが、結果は同じです。

誰かが私が間違っていることを見ることができますか？前もって感謝します。

私は、アスタリスク サーバーに接続して発信を試みる SIP ユーザー エージェント アプリケーションを開発しています。JAIN SIP API の NIST 実装を使用しています。

アプリケーションは、最初に自分自身を正常に登録します。次に、アプリケーションが INVITE 要求を X-Lite SIP ソフトフォンに送信すると、Asterisk は 407 (Proxy Authentication Required) 応答で応答します。応答には、Proxy-Authenticate ヘッダーが含まれています。私のアプリケーションは再び INVITE を送信しますが、今度は Proxy-Authorization ヘッダーを使用して、Asterisk が 488 (ここでは受け入れられません) で応答します。

次に、SIP カンバセーションを示します (「>>」は発信メッセージを示し、「<<」は着信メッセージを示します)。

>> REGISTER sip:10.0.84.30:5060 SIP/2.0
Call-ID: 7f2d15884ab375fc7b5d32fdd28426d5@10.0.85.3
CSeq: 1 REGISTER
From: <sip:301@asterisk>;tag=0vmZig
To: <sip:301@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK493cd4b63090dc9a8027931937b737c9353835 Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Expires: 300
Content-Length: 0

<< SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK493cd4b63090dc9a8027931937b737c9353835;received=10.0.85.3
From: <sip:301@asterisk>;tag=0vmZig
To: <sip:301@asterisk>
Call-ID: 7f2d15884ab375fc7b5d32fdd28426d5@10.0.85.3
CSeq: 1 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:301@10.0.84.30>
Content-Length: 0

<< SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK493cd4b63090dc9a8027931937b737c9353835;received=10.0.85.3
From: <sip:301@asterisk>;tag=0vmZig
To: <sip:301@asterisk>;tag=as4d134cc6
Call-ID: 7f2d15884ab375fc7b5d32fdd28426d5@10.0.85.3
CSeq: 1 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:301@10.0.84.30>
WWW-Authenticate: Digest realm="asterisk",nonce="27ca4a51"
Content-Length:0

>> REGISTER sip:10.0.84.30:5060 SIP/2.0
CSeq: 2 REGISTER
From: <sip:301@asterisk>;tag=0vmZig
To: <sip:301@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKe339b4ed9edc5d75379673b6dec7fc42353835 Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Expires: 300
Authorization: Digest username="301",realm="asterisk",nonce="27ca4a51",response="cfdcdff7ddee99d10c3099e88ffb73af",algorithm=MD5,uri="sip:10.0.84.30:5060",nc=00000001
Call-ID: 7f2d15884ab375fc7b5d32fdd28426d5@10.0.85.3
Content-Length: 0

<< SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKe339b4ed9edc5d75379673b6dec7fc42353835;received=10.0.85.3
From: <sip:301@asterisk>;tag=0vmZig
To: <sip:301@asterisk>
Call-ID: 7f2d15884ab375fc7b5d32fdd28426d5@10.0.85.3
CSeq: 2 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:301@10.0.84.30>
Content-Length: 0

<< SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKe339b4ed9edc5d75379673b6dec7fc42353835;received=10.0.85.3
From: <sip:301@asterisk>;tag=0vmZig
To: <sip:301@asterisk>;tag=as4d134cc6
Call-ID: 7f2d15884ab375fc7b5d32fdd28426d5@10.0.85.3
CSeq: 2 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Expires: 300
Contact: <sip:10.0.85.3:5060>;expires=300
Date: Tue, 03 May 2011 09:37:45 GMT
Content-Length: 0

>> INVITE sip:302@asterisk SIP/2.0
Call-ID: 003d85b0d0868f6f2a2d8c324d7f1d54@10.0.85.3
CSeq: 3 INVITE
From: <sip:301@asterisk>;tag=sJSeLA
To: <sip:302@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK6704cd9554c0c8e5bc94bc42b606147a353835 Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Route: <sip:10.0.84.30:5060;lr>
Content-Type: application/sdp
Content-Length: 106

v=0
o=- 3513403599 3513403599 IN IP4 10.0.85.3
s=-
c=IN IP4 10.0.85.3
t=0 0
m=audio 40000 RTP/AVP 3

<< SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK6704cd9554c0c8e5bc94bc42b606147a353835;received=10.0.85.3
From: <sip:301@asterisk>;tag=sJSeLA
To: <sip:302@asterisk>;tag=as7358e1b8
Call-ID: 003d85b0d0868f6f2a2d8c324d7f1d54@10.0.85.3
CSeq: 3 INVITE
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:302@10.0.84.30>
Proxy-Authenticate: Digest realm="asterisk",nonce="55deefb6"
Content-Length: 0

>> INVITE sip:302@asterisk SIP/2.0
CSeq: 4 INVITE
From: <sip:301@asterisk>;tag=sJSeLA
To: <sip:302@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK6e3501c0973664fcd7a17affddd23572353835 Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Route: <sip:10.0.84.30:5060;lr>
Content-Type: application/sdp
Proxy-Authorization: Digest username="301",realm="asterisk",nonce="55deefb6",response="47e2c7abe625e4a183726e29c035d7e0",algorithm=MD5,uri="sip:302@asterisk",nc=00000001
Call-ID: 003d85b0d0868f6f2a2d8c324d7f1d54@10.0.85.3
Content-Length: 106

v=0
o=- 3513403599 3513403599 IN IP4 10.0.85.3
s=-
c=IN IP4 10.0.85.3
t=0 0
m=audio 40000 RTP/AVP 3

<< SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK6e3501c0973664fcd7a17affddd23572353835;received=10.0.85.3
From: <sip:301@asterisk>;tag=sJSeLA
To: <sip:302@asterisk>;tag=as7358e1b8
Call-ID: 003d85b0d0868f6f2a2d8c324d7f1d54@10.0.85.3
CSeq: 4 INVITE
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:302@10.0.84.30>
Content-Length: 0

ここで何が間違っているのか、488 応答が発生しますか?

Jain sipを使用してAndroidでSIPクライアントを開発しています。そして、それを jain-sip-presence-proxy に登録したいと思います。

私のコード:

エラーメッセージは次のとおりです。

手伝って頂けますか？

タイトルはわかるほどわかりやすい。jain-sip のドキュメントを探していますが、見つかりません。jsip.java.net Web サイトにドキュメントへのリンクがありますが、hudson ビルダーに送信されます。

PBX（SIPpでシミュレート）と通信できるソフトフォンを作成しました。このために、私はJava用のjain-sipframeworktを使用します。私の問題は、jain-sipがsipメッセージを自動的に送信することです。たとえば、RE-INVITEメッセージを受信した後、私のプログラムはOKメッセージを送り返しますが、jain-sipは自動的にTRYINGメッセージを送り返します。なぜ？？？

Jain-sipはいくつかのOKメッセージも自動的に送信します。以下のコールフローを参照してください（PBXはINVITEメッセージを私のソフトフォンアプリに送信しています）：

• 招待->
• <-試してみる
• <-リンギング
• <-OK / SDP（ポート番号2000）
• ACK->

• ポート2000でRTPを送信する

• 再招待->

• <-試してみる
• <-OK / SDP（ポート番号2002）
• ACK->
• ポート2002でRTPを送信する
• <-OK / SDP（ポート番号2000）//jain-sipはこのメッセージを自動的に送信します!!!
• ACK->
• ポート2000でRTPを送信する //rtpデータが間違ったポートに送信されるようになりました
• <-OK / SDP（ポート番号2000）//そして再びjain-sipはokメッセージを自動的に送信します
• ACK->
• ポート2000でRTPを送信する //rtpデータが間違ったポートに送信される
• さようなら->
• <-OK

jain-sipがメッセージを自動的に送信するのはなぜですか？何か間違ったことをしたことがありますか、それともsipメッセージの自動送信を無効にすることは可能ですか？

レジストラ/プロキシは401/407でUEに何回チャレンジできますか？このUEがランダムなチャレンジ応答を送信し続ける悪意のあるUEである場合、プロキシ/レジストラがそれ以上の要求を受け付けないようにして、サービス拒否攻撃から自身を保護するにはどうすればよいでしょうか。