SIP softphone fails to register - repeating 401 Unauthorized

Asterisk Asterisk Support
1

I am trying to use Asterisk 13 across a WAN with SIP softphones and ATA’s. The server and client are on different private subnets, so there are routers and firewalls, but not NAT.

The problem is that remote softphones fail to ever register. Turning on SIP debug shows repeating REGISTER and SIP/2.0 401 Unauthorized messages over and over, but the authentication never completes (in fact, I never see the username and password sent).

Softphones in the same subnet as the server register immediately and work fine, so its obviously something to do with the data traversing the network, but I have confirmed with ncat that udp 5060 is definitely open between the client and server. I’ve tried every solution I could find on google (including every combination of nat= setting, insecure, canreinvite, localnet, tcp instead of udp, etc.)

I could have sworn I had this working at one point. I can’t figure out if I inadvertently changed some important setting or if something on our network changed (possibly some weird port redirection?) since then.

The following is an excerpt of the SIP debug. Client IP is 172.20.1.100 and server is at 192.168.2.200.

[Mar 12 21:30:43]
[Mar 12 21:30:43] <— SIP read from UDP:172.20.1.100:54719 —>
[Mar 12 21:30:43] REGISTER sip:192.168.2.200 SIP/2.0
[Mar 12 21:30:43] Via: SIP/2.0/UDP 172.20.1.100:5060;rport;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418
[Mar 12 21:30:43] Max-Forwards: 70
[Mar 12 21:30:43] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:43] To: sip:1001@172.20.1.100
[Mar 12 21:30:43] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:43] CSeq: 43119 REGISTER
[Mar 12 21:30:43] User-Agent: PJSoftPhone::PJSUA v1.10.0/win32
[Mar 12 21:30:43] Contact: sip:1001@172.20.1.100:5060;ob
[Mar 12 21:30:43] Expires: 300
[Mar 12 21:30:43] Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
[Mar 12 21:30:43] Content-Length: 0
[Mar 12 21:30:43]
[Mar 12 21:30:43] <------------->
[Mar 12 21:30:43] — (12 headers 0 lines) —
[Mar 12 21:30:43] Sending to 172.20.1.100:54719 (no NAT)
[Mar 12 21:30:43] Sending to 172.20.1.100:54719 (no NAT)
[Mar 12 21:30:43]
[Mar 12 21:30:43] <— Transmitting (no NAT) to 172.20.1.100:54719 —>
[Mar 12 21:30:43] SIP/2.0 401 Unauthorized
[Mar 12 21:30:43] Via: SIP/2.0/UDP 172.20.1.100:5060;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418;received=172.20.1.100;rport=54719
[Mar 12 21:30:43] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:43] To: sip:1001@172.20.1.100;tag=as7aafb3eb
[Mar 12 21:30:43] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:43] CSeq: 43119 REGISTER
[Mar 12 21:30:43] Server: Asterisk PBX 13.2.0
[Mar 12 21:30:43] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
[Mar 12 21:30:43] Supported: replaces, timer
[Mar 12 21:30:43] WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“10068310”
[Mar 12 21:30:43] Content-Length: 0
[Mar 12 21:30:43]
[Mar 12 21:30:43]
[Mar 12 21:30:43] <------------>
[Mar 12 21:30:43] Scheduling destruction of SIP dialog ‘b56af895b181400a912fbbff224491f1’ in 32000 ms (Method: REGISTER)
[Mar 12 21:30:44]
[Mar 12 21:30:44] <— SIP read from UDP:172.20.1.100:54719 —>
[Mar 12 21:30:44] REGISTER sip:192.168.2.200 SIP/2.0
[Mar 12 21:30:44] Via: SIP/2.0/UDP 172.20.1.100:5060;rport;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418
[Mar 12 21:30:44] Max-Forwards: 70
[Mar 12 21:30:44] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:44] To: sip:1001@172.20.1.100
[Mar 12 21:30:44] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:44] CSeq: 43119 REGISTER
[Mar 12 21:30:44] User-Agent: PJSoftPhone::PJSUA v1.10.0/win32
[Mar 12 21:30:44] Contact: sip:1001@172.20.1.100:5060;ob
[Mar 12 21:30:44] Expires: 300
[Mar 12 21:30:44] Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
[Mar 12 21:30:44] Content-Length: 0
[Mar 12 21:30:44]
[Mar 12 21:30:44] <------------->
[Mar 12 21:30:44] — (12 headers 0 lines) —
[Mar 12 21:30:44] Sending to 172.20.1.100:54719 (no NAT)
[Mar 12 21:30:44]
[Mar 12 21:30:44] <— Transmitting (no NAT) to 172.20.1.100:54719 —>
[Mar 12 21:30:44] SIP/2.0 401 Unauthorized
[Mar 12 21:30:44] Via: SIP/2.0/UDP 172.20.1.100:5060;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418;received=172.20.1.100;rport=54719
[Mar 12 21:30:44] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:44] To: sip:1001@172.20.1.100;tag=as7aafb3eb
[Mar 12 21:30:44] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:44] CSeq: 43119 REGISTER
[Mar 12 21:30:44] Server: Asterisk PBX 13.2.0
[Mar 12 21:30:44] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
[Mar 12 21:30:44] Supported: replaces, timer
[Mar 12 21:30:44] WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“10068310”
[Mar 12 21:30:44] Content-Length: 0
[Mar 12 21:30:44]
[Mar 12 21:30:44]
[Mar 12 21:30:44] <------------>
[Mar 12 21:30:44] Scheduling destruction of SIP dialog ‘b56af895b181400a912fbbff224491f1’ in 32000 ms (Method: REGISTER)
[Mar 12 21:30:45]
[Mar 12 21:30:45] <— SIP read from UDP:172.20.1.100:54720 —>
[Mar 12 21:30:45] REGISTER sip:192.168.2.200 SIP/2.0
[Mar 12 21:30:45] Via: SIP/2.0/UDP 172.20.1.100:5060;rport;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418
[Mar 12 21:30:45] Max-Forwards: 70
[Mar 12 21:30:45] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:45] To: sip:1001@172.20.1.100
[Mar 12 21:30:45] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:45] CSeq: 43119 REGISTER
[Mar 12 21:30:45] User-Agent: PJSoftPhone::PJSUA v1.10.0/win32
[Mar 12 21:30:45] Contact: sip:1001@172.20.1.100:5060;ob
[Mar 12 21:30:45] Expires: 300
[Mar 12 21:30:45] Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
[Mar 12 21:30:45] Content-Length: 0
[Mar 12 21:30:45]
[Mar 12 21:30:45] <------------->
[Mar 12 21:30:45] — (12 headers 0 lines) —
[Mar 12 21:30:45] Sending to 172.20.1.100:54720 (no NAT)
[Mar 12 21:30:45]
[Mar 12 21:30:45] <— Transmitting (no NAT) to 172.20.1.100:54720 —>
[Mar 12 21:30:45] SIP/2.0 401 Unauthorized
[Mar 12 21:30:45] Via: SIP/2.0/UDP 172.20.1.100:5060;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418;received=172.20.1.100;rport=54720
[Mar 12 21:30:45] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:45] To: sip:1001@172.20.1.100;tag=as7aafb3eb
[Mar 12 21:30:45] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:45] CSeq: 43119 REGISTER
[Mar 12 21:30:45] Server: Asterisk PBX 13.2.0
[Mar 12 21:30:45] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
[Mar 12 21:30:45] Supported: replaces, timer
[Mar 12 21:30:45] WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“10068310”
[Mar 12 21:30:45] Content-Length: 0
[Mar 12 21:30:45]
[Mar 12 21:30:45]
[Mar 12 21:30:45] <------------>
[Mar 12 21:30:45] Scheduling destruction of SIP dialog ‘b56af895b181400a912fbbff224491f1’ in 32000 ms (Method: REGISTER)
[Mar 12 21:30:47]
[Mar 12 21:30:47] <— SIP read from UDP:172.20.1.100:54721 —>
[Mar 12 21:30:47] REGISTER sip:192.168.2.200 SIP/2.0
[Mar 12 21:30:47] Via: SIP/2.0/UDP 172.20.1.100:5060;rport;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418
[Mar 12 21:30:47] Max-Forwards: 70
[Mar 12 21:30:47] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:47] To: sip:1001@172.20.1.100
[Mar 12 21:30:47] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:47] CSeq: 43119 REGISTER
[Mar 12 21:30:47] User-Agent: PJSoftPhone::PJSUA v1.10.0/win32
[Mar 12 21:30:47] Contact: sip:1001@172.20.1.100:5060;ob
[Mar 12 21:30:47] Expires: 300
[Mar 12 21:30:47] Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
[Mar 12 21:30:47] Content-Length: 0
[Mar 12 21:30:47]
[Mar 12 21:30:47] <------------->
[Mar 12 21:30:47] — (12 headers 0 lines) —
[Mar 12 21:30:47] Sending to 172.20.1.100:54721 (no NAT)
[Mar 12 21:30:47]
[Mar 12 21:30:47] <— Transmitting (no NAT) to 172.20.1.100:54721 —>
[Mar 12 21:30:47] SIP/2.0 401 Unauthorized
[Mar 12 21:30:47] Via: SIP/2.0/UDP 172.20.1.100:5060;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418;received=172.20.1.100;rport=54721
[Mar 12 21:30:47] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:47] To: sip:1001@172.20.1.100;tag=as7aafb3eb
[Mar 12 21:30:47] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:47] CSeq: 43119 REGISTER
[Mar 12 21:30:47] Server: Asterisk PBX 13.2.0
[Mar 12 21:30:47] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
[Mar 12 21:30:47] Supported: replaces, timer
[Mar 12 21:30:47] WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“10068310”
[Mar 12 21:30:47] Content-Length: 0
[Mar 12 21:30:47]
[Mar 12 21:30:47]
[Mar 12 21:30:47] <------------>
[Mar 12 21:30:47] Scheduling destruction of SIP dialog ‘b56af895b181400a912fbbff224491f1’ in 32000 ms (Method: REGISTER)
[Mar 12 21:30:51]
[Mar 12 21:30:51] <— SIP read from UDP:172.20.1.100:54722 —>
[Mar 12 21:30:51] REGISTER sip:192.168.2.200 SIP/2.0
[Mar 12 21:30:51] Via: SIP/2.0/UDP 172.20.1.100:5060;rport;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418
[Mar 12 21:30:51] Max-Forwards: 70
[Mar 12 21:30:51] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:51] To: sip:1001@172.20.1.100
[Mar 12 21:30:51] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:51] CSeq: 43119 REGISTER
[Mar 12 21:30:51] User-Agent: PJSoftPhone::PJSUA v1.10.0/win32
[Mar 12 21:30:51] Contact: sip:1001@172.20.1.100:5060;ob
[Mar 12 21:30:51] Expires: 300
[Mar 12 21:30:51] Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
[Mar 12 21:30:51] Content-Length: 0
[Mar 12 21:30:51]
[Mar 12 21:30:51] <------------->
[Mar 12 21:30:51] — (12 headers 0 lines) —
[Mar 12 21:30:51] Sending to 172.20.1.100:54722 (no NAT)
[Mar 12 21:30:51]
[Mar 12 21:30:51] <— Transmitting (no NAT) to 172.20.1.100:54722 —>
[Mar 12 21:30:51] SIP/2.0 401 Unauthorized
[Mar 12 21:30:51] Via: SIP/2.0/UDP 172.20.1.100:5060;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418;received=172.20.1.100;rport=54722
[Mar 12 21:30:51] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:51] To: sip:1001@172.20.1.100;tag=as7aafb3eb
[Mar 12 21:30:51] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:51] CSeq: 43119 REGISTER
[Mar 12 21:30:51] Server: Asterisk PBX 13.2.0
[Mar 12 21:30:51] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
[Mar 12 21:30:51] Supported: replaces, timer
[Mar 12 21:30:51] WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“10068310”
[Mar 12 21:30:51] Content-Length: 0
[Mar 12 21:30:51]
[Mar 12 21:30:51]
[Mar 12 21:30:51] <------------>
[Mar 12 21:30:51] Scheduling destruction of SIP dialog ‘b56af895b181400a912fbbff224491f1’ in 32000 ms (Method: REGISTER)
[Mar 12 21:30:55]
[Mar 12 21:30:55] <— SIP read from UDP:172.20.1.100:54723 —>
[Mar 12 21:30:55] REGISTER sip:192.168.2.200 SIP/2.0
[Mar 12 21:30:55] Via: SIP/2.0/UDP 172.20.1.100:5060;rport;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418
[Mar 12 21:30:55] Max-Forwards: 70
[Mar 12 21:30:55] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:55] To: sip:1001@172.20.1.100
[Mar 12 21:30:55] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:55] CSeq: 43119 REGISTER
[Mar 12 21:30:55] User-Agent: PJSoftPhone::PJSUA v1.10.0/win32
[Mar 12 21:30:55] Contact: sip:1001@172.20.1.100:5060;ob
[Mar 12 21:30:55] Expires: 300
[Mar 12 21:30:55] Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
[Mar 12 21:30:55] Content-Length: 0
[Mar 12 21:30:55]
[Mar 12 21:30:55] <------------->
[Mar 12 21:30:55] — (12 headers 0 lines) —
[Mar 12 21:30:55] Sending to 172.20.1.100:54723 (no NAT)
[Mar 12 21:30:55]
[Mar 12 21:30:55] <— Transmitting (no NAT) to 172.20.1.100:54723 —>
[Mar 12 21:30:55] SIP/2.0 401 Unauthorized
[Mar 12 21:30:55] Via: SIP/2.0/UDP 172.20.1.100:5060;branch=z9hG4bKPj3ed8ece0a5154b81a7e03116539ef418;received=172.20.1.100;rport=54723
[Mar 12 21:30:55] From: sip:1001@172.20.1.100;tag=d6dfd7db9c2c480697e838973e40a718
[Mar 12 21:30:55] To: sip:1001@172.20.1.100;tag=as7aafb3eb
[Mar 12 21:30:55] Call-ID: b56af895b181400a912fbbff224491f1
[Mar 12 21:30:55] CSeq: 43119 REGISTER
[Mar 12 21:30:55] Server: Asterisk PBX 13.2.0
[Mar 12 21:30:55] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
[Mar 12 21:30:55] Supported: replaces, timer
[Mar 12 21:30:55] WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“10068310”
[Mar 12 21:30:55] Content-Length: 0
[Mar 12 21:30:55]
[Mar 12 21:30:55]
[Mar 12 21:30:55] <------------>
[Mar 12 21:30:55] Scheduling destruction of SIP dialog ‘b56af895b181400a912fbbff224491f1’ in 32000 ms (Method: REGISTER)

