I have been working for quite some time (6+ months) perfectly fine with two trunks setup.
Both are SIP Registered, one is my own personal account and the second is a SIP account supplied by my employer. Both are for inbound and outbound terminated calls.
Until the last few weeks, everything has been absolutely fine. No problems at all, with the majority of my calls routed via my work PBX using the dialplan.
My personal trunk is mostly for inbound, but I do route freephone calls through it as well as calls made with a prefix (RRT to my employers PBX means I can reduce jitter if I do this selectively).
Inbound calls route to my mobile via the Snomone and always use my employers PBX. Over the last few weeks, I have noticed that the calls suddenly do not terminate correctly. I thought it has been the callers.
However, I have now started to see the issue when making calls from my Snom 360 directly attached to the LAN the Snomone is on.
The Snomone is behind a NAT router and there have been no physical or configuration changes in the LAN, the Snomone or at my ISP (cough, I contract for them).
Any and all calls via my private trunk are fine. Due to the limited / simple setup, I completely tarted from scratch and the problem persists.
So after some logging and digging, I now know the following. My employers PBX will accept the REGISTER and authenticate me successfully (as far as I can see). However, when the Snomone issues an INVITE, it gets a 401 with relevant digest payload, yet continues to return 401 when the Snomone returns the auth payload with the relevant challenge response.
I can't for any reason seem to figure out what may be causing this problem. My employers PBX is Asterisk using Freepbx. The logs there don't show unauthorised, but do return a message along the lines that a retransmit didn't take place in a timely way, suggesting this timed out after 6 seconds or so.
It's as if the PBX is expecting the INVITE to be issued three times. One to generate the initial challenge, then the correct response and then a further response again.
Included is a SIP trace of the events from the log. IP's and domains and numbers have been changed.
2014/7/18 13:16:13 Tx: udp:10.200.1.89:5060 (810 bytes)
INVITE sip:07777777777@ny-pbx.domain.com;user=phone SIP/2.0
v: SIP/2.0/UDP 192.168.0.194:5060;branch=z9hG4bK-71153e27db7dacc38d2ccb1678683c44;rport
f: "633" <sip:633@ny-pbx.domain.com>;tag=2083537615
t: <sip:07777777777@ny-pbx.domain.com>
i: bfed76ba@pbx
CSeq: 10360 INVITE
Max-Forwards: 70
m: <sip:633@192.168.0.194:5060;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
User-Agent: Vodia-PBX/5.1.3
c: application/sdp
l: 252
v=0
o=- 1320870782 1320870782 IN IP4 192.168.0.194
s=-
c=IN IP4 192.168.0.194
t=0 0
m=audio 60838 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
2014/7/18 13:16:13 Rx: udp:10.200.1.89:5060 (545 bytes)
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.194:5060;branch=z9hG4bK-71153e27db7dacc38d2ccb1678683c44;received=10.2.2.54;rport=5060
From: "633" <sip:633@ny-pbx.domain.com>;tag=2083537615
To: <sip:07777777777@ny-pbx.domain.com>;tag=as510dddc6
Call-ID: bfed76ba@pbx
CSeq: 10360 INVITE
Server: FPBX-2.10.1(1.8.10.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7778098d"
Content-Length: 0
2014/7/18 13:16:13 Tx: udp:10.200.1.89:5060 (321 bytes)
ACK sip:07777777777@ny-pbx.domain.com;user=phone SIP/2.0
v: SIP/2.0/UDP 192.168.0.194:5060;branch=z9hG4bK-71153e27db7dacc38d2ccb1678683c44;rport
f: "633" <sip:633@ny-pbx.domain.com>;tag=2083537615
t: <sip:07777777777@ny-pbx.domain.com>;tag=as510dddc6
i: bfed76ba@pbx
CSeq: 10360 ACK
Max-Forwards: 70
l: 0
2014/7/18 13:16:13 Tx: udp:10.200.1.89:5060 (993 bytes)
INVITE sip:07777777777@ny-pbx.domain.com;user=phone SIP/2.0
v: SIP/2.0/UDP 192.168.0.194:5060;branch=z9hG4bK-4093e939ed9c9d85db98d63d4bf1b81e;rport
f: "633" <sip:633@ny-pbx.domain.com>;tag=2083537615
t: <sip:07777777777@ny-pbx.domain.com>
i: bfed76ba@pbx
CSeq: 10361 INVITE
Max-Forwards: 70
m: <sip:633@192.168.0.194:5060;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
User-Agent: Vodia-PBX/5.1.3
Authorization: Digest realm="asterisk",nonce="7778098d",response="a0cce39a773b1a7eee07d7e1eb44d6dc",username="633",uri="sip:07777777777@ny-pbx.domain.com;user=phone",algorithm=MD5
c: application/sdp
l: 252
v=0
o=- 1320870782 1320870782 IN IP4 192.168.0.194
s=-
c=IN IP4 192.168.0.194
t=0 0
m=audio 60838 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
2014/7/18 13:16:14 Rx: udp:10.200.1.89:5060 (545 bytes)
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.194:5060;branch=z9hG4bK-71153e27db7dacc38d2ccb1678683c44;received=10.2.2.54;rport=5060
From: "633" <sip:633@ny-pbx.domain.com>;tag=2083537615
To: <sip:07777777777@ny-pbx.domain.com>;tag=as510dddc6
Call-ID: bfed76ba@pbx
CSeq: 10360 INVITE
Server: FPBX-2.10.1(1.8.10.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7778098d"
Content-Length: 0
2014/7/18 13:16:14 Tx: udp:10.200.1.89:5060 (368 bytes)
ACK sip:07777777777@ny-pbx.domain.com;user=phone SIP/2.0
v: SIP/2.0/UDP 192.168.0.194:5060;branch=z9hG4bK-4093e939ed9c9d85db98d63d4bf1b81e;rport
f: "633" <sip:633@ny-pbx.domain.com>;tag=2083537615
t: <sip:07777777777@ny-pbx.domain.com>;tag=as510dddc6
i: bfed76ba@pbx
CSeq: 10361 ACK
Max-Forwards: 70
m: <sip:633@192.168.0.194:5060;transport=udp>
l: 0
I understand how Digest auth works in HTTP and I have had a go are looking at the RFCs, but I cannot calculate the response to the challenge manually, thus I have been unable to calculate if or not it is a genuine unauthorised, or Snomone is doing something silly.
However, it's only this trunk, as again, my personal one is fine, though this uses a 407 Proxy authentication required.
Are there any pointers on working out what may or may not be going on?
Afterall, REGISTER is fine, but INVITE is not, so the shared secret should not be the cause.