SIP代理认证失败

发布于 2024-11-04 05:13:29 字数 8057 浏览 7 评论 0原文

我正在开发一个 SIP 用户代理应用程序,该应用程序连接到 Asterisk 服务器并尝试进行拨出呼叫。我正在使用 JAIN SIP API 的 NIST 实现。

当应用程序自行注册时,401(未经授权)响应会使用 WWW-Authenticate 标头对其进行质询。应用程序将 Authorization 标头插入下一个 REGISTER 请求中。这次 Asterisk 返回 200(OK)响应——注册成功。

当应用程序传输 INVITE 请求时,Asterisk 会使用 407(需要代理身份验证)响应进行响应。这次响应包含 Proxy-Authenticate 标头。我的应用程序再次发送 INVITE,但这次带有 Authorization 标头,Asterisk 会使用相同的 407(需要代理身份验证)响应进行响应。

以下是传输的 SIP 消息(“>>”表示传出消息;“<<”表示传入消息):

>>

REGISTER sip:10.0.84.30:5060 SIP/2.0
Call-ID: [email protected]
CSeq: 1 REGISTER
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKc7dd178d3d444ccc059a191e700fc8b73230
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=z9hG4bKc7dd178d3d444ccc059a191e700fc8b73230;received=10.0.85.3
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>
Call-ID: [email protected]
CSeq: 1 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:[email protected]>
Content-Length: 0

<强><<

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKc7dd178d3d444ccc059a191e700fc8b73230;received=10.0.85.3
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>;tag=as3c458716
Call-ID: [email protected]
CSeq: 1 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:[email protected]>
WWW-Authenticate: Digest realm="asterisk",nonce="6fbe5a68"
Content-Length: 0

>>

REGISTER sip:10.0.84.30:5060 SIP/2.0
CSeq: 2 REGISTER
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKffb0be254f93f61fa0dc7ac32b9078a43230
Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Expires: 300
Authorization: Digest username="301",realm="asterisk",nonce="6fbe5a68",response="bc7075e8e241a4109dfa24d6ae95e78c",algorithm=MD5,uri="sip:10.0.84.30:5060",nc=00000001
Call-ID: [email protected]
Content-Length: 0

<<

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

<<

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKffb0be254f93f61fa0dc7ac32b9078a43230;received=10.0.85.3
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>;tag=as3c458716
Call-ID: [email protected]
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 06:42:33 GMT
Content-Length: 0

>>

INVITE sip:302@asterisk SIP/2.0
Call-ID: [email protected]  
CSeq: 3 INVITE
From: <sip:301@asterisk>;tag=KOZWxg
To: <sip:302@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKaa0520efde83907b71d1f76315188c413230
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=- 3513393083 3513393083 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=z9hG4bKaa0520efde83907b71d1f76315188c413230;received=10.0.85.3
From: <sip:301@asterisk>;tag=KOZWxg
To: <sip:302@asterisk>;tag=as5de9ed83
Call-ID: [email protected]
CSeq: 3 INVITE
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:[email protected]>
Proxy-Authenticate: Digest realm="asterisk",nonce="74986b64"
Content-Length: 0

>>

INVITE sip:302@asterisk SIP/2.0
CSeq: 4 INVITE
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:302@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK86f9dbdff9eeca422fbb67321dd45f7a3230
Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Route: <sip:10.0.84.30:5060;lr>
Content-Type: application/sdp
Authorization: Digest   username="301",realm="asterisk",nonce="74986b64",response="a08b8d7ce96cae00e7d334e132bf7358",algorithm=MD5,uri="sip:302@asterisk",nc=00000001
Call-ID: [email protected]
Content-Length: 106

>> ;

v=0
o=- 3513393083 3513393083 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=z9hG4bK86f9dbdff9eeca422fbb67321dd45f7a3230;received=10.0.85.3
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:302@asterisk>;tag=as3c458716
Call-ID: [email protected]
CSeq: 4 INVITE
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:10.0.85.3:5060>
Proxy-Authenticate: Digest realm="asterisk",nonce="1bd30f50"
Content-Length: 0