2

Both components interact with there private IP-addresses. This won’t work.
The SIP-Phone - when behind it’s own NAT - should send it’s external IP-adress (use a STUN-Server in the phone-config) and Asterisk should response with it’s external IP-address (use localnet and externip/externhost). And: In this case NAT-setting on Asterisk-side should be rport,force_comedia

3

Thank you for the reply.

They are both responding with their private IP addresses, but both are on the same WAN and can reach each other by those addresses. They are not going across the internet, so there is no public IP for them to use. They are able ping each other, telnet, ssh, ftp, etc. across our network by those private IP’s. I have also confirmed that udp port 5060 is open between them.

Regardless, I will try the nat settings you suggest and will report back.

4

Form Your log it doesn’t seem, that they are reaching each other:

The incoming REGISTER-Request gets answered with the 401 UNAUTHORIZED (which is normal). But afterwards there’s no correspondending reply from the client (using the nonce from asterisk) to provide the credentials. Thats why the register fails.
You may try to check which packets are reaching the client and if there’s any error in the client logs …

5

Ah, I see what you are talking about.
It’s as if I have one-way communication - the server is seeing and responding to the client REGISTER, but the client is not seeing the unauthorized and keeps sending new REGISTER requests.

There are firewalls involved, but I can see UDP 5060 going both ways. Does Asterisk possibly reply on a different port or anything like that? Maybe I need to open things up further.

