Asterisk 401 rejecting Subscribe requests

Asterisk Asterisk Support
1

Good day,

I’m trying to set up a video conferencing solution with Asterisk. Right now, I have an Asterisk 11 server, a Cisco SX20 Telepresence box and two laptops with MicroSIP. The current system works, but I need presentation sharing and Far-End Camera Control, so I’d like to get Cisco Jabber Video softphones to register to Asterisk. Unfortunately, CJV doesn’t have many configuration options. I can set a SIP domain, external and internal servers (all of which point at Asterisk) and basic login info. When I try to register it to Asterisk, it sends out a “301 Subscribe” request, which Asterisk rejects with “401 Unauthorized”. This continues until Asterisk replies with “482 Loop Detected”.

SIP debug log from Asterisk:

<--- SIP read from TCP:10.X.X.149:49689 --->
SUBSCRIBE sip:1015@10.X.X.4 SIP/2.0
Via: SIP/2.0/TCP 10.X.X.149:49689;branch=z9hG4bK1d6bff2922da73f9f93b20aa0d28083d.1;rport
Call-ID: 6966e79621b94004@127.0.0.1
CSeq: 301 SUBSCRIBE
Contact: <sip:1015@10.X.X.149:49689;transport=tcp>
From: <sip:1015@10.X.X.4>;tag=d590bdc6fbddda85
To: <sip:provisioning@10.X.X.4>
Max-Forwards: 70
Route: <sip:10.X.X.4:5060;lr;transport=tcp>
User-Agent: TANDBERG/774 (MCX 4.5.7.16762) - Windows
Expires: 300
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.5.7.16762;clientid="S-1-5-21-3285856091-3657218573-1113374853";connectivity=0
Accept: application/pidf+xml
Content-Length: 0

<------------->
--- (14 headers 0 lines) ---
Sending to 10.X.X.149:49689 (no NAT)
Creating new subscription
Sending to 10.X.X.149:49689 (no NAT)
list_route: hop: <sip:1015@10.X.X.149:49689;transport=tcp>
Found peer '1015' for '1015' from 10.X.X.149:49689

<--- Transmitting (no NAT) to 10.X.X.149:49689 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 10.X.X.149:49689;branch=z9hG4bK1d6bff2922da73f9f93b20aa0d28083d.1;received=10.X.X.149;rport=49689
From: <sip:1015@10.X.X.4>;tag=d590bdc6fbddda85
To: <sip:provisioning@10.X.X.4>;tag=as7d765496
Call-ID: 6966e79621b94004@127.0.0.1
CSeq: 301 SUBSCRIBE
Server: Asterisk PBX 11.12.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="001f07a1"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '6966e79621b94004@127.0.0.1' in 32000 ms (Method: SUBSCRIBE)

<--- SIP read from TCP:10.X.X.149:49689 --->
SUBSCRIBE sip:1015@10.X.X.4 SIP/2.0
Via: SIP/2.0/TCP 10.X.X.149:49689;branch=z9hG4bK942a294a1b5dfd406a4cf7d2d9981ee0.1;rport
Call-ID: 6966e79621b94004@127.0.0.1
CSeq: 301 SUBSCRIBE
Contact: <sip:1015@10.X.X.149:49689;transport=tcp>
From: <sip:1015@10.X.X.4>;tag=d590bdc6fbddda85
To: <sip:provisioning@10.X.X.4>
Max-Forwards: 70
Route: <sip:10.X.X.4:5060;lr;transport=tcp>
User-Agent: TANDBERG/774 (MCX 4.5.7.16762) - Windows
Expires: 300
Authorization: Digest nonce="001f07a1", realm="asterisk", username="1015", uri="sip:10.X.X.4", response="04fa6e73ec9682137c11b781141af73c", algorithm=MD5
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.5.7.16762;clientid="S-1-5-21-3285856091-3657218573-1113374853";connectivity=0
Accept: application/pidf+xml
Content-Length: 0

<------------->
--- (15 headers 0 lines) ---
Sending to 10.X.X.149:49689 (no NAT)

<--- Transmitting (no NAT) to 10.X.X.149:49689 --->
SIP/2.0 482 (Loop Detected)
Via: SIP/2.0/TCP 10.X.X.149:49689;branch=z9hG4bK942a294a1b5dfd406a4cf7d2d9981ee0.1;received=10.X.X.149;rport=49689
From: <sip:1015@10.X.X.4>;tag=d590bdc6fbddda85
To: <sip:provisioning@10.X.X.4>;tag=as344f0739
Call-ID: 6966e79621b94004@127.0.0.1
CSeq: 301 SUBSCRIBE
Server: Asterisk PBX 11.12.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


<------------>

<--- SIP read from TCP:10.X.X.149:49689 --->
SUBSCRIBE sip:1015@10.X.X.4 SIP/2.0
Via: SIP/2.0/TCP 10.X.X.149:49689;branch=z9hG4bKab328577d0c98f2add19addad2b63206.1;rport
Call-ID: 46a6226fdf502f78@10.X.X.149
CSeq: 501 SUBSCRIBE
Contact: <sip:1015@10.X.X.149:49689;transport=tcp>
From: <sip:1015@10.X.X.4>;tag=97737c28eab28ec2
To: <sip:provisioning@10.X.X.4>
Max-Forwards: 70
Route: <sip:10.X.X.4:5060;lr;transport=tcp>
User-Agent: TANDBERG/774 (MCX 4.5.7.16762) - Windows
Expires: 300
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.5.7.16762;clientid="S-1-5-21-3285856091-3657218573-1113374853";connectivity=1
Accept: application/pidf+xml
Content-Length: 0

