Why isn't Asterisk accepting these SIP ACKS?

Asterisk Asterisk Support
1

Call dies after 20 seconds with the “no response to critical packet error displayed” yet turning on sip debug shows the ACKs coming in. Can anybody shed some light on this? running Asterisk 11.5.1

[2013-11-12 16:45:07] VERBOSE[21139] chan_sip.c: Retransmitting #3 (NAT) to 70.194.136.72:5583:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 70.194.136.72:5583;branch=z9hG4bK+81320c9c52d5dd46e80b673e6e0e53c01+s111+1;received=70.194.136.72;rport=5583
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
CSeq: 26872 INVITE
Server: FPBX-2.11.0(11.5.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:*97@1.1.1.1:5060>
Content-Type: application/sdp
Content-Length: 562

v=0
o=root 1921268681 1921268681 IN IP4 1.1.1.1
s=Asterisk PBX 11.5.1
c=IN IP4 1.1.1.1
t=0 0
m=audio 11926 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=ptime:20
a=ice-ufrag:0c0eb4fc08e593ea11b001aa0e8ce708
a=ice-pwd:57d491ff7c89b2517bbc695854a9a793
a=candidate:Ha000064 1 UDP 2130706431 2.2.2.2 11926 typ host
a=candidate:Had590e9c 1 UDP 2130706431 1.1.1.1 11926 typ host
a=candidate:Ha000064 2 UDP 2130706430 2.2.2.2 11927 typ host
a=candidate:Had590e9c 2 UDP 2130706430 1.1.1.1 11927 typ host
a=sendrecv

---
[2013-11-12 16:45:07] VERBOSE[21139] chan_sip.c:
<--- SIP read from UDP:70.194.136.72:5583 --->
ACK sip:*97@1.1.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP 70.194.136.72:5583;branch=z9hG4bK+b60cd5bd5ef0453473c92d57deabf9271+s111+1
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
CSeq: 26872 ACK
Contact: "501" <sip:501@70.194.136.72:5583;ob>;+sip.ice
Max-Forwards: 70
Content-Length: 0

<------------->
[2013-11-12 16:45:07] VERBOSE[21139] chan_sip.c: --- (9 headers 0 lines) ---
[2013-11-12 16:45:08] VERBOSE[21139] chan_sip.c: Retransmitting #3 (NAT) to 70.194.136.72:5583:
SIP/2.0 491 Request Pending
Via: SIP/2.0/UDP 70.194.136.72:5583;branch=z9hG4bK+77485432a132025c7d8c641f8e7d15a41+s111+1;received=70.194.136.72;rport=5583
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
CSeq: 26873 INVITE
Server: FPBX-2.11.0(11.5.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


---
[2013-11-12 16:45:08] VERBOSE[21139] chan_sip.c:
<--- SIP read from UDP:70.194.136.72:5583 --->
ACK sip:*97@1.1.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP 70.194.136.72:5583;rport;branch=z9hG4bK+77485432a132025c7d8c641f8e7d15a41+s111+1
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
CSeq: 26873 ACK
Max-Forwards: 70
Content-Length: 0

<------------->
[2013-11-12 16:45:08] VERBOSE[21139] chan_sip.c: --- (8 headers 0 lines) ---
[2013-11-12 16:45:09] VERBOSE[21139] chan_sip.c: Retransmitting #4 (NAT) to 70.194.136.72:5583:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 70.194.136.72:5583;branch=z9hG4bK+81320c9c52d5dd46e80b673e6e0e53c01+s111+1;received=70.194.136.72;rport=5583
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
CSeq: 26872 INVITE
Server: FPBX-2.11.0(11.5.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:*97@1.1.1.1:5060>
Content-Type: application/sdp
Content-Length: 562

v=0
o=root 1921268681 1921268681 IN IP4 1.1.1.1
s=Asterisk PBX 11.5.1
c=IN IP4 1.1.1.1
t=0 0
m=audio 11926 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=ptime:20
a=ice-ufrag:0c0eb4fc08e593ea11b001aa0e8ce708
a=ice-pwd:57d491ff7c89b2517bbc695854a9a793
a=candidate:Ha000064 1 UDP 2130706431 2.2.2.2 11926 typ host
a=candidate:Had590e9c 1 UDP 2130706431 1.1.1.1 11926 typ host
a=candidate:Ha000064 2 UDP 2130706430 2.2.2.2 11927 typ host
a=candidate:Had590e9c 2 UDP 2130706430 1.1.1.1 11927 typ host
a=sendrecv

---
[2013-11-12 16:45:09] VERBOSE[21139] chan_sip.c:
<--- SIP read from UDP:70.194.136.72:5583 --->
ACK sip:*97@1.1.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP 70.194.136.72:5583;branch=z9hG4bK+b60cd5bd5ef0453473c92d57deabf9271+s111+1
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
CSeq: 26872 ACK
Contact: "501" <sip:501@70.194.136.72:5583;ob>;+sip.ice
Max-Forwards: 70
Content-Length: 0

<------------->
[2013-11-12 16:45:09] VERBOSE[21139] chan_sip.c: --- (9 headers 0 lines) ---
[2013-11-12 16:45:09] VERBOSE[21139] chan_sip.c: Retransmitting #4 (NAT) to 70.194.136.72:5583:
SIP/2.0 491 Request Pending
Via: SIP/2.0/UDP 70.194.136.72:5583;branch=z9hG4bK+77485432a132025c7d8c641f8e7d15a41+s111+1;received=70.194.136.72;rport=5583
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
CSeq: 26873 INVITE
Server: FPBX-2.11.0(11.5.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


---
[2013-11-12 16:45:09] VERBOSE[21139] chan_sip.c:
<--- SIP read from UDP:70.194.136.72:5583 --->
ACK sip:*97@1.1.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP 70.194.136.72:5583;rport;branch=z9hG4bK+77485432a132025c7d8c641f8e7d15a41+s111+1
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
CSeq: 26873 ACK
Max-Forwards: 70
Content-Length: 0

<------------->
[2013-11-12 16:45:09] VERBOSE[21139] chan_sip.c: --- (8 headers 0 lines) ---
[2013-11-12 16:45:10] VERBOSE[21139] chan_sip.c:
<--- SIP read from UDP:70.194.136.72:5583 --->
INFO sip:*97@1.1.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP 70.194.136.72:5583;rport;branch=z9hG4bK+2f75a1e0596898191b134912b26543d41+s111+1
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
CSeq: 26874 INFO
Max-Forwards: 70
Authorization: Digest username="501", realm="asterisk", nonce="610332d0", uri="sip:*97@1.1.1.1:5060", response="7f2335a04edc66e3a5c85548e1219c8a", algorithm=MD5
User-Agent: Bria iOS 3.0.1
Content-Type: application/dtmf-relay
Content-Length: 22

Signal=5
Duration=160
<------------->
[2013-11-12 16:45:10] VERBOSE[21139] chan_sip.c: --- (11 headers 2 lines) ---
[2013-11-12 16:45:10] VERBOSE[21139][C-00000014] chan_sip.c: Receiving INFO!
[2013-11-12 16:45:10] VERBOSE[21139][C-00000014] chan_sip.c: * DTMF-relay event received: 5
[2013-11-12 16:45:10] VERBOSE[21139][C-00000014] chan_sip.c:
<--- Transmitting (NAT) to 70.194.136.72:5583 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 70.194.136.72:5583;branch=z9hG4bK+2f75a1e0596898191b134912b26543d41+s111+1;received=70.194.136.72;rport=5583
From: "501" <sip:501@pbx.thesystemgroup.com>;tag=s111+1+4e770004+4f75aacd
To: <sip:*97@pbx.thesystemgroup.com>;tag=as30fe5132
Call-ID: fWFiBMUdKE.D7.5mxqBtc5jA90MOuljA-S
CSeq: 26874 INFO
Server: FPBX-2.11.0(11.5.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
2

Apparently its got to do with some form of authorization information in the message header of the sip ACK itself. When I use SIP clients that can send this as a part of the ACK SIP response, then the ACK is accepted:

(from wiretrace SIP ACK packet decode)

Authorization: Digest username="999",realm="asterisk",nonce="12345abc",uri="sip:*97@pbx.thesystemgroup.com:5060",response="61269fdd0291e628cdda25466eee5ec3f",algorythm=MD5

Is this something new with Asterisk 11?

3

the bria client works internally so its an auth digest issue. Does anybody here know when a sip client is challenged for auth digest? Is it during registration?

4

Depends on insecure=invite. Without this, it will be challenged on INVITE and REGISTER (and possibly some other cases). With it, it won’t be challenged on INVITE (and possibly some other cases), but will be challenged on REGISTER.

You would not normally want insecure=invite on any peer that is allowed to make chargeable calls.

5

Thanks. I was wondering if the insecure setting had something to do with auth. In this case, it looks like the Bria client never sends auth data in ACKs even though it responds to other challenges correctly. When it issues a challenge, asterisk will ignore ACKs that don’t have the correct auth. I’m getting the feeling that this might be an RFC grey area since the Bria technician is inclined to think that this is an asterisk bug. However, I’ve traced SNOM and Android clients and they both send auth data in ACKs when challenged.