I’ll see about cranking up the logging level on my softphone for more clues as well.

6

The response comes from port 5060 (udp)

7

I did some packet capture on both ends and now see a little better WHAT is going on, but I’m still not sure WHY.

First, my client sends a 100 REGISTER message over udp port 5060 normally:

REGISTER sip:192.168.2.200 SIP/2.0
Via: SIP/2.0/UDP 172.20.1.100:5060;rport;branch=z9hG4bKPj0390600d1c2c43cdb28920d23abc6c32
Max-Forwards: 70
From: sip:1001@172.20.1.100;tag=7a11024a5f1a47d89de82d3df02b7374
To: sip:1001@172.20.1.100
Call-ID: c7fefde1a1f741f898295b8faef91ed6
CSeq: 12476 REGISTER
User-Agent: PJSoftPhone::PJSUA v1.10.0/win32
Contact: sip:1001@172.20.1.100:5060;ob
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0

Next, the server recieves it, but it replies its 401 UNAUTHORIZED response over a random high number port (udp 43501 in this case), and asks that the client do the same via the rport parameter.

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.20.1.100:5060;branch=z9hG4bKPj0390600d1c2c43cdb28920d23abc6c32;received=172.20.1.100;rport=43501
From: sip:1001@172.20.1.100;tag=7a11024a5f1a47d89de82d3df02b7374
To: sip:1001@172.20.1.100;tag=as512789d2
Call-ID: c7fefde1a1f741f898295b8faef91ed6
CSeq: 12476 REGISTER
Server: Asterisk PBX 13.2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="102a728e"
Content-Length: 0