在这两种情况下,授权标头的构造方式完全相同(执行的代码相同)。 我使用请求的 request-URI 作为“digestURI”。 我尝试使用代理授权标头而不是授权标头,但结果是相同的。

谁能看到我做错了什么吗? 提前致谢。

I'm developing a SIP user agent application that connects to an Asterisk server and tries to do an outgoing call. I'm using the NIST implementation of the JAIN SIP API.

When the application registers itself, a 401 (Unauthorized) response challenges it with a WWW-Authenticate header. The application inserts the Authorization header into the next REGISTER request. This time Asterisk returns a 200 (OK) response - the registration is successful.

When the application transmits an INVITE request, Asterisk responds with a 407 (Proxy Authentication Required) response. This time the response contains a Proxy-Authenticate header. My application sends an INVITE again, but this time with the Authorization header, upon which Asterisk responds with the same 407 (Proxy Authentication Required) response.

Here are the SIP messages that are transmitted ('>>' indicates outgoing messages; '<<' indicates incoming messages):

>>

REGISTER sip:10.0.84.30:5060 SIP/2.0
Call-ID: [email protected]
CSeq: 1 REGISTER
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKc7dd178d3d444ccc059a191e700fc8b73230
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=z9hG4bKc7dd178d3d444ccc059a191e700fc8b73230;received=10.0.85.3
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>
Call-ID: [email protected]
CSeq: 1 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:[email protected]>
Content-Length: 0

<<

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKc7dd178d3d444ccc059a191e700fc8b73230;received=10.0.85.3
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>;tag=as3c458716
Call-ID: [email protected]
CSeq: 1 REGISTER
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:[email protected]>
WWW-Authenticate: Digest realm="asterisk",nonce="6fbe5a68"
Content-Length: 0

>>

REGISTER sip:10.0.84.30:5060 SIP/2.0
CSeq: 2 REGISTER
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKffb0be254f93f61fa0dc7ac32b9078a43230
Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Expires: 300
Authorization: Digest username="301",realm="asterisk",nonce="6fbe5a68",response="bc7075e8e241a4109dfa24d6ae95e78c",algorithm=MD5,uri="sip:10.0.84.30:5060",nc=00000001
Call-ID: [email protected]
Content-Length: 0

<<

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

<<

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKffb0be254f93f61fa0dc7ac32b9078a43230;received=10.0.85.3
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:301@asterisk>;tag=as3c458716
Call-ID: [email protected]
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 06:42:33 GMT
Content-Length: 0

>>

INVITE sip:302@asterisk SIP/2.0
Call-ID: [email protected]  
CSeq: 3 INVITE
From: <sip:301@asterisk>;tag=KOZWxg
To: <sip:302@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bKaa0520efde83907b71d1f76315188c413230
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=- 3513393083 3513393083 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=z9hG4bKaa0520efde83907b71d1f76315188c413230;received=10.0.85.3
From: <sip:301@asterisk>;tag=KOZWxg
To: <sip:302@asterisk>;tag=as5de9ed83
Call-ID: [email protected]
CSeq: 3 INVITE
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:[email protected]>
Proxy-Authenticate: Digest realm="asterisk",nonce="74986b64"
Content-Length: 0

>>

INVITE sip:302@asterisk SIP/2.0
CSeq: 4 INVITE
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:302@asterisk>
Via: SIP/2.0/UDP 10.0.85.3:5060;branch=z9hG4bK86f9dbdff9eeca422fbb67321dd45f7a3230
Max-Forwards: 70
Contact: <sip:10.0.85.3:5060>
Route: <sip:10.0.84.30:5060;lr>
Content-Type: application/sdp
Authorization: Digest   username="301",realm="asterisk",nonce="74986b64",response="a08b8d7ce96cae00e7d334e132bf7358",algorithm=MD5,uri="sip:302@asterisk",nc=00000001
Call-ID: [email protected]
Content-Length: 106

