NO JOY User mismatch on incoming VOIPStreet SIP

Kimmy Dallas Posey

New Member
Joined
Apr 20, 2015
Messages
13
Reaction score
2
I have been a VOIPStreet customer for going on 10 years now but have used IAX the majority of that time and on multiple versions of PIAF going WAY back. Recently I upgraded from PIAF 2.0.6.4 to Incredible 13. I finally got some extensions to register and GV to work for outgoing at least. However when I turned to my trusty old VOIPStreet trunk I ran into problems.

Not sure what changed in IAX land, but this upgrade broke it as I started getting "invalid token" errors on registration. Instead of tracking that down (I gave it a half-hearted stab) I figured I'd move to SIP as there was a pre-configured VOIPStreet trunk in the release. However, that isn't working out so good either. The trunk registers OK and outbound calls work. But on inbound I get:

[2015-11-24 07:19:17] WARNING[18199][C-00000004]: chan_sip.c:16653 check_auth: username mismatch, have <voipstreet>, digest has <SOMEOLDGUY-123456789>
[2015-11-24 07:19:17] NOTICE[18199][C-00000004]: chan_sip.c:25550 handle_request_invite: Failed to authenticate device "12024558888" <sip:[email protected]>;tag=as57042e37

The trunk setup is right at least according to both the sample trunk in the release and VOIPStreet's recommended settings. The only difference between the two being order and type=friend/type=peer respectively. I've tried both ways so I don't believe that is an issue. The traffic does traverse a pfSense based router, but I have both UDP 5060-5061 and UDP 10000-10100 ranges forwarded to my PIAF VM. Here is the SIP trace. Names have been changed to protect the innocent. Any help is much appreciated:

<--- SIP read from UDP:64.136.174.24:5060 --->
INVITE sip:[email protected]:55295 SIP/2.0
Via: SIP/2.0/UDP 64.136.174.24:5060;branch=z9hG4bK696a5645;rport
From: "12024558888" <sip:[email protected]>;tag=as57042e37
To: <sip:[email protected]:55295>
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: VoIPStreet
Max-Forwards: 70
Remote-Party-ID: "12024558888" <sip:[email protected]>;privacy=off;screen=no
Date: Tue, 24 Nov 2015 10:58:12 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 2040 2040 IN IP4 64.136.174.24
s=session
c=IN IP4 64.136.174.24
t=0 0
m=audio 10510 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:eek:ff - - - -
a=ptime:20
a=sendrecv
<------------->
--- (15 headers 12 lines) ---
Sending to 64.136.174.24:5060 (NAT)
Sending to 64.136.174.24:5060 (NAT)
Using INVITE request as basis request - [email protected]
Found peer 'voipstreet' for '12024558888' from 64.136.174.24:5060

<--- Reliably Transmitting (NAT) to 64.136.174.24:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 64.136.174.24:5060;branch=z9hG4bK696a5645;received=64.136.174.24;rport=5060
From: "12024558888" <sip:[email protected]>;tag=as57042e37
To: <sip:[email protected]:55295>;tag=as34c818fe
Call-ID: [email protected]
CSeq: 102 INVITE
Server: FPBX-12.0.70(13.5.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="299f423c"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '[email protected]' in 32000 ms (Method: INVITE)

<--- SIP read from UDP:64.136.174.24:5060 --->
ACK sip:[email protected]:55295 SIP/2.0
Via: SIP/2.0/UDP 64.136.174.24:5060;branch=z9hG4bK696a5645;rport
From: "12024558888" <sip:[email protected]>;tag=as57042e37
To: <sip:[email protected]:55295>;tag=as34c818fe
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: VoIPStreet
Max-Forwards: 70
Remote-Party-ID: "12024558888" <sip:[email protected]>;privacy=off;screen=no
Content-Length: 0

<------------->
--- (11 headers 0 lines) ---

<--- SIP read from UDP:64.136.174.24:5060 --->
INVITE sip:[email protected]:55295 SIP/2.0
Via: SIP/2.0/UDP 64.136.174.24:5060;branch=z9hG4bK3f68de54;rport
From: "12024558888" <sip:[email protected]>;tag=as57042e37
To: <sip:[email protected]:55295>
Contact: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 103 INVITE
User-Agent: VoIPStreet
Max-Forwards: 70
Remote-Party-ID: "12024558888" <sip:[email protected]>;privacy=off;screen=no
Authorization: Digest username="SOMEOLDGUY246910382", realm="asterisk", algorithm=MD5, uri="sip:[email protected]:55295", nonce="299f423c", response="435ea9faa35f809d08b3d9cbdbfda7dd"
Date: Tue, 24 Nov 2015 10:58:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 240

v=0
o=root 2040 2041 IN IP4 64.136.174.24
s=session
c=IN IP4 64.136.174.24
t=0 0
m=audio 10510 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:eek:ff - - - -
a=ptime:20
a=sendrecv
<------------->
--- (16 headers 12 lines) ---
Sending to 64.136.174.24:5060 (NAT)
Using INVITE request as basis request - [email protected]
Found peer 'voipstreet' for '12024558888' from 64.136.174.24:5060
[2015-11-24 07:19:17] WARNING[18199][C-00000004]: chan_sip.c:16653 check_auth: username mismatch, have <voipstreet>, digest has <SOMEOLDGUY246910382>
[2015-11-24 07:19:17] NOTICE[18199][C-00000004]: chan_sip.c:25550 handle_request_invite: Failed to authenticate device "12024558888" <sip:[email protected]>;tag=as57042e37

<--- Reliably Transmitting (NAT) to 64.136.174.24:5060 --->
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 64.136.174.24:5060;branch=z9hG4bK3f68de54;received=64.136.174.24;rport=5060
From: "12024558888" <sip:[email protected]>;tag=as57042e37
To: <sip:[email protected]:55295>;tag=as34c818fe
Call-ID: [email protected]
CSeq: 103 INVITE
Server: FPBX-12.0.70(13.5.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
 

tbrummell

Guru
Joined
Jan 8, 2011
Messages
1,275
Reaction score
339
For the IAX problem, I be;lieve you can set "requirecalltoken" to no in the trunk settings and the problem will go away. Maybe.
 

Members online

No members online now.

Forum statistics

Threads
25,780
Messages
167,506
Members
19,199
Latest member
leocipriano
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Top