The problem is, the client wasn’t listening on 43501, it was listening on 5060, so it doesn’t get the reply. It then starts over and sends a brand-new 100 REGISTER over udp 5060, to which the server replies with a new 401 UNAUTHORIZED, this time incrementing the port to 43502. This keeps repeating indefinitely. If I start over with a new connection attempt, a new high number port is selected seemingly at random.

When a client connects from the local LAN, all communication is done over udp 5060 both ways, the rport value also stays at 5060, and things work beautifully.

This leads me to believe there is something about the data path across this WAN that is confusing Asterisk. The original 100 REGISTER does arrive on udp 5060 and the server does read it, but for some reason it seems to think that it needs to reply on a different port and I cannot figure why. I’ve tried all sort of values for NAT that affect the rport behavior, but the same thing still happens. I’ve also tried different softphones and the same problem occurs.

Is there some way I can force Asterisk to always stick to responding on udp 5060 no matter what it thinks it detects?

8

I don’t believe there is any way of doing this. You need to remove the NAT from the network. Even with NAT, Asterisk can only really cope with symmetrical translations, i.e. where the translation going backwards is the inverse of that going forwards.

9

So I’ve got a little farther…
Packet capture on the client side shows that when the softphone sends the Register message, both the source port and destination are udp 5060, as expected. However, a capture on the server end shows that when the same packet is received, the source port has changed to a random high number ephemeral port. Because of this, Asterisk sends the 401 Unauthorized challenge back on this high number port, and although it is not blocked, my client doesn’t get the reply because it was expecting it on 5060 still - it’s falling on deaf ears, so to speak.
The changing of the source port mid-transit is unexpected on our WAN so I have some digging to do there with our network folks.
However, it seems that Asterisk will always send the 401 Unauthorized challenge back on the source port that the original Register message came in on rather than use the IP and port in the Via header, despite what configuration settings I tinker with. So while I intend to fix my Asterisk problem by sorting out this source port issue, it seems like there should be some way to make Asterisk respect the VIA header, where the correct IP and port are already indicated (otherwise what’s the point of even having it there?).

