REGISTER and INVITE get sent to different IPs

Hello,

I’m having trouble understanding Asterisk’s/PJSIP’s DNS handling.

Given:

  • Asterisk 16.2.1~dfsg-1+deb10u1
  • domain name of ITSP register server: sip.itsp.example
  • DNS A record of sip.itsp.example: 1.2.3.4
  • DNS SRV records of _sip._udp.sip.itsp.example: prio 10 -> 4.3.2.1, prio 20 -> 1.2.3.4

It seems as if Asterisk is sending an outbound REGISTER request always to the IP address of the A record (1.2.3.4).

Outbound INVITE requests, in contrast, get sent to the IP address of the lowest priority number/highest priority SRV record (4.3.2.1).

My ITSP doesn’t allow this and rejects such calls/INVITEs by replying with Forbidden 403. They seem to expect INVITEs to be sent to the same IP address as the REGISTER was sent to.

As I was told, there is nothing wrong with an A record differing from the highest priority SRV record.

But what can I do?

Is this standard Asterisk behavior or is there something wrong with my configuration?

Thanks in advance!

If you enable debug in logger.conf to console and do “core set debug 9” then DNS resolution information will be output telling you what it is doing and the actual results returned. We’d need to see that to understand precisely what is going on. Otherwise, there is nothing configuration wise you can do to alter that process itself besides explicitly using an IP address.

Hello,

that’s about the best I could get. I used grep to get the resolver messages from the debug log.

[Oct 26 20:27:43] DEBUG[1455] res_pjsip/pjsip_resolver.c: Performing SIP DNS resolution of target 'sip.alice-voip.de'
[Oct 26 20:27:43] DEBUG[1455] res_pjsip/pjsip_resolver.c: Transport type for target 'sip.alice-voip.de' is 'UDP'
[Oct 26 20:27:43] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2dc92d8] Created resolution tracking for target 'sip.alice-voip.de'
[Oct 26 20:27:43] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2dc92d8] Added target 'sip.alice-voip.de' with record type '1', transport 'UDP', and port '5060'
[Oct 26 20:27:43] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2dc92d8] Starting initial resolution using parallel queries for target 'sip.alice-voip.de'
[Oct 26 20:27:43] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x2dc92d8] All parallel queries completed
[Oct 26 20:27:43] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x2dc92d8] A record received on target 'sip.alice-voip.de'
[Oct 26 20:27:43] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x2dc92d8] Resolution completed - 1 viable targets
[Oct 26 20:27:43] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2dc92d8] Address '0' is 1.1.1.1:5060 with transport 'UDP'
[Oct 26 20:27:43] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2dc92d8] Invoking user callback with '1' addresses
...
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: Performing SIP DNS resolution of target 'sip.alice-voip.de'
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: Transport type for target 'sip.alice-voip.de' is 'UDP'
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x30ac190] Created resolution tracking for target 'sip.alice-voip.de'
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x30ac190] Added target 'sip.alice-voip.de' with record type '35', transport 'UDP', and port '5060'
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x30ac190] Added target '_sip._udp.sip.alice-voip.de' with record type '33', transport 'UDP', and port '5060'
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x30ac190] Added target 'sip.alice-voip.de' with record type '1', transport 'UDP', and port '5060'
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x30ac190] Starting initial resolution using parallel queries for target 'sip.alice-voip.de'
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] All parallel queries completed
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] SRV record received on target '_sip._udp.sip.alice-voip.de'
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] Added target 's1.sip.alice-voip.de' with record type '1', transport 'UDP', and port '5060'
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] SRV record received on target '_sip._udp.sip.alice-voip.de'
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] Added target 's2.sip.alice-voip.de' with record type '1', transport 'UDP', and port '5060'
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] A record being skipped on target 'sip.alice-voip.de' because NAPTR or SRV record exists
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] New queries added, performing parallel resolution again
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] All parallel queries completed
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] A record received on target 's1.sip.alice-voip.de'
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] A record received on target 's2.sip.alice-voip.de'
[Oct 26 20:30:15] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x30ac190] Resolution completed - 2 viable targets
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x30ac190] Address '0' is 1.1.1.2:5060 with transport 'UDP'
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x30ac190] Address '1' is 1.1.1.3:5060 with transport 'UDP'
[Oct 26 20:30:15] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x30ac190] Invoking user callback with '2' addresses
...
[Oct 26 20:33:23] DEBUG[1455] res_pjsip/pjsip_resolver.c: Performing SIP DNS resolution of target 'sip.alice-voip.de'
[Oct 26 20:33:23] DEBUG[1455] res_pjsip/pjsip_resolver.c: Transport type for target 'sip.alice-voip.de' is 'UDP'
[Oct 26 20:33:23] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2cea088] Created resolution tracking for target 'sip.alice-voip.de'
[Oct 26 20:33:23] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2cea088] Added target 'sip.alice-voip.de' with record type '1', transport 'UDP', and port '5060'
[Oct 26 20:33:23] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2cea088] Starting initial resolution using parallel queries for target 'sip.alice-voip.de'
[Oct 26 20:33:23] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x2cea088] All parallel queries completed
[Oct 26 20:33:23] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x2cea088] A record received on target 'sip.alice-voip.de'
[Oct 26 20:33:23] DEBUG[1464] res_pjsip/pjsip_resolver.c: [0x2cea088] Resolution completed - 1 viable targets
[Oct 26 20:33:23] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2cea088] Address '0' is 1.1.1.1:5060 with transport 'UDP'
[Oct 26 20:33:23] DEBUG[1455] res_pjsip/pjsip_resolver.c: [0x2cea088] Invoking user callback with '1' addresses

As you can see, Asterik sent the REGISTER message to 1.1.1.1 but used 1.1.1.2 to send the INVITE message to. (I changed some IPs and hostnames.)

The SRV record delivers two different records than the A record does. That doesn’t happen frequently. But the ITSP won’t accept calls on other IPs than the one registered to.

If needed, I’ve got a full full debug log and a verbose message log and a tcpdump.

I would appreciate your help or any ideas.

BTW: Is there a way of setting the debug level in logger.conf? I was able to tell Asteriks to create a debug.log file, but I could set set the debug level. I had to use the Asterisk CLI to set it. Default was off. Or do I have to add 9 ‘-d’ parameter to the start script?

It appears as though it’s not doing SRV for the REGISTER. I’d suggest updating to the latest version of Asterisk, and also providing the configuration.

As for the logger.conf debug level, that I do not know.

It should always use the highest priority (lowest prio number) SRV record for registration?

Yes, that is how SRV records are supposed to work.