Invite and register sent to different servers (multiple A records)

[ineant7]

Hi Asterisk is sending the invites to the wrong server (unregistered server) , so I get a forbidden reply.

Is there anyway to tell asterisk to send invites only to the registered server ?

Domain name has two A records, and it does not support srv records.

Register to IP_ADDRESS_2 :
DEBUG[1523] res_pjsip/pjsip_resolver.c: [0xXXXX] All parallel queries completed
DEBUG[1523] res_pjsip/pjsip_resolver.c: [0xXXXX] A record received on target 'domain.com'
DEBUG[1523] res_pjsip/pjsip_resolver.c: [0xXXXX] A record received on target 'domain.com'
DEBUG[1523] res_pjsip/pjsip_resolver.c: [0xXXXX] Resolution completed - 2 viable targets
DEBUG[1512] res_pjsip/pjsip_resolver.c: [0xXXXX] Address '0' is IP_ADDRESS_2:5060 with transport 'UDP transport'
DEBUG[1512] res_pjsip/pjsip_resolver.c: [0xXXXX] Address '1' is IP_ADDRESS_1:5060 with transport 'UDP transport'
VERBOSE[1512] res_pjsip_logger.c: <--- Transmitting SIP request (572 bytes) to UDP:IP_ADDRESS_2:5060 --->

Invite to ip IP_ADDRESS_1 :
DEBUG[1410] res_pjsip/pjsip_resolver.c: Performing SIP DNS resolution of target 'domain.com'
DEBUG[1410] res_pjsip/pjsip_resolver.c: Transport type for target 'domain.com' is 'UDP transport'
DEBUG[1410] res_pjsip/pjsip_resolver.c: [0xXXXX] Created resolution tracking for target 'domain.com'
DEBUG[1410] res_pjsip/pjsip_resolver.c: [0xXXXX] Added target 'domain.com' with record type '1', transport 'UDP transport', and port '5060'
DEBUG[1410] res_pjsip/pjsip_resolver.c: [0xXXXX] Starting initial resolution using parallel queries for target 'domain.com'
DEBUG[1351] res_pjsip/pjsip_resolver.c: [0xXXXX] All parallel queries completed
DEBUG[1351] res_pjsip/pjsip_resolver.c: [0xXXXX] A record received on target 'domain.com'
DEBUG[1351] res_pjsip/pjsip_resolver.c: [0xXXXX] A record received on target 'domain.com'
DEBUG[1351] res_pjsip/pjsip_resolver.c: [0xXXXX] Resolution completed - 2 viable targets
DEBUG[1410] res_pjsip/pjsip_resolver.c: [0xXXXX] Address '0' is IP_ADDRESS_1:5060 with transport 'UDP transport'
DEBUG[1410] res_pjsip/pjsip_resolver.c: [0xXXXX] Address '1' is IP_ADDRESS_2:5060 with transport 'UDP transport'
DEBUG[1410] res_pjsip/pjsip_resolver.c: [0xXXXX] Invoking user callback with '2' addresses
DEBUG[1410] res_pjsip/pjsip_resolver.c: Performing SIP DNS resolution of target 'IP_ADDRESS_1'
DEBUG[1410] res_pjsip/pjsip_resolver.c: Transport type for target 'IP_ADDRESS_1' is 'UDP transport'
DEBUG[1410] res_pjsip/pjsip_resolver.c: Target 'IP_ADDRESS_1' is an IP address, skipping resolution
DEBUG[1410] res_pjsip/pjsip_resolver.c: Performing SIP DNS resolution of target 'IP_ADDRESS_1'
DEBUG[1410] res_pjsip/pjsip_resolver.c: Transport type for target 'IP_ADDRESS_1' is 'UDP transport'
DEBUG[1410] res_pjsip/pjsip_resolver.c: Target 'IP_ADDRESS_1' is an IP address, skipping resolution```

[jcolp]

There is not. It has been requested in the past, but noone has worked on such a thing.

[ineant7]

Thanks for the info and fast reply. I’ll setup one server only with a local dns record then.

[EkFudrek]

You would have to post more specific information, but there are some providers who do not maintain a global state for registrations. If session timers are used, longer phone calls will also abort with a certain probability ( due to re-INVITES). By the same token these providers usually allow you being registered to multiple proxy servers at the same time.

Let’s say the provider rotates its proxy servers and updates the servers that are resolved via NAPTR requests, then your approach will not work. I’ve seen specific servers going out of operation, so you cannot set the proxy statically.

Either you modify Asterisk a bit such that calls always use the IP that was used for registration, or you use a DNS stragety outside of Asterisk and reload PJSIP perhaps once during every night. This way you have at least always a fresh set of proxy servers.

[david551]

SIP doesn’t require registration before sending an outgoing INVITE. If the provider does, and doesn’t maintain a global registration database, I think it is wrong of them to provide multiple IP addresses.

[EkFudrek]

Just for the hack of it, do a simple dig tel.t-online.de NAPTR and resolve until you get real IPs. Script that, let it run every couple of minutes and store the results. Asterisk uses the highest priority addresses and does not seem to use the rest.

Then you can be amazed. No matter what and how many academic degrees you have and in how many languages you know the SIP RFCs by heart, this company will not change anything.

It’s actually not that bad if you know what you can do with a setup like that. But you have to know about the DNS records and have read a strange document called 1TR88.