PJSIP: Unable to use AOR with different name from the endpoint

Asterisk Asterisk SIP
1

Hello, I’m trying to set up an Asterisk server with PJSIP using static realtime, and it failed because the categories are the same, making the data from the database not work.
Then, I tried setting up the endpoint to one category, the AOR to another and the Auth to another, which caused the problem I’m asking for help here. The following PJSIP configuration can trigger the issue I’m having:

[transport-udp-bug]
type=transport
bind=0.0.0.0:5071
symmetric_transport=yes
allow_reload=yes

[2000]
type=endpoint
transport=transport-udp-bug
aors=2000-aor
auth=2000-auth
callerid=User <2000>
allow=!all,opus,alaw,ulaw,gsm
direct_media=no
force_rport=yes
rtp_symmetric=yes
rewrite_contact=yes
use_avpf=yes
rtp_timeout=60
rtp_timeout_hold=3600
rtcp_mux=yes

[2000-aor]
type=aor
max_contacts=10
remove_existing=yes
remove_unavailable=yes
default_expiration=600
maximum_expiration=1800

[2000-auth]
type=auth
auth_type=userpass
username=2000
password=theBestPassword

In this example, the endpoint 2000 would use the AOR 2000-aor and the Auth 2000-auth. The auth works correctly. Unfortunately, the AOR fails with the following message when registering:
WARNING[702195]: res_pjsip_registrar.c:1166 find_registrar_aor: AOR '' not found for endpoint '2000' (A.B.C.D:5060)
When setting up another SIP server setting the contact parameter on the type=aor, it works correctly, so it seems to fail when there is no contact set and a registration is required.
I’m thinking on ways to work around this limitation on PJSIP, as creating one table for every type. I want to avoid the dynamic realtime option, because Asterisk may fail because the database connection was lost for a few moments, this is especially bad with dynamic realtime transports.
Is this AOR issue a known limitation or it is a bug, considering the auth with different name works correctly?
If this isn’t possible to fix, is one table for every type the proper way to use static realtime with PJSIP?

Tested on Asterisk 18.17 and 20.1.0

2

It’s a bit late, and I’ve only read this quickly. Also, the documentation is weak on non-degenerate case. However, my understanding is that the type=aor section name is the user part of the address of record, as defined by RFC 3261, so if you want to register against 2000-aor, your REGISTER To header would need to be:

To: <2000-aor@domain.example>

I think you misunderstand the data model.

If the registrant were also chan_pjsip, its client URI field would be: sip:2000-aor@domain.example

3

David is correct regarding the To header and the matching of the AOR. It’s how SIP inbound registration works.

4

What was unexpected to me was that the section name of the aor section is the user part of the address, I thought it would use the endpoint data, as it’s possible to set multiple aors in the endpoint settings.

I tested the idea of creating different tables for every PJSIP section, so having one table for endpoint, another for aor and so on. This way, I managed to make static realtime work, as long as I set the #include on the pjsip.conf file.

Considering this, it’s not possible to use static realtime with PJSIP using only one table for the configuration?

5

Endpoint data restricts what AORs it can register to. It doesn’t dictate WHICH AOR a REGISTER uses. The incoming REGISTER request does that. A REGISTER is “Add this Contact to this AOR”.

As for using the same table, probably not since the category names would overlap.

6

You can use the same section name for different section types. E.g your endpoint, aor and auth section types can all be named [2000].

What about putting a contact= line in the aor section? Doesn’t that override whatever the SIP peer tries to specify?

7

I’m not sure if you are allowed both contact and max_contacts, but if not, you won’t be allowed to register, and if you are, the dynamic contacts will be added to the static ones. Remember that registration is not intended as a means of authentication, but rather as a means of providing an, otherwise unknown, contact address.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.