No AMI ContactStatus events for newly created PJSIP clients

Hello everyone,

We are using the AMI for obtaining information about contact statuses from an Asterisk server in a third party application that we are developing. So far, this works fine, however, we noticed that sometimes, no ContactStatus events will be sent.

After some digging, it turned out that the AMI only emits ContactStatus events for contacts that already existed when we started the Asterisk service. New contacts that have been added later do not emit any ContactStatus events, despite working flawlessly and outputting in the console (asterisk -rvvvv)

Is this a bug? Or can anyone point me to a potential configuration issue?


This is an example when registering/unregistering from a client that has been added after Asterisk has been started:


Output of the console:

-- Removed contact 'sips:74@ip:61406;transport=TLS;ob' from AOR '74' due to shutdown
-- Added contact 'sips:74@ip;transport=TLS;ob' to AOR '74' with expiration of 120 second

Output of AMI:

[nothing]

However, after we restart asterisk or reload pjsip using pjsip reload


Output of the console:

-- Removed contact 'sips:74@ip:61406;transport=TLS;ob' from AOR '74' due to shutdown
-- Added contact 'sips:74@ip;transport=TLS;ob' to AOR '74' with expiration of 120 second

Output of AMI:

Event: ContactStatus
Privilege: system,all
SystemName: asterisk-238
URI: sips:74@ip:61640;transport=TLS;ob
ContactStatus: Removed
AOR: 74
EndpointName: 74
RoundtripUsec: 0

[...]

Event: ContactStatus
Privilege: system,all
SystemName: asterisk-238
URI: sips:74@ip:61653;transport=TLS;ob
ContactStatus: NonQualified
AOR: 74
EndpointName: 74
RoundtripUsec: 0

So as you can see, the AMI works as expected but only after reloading PJSIP, which is not an option to do constantly in production.

Where is configuration being stored? Are you using realtime? If so then Asterisk has to be told about the AOR using the “pjsip reload qualify aor” or “pjsip reload qualify endpoint” CLI commands, which can be done over AMI. Trying to do this automatically proved to be disastrous to performance.

1 Like

Thanks for the fast reply! Yes, we are using realtime and this did indeed seem to be the issue.

The commands you provided work. Sending them via AMI as following also works :+1:

Action: Command
ActionID: reloadme
Command: pjsip reload qualify aor 74

For completion for anyone searching for this, our realtime setup:

/etc/asterisk/extconfig.conf

[settings]
ps_endpoints => odbc,asterisk,telephony_endpoints
ps_auths => odbc,asterisk,telephony_credentials
ps_aors => odbc,asterisk,telephony_leases

/etc/asterisk/sorcery.conf

[res_pjsip]
; Caching configured according to sample config in https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching
; No caching for auth as the user is able to change the Password anytime via WI.

endpoint/cache = memory_cache,object_lifetime_stale=1500,object_lifetime_maximum=1800,expire_on_reload=yes
endpoint=realtime,ps_endpoints

auth=realtime,ps_auths

aor/cache = memory_cache,object_lifetime_stale=1500,object_lifetime_maximum=1800,expire_on_reload=yes
aor=realtime,ps_aors

;contact/cache = memory_cache,object_lifetime_stale=600,object_lifetime_maximum=1800,expire_on_reload=yes,full_backend_cache=yes

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