10

That’s because Asterisk is sending the rport parameters. It always does this when it thinks it is dealing with a NAT situation, as that is normally the only sensible think to do in a NAT environment. There is a flag that disables this, but there seems to be no way of modifying this flag.

Please note that this statement in your original posting is untrue “there are routers and firewalls, but not NAT”, as there is very definitely NAT.

You need to do one of the following, in descending order of preference:

Disable NAT in the network;

Make the network NAT work sensibly and automatically reverse the translation on the reverse path;

Trick asterisk into believing that there isn’t really any NAT.

Modify the source code to disable the AUTO_RPORT function.

11

Thank you for the reply and information, those are good suggestions.
We definitely have some sort of port address translation happening on that subnetwork, but it is not intentional. We are trying to track it down and eliminate it. It seems to be only happening to SIP traffic thus far (but could be other UDP too).
I’ve managed to get additional servers setup elsewhere on our WAN (different physical locations and different subnets) and Asterisk 13 works just fine with the exact same configurations and clients, so it’s definitely a setting (or malfunction) in the hardware of that particular network, which we’ll eventually get to the bottom of.
Thanks everyone for your help.

12

Just to finish out the thread for anyone who searches this up in the future, the problem did turn out to be network-related and not something that I had setup wrong in Asterisk.
One of the checkpoint firewalls in our WAN was shifting the source ports in the ethernet packet header on UDP traffic. There is a setting buried in the firewall configuration to specifically indicate that a certain port is for SIP traffic. Once enabled, it properly preserves the source port, and then SIP calls worked like a charm.
Thanks to all who replied for the support.

13

I have exactly the same problem with Checkpoint, Could you tell me what was the setting in the fw which allows SIP traffic? Thanks!!