<------------->
--- (14 headers 0 lines) ---
Sending to 10.X.X.149:49689 (no NAT)
Creating new subscription
Sending to 10.X.X.149:49689 (no NAT)
list_route: hop: <sip:1015@10.X.X.149:49689;transport=tcp>
Found peer '1015' for '1015' from 10.X.X.149:49689

<--- Transmitting (no NAT) to 10.X.X.149:49689 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 10.X.X.149:49689;branch=z9hG4bKab328577d0c98f2add19addad2b63206.1;received=10.X.X.149;rport=49689
From: <sip:1015@10.X.X.4>;tag=97737c28eab28ec2
To: <sip:provisioning@10.X.X.4>;tag=as7413398a
Call-ID: 46a6226fdf502f78@10.X.X.149
CSeq: 501 SUBSCRIBE
Server: Asterisk PBX 11.12.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="332c71bc"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '46a6226fdf502f78@10.X.X.149' in 32000 ms (Method: SUBSCRIBE)

<--- SIP read from TCP:10.X.X.149:49689 --->
SUBSCRIBE sip:1015@10.X.X.4 SIP/2.0
Via: SIP/2.0/TCP 10.X.X.149:49689;branch=z9hG4bK3a234bd8c8e0fd1e2ea665f086f59bc3.1;rport
Call-ID: 46a6226fdf502f78@10.X.X.149
CSeq: 501 SUBSCRIBE
Contact: <sip:1015@10.X.X.149:49689;transport=tcp>
From: <sip:1015@10.X.X.4>;tag=97737c28eab28ec2
To: <sip:provisioning@10.X.X.4>
Max-Forwards: 70
Route: <sip:10.X.X.4:5060;lr;transport=tcp>
User-Agent: TANDBERG/774 (MCX 4.5.7.16762) - Windows
Expires: 300
Authorization: Digest nonce="332c71bc", realm="asterisk", username="1015", uri="sip:10.X.X.4", response="88fb05a307d8f921a88187ed08cbce30", algorithm=MD5
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.5.7.16762;clientid="S-1-5-21-3285856091-3657218573-1113374853";connectivity=1
Accept: application/pidf+xml
Content-Length: 0

<------------->
--- (15 headers 0 lines) ---
Sending to 10.X.X.149:49689 (no NAT)

<--- Transmitting (no NAT) to 10.X.X.149:49689 --->
SIP/2.0 482 (Loop Detected)
Via: SIP/2.0/TCP 10.X.X.149:49689;branch=z9hG4bK3a234bd8c8e0fd1e2ea665f086f59bc3.1;received=10.X.X.149;rport=49689
From: <sip:1015@10.X.X.4>;tag=97737c28eab28ec2
To: <sip:provisioning@10.X.X.4>;tag=as21a52906
Call-ID: 46a6226fdf502f78@10.X.X.149
CSeq: 501 SUBSCRIBE
Server: Asterisk PBX 11.12.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


<------------>

Sip.conf:

[code][general]
transport=udp
videosupport=yes
callcounter=yes
allowguest=yes
tcpenable=yes
tcpbindaddr=0.0.0.0
allowsubscribe=yes

internal
type=friend
secret=insertpasswordofchoicehere
host=dynamic
context=internal
disallow=all
allow=h264,h263,speex,ulaw,alaw,gsm
busylevel=10
[/code]

Is the issue here that I haven’t enabled the other Subscribe features, such as Notify on Hold? Or something else? I’m really kinda stumped here and running low on time to get it working. Can someone help me figure this out?

Best regards,
Martin

2

The 301 is a sequence number and nothing to do with the request type.

The 401 response is not causing a problem; it is normal to get 401 and then retry with the right credentials.

The actual error is the Loop Detected one.

The peer is definitely in contravention of this requirement in section 8.1.3.5 of RFC 3261, but it’s not clear to me why this should cause a loop detected rejection, although Asterisk may well be confused by the fact that it previously rejected the request for other reasons, but those other reasons are no longer valid.

[quote] In all of the above cases, the request is retried by creating a [color=#FF0000]new[/color]
request with the appropriate modifications. This new request
constitutes a new transaction and SHOULD have the same value of the
Call-ID, To, and From of the previous request, but the CSeq should
contain [color=#FF0000]a new sequence number that is one higher than the previous[/color].
[/quote]

3

Ah, I see what you mean. Sorry, I’m still new to VoIP in general.

Alright, since Cisco Jabber not incrementing CSeq seems to be the issue, is there anything I can do in Asterisk that might resolve this? Don’t suppose turning off loop detection (if that’s even possible) is a viable solution?

4

Looking at the code, I don’t see a way of disabling this error case handling.

The one thing that was confusing me is why it didn’t treat it as a duplicate, but that is because, although the CSEQ wasn’t changed, the branch id was changed. Asterisk thinks the request has been branched and it is seeing a duplicate on another branch.

Asterisk is not actually getting confused, it is positively recognizing this as an error case for which a 482 response is appropriate.

The easiest solution is to turn off authentication and rely entirely on IP address checks for security.

5

Looking at bit closer, it looks like this test is only done in pedantic SIP checking mode, so, if you disable that, it may work.

6

No dice. Turning off pedantic checking switched the error to a 489 Bad Event. Setting “insecure=port,invite” does nothing, but from what I understand, it only works for incoming INVITEs anyway.