Yes, using identify_by[1] you can specify what methods are allowed for an endpoint.
[1] https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L633
So whatever parameters are configured in identify_by (and those can be more separated via comma), those are the only ones matching can be done by.
That is how you can disallow matching of certain types as well.
Correct?
Does the sequence in identify_by also set the order by which matching is done for that specfic endpoint?
They allow or disallow the method, yes.
There is no way to set a unique order for an endpoint. In order to do that you need to match an endpoint (so you need to know an order already). You could re-run the logic in the new order, but if that yielded a different order then what do you do?
It getsā¦ complicatedā¦ so only a global order is permitted.
Are outbound Invites sent to the address/FQDN in the contact parameter in the AOR section?
If you havenāt specified a SIP URI in the Dial() string, yes. Thatās how it works.
So the address in the Invite header comes from the AOR contact, like:
INVITE sip:5000@13245675.home.depot.com:5160
Does the lookup of my FQDN example address also only happen on loadtime?
So Asterisk would send the Invite to the wrong address if it has changed since load?
No. A contact is stored as a SIP URI. Only at use time (sending an INVITE, sending an OPTIONS) is it resolved to an address.
How does that resolving of SIP URI take place?
Via SRV?
Thereās an RFC[1] for SIP which details how it works. In 13 SRV, A, and AAAA record lookups are done. In 15 we do NAPTR, SRV, A, and AAAA. (Depends on what the system configuration is - if you have no IPv6 transport then AAAA wonāt be done).
1 Like
And what registration does is it allows for the party thatās being registered to store an AOR contact with the IP address of the registering party?
Yes. Itās a defined mechanism in SIP to allow something to provide information on how it can be reached.