In playing with two of our systems in Google Compute Engine, I’m trying to get the two systems to have a SIP trunk between them, yet I end up with a 401 Unauthorized error every time I try to send a call from one system to another. I’ve created an inbound route (in fact, it’s the same inbound route we use for SIP PSTN connectivity (same matching digits).
System A (at 10.128.0.2) Outbound SIP Trunk:
type=friend
transport=udp
t38pt_udptl=yes,redundancy,maxdatagram=400
srvlookup=no
qualify=yes
host=10.142.0.3
dtmfmode=rfc2833
directrtpsetup=yes
directmedia=no
context=from-pstn-e164-us
System B (at 10.142.0.3) Inbound SIP Trunk:
type=friend
transport=udp
t38pt_udptl=yes,redundancy,maxdatagram=400
srvlookup=no
qualify=yes
host=10.128.0.2
dtmfmode=rfc2833
directrtpsetup=yes
directmedia=no
context=from-pstn-e164-us
Both systems show trunks up. Both systems are pingable. Both systems can SSH from one to the other (clear communication), there’s an inbound call route built for “5137773456” (I changed the number for the post), yet every call attempt shows the attached (Had to remove from the body of the forum, as it was stripping some of the content - attachment now has the SIP DEBUG data from the sending machine)…
I would suggest you might need NAT between your two private networks. 10.0.0.0/8 is not generally route-able but perhaps Google allows that routeing internally ( your icmp and ssh). in your case for SIP, apparently not so much.
I would suggest you might firstly try IAX2 instead as it traverses complicated networks way more “slickly” ( IAX=“INTER ASTERISK EXCHANGE”) And it is unlikely that both ends of the sip connection should be 10.142.0.3
Those are routable IPs. It’s actually a new function we’re playing with - cross-peoject networking. The two systems are in two different data centers that are connected with a WAN connection (like a corporate network). No firewall or address translation exists beteeen the two devices and they have full communication with each other. I can also SSH from one box to the other, on their private IPs confirming there is no NAT involved.
Also, they aren’t both 10.142.0.3. One box is 10.142.0.3 - the other is 10.128.0.2. It seems the forum interpreted some of the SIP dialog as special text and it removed some of it. I’ll try to add it a different way.
Your log stopped just as the second invite would have been sent and possibly replied to (you do have alwaysauthreject enabled , yes?), As suggested try IAX2 it’s way easier to transverse strange routings
That was the end of the call - it just failed. I really don’t want to use IAX - I’ve not needed it before and I’d rather keep all this SIP native, as I plan to eventually add a SIP proxy in the middle of all this.
I did have “alwaysauthreject” enabled, but disabled it to see if it changed the response (which it didn’t), so I turned it back on.
That might have been the end of the call, I can assure you that two SIP messages will not a SIP connection make, there will be MANY from both chan_sip or chsn_pjsip and also from asterisk itself.
The last SIP message you posted said “FAILED AUTHERNTIFICATION” , , this is pretty well self explanatory, if you want help , then post the whole effing call , not just what you think is appropriate, no ?
Put insecure=port,invite in both trunks and try again. If it fails again post your log from asterisk CLI.
I did this before and it still failed with the same message, but I will test again and recapture.
The last SIP message you posted said “FAILED AUTHERNTIFICATION” , , this is pretty well self explanatory, if you want help , then post the whole effing call , not just what you think is appropriate, no ?
Well, you certainly do live up to your screen name… That was a SIP DEBUG trace from the console. I didn’t filter or modify it - yes, it looked a little light on transactional information to me as well, yet that’s what was shown in the sip debug, so I pasted it. I didn’t filter what I “thought” was appropriate - I posted everything that was output from the second I hit SEND on the phone to the second I hung up because it failed. You are right, “not authorized” is indeed self-explanatory, and perhaps that’s happening because some SIP messages are actually missing in the call setup (the reason “why”, still yet to be determined). Do you really feel that level of nastiness is appropriate for a help forum - jeez…
If you’re using Chan-SIP, maybe a simpler connection would work better. Use host-based authentication and simplify your setup a lot. Something simple like:
If that works, you get IP address authentication and it should be simple enough. Since you are connecting both ways, the ‘friend’ type is the way to go.
I actually had the “insecure=invite,port” during initial testing and it had no effect. I’ve since added it back with no change.
Doing some further digging/testing, I did notice that the issue actually appears to be one-way (from system A to B, not system B to A). This got me on the right track…
In Google Compute Engine, there are a ton of ACLs that allow/deny traffic from outside in, inside out, and even inside in. By default, there is a rule that allows all TCP, UDP, and ICMP traffic (on any port) to anywhere on the internal network. But I found that didn’t quite cut it - Instead of this: ALLOW tcp:0-65535; udp:0-65535; icmp
it had to be changed to: ALLOW ANY.
This also explained the missing parts of the call setup as well, which allowed me to see the cause of the problem…
Sending to 10.128.0.2:5060 (no NAT)
Using INVITE request as basis request - [email protected]:5060
Found peer ‘1999’ for ‘1999’ from 10.128.0.2:5060
Both systems have a test extension of “1999”. It seems the receiving system saw an invite from a number it knew it had locally (and not registered) and denied the call. Sure enough, when I changed to another test number (one that was unique to that system), it worked just fine…
Thanks to all those that helped and got me on the right track!!!
One-way connectivity usually implies a firewall problem. If everything’s the same and you’re using IP-based authentication, the /var/log/asterisk/full logs should show us some of what’s causing the problem.
Have you set up the integrated firewalls on both machines to trust the other?
It sounds like you’re doing everything correctly - there probably a single setting someplace that got skipped or misspelled. Misspelled is where I’d start. The brain is great at reading those “as if” they were correct.
I had placed all private scopes in the integrated firewall to be trusted (on both machines). I updated my post above to identify the problem and the two changes that were required to fix the problem.
That would do it. I’m in the process of “updating” a system that has a similar problem - I couldn’t get the calls on 4002 to go to the new server. Same basic issue and solution.