>>

v=0
o=- 3513393083 3513393083 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=z9hG4bK86f9dbdff9eeca422fbb67321dd45f7a3230;received=10.0.85.3
From: <sip:301@asterisk>;tag=2B3n8g
To: <sip:302@asterisk>;tag=as3c458716
Call-ID: [email protected]
CSeq: 4 INVITE
User-Agent: Asterisk PBX (switchvox)
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:10.0.85.3:5060>
Proxy-Authenticate: Digest realm="asterisk",nonce="1bd30f50"
Content-Length: 0

The Authorization header is constructed in exactly the same way in both cases (same code that is executed).
I'm using the request's request-URI for "digestURI".
I've tried using a Proxy-Authorization header instead of an Authorization header, but the result is the same.

Can anyone see what I'm doing wrong?
Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

傾城如夢未必闌珊 2024-11-11 05:13:30

我已经解决了这个问题。
Asterisk 似乎无法将我的第二个 INVITE 请求与前面的 407(需要代理身份验证)响应关联起来,其中包含代理身份验证标头的随机数值。

这是因为我没有为两个 INVITE 请求使用相同的 Call-ID 值和 From-header 标记。对于包含代理身份验证标头的第二个 INVITE 请求,我不小心使用了第一个 REGISTER 请求的 Call-ID 和 From-header 标记值,而不是第一个 INVITE 请求。

不过,INVITE 尚未成功。对于第二个响应,我现在得到 488(此处不可接受),但我会尝试在另一个问题中找出现在的问题。

I've solved the problem.
It seems that Asterisk could not associate my second INVITE request to the preceding 407 (Proxy Authentication Required) response, containing the nonce value for the Proxy-Authentication header.

This was because I didn't use the same values for Call-ID and the tag of the From-header for the two INVITE requests. For the second INVITE request, which contains the Proxy-Authentication Header, I've accidentally used the Call-ID and From-header tag values of the first REGISTER request, instead of the first INVITE request.

The INVITE does not yet succeed, though. For the second response I now get 488 (Not acceptable here), but I will try to find out what is wrong now in a different question.

浅沫记忆 2024-11-11 05:13:30

你的 Asterisk 服务器响应 407 有点奇怪,我刚刚检查了我的服务器,它响应 401。毕竟 Asterisk 是 B2BUA 而不是代理。我建议在经过身份验证的请求中尝试授权标头,而不是代理授权,因为它适用于我的 Asterisk 服务器。

此外,您还需要在摘要中使用请求 URI,而不是 From 标头 URI。所以在你的情况下它应该是 uri=sip:302@asterisk。

It's s bit strange that your Asterisk server is responding with a 407 I just checked mine and it responds with 401. Asterisk is after all a B2BUA rather than a proxy. I'd recommend trying an Authorization header in the authenticated request rather than Proxy-Authorization as that works with my Asterisk server.

Also you need to use the request URI in the digest and not the From header URI. So in your case it should be uri=sip:302@asterisk.

稳稳的幸福 2024-11-11 05:13:29

要对代理进行身份验证(换句话说,您需要 407 代理身份验证),您需要一个 Proxy-Authorization 标头。

RFC 2617 说,你可以用同样的方式构建它 的 Authorization 标头一样

就像您在问题中提到 RFC 2617 第 3.2.2 节 表示您使用 Request-URI (sip:302@asterisk)。观看请参阅 RFC 3261 第 22.4 节 中针对 SIP 的更改。

For authenticating to a proxy (in other words you got a 407 Proxy Authentication Required you need a Proxy-Authorization header.

As RFC 2617 says, you construct this in the same way as you would an Authorization header.

You mention using the From URI in your question. RFC 2617 section 3.2.2 says you use the Request-URI (sip:302@asterisk). Watch out for the SIP-specific changes in RFC 3261 section 22.4.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文