Non-symmetrical behavior of pjsip.conf to database; not registering correctly with database


So I took a working configuration and went to replicate it in the database that I just connected with ODBC. I went for an exact match to the working configuration, which I will post here for comparison:

callerid=Test <53998>



insert into ps_endpoints (id,aors,auth,context,disallow,allow,direct_media,trust_id_outbound,device_state_busy_at,dtmf_mode,callerid) values (53998,53998,53998,‘Test802’,‘all’,‘ulaw’,‘yes’,‘yes’,1,‘rfc4733’,‘Test <53998>’);

insert into ps_auths (id,auth_type,password,username) values (53998,‘userpass’,‘unsecurepassword’,53998);

insert into ps_aors (id,max_contacts,mailboxes) values (53998,5,‘53998@example’);

So, I think that this should be an exact duplicate of the information in the working PBX. However, while the REGISTER messages appear to be identical between the working and non-working PBXs, the one with ODBC configured is not allowing the phones to register correctly. I am getting this behavior in the PBX logging, and my softphones never seem to log all the way in:

[Jan 25 17:27:26] ERROR[12250]: res_pjsip_registrar.c:637 register_aor_core: Unable to bind contact ‘sip:53998@[my_ip]:55887;rinstance=e9dd546c6c16966c’ to AOR ‘53998’

Can anyone point me in the right direction as to what might be causing this? My understanding was that if the database held the same values as the configuration file, it should work the same.

Thanks for the help.


Have you configured contacts to go to the ps_contacts table? Does it exist? What is the schema?


Hi jcolp,

Thanks for the reply. I created this based on the documentation Setting up PJSIP Realtime, and this process did yield a ps_contacts table and involves setting up the extconfig.conf file with the following line:

ps_contacts => odbc,asterisk

I am not sure if there is more to configuring Asterisk to use the ps_contacts table than this step.

Right now, my extconfig.conf file looks like this:

;iaxusers => odbc,asterisk
;iaxpeers => odbc,asterisk
;sippeers => odbc,asterisk
;sipregs => odbc,asterisk ; (avoid sipregs if possible, e.g. by using a view)
ps_endpoints => odbc,asterisk
ps_auths => odbc,asterisk
ps_aors => odbc,asterisk
ps_domain_aliases => odbc,asterisk
ps_endpoint_id_ips => odbc,asterisk
ps_contacts => odbc, asterisk
ps_outbound_publishes => odbc,asterisk
ps_inbound_publications = odbc,asterisk
ps_asterisk_publications = odbc,asterisk
;voicemail => odbc,asterisk
;extensions => odbc,asterisk
;meetme => mysql,general
;queues => odbc,asterisk
;queue_members => odbc,asterisk
;queue_rules => odbc,asterisk
;acls => odbc,asterisk
;musiconhold => mysql,general
;queue_log => mysql,general

Regarding the schema, are you looking for the list of tables?

| Tables_in_asterisk |
| alembic_version_config |
| extensions |
| iaxfriends |
| meetme |
| musiconhold |
| ps_aors |
| ps_asterisk_publications |
| ps_auths |
| ps_contacts |
| ps_domain_aliases |
| ps_endpoint_id_ips |
| ps_endpoints |
| ps_globals |
| ps_inbound_publications |
| ps_outbound_publishes |
| ps_registrations |
| ps_resource_list |
| ps_subscription_persistence |
| ps_systems |
| ps_transports |
| queue_members |
| queue_rules |
| queues |
| sippeers |
| voicemail |

Thanks again!


I also did a few days ago real-time configuration, so I am noticing you have not mentioned transport field in your database, not sure if its effect but I think it should be included as it is in my database and also in sample configuration.

insert into ps_endpoints (id,aors,auth,context,disallow,allow,direct_media,trust_id_outbound,
 values (53998,53998,53998,‘Test802’,‘all’,‘ulaw’,‘yes’,‘yes’,1,‘rfc4733’,‘Test &lt;53998&gt;’);

should be

insert into ps_endpoints (id,transport,aors,auth,context,disallow,allow,direct_media,trust_id_outbound,
 values (53998,transport-udp,53998,53998,‘Test802’,‘all’,‘ulaw’,‘yes’,‘yes’,1,‘rfc4733’,‘Test &lt;53998&gt;’);

As in the sample configuration it is included here is reference from it.

insert into ps_endpoints (id, transport, aors, auth, context, 
disallow, allow, direct_media) 
values (101, 'transport-udp', '101', '101', 'testing', 'all', 'g722', 'no');

Just try may be it will work, transport-udp is usually on the top of your PJSIP.conf file.


Hi Kamal, thanks for the quick response. I actually did have the transport in there initially, but then I removed it to make it identical to my working pjsip.conf configuration. I don’t see that a default value is listed in the Asterisk 13 Configuration_res_pjsip documentation for the transport option, but it does appear that it defaults to UDP if nothing is specified.

I find this issue particularly perplexing because the signaling of the REGISTER flow is identical to the working example (except the obvious differences like tags, etc.) Looking at the signaling alone, the phone appears to register successfully. It’s clear that Asterisk recognizes that the URI belongs to the endpoint as it matches it to the correct AOR. It seems that the problem is with Asterisk being able to update its Contact database. I’m looking for more documentation on this bit, but unfortunately I haven’t found anything except the guide that you and I have referenced so far.

Thanks again for your help.


You may try enabling debug in logger.conf and then doing “core set debug 9” on the console. That should provide more ODBC information. What is your backend database?


Will do, thanks. It is mysql.


Unfortunately, there’s nothing new with this logging. Is there anywhere else that you can think of that might have some useful logging?


I got it in the end. I didn’t have the debug set up properly to give me the full logs initally. Once I got it set correctly, I saw that the issue was an extra space in the following line:

ps_contacts => odbc, asterisk

The space before ‘asterisk’ was causing the following error:

[Jan 28 20:59:09] DEBUG[10774]: res_odbc.c:813 _ast_odbc_request_obj2: Class ’ asterisk’ not found!

On the bright side, I’m now getting the real debug logging now for whenever I have an issue.

Thanks again for the pointers.